Bugzilla – Bug 1689
iwl3945, ad-hoc mode not working
Last modified: 2008-12-08 22:52:27
You need to log in before you can comment on or make changes to this bug.
I've been trying to set up an ad-hoc network with iwl3945, but without any success. I've seen that this has been reported here before as bug id=1606. However, I'm not allowed to read this bug, even when logged in. Shall I repost debugging information here / is there a particular reason why http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1606 is not accessible?
(In reply to comment #0) > http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1606 is not > accessible? I can access it. You can enter your bug report here anyway. Please provide the steps how you create/join the ad-hoc network. Please attach dmesg from both sides.
Eugene hidden that bug, maybe by accident. I already send an email for it.
Mehnert, #1606 is about TX and rf_kill, are sure it's relevant to ad-hoc mode on 3945?
what version are you using? iwl4965 ever had ad-hoc issue on snapshot 05232008, but it's fixed in snapshot 06122008. Would you try this version? or try with following patch http://www.intellinuxwireless.org/bugzilla/attachment.cgi?id=1457
Thanks for the replies. I'll test that as soon as I' back in a situation to set up an ad-hoc net - which will be in about two weeks.
Change to Needmoredata
I, too, have been having problems with ad-hoc mode when using the iwl driver, along with a lot of other problems that I didn't previously have with the ipw driver. I'm using iwlwifi 1.2.25 (from the linux-backports-modules-2.6.24-19.17 package in Ubuntu Hardy) on a 3945 card. To configure ad-hoc mode, I do: 'iwconfig eth1 mode ad-hoc' 'ifconfig eth1 up' 'iwconfig eth1 essid mynet' 'iwlist eth1 scan' shows the other machine I'm trying to connect to: Cell 02 - Address: 02:0C:F1:FF:F9:FC ESSID:"mynet" Mode:Ad-Hoc Channel:10 Frequency:2.457 GHz (Channel 10) Quality=96/100 Signal level=-30 dBm Noise level=-83 dBm Encryption key:off Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s Extra:tsf=000000009d8cc5c5 'iwconfig eth1' also shows that I've joined the cell created by the other machine: eth1 IEEE 802.11g ESSID:"mynet" Nickname:"" Mode:Ad-Hoc Frequency:2.457 GHz Cell: 02:0C:F1:FF:F9:FC___ Tx-Power=27 dBm___ Retry min limit:7 RTS thr:off Fragment thr=2346 B___ Encryption key:off Power Management: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 However, it shows 0 signal, and if I look on the other machine, the other machine also shows 0 signal, and it does not show any evidence of another machine having joined it's cell.
Some of the other odd problems I've been having: If I do 'iwconfig eth1 mode ad-hoc' after doing 'ifconfig eth1 up', it gives me an error: Error for wireless request "Set Mode" (8B06) : SET failed on device eth1 ; Device or resource busy. In managed mode... If I don't do 'ifconfig eth1 up' before doing 'iwconfig eth1 essid <whatever>', the card will not actually associate with an access point (but it does not return any error). However, if I don't do 'ifconfig eth1 up' first, 'iwlist eth1 scan' does return an error: eth1 Interface doesn't support scanning : Network is down After running 'ifconfig eth1 up', if I do 'iwconfig eth1 essid any', the card will not associate to any available access point - I have to explicitly specify a valid essid or the card will not associate. If I run 'iwconfig eth1 essid myap' while my access point is out of range, then I walk within range of my access point, the card will not automatically associate with it - I have to explicitly run 'iwconfig eth1 essid myap' again to get it to associate. If I associate with my access point, then walk out of range of my access point, then return within range (or turn on my radio kill switch, then turn it back off again), the card will not automatically reassociate - I have to explicitly run 'iwconfig eth1 essid myap' again to get it to reassociate. If my association times out for any reason, my card will not automatically attempt to reassociate (this happens fairly commonly when I have a weak signal): eth1: Initial auth_alg=0 eth1: authenticate with AP 00:13:10:bc:b9:c0 eth1: RX authentication from 00:13:10:bc:b9:c0 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:13:10:bc:b9:c0 eth1: authentication frame received from 00:13:10:bc:b9:c0, but not in authenticate state - ignored eth1: associate with AP 00:13:10:bc:b9:c0 eth1: associate with AP 00:13:10:bc:b9:c0 eth1: association with AP 00:13:10:bc:b9:c0 timed out If I run 'ifconfig eth1 hw ether 00DEADBEEF00' to change my card's mac address before bringing up the interface or attempting to associate to an AP, the card will not associate with any access points (but no errors are given). This worked fine with the ipw drivers, however. And finally, if I attempt to associate with a Cisco Aironet 340 or 350 access point (using either an older v10 VxWorks firmware, or the latest v12.0 VxWorks firmware), the access point will hang. The wired network interface continues to respond, and the admin interface of the AP works fine, but it appears that the wireless hardware in the AP completely locks up (other users already associated to the access point will be kicked off, the AP will stop sending beacons, and the admin interface on the AP shows no incoming data from wireless). Cisco Aironet 1100/1200 series access points work fine. I have not tried a Cisco Aironet 350 AP running IOS firmware (I tried updating one of my APs from VxWorks to IOS to test this, and I managed to permanently kill the access point, so I'm not going to try that again). Aironet 340/350 access points had no problems with the ipw driver.
I can confirm that I saw this issue since moving to ubuntu hardy (moved from ipw to iwl). I have 2 laptops, 1 with 4965 and the other one with 3945 and both could not connect to ad-hoc anymore (or barely after rmmod'ing and modprobe'ing, ifconfig up/down, iwconfig). I used to have the : Error for wireless request "Set Mode" (8B06) : SET failed on device eth1 ; Device or resource busy. issue too.
I am seeing the same issue on hardy haron. I use WMWifiRouter on my smart phone. It no longer works since my upgrade to hardy.
I've compiled/installed compat-wireless-2008-07-27 and uninstalled the linux-backports-modules-2.6.24-19.17 package (to avoid any conflicts). This helped, but I'm still having some problems. Once again, I'm doing: 'iwconfig eth1 mode ad-hoc' 'ifconfig eth1 up' 'iwconfig eth1 essid mynet' If I try to connect from another laptop (in this case, an Apple MacBook) to my ad-hoc network, it seems to associate: eth1 IEEE 802.11abg ESSID:"mynet"__ Mode:Ad-Hoc Frequency:2.412 GHz Cell: 22:69:0C:D3:C5:36___ Tx-Power=15 dBm___ Retry min limit:7 RTS thr:off Fragment thr=2352 B___ Encryption key:off Power Management: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 The following line shows up hundreds of times in 'dmesg' output, but doesn't seem to affect anything: eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 22:69:0c:d3:c5:3 After I configure IP addresses at each end, I can ping between the machines, but I see duplicate replies for about 1 out of every 10 packets. If I instead try to connect from an iPhone to my ad-hoc network, my laptop keyboard stops responding until the iPhone pops up an error message saying 'Could not connect to network'. After that, my laptop appears to think it has associated: eth1 IEEE 802.11abg ESSID:"mynet"__ Mode:Ad-Hoc Frequency:2.412 GHz Cell: EE:E4:43:C5:98:BA___ Tx-Power=15 dBm___ Retry min limit:7 RTS thr:off Fragment thr=2352 B___ Encryption key:off Power Management: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 But, of course, I can't pass any traffic, since the iPhone does not think it has associated. I also see a similar line in the 'dmesg' output, but it appears thousands rather than hundreds of times this time: eth1: beacon TSF higher than local TSF - IBSS merge with BSSID ee:e4:43:c5:98:ba
As for the other problems/unexpected behavior I was seeing: 'iwconfig eth1 mode ad-hoc' still will not work once 'ifconfig eth1 up' has been run (not a big deal, but the error message is not very helpful if you don't know why it is failing) 'iwlist eth1 scan' and 'iwconfig eth1 essid <whatever>' still do not work until after 'ifconfig eth1 up' has been run (but 'iwconfig eth1 essid <whatever>' does not return any error when run before 'ifconfig eth1 up' is run ... again, not a big deal, but it would be nice to have helpful error messages) 'iwconfig eth1 essid any' DOES appear to work now, and I CAN now walk out of range of access points or flip my radio kill switch and it WILL automatically reassociate without explicitly running 'iwconfig eth1 essid <whatever>' again. I am not seeing association/authentication timeouts like I used to (association or authentication previously would time out about one out of two or three times I tried to associate, but I don't believe I have seen any timeouts yet with the updated driver).
'ifconfig eth1 hw ether <whatever>' also now seems to work again when I run it before running 'ifconfig eth1 up' and 'iwconfig eth1 essid any'. I don't have a Cisco Aironet 340 or 350 access point handy at the moment to test that again. I will test it again next time I am near one.
After a number of associations today, I did end up seeing an authentication timeout: eth1: authenticate with AP 00:13:5f:55:19:1f eth1: authenticate with AP 00:13:5f:55:19:1f eth1: authenticate with AP 00:13:5f:55:19:1f eth1: authentication with AP 00:13:5f:55:19:1f timed out And when this happend, my card did not automatically try to reassociate or reauthenticate to either the same or another access point. I had to explicitly run 'iwconfig eth1 essid any' again to get it to try again.
To create an ibss network, you need: 1. ifconfig wlan0 down # You should down the network if you want to set mode 2. iwconfig wlan0 mode ad-hoc 3. ifconfig wlan0 up 4. iwconfig wlan0 channel <channel> 5. iwconfig wlan0 essid <essid> And could you please use the latest driver
I tried it again today using today's compat-wireless driver. This time I did: 'ifconfig eth1 down' 'iwconfig eth1 mode ad-hoc' 'ifconfig eth1 up' 'iwconfig eth1 channel 6' 'iwconfig eth1 essid mynet' I then configured another laptop (in this case, a Panasonic ToughBook) to join my ad-hoc network, and it associated. I still got tons of lines like this in the 'dmesg' output: eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 76:57:1d:c8:d4:d2 Then I did: 'ifconfig eth1 10.10.10.3' on my laptop and configured the other laptop with IP 10.10.10.2. I can ping between the machines, but this time I see about 10% packet loss (I previously saw about 10% duplicated packets). I then turned off the other laptop and configured my iPhone to join my ad-hoc network, and it associated. However, shortly after associating, my laptop keyboard stopped responding (my mouse still worked, however). I disassociated my iPhone, and my keyboard came back, so I ran 'ping 10.10.10.2' on my laptop, then reassociated my iPhone. My keyboard stopped working again, but the ping showed responses from the iPhone. However, after about 10 seconds, the iPhone reported that it was disconnected, my keyboard started working again, and dmesg showed the following: iwl3945: Microcode SW error detected. Restarting 0x82000008. iwl3945: Error Reply type 0x00000000 cmd REPLY_SCAN_CMD (0x80) seq 0x44FA ser 0x00000000 iwl3945: Can't stop Rx DMA. eth1: failed to restore operational channel after scan iwl3945: No space for Tx iwl3945: Error sending REPLY_TX_PWR_TABLE_CMD: iwl3945_enqueue_hcmd failed: -28
I've had this problem with iwl4965 since I installed Ubuntu Hardy. I have tried the compat-wireless package and the same issue remains. The version of my iwl4965 is 1.2.25 right now. I opened a thread in Ubuntuforums.org a while ago, even though nobody was able to solve the problem. http://ubuntuforums.org/showthread.php?t=838775&highlight=ad-hoc+4965
Created an attachment (id=1545) [details] Please try out this patch
If patch didn't work , Can you try loading the driver with 0x43fff and send me a dump log. e.g.modprobe iwl3945 debug=0x43fff
It looks like the compat-wireless project's nightly tarball hasn't been updated since 8/6/08: http://linuxwireless.org/download/compat-wireless-2.6/ I'll try to grab the latest drivers from git if I have the time, but for now, I've just applied this patch to the 8/6/08 compat-wireless tarball. Same behavior as before: ifconfig eth1 down modprobe -r iwl3945 modprobe iwl3945 debug=0x43fff iwconfig eth1 mode ad-hoc ifconfig eth1 up iwconfig eth1 channel 6 iwconfig eth1 essid mynet ifconfig eth1 10.10.10.3 ping 10.10.10.2 <Configure iPhone to associate to mynet and use ip 10.10.10.2> <ping begins to see responses, but keyboard on my laptop stops responding, and lots of packets are dropped> <Turn off WiFi on iPhone> <keyboard starts responding again> Here's the output in syslog, doesn't look particularly useful ... is the debug output going somewhere else? Sep 2 13:52:51 mooninite kernel: iwl3945: Intel(R) PRO/Wireless 3945ABG/BG Network Connection driver for Linux, 1.2.26k Sep 2 13:52:51 mooninite kernel: iwl3945: Copyright(c) 2003-2008 Intel Corporation Sep 2 13:52:51 mooninite kernel: ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 Sep 2 13:52:51 mooninite kernel: PCI: Setting latency timer of device 0000:05:00.0 to 64 Sep 2 13:52:51 mooninite kernel: iwl3945: Detected Intel Wireless WiFi Link 3945ABG Sep 2 13:52:51 mooninite kernel: iwl3945: Tunable channels: 11 802.11bg, 13 802.11a channels Sep 2 13:52:51 mooninite kernel: phy0: Selected rate control algorithm 'iwl-3945-rs' Sep 2 13:52:51 mooninite kernel: udev: renamed network interface wlan0 to eth1 Sep 2 13:53:01 mooninite kernel: ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 18 (level, low) -> IRQ 18 Sep 2 13:53:03 mooninite avahi-daemon[5217]: Registering new address record for fe80::213:2ff:fe9d:a8e1 on eth1.*. Sep 2 13:53:12 mooninite kernel: eth1: no IPv6 routers present Sep 2 13:53:15 mooninite avahi-daemon[5217]: Joining mDNS multicast group on interface eth1.IPv4 with address 10.10.10.3. Sep 2 13:53:15 mooninite avahi-daemon[5217]: New relevant interface eth1.IPv4 for mDNS. Sep 2 13:53:15 mooninite avahi-daemon[5217]: Registering new address record for 10.10.10.3 on eth1.IPv4. Sep 2 13:53:17 mooninite kernel: eth1: Creating new IBSS network, BSSID 0a:0d:5c:32:b9:68 Sep 2 13:53:47 mooninite kernel: eth1: No active IBSS STAs - trying to scan for other IBSS networks with same SSID (merge) Sep 2 13:54:02 mooninite kernel: eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 0a:0d:5c:32:b9:68 Sep 2 13:54:16 mooninite last message repeated 1160 times Sep 2 13:54:31 mooninite ntpd[5325]: Listening on interface #4 eth1, fe80::213:2ff:fe9d:a8e1#123 Enabled Sep 2 13:54:31 mooninite ntpd[5325]: Listening on interface #5 eth1, 10.10.10.3#123 Enabled On a somewhat related note, I have noticed that my keyboard also stops responding momentarily when reassociating to an access point that lost signal momentarily... Not sure what is causing the keyboard to stop responding, but I wonder if this behavior during a reassociation is related to the keyboard non-responsiveness in ad-hoc mode...
Please download the new compact package. Few patches have been submitted to this version for ad-hoc mode.
Sorry for the delay in response. I've been really busy the past two weeks. I've updated to compat-wireless-old-2008-09-25, and get the same results as I mentioned in comment #20 above ... looks like on average about 2 in 10 packets are dropped, and my laptop's keyboard will not respond as long as the iPhone is associated with my laptop (the mouse, however, does respond). Again, I don't see anything particularly interesting in the system logs, even when using 'modprobe iwl3945 debug=0x43fff': Sep 25 12:08:02 mooninite kernel: eth1: Trigger new scan to find an IBSS to join Sep 25 12:08:08 mooninite kernel: eth1: Trigger new scan to find an IBSS to join Sep 25 12:08:10 mooninite kernel: eth1: Creating new IBSS network, BSSID ce:8b:50:7e:96:44 Sep 25 12:08:13 mooninite kernel: eth1: no IPv6 routers present Sep 25 12:08:21 mooninite kernel: eth1: beacon TSF higher than local TSF - IBSS merge with BSSID ce:8b:50:7e:96:44
Fix has been submitted. Marking it as fixed for validation. http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1781
For those following along, the patch was committed to the iwlwifi git tree: http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=2c1a1f07695439fe1727dad6193dac2f8b96f791 But has not yet made it into the wireless-testing git tree...
It looks like the patch made it to the wireless-testing git tree on Oct 27: http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=2e9728a19111af60eb4244819f9374c055324d68 It will probably make it into kernel 2.6.28-rc3
Using today's compat-wireless driver with kernel 2.6.27, I put my card in ad-hoc mode: iwconfig eth1 mode ad-hoc ifconfig eth1 up iwconfig eth1 channel 6 iwconfig eth1 essid mynet ifconfig eth1 10.10.10.3 If I do a scan from another laptop (I tried two other laptops and my iPhone), no ad-hoc networks appear to be found, and if i manually configure the other laptop or iPhone to connect to an ad-hoc network named 'mynet', both my laptop and the other laptop/iPhone show 0 signal, and don't appear to associate with eachother at all.
Patch is submitted internally. Will be upstream soon.
It looks like this is the patch being referred to: http://git.kernel.org/?p=linux/kernel/git/iwlwifi/iwlwifi-2.6.git;a=commit;h=c12b222b32f02fbfaab76b354471791036dafb15 I'll test this once it makes it into compat-wireless.
This looks like it made it into today's compat-wireless tarball. It will probably make it into kernel 2.6.28-rc6
This latest update appears to work for me! I can now associate with my iPhone, my laptop's keyboard does not lock up, and I can pass traffic without dropping packets. Thanks!
Thanks Paul for quickly updating us. I am marking this bug as fixed. Reopen it if you see the issue.
Mark as Verified.