Description of problem: After upgrading to kernel-2.6.25.14-108.fc9.x86_64, my iwl4965 chip can no longer connect to the WPA EAP network at school. WPA-PSK is untested, but last time this broke it didn't work. This seems to be a regression of a previous bug (2.6.25.11-97.fc9.x86_64 worked, previous one didn't). Version-Release number of selected component (if applicable): kernel-2.6.25.14-108.fc9.x86_64 How reproducible: Attempting to connect to a WPA network. Steps to Reproduce: 1. Attempt to connect to a WPA EAP network. Actual results: Fails to connect (NetworkManager keeps prompting for password and never connecting). dmesg reports a variety of 'denied association (code=18)' and 'association with AP <mac> timed out' messages. Expected results: A usable network connection. Additional info: 2.6.25.9-76.fc9 was the last kernel to reliably and completely support my chipset. The subsequent one (version number presently unavailable, as I uninstalled it) didn't work. WPA worked again in 2.6.25.11-97.fc9, but suspend and hibernate were unreliable (I recall no problems in -76). WPA is broken again now in 2.6.25.14-108.fc9.
Persists with 2.6.26.3-29.fc9.x86_64.
Also occurs in kernel-2.6.26.3-29.fc9.i686
I've not been able to connect to WPA either with kernel-PAE-2.6.26.5-19.fc8.
Created attachment 317029 [details] relevant dmesg output
I have also been having problems with connecting to my home router with WPA-PSK/TKIP+AES since upgrading to kernel 2.6.26.3-29.fc9.i686.PAE. I am able to connect to our router/AP at work which (I believe) is configured for WPA-PSK/TKIP. Both worked flawlessly for me prior to the upgrade. My last comment has the kernel messages from dmesg while I am trying to connect multiple times.
What is the latest kernel you have tried? Have you tried a rawhide kernel? FWIW, I can replicated this on 2.6.26.3-29.fc9 but I am _not_ seeing it on today's wireless-testing kernel.
The latest kernel I have tried is 2.6.26.3-29.fc9 (x86_64). I have not tried a rawhide kernel.
I have the same problem on 2.6.26.3-14.fc8
FWIW, I'm having the same issue running under 2.6.26.5-47.fc9.x86_64 Also, another problem I've noticed is (at least on a Dell XPS M1330) if have the wireless toggle switch-wifi catcher enabled in bios, it causes a kernel panic if the wifi is on. Disabling this in BIOS works just fine. Also want to confirm that unencrypted networks connect no problem.
*** Bug 462167 has been marked as a duplicate of this bug. ***
Alright, I can get WPA working on a variety of both vanilla and Fedora kernels if I do _not_ use NetworkManager and only start wpa_supplicant manually with my own configuration: chkconfig NetworkManager off chkconfig wpa_supplicant off Reboot... wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/linville.conf Got to another shell... dhclient wlan0 Surf the web normally! I'll attach the configuration I am using, but it is nothing fancy.
Created attachment 319409 [details] linville.conf Simple wpa_supplicant config that makes things work...
John, can you try that same config with "proto=WPA RSN"? Does that still work? Dan
Yes, it still seems solid with the modification suggested in comment 13.
Latest NetworkManager packages for F9 ( 0.7.0-0.11.svn4022.4 ) fixes the problem for my WPA-PSK Home network. On monday I will check the WPA-Enterprise PEAP Auth network at work. My config: kernel - 2.6.26.5-45.fc9.x86_64 IWL-4965 NetworkManager 0.7.0-0.11.svn4022.4
Also appears to be resolved in 2.6.26.5-45.fc9.i686
Dan, did you change anything in NM to make things work?
My luck with the 2.6.26 kernels has been no good. kernel-2.6.25.14-108.fc9.x86_64 = Good kernel-2.6.26.3-29.fc9.x86_64 = Bad kernel-2.6.26.5-45.fc9.x86_64 = Bad With the 2.6.26 kernels I associate and get an IP address, and then within 10 mins the following message shows up in dmesg and then I can no longer pass traffic. wlan0 (WE) : Wireless Event too big (342) If I modprobe -r iwl496 and then modprobe it back I'm able to reassociate, get an IP and pass traffic again, for about 10 mins, and then it happens again. Then within 30 mins my system (T61p) will hard lock and my num lock blinking at me. With the 2.6.25.14-108.fc9.x86_64 kernel I don't have the above problems.
I tried another kernel - 2.6.26.6-39.fc8 (from koji) - still no go - it connects and a little while later hoses connection - tho iwconfig shows it believes it is still connected. I still see the error kernel : wlan0 (WE) : Wireless Event too big (342) The last working kernel remains 2.6.25.14-28.fc8. Other things I tried - i was using AES (WPA2 personal) - i tried allowing TKIP or AES - no difference. I also tried changing the AP to use 20 MHz channels inseat of auto or wide (40) .. no difference. I tried using wpa_supplicant directly instead of network manager - no difference. wiht 2.6.26.5 I actuall oops'ed and only thing I could do was power off - even sysrq-b would not respond - flashing caps lock key etc. This is a nasty one ...
We have three guys in our office with ThinkPad T61p's with the iwl4965. All three of us are continually seeing kernel panics and the message: wlan0 (WE) : Wireless Event too big (342) How can we debug this? We are using WPA2 with a Linksys ABGN access point.
As I've said, the configuration in comment 12 works for me. Of course you may need to alter it to fit your own environment. Either way, this implies to me that this issues either does not involve the driver(s), or it is some subtle reaction between the driver(s) and NM or whatever -- Dan, please comment. The "Wireless Event too big" messages are driven by your local APs sending more IE data than we were expecting to see. Nevertheless, I have been assured that the information is not needed by wpa_supplicant. So, those messages are really just a nuisance. As for comment 19, it sounds like a different problem -- especially the "it believes it is still connected" part and the oops.
ThinkPad T61. Seeing the same problem. No kernel panics, but my iwl4965 is completely broken. I can connect (only manually, using iwconfig/ifconfig/dhclient) to open networks, but when I try to connect to my own network (worked just fine back in F8) I get an IP (after the 16'th attempt) but the connection times out. - Gilboa
Gilboa, what kernel are you using? Did you try starting wpa_supplicant with a config like in comment 12?
It seems to be working now. (Somehow missed comment 12) I had to manually create the wpa_supplicant file (and edit the /etc/sysconfig/wpa_supplicant configuration files)... but it works. ... Now if only NetworkManager didn't spend it's time trashing my bridge Ethernet devices... :) - Gilboa
I've said in comment 16 that it appeared to work for my kernel. However, now, ever since the 2.6.26 kernels, it appears that it would work only within a small time window if I immediately logged on an connected to a wireless network. If I did not do this immediately, I would be unable to connect to any wireless network (any WPA anyways), until rebooting. Restarting NetworkManager, or re-inserting the iwl4965 kmod would not work either. It almost "feels" like the device is being shut down if not in use, and is unable to come back at all once it is shut down (a power save problem?). Instead, it just keeps asking for the PSK, which never works. Recently, I've had to reboot several times to get it to connect. Once connected, I have no problems whatsoever. I have not yet tried comment #12 in the cases where NetworkManager fails to make the connection, but will post my comments here when I do.
Tested kernel-PAE-2.6.26.6-49.fc8 - on fresh boot - i connected immediately - but after a few seconds the connection was dropped and device appears deactivated. Just like earlier kernels. Is there a plan for 2.6.27 for fc8 - be happy to try that ?
No, AFAIK FC8 will not get 2.6.27-based kernels.
Hi all, I had the same problem on my thinkpad T61 (4965 wifi chipset) when upgrading to kernel 2.6.26.79_686 FC9 The workaround by Linville in comment 12 works (thank you), but now I have no graphical netwokrmanager anymore Since I installed FC9 in july, it is already the 4th kernel upgrade which brakes my Wifi !!!
I'm hesitant to suggest this, because previous kernels seemed to work, but then started breaking, but kernel-2.6.26.6-79.fc9.i686 appears to be the first 2.6.26 kernel that works fine for me.
see also this link where I submitted previous issues I had to download temporary kernel builds, get the wifi firmware from the intel site cause the kernel changed it, etc... http://fedoraforum.org/forum/showthread.php?t=193437
I have news - I can connect (using wpa_supplicant directly) if the AP is in BG mode - as soon as I put the AP into mixed BGN - the connection drops. So this problem is specific to having N turned on on the AP (this one is a Cisco/Linksys WRT160N. I am connecting fine - and solid with a simple wpa_supplicant.conf - next with the AP in BG only mode - I will restore the original wpa_supplicant.conf file - which contains several entries instead of just 1.
Confirming that my standard wpa_supplicant.conf works fine - it has multiple entries - again provided the AP is BG only mode - BGN on and it stops working. Kernel is 2.6.26.6-49.fc8PAE I have not yet tried using NM.
NM works fine as well - same conditions as above.
Oh yes - I still have the problem with the connection preferring the AP 100 feet away instead of the AP 12 inches from the wireless .. these are identical AP's with the same config. By the way - for BG, in a multi AP setup - I always kept the channels of nearest neighbors 6 apart if possible. for N class AP's (if i ever can turn them on again) - i had been leaving the channel frequency on auto - is this ok in a multi AP setup ? Thanks.
wpa_supplicant orders the APs in its scan list by signal strength if available, but of course since scanning is somewhat unreliable (in that not all APs show up in every scan) if the closest AP's beacon did not arrive while the card was listening, or got squelched, then it wouldn't show up in the scan list and the supplicant might well choose the farther AP instead, because it was the only one in the scan list. But yeah, sounds like a driver problem now...
I'm pretty sure this is an iwlwifi problem and not a general mac80211 one, see: https://bugzilla.redhat.com/show_bug.cgi?id=462167#c12
Dan, what makes you say "sounds like a driver problem now"? Because it relates to using a .11n AP? So let's clarify: with a .11n AP, you can only connect using wpa_supplicant manually? But with a .11g AP, you can connect with either wpa_supplicant or NetworkManager? Is that correct? Or has this bug been hijacked to a new problem (i.e. "iwlagn doesn't work with .11n APs")?
From what I see in summary: (1) With AP in B/G I can connect fine using using newer kernels (2.6.26.x) or older kerneles (2.6.25.x) with both wpa_supplicant directly or with network manager. (2) With AP in B/G/N mode - I can connect fine only with older kerneles (2.6.25.x) using both wpa_supplicant directly or network manager. However Newer kernels are a problem with either wpa_supplicant or NM.
I see -- well, that would seem to be different than the original problem reported here. Would you mind opening a new bug for that specific issue? Thanks!
So, are current kernels working fine for everyone using WPA (so long as they are only using .11g APs)?
Ok created - https://bugzilla.redhat.com/show_bug.cgi?id=471058.
I have a T61 with iwl4965. I've had many troubles with this system in the past and it seems to be hit-or-miss for getting open wifi and WPA connections either on a freshly booted system or resume from suspend-to-ram or hibernate-to-disk, although fresh boots seem to work more often. On Sunday I was having my usual troubles connecting to an open network with NetworkManager. I ended up turning off NetworkManger/wpa_supplicant, and using iwconfig/ifconfig directly which worked immediately despite 10 or so tries with NM. Something in NM or wpa_supplicant seems to be tickling the hardware in a way that breaks it. I turned on debugging on the driver: /etc/modprobe.conf: options iwl4965 debug=65535 then re-enabled NM and hibernated the system. This morning, I was able to resume from hibernate and make a WPA2 Enterprise (EAP-TLS, certificates) connection immediately without trouble (I had to enter my password to unlock the keyring as usual when resuming). I was very surprised, because last week the exact same thing didn't work at all and I gave up in frustration. I've had the following packages installed on the given dates: 10/29/2008 kernel-2.6.26.6-79.fc9.x86_64 10/05/2008 NetworkManager-0.7.0-0.11.svn4022.4.fc9.x86_64 06/13/2008 wpa_supplicant-0.6.3-6.fc9.x86_64 and I know I've had 2.6.26.6-79 booted since Oct 29 as well from "last" logs. I know that since 10/29 I've had lots of troubles with connecting to both open and WPA networks, so this is just as flakey as ever. Sometimes it works immediately, sometimes it never connects and I basically give up and plug into a wired network. There are no 802.11n networks that I know of, and certainly not the ones I'm trying to connect to. The open network is an old Linksys and the WPA one is a big centralized AP system from Nortel/Trapeze.
Charles, I have exactly the same problem, I have 2 linksys AP's at 2 different locations, and I have troubles with both of them. This morning I couldn't even connect with wpa_supplicant, as soon as I started dhclient wlan0, i got "package L2 received, network dead". This worked before. Now I am home again and decided to start the networkmanager again, and as I am typing, all works fine. I have fedora 9 2.6.26.6-79.fc9.i686 on a Lenovo T61 and linksys accesspoints. I am also frustrated about this, one kernel works fine, the other can't connect,... and I connect to the wired net. Tony
> So, are current kernels working fine for everyone using WPA (so long as they > are only using .11g APs)? No, in my case it's 11g APs which are not working, not 11n. There are either 2 bugs or the bug is not 11n-specific.
Not in my case, I don't have 11n, only 11g AP's
Ugh, this bug goes on forever -- what kernels are you using? What is the _exact_ issue with the current kernel? Does the problem occur with NetworkManager turned-off and using wpa_supplicant directly?
John; sorry for the lag on my end, I'm buried in F10/5.3/NM 0.7 at the moment and I intend to go through some more systematic testing in the next couple days to determine whether all the relevant configurations work on at least ipw, iwl, and ath5k. Everyone else: To debug these issues, anyone having problems with *NetworkManager* please add "-dddt" to the end of the Exec= line in the file /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service and either restart the machine, or (1) "/sbin/service NetworkManager stop", (2) "killall -TERM wpa_supplicant", (3) "/sbin/service NetworkManager start", and then reproduce the issue. Using "-dddt" when running wpa_supplicant manually will also produce output that is useful. When running it manually, *be sure* to 'killall -TERM wpa_supplicant' to stop any auto-started supplicant that might interfere with your testing. The supplicant can be either dbus-activated on demand, or run as a system service, and if two copies run, they fight with each other. When you have reproduced the NetworkManager issues, I need _both_ /var/log/messages and /var/log/wpa_supplicant.log. Feel free mark the logs as private when you attach them, since they may contain site- and machine-specific data that you may want to remain private.
(In reply to comment #47) Hi Dan, in response to your comment, I am uploading two set of files (both wpa_supplicant.log and messages), one with the kernel-2.6.25.14-108.fc9.x86_64 (correct_connection.tar.gz) which succesfully connects, and the other with the latest kernel-2.6.26.6-79.fc9.x86_64, which does not connect. To further clarify the situation, I have a Fedora 9 with all latest patches applied. Relevant packages are: wpa_supplicant-0.6.3-6.fc9.x86_64 NetworkManager-openvpn-0.7.0-16.svn4027.fc9.x86_64 NetworkManager-0.7.0-0.11.svn4022.4.fc9.x86_64 NetworkManager-glib-0.7.0-0.11.svn4022.4.fc9.x86_64 NetworkManager-vpnc-0.7.0-0.10.svn4024.fc9.x86_64 NetworkManager-gnome-0.7.0-0.11.svn4022.4.fc9.x86_64 NetworkManager-pptp-0.7.0-0.10.svn4027.fc9.x86_64 iwl4965-firmware-228.57.2.21-1.1.noarch Thanks & Best Regards
Created attachment 323458 [details] Messages and wpa_supplicant log when failing connection as per comment 48 Messages and wpa_supplicant log when failing connection as per comment #48
Created attachment 323460 [details] Messages and wpa_supplicant log with working connection as per comment #48 Messages and wpa_supplicant log with working connection as per comment #48
From Luca's logs, they are exactly the same up until the association attempt is in progress. The config that NM sends to the supplicant is _exactly_ the same and the supplicant performs the same steps. In the failure case though, there is: 1226586426.722457: EAPOL: SUPP_BE entering state RECEIVE 1226586429.722807: EAPOL: startWhen --> 0 1226586449.795183: wpa_driver_wext_disassociate the success case shows: 1226586909.484861: EAPOL: SUPP_BE entering state RECEIVE 1226586909.494343: RX EAPOL from 00:xx:xx:xx:xx:xx 1226586909.494374: RX EAPOL - hexdump(len=10): 01 00 00 06 01 01 00 06 19 20 Note the 3-second pause after RECEIVE where the AP should be replying with EAPOL frames in the failure case. Given that all other things are equal except the kernel, it looks to me like a driver issue still. Unfortunately that means either a bisection, frame grabbing over the air from a second machine to ensure that the AP sends the correct frames back to the client (or that the client's frames get to the AP correctly), or additional driver debugging... Thoughts John?
I can confirm this. A working standalone wpa_supplicant says: 1226680219.388339: EAP: EAP entering state IDENTITY 1226680219.388343: CTRL-EVENT-EAP-STARTED EAP authentication started 1226680219.388349: EAP: EAP-Request Identity data - hexdump_ascii(len=53): 00 6e 65 74 77 6f 72 6b 69 64 3d 49 6d 70 65 72 _networkid=Imper 69 61 6c 2d 57 50 41 2c 6e 61 73 69 64 3d 77 6c ial-WPA,nasid=wl 61 6e 2d 77 69 73 6d 2d 33 2d 32 2c 70 6f 72 74 an-wism-3-2,port 69 64 3d 32 39 id=29 1226680219.388408: EAP: using real identity - hexdump_ascii(len=4): 70 6a 6d 33 pjm3 1226680219.388422: EAP: EAP entering state SEND_RESPONSE 1226680219.388427: EAP: EAP entering state IDLE 1226680219.388433: EAPOL: SUPP_BE entering state RESPONSE 1226680219.388438: EAPOL: txSuppRsp 1226680219.388445: TX EAPOL: dst=00:1a:a2:fa:a8:a1 1226680219.388452: TX EAPOL - hexdump(len=13): 01 00 00 09 02 01 00 09 01 70 6a 6d 33 1226680219.388503: EAPOL: SUPP_BE entering state RECEIVE 1226680219.392282: RX EAPOL from 00:1a:a2:fa:a8:a1 ...but a failing one (run under NetworkManager) says: 1226680780.434903: EAP: EAP entering state IDENTITY 1226680780.434930: CTRL-EVENT-EAP-STARTED EAP authentication started 1226680780.434957: EAP: EAP-Request Identity data - hexdump_ascii(len=53): 00 6e 65 74 77 6f 72 6b 69 64 3d 49 6d 70 65 72 _networkid=Imper 69 61 6c 2d 57 50 41 2c 6e 61 73 69 64 3d 77 6c ial-WPA,nasid=wl 61 6e 2d 77 69 73 6d 2d 33 2d 32 2c 70 6f 72 74 an-wism-3-2,port 69 64 3d 32 39 id=29 1226680780.435096: EAP: using anonymous identity - hexdump_ascii(len=4): 70 6a 6d 33 pjm3 1226680780.435138: EAP: EAP entering state SEND_RESPONSE 1226680780.435163: EAP: EAP entering state IDLE 1226680780.435192: EAPOL: SUPP_BE entering state RESPONSE 1226680780.435217: EAPOL: txSuppRsp 1226680780.435243: TX EAPOL: dst=00:1a:a2:fa:c3:71 1226680780.435270: TX EAPOL - hexdump(len=13): 01 00 00 09 02 01 00 09 01 70 6a 6d 33 1226680780.435351: EAPOL: SUPP_BE entering state RECEIVE 1226680783.413522: EAPOL: startWhen --> 0 1226680798.021364: wpa_driver_wext_disassociate 1226680798.021669: No keys have been configured - skip key clearing 1226680798.021703: State: ASSOCIATED -> DISCONNECTED HOWEVER: I don't think it's solely a driver problem, because my timeline looks like this: This morning I was running: kernel-2.6.25.11-97.fc9.x86_64 1:NetworkManager-0.7.0-0.9.4.svn3675.fc9.x86_64 ...and everything worked. Then I (finally) did the upgrade to "updates-newkey" and was running: kernel-2.6.26.6-79.fc9.x86_64 1:NetworkManager-0.7.0-0.11.svn4022.4.fc9.x86_64 ...which failed, however I then *rebooted* into the older kernel i.e. [root@wedge ~]# uname -r 2.6.25.11-97.fc9.x86_64 [root@wedge ~]# rpm -q NetworkManager NetworkManager-0.7.0-0.11.svn4022.4.fc9.x86_64 ...and it *still* fails. I'll try to find the older NetworkManager RPM.
Ray of light, and no, I'm no fan of Ms. Ciccone. Latest kernel update ( kernel-2.6.27.5-37.fc9.x86_64 ) solves the issue at least for simple WPA-PSK configuration (my home). Tomorrow morning I'll be at work, and will check a more complex WPA Enterprise with PEAP and MSCHAP v2 configuration - my comments #48 #49 #50 where referring to work configuration. I am confident the bug is resolved in 2.6.27, the question is - why the regression? Dan, any Hint ? See ya
In reference to my comment #53, I am now sending this from work with new kernel-2.6.27-5-37.fc9.x86_64 (latest from updates-newkey). So it looks like a fix for a regression that was happening in 2.6.26 kernel. I will briefly post logs of both wpa_supplicant and messages. Best regards
Created attachment 323688 [details] Working connection with kernel 2.6.27 As per comment #54, the attachment has the logs of the working connection at my workplace. Thnks Again
Confirmed - WPA enterprise works with kernel-2.6.27-5-37.fc9.x86_64 Wow - speedy service ;o)
kernel-2.6.27-5-37.fc9.x86_64 works for me too. All my problems with open wifi networks and WPA Enterprise networks are gone. I can suspend/resume or fresh boot and it connects quickly every time. Yay!
Sounds like the 2.6.27 kernels are working...
Given the large F8 user base for various reasons - even tho' it is EOL in the not too distant future - it would be really helpful to have a 2.6.27 compiled for F8 as well. Thanks.