mac80211/iwl4965: ad-hoc broken in 2.6.25-rc1

DISCUSSION Richard Scherping 3 participants 15 messages Feb 12, 2008 – Feb 17, 2008 Networking drivers (wireless)

lore

Share & tools

lore

Richard Scherping

author

2008-02-12 19:31 UTC #0 lore raw

Hello list!

Sorry for this slightly off-topic post (as I have not tried the latest wirless-dev git version)...

When trying to set up an ad-hoc interface on iwl4965 (version 1.2.23 according to modinfo) on recently released kernel 2.6.25-rc1 it seems to work at first glance (accepts setting of channel and essid, starts beaconing and receives frames just fine) but the TX part does not work at all. Frames are shown in "tcpdump -i wlan0" but never make it into the air (checked with dedicated machine equipped with an Atheros card running in monitor mode). With 2.6.24 (iwl4965 version 1.1.17) everything worked fine. System is Debian Lenny amd64 on a Thinkpad T61p.

Unfortunately I do not have the time to debug this intensively, so any hints what to check first are welcome! Did something with the last big API change in mac80211 went wrong?

Richard

Chatre, Reinette

2008-02-12 22:01 UTC #1 lore raw

Quoted 15 lines · Richard Scherping

Hello list!
Sorry for this slightly off-topic post (as I have not tried the latest wirless-dev git version)...
When trying to set up an ad-hoc interface on iwl4965 (version 1.2.23 according to modinfo) on recently released kernel 2.6.25-rc1 it seems to work at first glance (accepts setting of channel and essid, starts beaconing and receives frames just fine) but the TX part does not work at all. Frames are shown in "tcpdump -i wlan0" but never make it into the air (checked with dedicated machine equipped with an Atheros card running in monitor mode). With 2.6.24 (iwl4965 version 1.1.17) everything worked fine. System is Debian Lenny amd64 on a Thinkpad T61p.

Quoted 3 lines

Unfortunately I do not have the time to debug this intensively, so any hints what to check first are welcome! Did something with the last big API change in mac80211 went wrong?

We have not done ad-hoc testing in the recent code. Any debugging you can do will be greatly appreciated (anything interesting in your logs?). Just to confirm the monitor mode is ok, can you confirm that your monitoring machine can see data between a host and AP? We have seen some problems with monitoring in iwlwifi so I would like to make sure.

Please load the driver with debugging (debug=0x43fff) and send us what you see during data transmission. It may be useful to open a bug at bughost.org at this point for us to keep track of the problem.

Thanks!

Reinette

Richard Scherping

author

2008-02-12 23:06 UTC #2 lore raw

Quoted 5 lines · Reinette

We have not done ad-hoc testing in the recent code. Any debugging you can do will be greatly appreciated (anything interesting in your logs?). Just to confirm the monitor mode is ok, can you confirm that your monitoring machine can see data between a host and AP? We have seen some problems with monitoring in iwlwifi so I would like to make sure.

The monitoring (as well as the counterpart for ad-hoc operation) was done with madwifi 0.9.3.3 on a different machine with kernel 2.6.22 - a setup that has proven to work for me already.

Quoted 3 lines

Please load the driver with debugging (debug=0x43fff) and send us what you see during data transmission. It may be useful to open a bug at bughost.org at this point for us to keep track of the problem.

Looking at the debugging output helped a bit:

Feb 12 23:27:37 merom kernel: iwl4965: I iwl4965_mac_tx enter
Feb 12 23:27:37 merom kernel: iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated
Feb 12 23:27:37 merom kernel: iwl4965: I iwl4965_mac_tx leave

I changed that output to be more verbose:

iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated: iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1

This is in line with the following output:

Feb 12 23:44:08 merom kernel: iwl4965: U iwl4965_bg_post_associate Associated as 0 to: 2a:20:22:f0:4f:f0

The full log is available at http://www.scherping.de/misc/iwl4965-2625rc1.txt
What I did is:

merom:/home/richard# uname -a
Linux merom 2.6.25-rc1 #1 SMP Mon Feb 11 08:18:47 CET 2008 x86_64 GNU/Linux
merom:/home/richard# modprobe iwl4965 debug=0x43fff
merom:/home/richard# iwconfig wlan0 mode ad-hoc
merom:/home/richard# ifconfig wlan0 10.0.0.1 up
merom:/home/richard# iwconfig wlan0 channel 1
merom:/home/richard# iwconfig wlan0 essid test
merom:/home/richard# iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"test"  
         Mode:Ad-Hoc  Frequency:2.412 GHz  Cell: 2A:20:22:F0:4F:F0   
         Tx-Power=27 dBm   
         Retry min limit:7   RTS thr:off   Fragment thr=2352 B   
         Encryption key:off
         Link Quality:0  Signal level:0  Noise level:0
         Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
         Tx excessive retries:0  Invalid misc:0   Missed beacon:0

merom:/home/richard# ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.

Quoted 3 lines

From 10.0.0.1 icmp_seq=1 Destination Host Unreachable From 10.0.0.1 icmp_seq=2 Destination Host Unreachable From 10.0.0.1 icmp_seq=3 Destination Host Unreachable

^C
--- 10.0.0.2 ping statistics ---
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4016ms , pipe 3
merom:/home/richard#

The same thing worked with 2.6.24 - 10.0.0.2 is the other ad-hoc station (MadWifi-based).

Thanks for your help!

Richard

Richard Scherping

author

2008-02-13 09:07 UTC #3 lore raw

Quoted 1 line

iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated: iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1

Simply uncommenting the check for priv->assoc_id to be non-zero (line 2938 in iwl4965-base.c) made ad-hoc working. Thanks for helping me to find this! Does this change have any negative side effects?

Richard

Chatre, Reinette

2008-02-13 22:26 UTC #4 lore raw

Quoted 10 lines · Richard Scherping

Quoted 3 lines
iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1
Simply uncommenting the check for priv->assoc_id to be non-zero (line 2938 in iwl4965-base.c) made ad-hoc working. Thanks for helping me to find this!
Does this change have any negative side effects?
Richard

Could you please try the attached patch instead?

Thanks

Reinette

From 1c17f7c2da3e381dad309f612dbf56db1e4d868f Mon Sep 17 00:00:00 2001
From: Reinette Chatre <[email protected]>
Date: Wed, 13 Feb 2008 14:17:40 -0800
Subject: [PATCH] iwlwifi: only check for association id when associating with AP

There is no association process in IBSS mode - so testing the association id is not needed.

Signed-off-by Reinette Chatre <[email protected]>

---
 drivers/net/wireless/iwlwifi/iwl3945-base.c |    3 ++-
 drivers/net/wireless/iwlwifi/iwl4965-base.c |    2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

drivers/net/wireless/iwlwifi/iwl3945-base.c +2 -1

index c0d99ca..6b5b6de 100644
@@ -2806,7 +2806,8 @@ static int iwl3945_tx_skb(struct iwl3945_priv *priv,
 #endif
 
 	/* drop all data frame if we are not associated */
-	if ((!iwl3945_is_associated(priv) || !priv->assoc_id) &&
+	if ((!iwl3945_is_associated(priv) ||
+	     ((priv->iw_mode == IEEE80211_IF_TYPE_STA) && !priv->assoc_id)) &&
 	    ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)) {
 		IWL_DEBUG_DROP("Dropping - !iwl3945_is_associated\n");
 		goto drop_unlock;

drivers/net/wireless/iwlwifi/iwl4965-base.c +1 -1

index 3fa0bb4..ca03a9b 100644
@@ -2932,7 +2932,7 @@ static int iwl4965_tx_skb(struct iwl4965_priv *priv,
 	/* drop all data frame if we are not associated */
 	if (((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA) &&
 	   (!iwl4965_is_associated(priv) ||
-	    !priv->assoc_id ||
+	    ((priv->iw_mode == IEEE80211_IF_TYPE_STA) && !priv->assoc_id) ||
 	    !priv->assoc_station_added)) {
 		IWL_DEBUG_DROP("Dropping - !iwl4965_is_associated\n");
 		goto drop_unlock;

Signature · 1 line

1.5.3.4

Richard Scherping

author

2008-02-14 18:27 UTC #5 lore raw

Quoted 5 lines · Reinette

Quoted 3 lines · Richard Scherping
Quoted 3 lines
iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1

Quoted 8 lines

Quoted 6 lines
Simply uncommenting the check for priv->assoc_id to be non-zero (line 2938 in iwl4965-base.c) made ad-hoc working. Thanks for helping me to find this!
Does this change have any negative side effects?
Richard
Could you please try the attached patch instead?

Works for me (iwl4965). Thanks!

Richard

Patrick Grimm

2008-02-15 00:18 UTC #6 lore raw

Am Donnerstag, 14. Februar 2008 19:26:54 schrieb Richard Scherping:

Quoted 11 lines

Quoted 10 lines · Reinette
Quoted 9 lines · Richard Scherping
Quoted 3 lines
iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1
Simply uncommenting the check for priv->assoc_id to be non-zero (line 2938 in iwl4965-base.c) made ad-hoc working. Thanks for helping me to find this!
Does this change have any negative side effects?

Quoted 5 lines

Quoted 3 lines
Quoted 1 line
Richard
Could you please try the attached patch instead?
Works for me (iwl4965). Thanks!

For me not.
I use 3945ABG card in an ad-hoc network with 4 other wlan devices like rt2500 and ath5k.
I have applied your 0001-iwlwifi-only-check-for-association-id-when-associat.patch patch. But i can't see incoming packets witch tcpdump. I have try to commet out the check for associat with the same result.

dmesg
iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_mac_tx enter
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
iwl3945: I iwl3945_mac_tx leave
iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b

Patrick

Chatre, Reinette

2008-02-14 23:58 UTC #7 lore raw

Quoted 24 lines · Patrick Grimm

Am Donnerstag, 14. Februar 2008 19:26:54 schrieb Richard Scherping:
Quoted 11 lines
Quoted 10 lines · Reinette
Quoted 9 lines · Richard Scherping
Quoted 3 lines
iwl4965: I iwl4965_tx_skb Dropping - !iwl4965_is_associated:
iwl4965_is_associated(priv)=1; priv->assoc_id=0; priv->assoc_station_added=1
Simply uncommenting the check for priv->assoc_id to be non-zero (line 2938 in iwl4965-base.c) made ad-hoc working. Thanks for helping me to find this!
Does this change have any negative side effects?
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Richard
Could you please try the attached patch instead?
Works for me (iwl4965). Thanks!
For me not.
I use 3945ABG card in an ad-hoc network with 4 other wlan devices like rt2500 and ath5k. I have applied your 0001-iwlwifi-only-check-for-association-id-when-associat.patch patch. But i can't see incoming packets witch tcpdump.
I have try to commet out the check for associat with the same result.

Quoted 8 lines

dmesg
iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_mac_tx enter
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
iwl3945: I iwl3945_mac_tx leave
iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b

When you say "with the same result" does it mean that you comment out the check for priv->assoc_id and you still see the error "Dropping - !iwl3945_is_associated" or do you then see traffic with tcpdump?

Could you please print out the values of fc, priv->iw_mode, iwl3945_is_associated(priv) and priv->assoc_id just before that error message is printed?

Thanks!

Reinette

Chatre, Reinette

2008-02-15 00:23 UTC #8 lore raw

Quoted 19 lines · Reinette

Quoted 8 lines · Patrick Grimm
For me not.
I use 3945ABG card in an ad-hoc network with 4 other wlan devices like rt2500 and ath5k. I have applied your 0001-iwlwifi-only-check-for-association-id-when-associat.patch patch. But i can't see incoming packets witch tcpdump. I have try to commet out the check for associat with the same result.
Quoted 8 lines
dmesg
iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_mac_tx enter
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
iwl3945: I iwl3945_mac_tx leave
iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b

Quoted 7 lines

When you say "with the same result" does it mean that you comment out the check for priv->assoc_id and you still see the error "Dropping - !iwl3945_is_associated" or do you then see traffic with tcpdump?
Could you please print out the values of fc, priv->iw_mode, iwl3945_is_associated(priv) and priv->assoc_id just before that error message is printed?

One more question ... did ad-hoc work for you before this patch?

Thanks

Reinette

Patrick Grimm

2008-02-15 02:05 UTC #9 lore raw

Am Freitag, 15. Februar 2008 01:21:15 schrieb Chatre, Reinette:

Quoted 19 lines · Reinette

Quoted 18 lines · Patrick Grimm
Quoted 16 lines
For me not.
I use 3945ABG card in an ad-hoc network with 4 other wlan devices like rt2500 and ath5k. I have applied your 0001-iwlwifi-only-check-for-association-id-when-associat.patch patch. But i can't see incoming packets witch tcpdump. I have try to commet out the check for associat with the same result.
dmesg
iwl3945: I iwl3945_rx_handle r = 76, i = 75, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 77, i = 76, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_mac_tx enter
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated
iwl3945: I iwl3945_mac_tx leave
iwl3945: I iwl3945_rx_handle r = 78, i = 77, REPLY_3945_RX, 0x1b
iwl3945: I iwl3945_rx_handle r = 79, i = 78, REPLY_3945_RX, 0x1b

Quoted 3 lines

Quoted 3 lines
When you say "with the same result" does it mean that you comment out the check for priv->assoc_id and you still see the error "Dropping - !iwl3945_is_associated" or do you then see traffic with tcpdump?

I mean that I don't see traffic with tcpdump and I don't see the Dropping error.

Quoted 4 lines

Quoted 4 lines
Could you please print out the values of fc, priv->iw_mode, iwl3945_is_associated(priv) and priv->assoc_id just before that error message is printed?

Yes
iwl3945: I iwl3945_tx_skb fc: 8<3>
iwl3945: I iwl3945_tx_skb mode: 2<3>
iwl3945: I iwl3945_tx_skb assoc_id: 0<3>
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated My changes

	IWL_DEBUG_DROP("fc: %d\n", fc);
	IWL_DEBUG_DROP("mode: %d\n", priv->iw_mode);
	IWL_DEBUG_DROP("assoc_id: %d\", priv->assoc_id);
	if ((!iwl3945_is_associated(priv) ||
	    ((priv->iw_mode == IEEE80211_IF_TYPE_STA) && !priv->assoc_id)) &&
	    ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)) {
		IWL_DEBUG_DROP("Dropping - !iwl3945_is_associated\n");
		goto drop_unlock;
	}

Was it right?

Quoted 2 lines

One more question ... did ad-hoc work for you before this patch?

No. In my tests only ipw3945 works in Ad-Hoc mode.

Chatre, Reinette

2008-02-15 16:42 UTC #10 lore raw

Quoted 10 lines · Patrick Grimm

Quoted 3 lines
Quoted 3 lines
Could you please print out the values of fc, priv->iw_mode, iwl3945_is_associated(priv) and priv->assoc_id just before that error message is printed?
Yes
iwl3945: I iwl3945_tx_skb fc: 8<3>
iwl3945: I iwl3945_tx_skb mode: 2<3>
iwl3945: I iwl3945_tx_skb assoc_id: 0<3>
iwl3945: I iwl3945_tx_skb Dropping - !iwl3945_is_associated My changes

Quoted 8 lines

	IWL_DEBUG_DROP("fc: %d\n", fc);
	IWL_DEBUG_DROP("mode: %d\n", priv->iw_mode);
	IWL_DEBUG_DROP("assoc_id: %d\", priv->assoc_id);
	if ((!iwl3945_is_associated(priv) ||
	    ((priv->iw_mode == IEEE80211_IF_TYPE_STA) &&
!priv->assoc_id)) &&
	    ((fc & IEEE80211_FCTL_FTYPE) == IEEE80211_FTYPE_DATA)) {
		IWL_DEBUG_DROP("Dropping - !iwl3945_is_associated\n");

goto

Quoted 2 lines

	drop_unlock; }
Was it right?

great - thanks!

I think you have given us hints about why ad-hoc does not work in iwl3945. From the above the device thinks it is in STA mode, it should be in IBSS mode. This is thus a different bug from what the patch is trying to solve. The patch is still good for iwl3945.

Quoted 3 lines

Quoted 1 line
One more question ... did ad-hoc work for you before this patch?
No. In my tests only ipw3945 works in Ad-Hoc mode.

ok - that explains things. The patch assumes that ad-hoc mode is working, which is unfortunately not the case. We have to fix this.

Reinette

Richard Scherping

author

2008-02-15 21:12 UTC #11 lore raw

Quoted 7 lines · Reinette

Quoted 2 lines
Quoted 1 line
One more question ... did ad-hoc work for you before this patch?
No. In my tests only ipw3945 works in Ad-Hoc mode.
ok - that explains things. The patch assumes that ad-hoc mode is working, which is unfortunately not the case. We have to fix this.
Reinette

As I said, I have tested with iwl4965 only. Seems as if there are more problems with ad-hoc and iwl3945. Did ad-hoc work in the "old" iwl3945 (before the API change with old version 1.1.17, compared to new version 1.2.23/26)?

Richard

Chatre, Reinette

2008-02-15 21:29 UTC #12 lore raw

Quoted 11 lines · Richard Scherping

Quoted 7 lines · Reinette
Quoted 2 lines
Quoted 1 line
One more question ... did ad-hoc work for you before this patch?
No. In my tests only ipw3945 works in Ad-Hoc mode.
ok - that explains things. The patch assumes that ad-hoc mode is working, which is unfortunately not the case. We have to fix this.
Reinette
As I said, I have tested with iwl4965 only. Seems as if there are more problems with ad-hoc and iwl3945.

I understand. Thanks for your testing. There indeed appears to be more problems with ad-hoc and iwl3945, but they are unrelated to the patch that you tested.

Quoted 2 lines

Did ad-hoc work in the "old" iwl3945 (before the API change with old version 1.1.17, compared to new version 1.2.23/26)?

This needs to be checked. We do have some bug reports about ad-hoc mode in iwl3945 (see http://www.bughost.org/bugzilla/show_bug.cgi?id=1472).
In this case it was specific to ad-hoc mode in b mode. We will look more into ad-hoc mode with iwl3945.

Reinette

Patrick Grimm

2008-02-16 13:00 UTC #13 lore raw

In reply to Richard Scherping

Am Freitag, 15. Februar 2008 22:12:36 schrieb Richard Scherping:

Quoted 8 lines

Quoted 7 lines · Reinette
Quoted 3 lines
Quoted 1 line
One more question ... did ad-hoc work for you before this patch?
No. In my tests only ipw3945 works in Ad-Hoc mode.
ok - that explains things. The patch assumes that ad-hoc mode is working, which is unfortunately not the case. We have to fix this.

Quoted 6 lines

Quoted 1 line
Reinette
As I said, I have tested with iwl4965 only. Seems as if there are more problems with ad-hoc and iwl3945. Did ad-hoc work in the "old" iwl3945 (before the API change with old version 1.1.17, compared to new version 1.2.23/26)?

I have made some short tests with my working kernel 2.6.23. Version 1.1.17 - 1.1.22 Ad-Hoc mode is working.
Version 1.1.23 - Ad-Hoc mode is not working.

Changes in 1.2.23

* fix problem when rf_kill switch change during suspend/resume
* fix possible priv->mutex deadlock during suspend
* 3954 renames iwl3945_rate_scale_priv to iwl3945_rs_sta
* 4965 unify rate scale variable names for station data
* move uCode helper functions to iwl-helpers.h
* Makefile: enable building using "make -C /path/to/iwlwifi"
* fix iwl_mac_add_interface handler
* Fix race conditional panic
* remove redundant declaration of 'iwl3945_priv' and 'iwl4965_priv' structs
* document scan command
* remove iwl4965_tx_cmd
* move iwl4965_get_dma_hi_address function to iwl-helpers.h
* fix rate control algo reference leak
* fix rf_kill state inconsistent during suspend and resume
* fix priv->ucode_data_backup save problem
* iwl4965: fix mutex_unlock missed problem in iwl_mac_config exit path
* iwl4965: Remove redundant code in iwl4965_tx_cmd
* fix compilation warnings
* use pci_save_state() before calling pci_disable_device()
* skip mac80211 conf during a hardware scan and replay it afterwards
* delay firmware loading from pci_probe to network interface open
* Makefile: enable HT and HT_AGG by default

Patrick

Patrick Grimm

2008-02-17 21:37 UTC #14 lore raw

Am Samstag, 16. Februar 2008 01:19:07 schrieb Patrick Grimm:

Quoted 9 lines

Am Freitag, 15. Februar 2008 22:12:36 schrieb Richard Scherping:
Quoted 8 lines
Quoted 7 lines · Reinette
Quoted 3 lines
Quoted 1 line
One more question ... did ad-hoc work for you before this patch?
No. In my tests only ipw3945 works in Ad-Hoc mode.
ok - that explains things. The patch assumes that ad-hoc mode is working, which is unfortunately not the case. We have to fix this.

Quoted 8 lines

Quoted 6 lines
Quoted 1 line
Reinette
As I said, I have tested with iwl4965 only. Seems as if there are more problems with ad-hoc and iwl3945. Did ad-hoc work in the "old" iwl3945 (before the API change with old version 1.1.17, compared to new version 1.2.23/26)?
I have made some short tests with my working kernel 2.6.23.

With 2 Ad-Hoc Nodes.

Quoted 2 lines

Version 1.1.17 - 1.1.22 Ad-Hoc mode is working.
Version 1.1.23 - Ad-Hoc mode is not working.

The iwlwifi versions 1.1.17 - everything is not working with more then 2 Ad-Hoc Nodes.

Please keep me updated I will test your patches again.

Patrick