iwlwifi doesn't seem to ever want to associate with access points automatically; setting the access point and frequency manually seems to be able to get things working but the default case and with NetworkManager does not
James, have you investigate this at all? FWIW, I recall that Michael Wu had a theory about the cause, but I can't remember what it was ATM... :-(
BTW, this is a feature that has worked fine with ipw3945 for a while, so it's a regression relative to that code base.
With .3056, I can finally associate with non-encrypted access points: I am running on Thinkpad x60 with Intel 3945. All works fine with older ipw3945 driver and daemon. Also, I can associate with GoogleWifi (unencrypted access point) with iwlwifi and NM. Below is snipped from /var/log/messages: Apr 11 06:48:33 localhost NetworkManager: <WARN> nm_device_802_11_wireless_set_mode(): error setting card eth0 to Infrastructure mode: Device or resource busy Apr 11 06:48:34 localhost NetworkManager: <info> SWITCH: no current connection, found better connection 'eth0'. Apr 11 06:48:35 localhost dhcdbd: message_handler: message handler not found under /com/redhat/dhcp/eth0 for sub-path eth0.dbus.get.reason Apr 11 06:48:36 localhost NetworkManager: <info> Will activate connection 'eth0/free4all'. Apr 11 06:48:36 localhost NetworkManager: <info> Device eth0 activation scheduled... Apr 11 06:48:37 localhost NetworkManager: <info> Activation (eth0) started... Apr 11 06:48:38 localhost NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Apr 11 06:48:38 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:38 localhost NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started... Apr 11 06:48:39 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:39 localhost NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Apr 11 06:48:40 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:40 localhost NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Apr 11 06:48:41 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:41 localhost NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting... Apr 11 06:48:41 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:41 localhost NetworkManager: <info> Activation (eth0/wireless): access point 'free4all' is encrypted, but NO valid key exists. New key needed. Apr 11 06:48:41 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:41 localhost NetworkManager: <info> Activation (eth0) New wireless user key requested for network 'free4all'. Apr 11 06:48:41 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:41 localhost NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete. Apr 11 06:48:41 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:42 localhost last message repeated 6 times Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0) New wireless user key for network 'free4all' received. Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) started... Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) starting... Apr 11 06:48:50 localhost NetworkManager: <info> Activation (eth0/wireless): access point 'free4all' is encrypted, and a key exists. No new key needed. Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'INTERFACE_ADD eth0 wext /var/run/wpa_supplicant ' Apr 11 06:48:51 localhost kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'AP_SCAN 1' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'ADD_NETWORK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was '0' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 ssid 6672656534616c6c' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 key_mgmt NONE' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 wep_key0 <key>' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'SET_NETWORK 0 wep_tx_keyidx 0' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: sending command 'ENABLE_NETWORK 0' Apr 11 06:48:51 localhost NetworkManager: <info> SUP: response was 'OK' Apr 11 06:48:51 localhost NetworkManager: <info> Activation (eth0) Stage 2 of 5 (Device Configure) complete. Apr 11 06:48:51 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:52 localhost last message repeated 6 times Apr 11 06:48:52 localhost avahi-daemon[2956]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::213:2ff:fe6f:fc3c. Apr 11 06:48:52 localhost avahi-daemon[2956]: New relevant interface eth0.IPv6 for mDNS. Apr 11 06:48:52 localhost avahi-daemon[2956]: Registering new address record for fe80::213:2ff:fe6f:fc3c on eth0.*. Apr 11 06:48:52 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:54 localhost last message repeated 6 times Apr 11 06:48:54 localhost wpa_supplicant[3572]: Trying to associate with 00:12:17:46:42:51 (SSID='free4all' freq=2457 MHz) Apr 11 06:48:54 localhost kernel: hwcrypto disabled! Apr 11 06:48:54 localhost kernel: iwlwifi: TODO: Look into long/short preamble change handling. Apr 11 06:48:54 localhost wpa_supplicant[3572]: Association request to the driver failed Apr 11 06:48:54 localhost kernel: iwlwifi: Network RSSI: -40 Apr 11 06:48:55 localhost kernel: iwlwifi: REPLY_ADD_STA failed Apr 11 06:48:55 localhost kernel: iwlwifi: Network RSSI: -40 Apr 11 06:48:55 localhost kernel: iwlwifi: REPLY_ADD_STA failed Apr 11 06:48:55 localhost kernel: iwlwifi: Network RSSI: -38 Apr 11 06:48:59 localhost NetworkManager: <info> Old device 'eth0' activating, won't change. Apr 11 06:49:09 localhost wpa_supplicant[3572]: Authentication with 00:00:00:00:00:00 timed out.
Tom, please don't paste wads of output into the bug; add them as attachments instead. I'm also running the 3054 kernel on an X60 with a 3945abg card inside, and I can't associate with any access points, either encrypted or unencrypted.
Bryan -- 3056 seems to be a turning point for a lot of people. And for me too. Tom -- what access points are you connecting to?
Jeremy, I'm glad it's working for you. It's not much of an inconvenience for me that it's not working, because I can fall back to ipw3945. But it sure isn't working :-)
(In reply to comment #6) > Jeremy, I'm glad it's working for you. It's not much of an inconvenience for me > that it's not working, because I can fall back to ipw3945. But it sure isn't > working :-) With 3056 or 3054?
Oops, I misread 3054 for 3056. What an idiot :-( I just installed 3056 (yum doesn't believe in its existence yet, so I had to do it by hand). And it associated with an unencrypted AP on the first try! Nice. I've not had a chance to try with WEP yet.
WEP fails with a Linksys WRT54G. WPA fails with Cisco APs. Tracking down model #s..... Unencrypted works on GoogleWiFi. Believe they use Tropos.
*** Bug 235139 has been marked as a duplicate of this bug. ***
I have WEP "working" with a WRT54GL running OpenWRT. However, the packet loss rate is 15%. Every minute or two, the card loses its association. I'll post some sample output from logs and dmesg.
Created attachment 152360 [details] Symptoms of WEP flakiness I've added a snippet of /var/log/messages output that shows the symptoms of the WEP flakiness problem.
Created attachment 152361 [details] Symptoms of WEP flakiness, dmesg output Here's the raw dmesg output that corresponds to the stuff from /var/log/messages, again relating to the problem of association flapping with WEP.
Bumping the priority on this, due to its wide impact. Please feel free to push the priority back down if you disagree with me.
Tried the 3069 and 3079 kernels, both of which regress in stability relative to 3056. 3079 associates for about 30 seconds, then printk's an "out of Tx space" error message that only goes to the console and dmesg. Unfortunately, I forgot to capture it before rebooting. Can reproduce if needed.
(In reply to comment #15) > Tried the 3069 and 3079 kernels, both of which regress in stability relative to > 3056. 3079 associates for about 30 seconds, then printk's an "out of Tx space" > error message that only goes to the console and dmesg. Unfortunately, I forgot > to capture it before rebooting. Can reproduce if needed. Going to track the oops + "out of Tx space" thing as a separate bug (bug 237182) and use this one to track the frequent drops when things were associating.
(In reply to comment #9) > WEP fails with a Linksys WRT54G. > > WPA fails with Cisco APs. Tracking down model #s..... > > Unencrypted works on GoogleWiFi. Believe they use Tropos. I'm still having this exact problem with 2.6.20-1.3104.fc7PAE: I can associate/use with unencrypted networks, but cannot associate with any tested WEP or WPA network. NetworkManager reports all scanned networks at 100%, etc. This is with Intel 3945 on Thinkpad X60. Release notes for T4 appear to indicate iwlwifi is working...? Only way I get Wifi is to install old ipw3945 module/userspace daemon.
Created attachment 153622 [details] /var/log/messages of iwlwifi 'failure to associate' .3116: iwlwifi remains borked for me. Attached is snippet from /var/log/messages of attempt to associate using WPA with Linksys WRT54G with NetworkManager on Thinkpad X60, but this fails with other (encrypted) access points as well. I'm trying to use NetworkManager..... Continue to get lots of 'long/short preamble' and 'REPLY_ADD_STA failed' messages. [This all works fine if I compile/install the older ipw3945 driver/user daemon.] Is this a known issue? Is there some other testing/probing I can do?
3125 seems better.
Tom/Jeremy, are you still seeing this on the 3122 or later kernels?
I'm running .3125 and can associate properly only if I kill off NetworkManager and run wpa_supplicant/dhclient manually. System is quite stable if I run that way. If I start NM something with its regular scans cause the association to drop. I can reconnect only after rebooting. (Haven't tried rmmod'ing iwlwifi......)
I'm seeing this wireless problem too on the .3116 kernel. I can associate to my Linksys WRV200 using WPA2 and NetworkManager, but the connection only stays live for an extremely short period of time, then it dies. NetworkManager says it's still associated, but it's not. The laptop is a Thinkpad T60p with 3945 wireless running F7 with the latest code from the public devel server.
Similar experience with the 3142 kernel. Important dmesg seems to be iwl3945: Error not a valid ipw_rxon_assoc_cmd field values iwl3945: Invalid RXON configuration. Not committing. I can post more if it helps.
with DaveJ's 3163 kernel and the new v2.14.3 firmware just released today-ish on http://intellinuxwireless.org/?p=iwlwifi the iwl3945 on my sparkly new x86_64 dell xps 1210 seems to connect and work ok. all the other fedora7-test4 combinations that I tried (kernel 3149/3163 with firmware from the iwlwifi-firmware-2.14.1 rpm, or kernel 3149 with new ucode) didn't associate. I'm connecting to a WEP 128 billion 7404vgpm if that matters. HTH. let me know if you'd like more info or me to try something.
still not working for me (lenovo t60 laptop) 2.6.21-1.3167 kernel and all latest updates. works when standing right next to access point only. logs attached
Created attachment 154993 [details] result of "iwlist wlan0 scanning" and /var/log/messages using wireless manager
Have same 'only works when 3 feet or less from AP' issue.... Running .3163, 2.14.3 firmware on Thinkpad X60.
more success (hopefully) Also manually installed the latest microcode (/lib/firmware) 3 times out of 3 wireless worked. 3rd time it lost connection after a while, but removing and reinserting module (and deleting all settings from network manager allowed me to manually reconnect - writing this now over wireless. http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-3945-ucode-2.14.3.tgz not sure if that helped - (was very confused that initial install of test 4 didnt by default install microcode rpm - lots of problems till that point i installed it as device wlan0 didnt exist at all).
2.6.21-1.3174 installed - scanning working fine - seems much more stable. Network manager breaks everything, but thats because it doesn't seem to support the newer iwlwifi driver (when you run it it doesnt find wlan0 device, but tries to force wmaster0 which is older version of driver).
spoke too soon. log attached
Created attachment 155046 [details] /var/log/messages
running latests 2.6.21-1.3175.fc7 iwlwifi-firmware-2.14.3-2. it connects reliably, but disconnects pretty regularly (especially with a bit of network traffic, sometimes for no reason) with extreme prejudice requiring a complete power-button shutdown. usually the last sensible thing seen is kernel: iwl3945: REPLY_ADD_STA failed oops'd once - attached.
Created attachment 155233 [details] NetworkManager / netlink / iwl3945 / ondemand Oops
some progress (kernel .3189) Network manager now sees correct devices. open network now connects and is basically stable for long periods of time 1-2 hrs (although still some random disconnections) not working: using cisco 1100 access point with wpa1/tkip : failed to find access point initially. removed module (which seemed to automatically re-insert!) allowed it to scan network and find the access point. correctly identifies encryption/authentication level and brings up password box attempting to associate fails with same errors as previously. i think this links to iwlwifi/wext wpa2 bug in bugzilla for iwlwifi log attached
Created attachment 155334 [details] /var/log/messages
it seems better for me also. now it mostly associates ok. it disconnects about once an hour or two - especially when there are other laptops in the vicinity, but usually reconnects automatically or after prompting networkmanager - after 30s or so, or failing that, sometimes with a rmmod/modprobe iwl3945. it's much better than it was in that it hasn't hung the machine and forced a power-button reset with kernel 3194. so kinda less than normal linux standard wireless reliability, but it doesn't seem dangerous any more :-)
No longer messing up people's systems, hooray - moving to FC7Tracker
I'm having the exact same situation with all the details posted with an install of fedora 7. Stock standard didn't work. I've had to post this at Uni cause if I reboot it connects but then any sort of traffic it disconnects and generates the errors in the first post.
There is an F7 kernel-update candidate available here: http://people.redhat.com/davej/kernels/Fedora/fc7/RPMS.kernel/ Which amongst other things contains various fixes to the iwl3945 driver. Please try this kernel and report back how it works for you. Always be carefull when testing new kernels. Use rpm -ivh to install the new kernel besides your current one so that you can always boot back into the old kernel.
With 2.6.21-1.3226.fc7 I can associate with a La Fonera and get an IP, but no traffic would go through. I once got traffic through and even the connection didn't get lost for a few hours, but it seems this was just a lucky day. Also no luck with a WPA connection. It won't even associate again after a rmmod/modprobe iwl3945 :-/
The new kernel generates this error for me constantly rendering my computer very slow. It just keeps generating this same log output. Jun 11 09:00:37 localhost kernel: iwl3945: Can't stop Rx DMA. Jun 11 09:00:37 localhost kernel: iwl3945: Grabbing access while already held at line 825. Jun 11 09:00:37 localhost kernel: iwl3945: Microcode SW error detected. Restarting 0x82000000. Jun 11 09:00:37 localhost kernel: iwl3945: Error Reply type 0x0000003A cmd REPLY_RXON_ASSOC (0x11) seq 0x0402 ser 0x00000000 Jun 11 09:00:37 localhost kernel: iwl3945: Error setting RXON_ASSOC configuration (-5). Jun 11 09:00:37 localhost kernel: iwl3945: Error sending REPLY_TX_PWR_TABLE_CMD: time out after 500ms. Jun 11 09:00:37 localhost kernel: iwl3945: ipw going down
It attempts to work and does if I'm closer to the access point. However the issue is getting an equivalent signal strength. I'm on 75% with the ipw3945 driver and with the iwl3945 driver I'm on 25%.
with kernels 3226 and 3228 an attempt to rmmod the iwl3945 after a suspend/resume hangs the machine. ie. rmmod hangs, ifconfig hangs, iwconfig hangs and pretty soon there's a dozen processes in D state, it won't reboot, and I have to lean on the power button to turn off the machine. A BUG during resume once is attached. this hang doesn't happen with kernel 3194. as rmmod/modprobe'ing the iwl3945 is currently a necessary part of NetworkManager Applet getting a wireless connection after a suspend/resume, then I'm sticking with the 3194 kernel. hardware is a Dell m1210 laptop, x86_64.
Created attachment 157182 [details] BUG during resume
Please try the kernels from here: http://koji.fedoraproject.org/koji/buildinfo?buildID=10941 Do they work any better for you?
The included newer driver needs newer firmware available from intellinuxwireless.org. I'm using the 2.6.22.1-20 version and I still am getting many of these: iwl3945: REPLY_ADD_STA failed in dmesg. I'll be able to better test wireless this weekend.
I am also still getting "REPLY_ADD_STA failed" with kernel 2.6.22-8.fc7 downloaded from the given link. The wireless netework interface now shuts down within seconds after connect, while it lasted many minutes with kernel 3194 and 3228. I am also getting lines like this: "NetworkManager: <WARN> request_and_convert_scan_results(): card took too much time scanning. Get a better one. " I don't know if this is related. I can provide more logs if needed.
It doesn't even find my wireless card which is a concern. The error message I receive is as follows. Jul 16 16:00:02 localhost system-config-network[2859]: Error: Unknown not in DeviceFactory! Jul 16 16:00:04 localhost NetworkManager: <info> Error getting killswitch power: org.freedesktop.Hal.Device.KillSwitch.NotSupported - Access type not supported
I think you need to update your firmware. It is available here: http://intellinuxwireless.org/iwlwifi/downloads/iwlwifi-3945-ucode-2.14.4.tgz You will need to copy the firmware files into /lib/firmware. Does that work better for you with the 2.6.22-8 kernel?
2.6.22-8.fc7 doesn't even boot for me on x86_64 dell m1210. however 2.6.22.1-21.fc7 boots and iwl3945 works a little better than before - the module doesn't always need rmmod/modprobe after a suspend/resume any more - twice it's reconnected on it's own successfully - yay! and although I have had to do a rmmod to get re-associated once out of the 3 times I've tried suspend/resume, this time the rmmod didn't seem to halt the whole kernel (previously characters were lost, whole machine froze for a few seconds) which is also an improvement. 2.6.22.1-21.fc7 needs the new firmware too. signal strength seems roughly the same as kernel 3194 and doesn't seem bad to me. I can't test behaviour with other network traffic (which previously was a problem) as there is none here at the moment. I still get the "iwl3945: REPLY_ADD_STA failed" messages regularly.
Magnificent work. I put the new firmware in as recommended. It works perfectly. I tried shifting my laptop to where it usually doesn't have the same connections strength and it's brilliant. Jul 16 23:26:39 localhost avahi-daemon[2339]: New relevant interface wlan0.IPv4 for mDNS. Jul 16 23:26:39 localhost avahi-daemon[2339]: Registering new address record for 192.168.1.235 on wlan0.IPv4. Jul 16 23:26:40 localhost NetworkManager: <info> Activation (wlan0) Finish handler scheduled. Jul 16 23:26:40 localhost NetworkManager: <info> Activation (wlan0) Stage 5 of 5 (IP Configure Commit) complete. Jul 16 23:26:40 localhost NetworkManager: <info> Activation (wlan0) successful, device activated. Jul 16 23:26:40 localhost kernel: wlan0: duplicate address detected! Jul 16 23:26:42 localhost NetworkManager: <info> Error getting killswitch power: org.freedesktop.Hal.Device.KillSwitch.NotSupported - Access type not supported I'm still getting that org.freedesktop output but apart from that it's perfect. I for one am sticking to this kernel. Thanks so much :)
Sadly I'm spoke to soon. The improvements are there and I had a really good connection but putting a strain on the data seemed to cause issues. Rebooting helped but there is no output in the log files. Nearly there from the looks of it.
I can report a stable network using kernel 2.6.22.1-27.fc7.