Description of problem: after an upgrade of the kernel to 2.6.24 iwl4965 stopped connecting to the wifi network. Version-Release number of selected component (if applicable): any 2.6.24 kernel for fedora 8 or 2.6.25 kernel for fedora 9 beta How reproducible: always Actual results: network manager / whatever you're using / can see list of networks, but is not bale to connect Expected results: connect to the wifi network Additional info: I am using kernel 2.6.23 and iwl4965 works fine there. I've tested latest update of 2.6.24 kernel and... iwl4965 does not work with the newest kernel. Also - just for a test, I've downloaded Fedora 9 Beta and tried to connect to wifi with its 2.6.25 kernel - same problem. I've attached log from dmesg. I am using Dell Precision M4300 laptop with Fedora 8 with all updates.
Created attachment 299368 [details] wlan0 related entries in dmesg
Same here. Extremely annoying bug, that forces me to use the old kernel (2.6.23) in order to get wireless working :(
Heh! you have made a "task force" here?! 2 reporters in 3 min of time. @Marek when you have tested F-9, was it from a separate Fedora installation (Good) a LiveCD (Good) or did you just installed the F-9 kernel on a normal Fedora 8 installation (NOT_GOOD)? Can you provide a dmesg output from the "faulty" kernel ? and iwconfig wlan0 ? You seem to authenticate well but association fails: wlan0: RX AssocResp from 00:1c:f9:72:d0:b1 (capab=0x431 status=18 aid=0) wlan0: AP denied association (code=18) association was denied from the AP. See if there is problem with your AP (may need a reboot)... @linville Maybe we can take the iwl4965-firmware bugzilla component as a proxy for kernel iwl4965.ko bug report, as kernel bug related to this chipset will already be "sorted" that way ?
(In reply to comment #3) > Heh! you have made a "task force" here?! 2 reporters in 3 min of time. Unfortunately wireless is very important these days... can you live without internet connection? ;-) > @Marek when you have tested F-9, was it from a separate Fedora installation > (Good) a LiveCD (Good) or did you just installed the F-9 kernel on a normal > Fedora 8 installation (NOT_GOOD)? I have downloaded Fedora 9 Beta LiveCD and tested it from live cd. > Can you provide a dmesg output from the "faulty" kernel ? > and iwconfig wlan0 ? dmesg output is from Fedora 9 Beta LiveCD - I have changed nothing, just opened a profile and tried to connect to the network using Network Manager. does it help? I am happy to give more information on request.
(In reply to comment #3) > Heh! you have made a "task force" here?! 2 reporters in 3 min of time. Kinda. We are both working in the same office on daily basis, and both using the same machines ;) > See if there is problem with your AP (may need a reboot)... I've been thinking about that solution, but on the other hand - if it's AP related thing, why I'm still able to connect to the same AP while using 2.6.23 kernel? I've submitted similar bug here: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1639 Fingers crossed to get this fixed ASAP, as when F9 would get released, there would be no easy way back to 2.6.23 kernels. :( Ideally, I'd have my ipw3945(d) back, as iwlwifi constantly keeps disappointing me. Here are my further thoughts, if you fancy: http://klamstwo.org/evad/archives/59
kwizart, I don't know how to do the bugzilla magic you describe. If you know, please feel free to suggest it on #fedora-admin. :-) What kernel version are you you using that gives a problem. "2.6.24" is not very descriptive. What is the latest version you have used? Please also make sure you are not running both the wpa_supplicant service and NetworkManager at the same time -- that causes problems: chkconfig wpa_supplicant off service wpa_supplicant start chkconfig NetworkManager on service NetworkManager start Also, make sure to run system-config-network and un-check "Active device when computer starts" and save your configuration. After a reboot, does the device work better?
John, when I am referring to "2.6.24" kernel, I mean kernels distributed through fedora-updates channel. I don't compile kernel by myself and I don't like to use kernels from other sources. My latest kernel, which I tried, was 2.6.24.3-50.fc8PAE (I have a 4 GB ram, dual core intel machine). wpa_supplicant is disabled in my Services config, connection is unchecked in system-config-network (yeah, the first thing actually). I was trying to connect using Network Manager (it does not work and it's not a surprise) and wicd - both does not work. when using kernel 2.6.23.14-107.fc8 I can easily connect to the network, but not with 2.6.24.*. Dawid has given details at: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1639#c3
[Just copying across my comment from the other bugtrack] OK, I have my home laptop at work, and I did some proper testing. We have WPA/WPA2 WLAN here, based on Cisco Access Points - our network admin is not here at the moment, so I can't give any more details other than actual scan result: [root@M4300 ~]# iwlist wlan0 scan wlan0 Scan completed : Cell 01 - Address: 00:1C:F9:04:4F:71 ESSID:"tangent-data" Mode:Master Channel:6 Frequency:2.437 GHz (Channel 6) Quality=83/100 Signal level=-51 dBm Noise level=-127 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000001ef97cc6160 Cell 02 - Address: 00:1C:F9:72:D0:B1 ESSID:"tangent-data" Mode:Master Channel:11 Frequency:2.462 GHz (Channel 11) Quality=94/100 Signal level=-35 dBm Noise level=-127 dBm Encryption key:on IE: WPA Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : TKIP Authentication Suites (1) : PSK IE: IEEE 802.11i/WPA2 Version 1 Group Cipher : TKIP Pairwise Ciphers (1) : CCMP Authentication Suites (1) : PSK Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:tsf=000000fd5d5dd863 Now, I have two machines: 1) Dell Precision M4300 (work) with 2.6.24.3-50.fc8PAE and iwl4965 v1.2.26kds 2) Dell Latitude D620 (home) with 2.6.24.3-50.fc8 and iwl3945 v1.2.26kds Machine 1) does NOT connect to the network, giving following dmesg output: wlan0: Initial auth_alg=0 wlan0: authenticate with AP 00:1c:f9:72:d0:b1 wlan0: RX authentication from 00:1c:f9:72:d0:b1 (alg=0 transaction=2 status=0) wlan0: authenticated wlan0: associate with AP 00:1c:f9:72:d0:b1 wlan0: RX AssocResp from 00:1c:f9:72:d0:b1 (capab=0x431 status=18 aid=36) wlan0: AP denied association (code=18) wlan0: associate with AP 00:1c:f9:72:d0:b1 wlan0: RX AssocResp from 00:1c:f9:72:d0:b1 (capab=0x431 status=18 aid=36) wlan0: AP denied association (code=18) wlan0: associate with AP 00:1c:f9:72:d0:b1 wlan0: RX AssocResp from 00:1c:f9:72:d0:b1 (capab=0x431 status=18 aid=36) wlan0: AP denied association (code=18) wlan0: association with AP 00:1c:f9:72:d0:b1 timed out wlan0: RX disassociation from 00:1c:f9:72:d0:b1 (reason=1) wlan0: RX deauthentication from 00:1c:f9:72:d0:b1 (reason=1) wlan0: deauthenticated Machine 2) does connect to the network without problems with following output: eth1: Initial auth_alg=0 eth1: authenticate with AP 00:00:00:00:00:00 eth1: Initial auth_alg=0 eth1: authenticate with AP 00:1c:f9:72:d0:b1 eth1: RX authentication from 00:1c:f9:72:d0:b1 (alg=0 transaction=2 status=0) eth1: authenticated eth1: associate with AP 00:1c:f9:72:d0:b1 eth1: RX AssocResp from 00:1c:f9:72:d0:b1 (capab=0x431 status=0 aid=38) eth1: associated When I run machine 1) with 2.6.23.14-107.fc8PAE kernel - it connects to the network without a hassle.
"AP denied association (code=18)" ==> "Group cipher is not valid" That would seem to suggest a tkip problem, or one relating to different group vs. pairwise encryption. Can you attempt connecting using WPA1 instead of WPA2? Does that behave any differently?
How do I connect specifically through WPA1, while network seamlessly supports WPA1/2? Sorry for ignorance, but I'm using wicd to manage my connections, and I only have 'WPA1/2' option there. :(
Ah, well...I was hoping you would know... :-) FWIW, I don't think I've ever used wicd. knetworkmanager allows me to "Connect to Other Wireless Network" and then specify "WPA Personal" or "WPA Enterprise", but I think that has to do with key management rather than encryption. I'll CC Dan Williams (the NetworkManager guy) -- he is quite knowledgeable about userland wireless tools and may be able to direct us. :-)
Thanks, let's wait for Dan then ;)
It depends on how wicd is using wpa_supplicant for the underlying WPA connection. If wicd is using ap_scan=2, then you must match the pairwise and group ciphers _exactly_ to what the AP advertises. If it's using ap_scan=1 then wpa_supplicant should be able to filter out the unsupported options automatically (because it's found the IEs from the beacons). The issue here is that ap_scan=2 (normally used for hidden APs and older drivers) just blows the settings you specify to the driver, and if they don't match the AP's settings you won't be able to connect. ap_scan=1 lets the supplicant scan for the AP, get the AP's IE, and filter out the stuff the AP doesn't support. The whole reason we put the SCAN_CAPA patch in the kernel was to automatically detect this in userspace programs. If there was a way to find out what wicd was pushing to wpa_supplicant, we could determine whether it's using ap_scan=1 or ap_scan=2. If it's using ap_scan=1 already, then I have no idea why it it's not working.
We could also try to narrow this down by turning off wicd and using wpa_supplicant directly, to determine if 3945 and 4965 have different behavior with the same wpa_supplicant config.
I've tried Network Manager with our network and it looks like it does not matter if I use wicd or NM, both cannot connect to our work network. with kernel 2.6.23 I can connect to the network using both NM and wicd (not at the same time though :))
(In reply to comment #13) > If there was a way to find out what wicd was pushing to wpa_supplicant, we could > determine whether it's using ap_scan=1 or ap_scan=2. If it's using ap_scan=1 > already, then I have no idea why it it's not working. Wicd stores it's connection settings in /opt/wicd/encryption/configurations directory. Here is what I have there: [root@M4300 configurations]# cat * ap_scan=1 network={ ssid="tangent-data" scan_ssid=0 proto=WPA RSN key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk=xxx }ap_scan=1 network={ ssid="tangent-data" scan_ssid=0 proto=WPA RSN key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP psk=xxx } Seems like ap_scan=1 for me. :(
*** Bug 440167 has been marked as a duplicate of this bug. ***
Similar/Same bug with me. I cannot connect to my school's WPA Enterprise with the most recent kernels. I can connect with kernel-2.6.24.3-22.fc8, but not with kernel-2.6.24.3-34.fc8 or kernel-2.6.24.3-50.fc8. Also, what is weird is that with both kernel-2.6.24.3-50.fc8 and kernel-2.6.24.3-34.fc8, I can connect to my home WPA Personal.
Some differences between the working kernel (-12) and failing (anything newer, including the latest -64 from koji): (Some logs are in bug 440167) - The failing kernel shows (in iwlist wlan0 freq) additional channels on the failing kernel (36, 40, 44, 48). These are valid channels for me (in Australia), and its not trying to use them according to the logs, but since the SSIDs that are failing are present both on 2.4GHz and 5GHz, its possibly related. Is there some way that I can disable the 5GHz band, just for testing? - On the failing kernel, /var/log/wpa_supplicant says: Trying to associate with 00:19:07:8f:fd:b5 (SSID='AGSM2' freq=2462 MHz) Authentication with 00:00:00:00:00:00 timed out. for each attempt. wireshark on wmaster0 shows that the auth request is going to a valid MAC, so the 00 one may be a cosmetic logging thing. wireshark on wmaster0 only seems to show me stuff from my laptop to the AP - how can I get both sides? On the failing kernel I see the association and authentication frames, but on the working kernel I also see the EAPOL 802.1x - those don't show at all on the failing one.
Just installed the newest 2.6.24.4-64 kernel from updates repo, and - tada! - connection still doesn't work. :( Bradley: I don't think it's related with 5GHz band. Check out my comment #8 where I compare two machines that both support that band, but with different adapters (iwl3945 vs. iwl4965). My test proved that iwl3945 does connect, while iwl4965 doesn't, so I'd rather focus on that specific driver/adapter, rather than band. I guess.
In your comment #8 there aren't any 5G scan results. And you're getting code=18 while I'm getting a different error. Is there a way for me to packet sniff both sides of the association?
(In reply to comment #21) > In your comment #8 there aren't any 5G scan results. And you're getting code=18 > while I'm getting a different error. I've scanned available networks in #8, but not channels. When it comes to channels I have currently at work, then: [root@M4300 ~]# iwlist wlan0 freq wlan0 32 channels in total; available frequencies : Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 12 : 2.467 GHz Channel 13 : 2.472 GHz Channel 36 : 5.18 GHz Channel 40 : 5.2 GHz Channel 44 : 5.22 GHz Channel 48 : 5.24 GHz Channel 52 : 5.26 GHz Channel 56 : 5.28 GHz Channel 60 : 5.3 GHz Channel 64 : 5.32 GHz Channel 100 : 5.5 GHz Channel 104 : 5.52 GHz Channel 108 : 5.54 GHz Channel 112 : 5.56 GHz Channel 116 : 5.58 GHz Channel 120 : 5.6 GHz Channel 124 : 5.62 GHz Channel 128 : 5.64 GHz Channel 132 : 5.66 GHz Channel 136 : 5.68 GHz Channel 140 : 5.7 GHz Current Frequency:2.462 GHz (Channel 11) As for 'code=18' error, if you've reffered to bug #440167, I can see you're getting these errors as well..
There are a few more key fixes in -69.fc8. In lieu of anything specific, would you mind trying that one? http://koji.fedoraproject.org/koji/buildinfo?buildID=44648 Any improvements with that? It seems to have helped some other iwlwifi users.
Created attachment 301528 [details] dmesg output after booting a machine Also, there is output after trying to connect to the network manually by clicking apropiate option in wicd application.
Created attachment 301529 [details] dmesg after reloading iwl4965 module
(In reply to comment #23) > There are a few more key fixes in -69.fc8. In lieu of anything specific, > would you mind trying that one? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=44648 > > Any improvements with that? It seems to have helped some other iwlwifi users. I've just installed -69.fc8PAE manually, but still no luck :( I'm attaching some dmesg output, as I think something new appeared there...
I tried -74 and still get the code=18 error
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1639 is this bug; I've bisected the commit that broke this for me.
Bradley, thanks for the bisection and for updating the bug both here and there! I'm sure the Intel guys will resolve this shortly.
Created attachment 303200 [details] revert-iwlwifi-refactor-init-geos.patch Bradley, since you mentioned trying to revert elsewhere I'm assuming you can handle a kernel build -- if not, let me know. Give this patch a try?
Yep, that works, thanks. Tested against iwlwifi-2.6 and the latest 2.6.24.5-85 RPM from koji. The patch doesn't apply to iwlwifi-2.6's HEAD - there are conflicts for the 3965 part of the patch. Since I have a 4965, I didn't look at what those were and just applied the 4965 part. So thats the backout; as for the cause I'm in Australia, so I get more frequencies than the FCC allocations. Not sure if thats relevant, but if you can tell me how to get the valid channel list out of the hardware I'll dump that here too.
I don't see anything obvious that relates to the exact channel allocation -- more likely there is just some bug in there. I have pinged the Intel folks about reverting it. Hopefully they will take the hint that it needs to be fixed or undone.
I've just installed 2.6.24.5-85.fc8PAE kernel, and checked if iwl4965 is finally working. Unfortunately - it still doesn't. :( Btw, I've ran the latest Ubuntu 8.04 the other day from live CD. Wireless on iwl4965 worked out of the box with 2.6.24 (!!!) kernel. With less than two weeks before F9 release I am *seriously* worried if I should upgrade my Fedora, as I'm still not convinced if wireless would just work as it should after upgrade...
Anything back from Intel? Its still broken on latest iwlwifi-2.6, so I guess not :(
Sadly, no...perhaps I need to threaten to revert it without their consent...
Linville, the bug owner at Intel is in leave now. I will try to find other proper person at Intel to look over this issue.
Just to confirm, the stock f9 kernel doesn't work, but does with the revert. I won't be able to test this further until I'm back at uni at the start of June.
(In reply to comment #37) > Just to confirm, the stock f9 kernel doesn't work, but does with the revert. I can also confirm that F9 LiveCD on a machine with iwl4965 still won't connect to the wireless network. Btw, how can I apply that patch? Does that require recompiling whole kernel from scratch?
Yes, you need to rebuild it with the attachment here applied.
I just tried rebuilding the current F9 update kernel (2.6.25.3-18) with the patch in the attachment applied, and am still unable to connect to a WPA/WPA2 network with the iwl4965 driver. I haven't built a kernel from a source rpm in a long time, so I can't be sure that I did it correctly, but drivers/net/wireless/iwlwifi/iwl4965-base.c in the BUILD directory looked patched. Any way to tell if I'm having an unrelated problem or if I did something wrong?
Are you seeing: wlan0: AP denied association (code=18) (and possibly code=17) errors in the logs when it fails? If not, its possibly not this bug.
I'm not, but I am seeing errors like: wlan0: associate with AP 00:19:aa:26:21:60 wlan0: RX deauthentication from 00:19:aa:26:21:60 (reason=2) wlan0: deauthenticated I'm not sure what the right debugging options are for the iwl4965 module; they don't seem to be too well documented. I'm using 0x43fff (which I saw in one of the attachments either here or in the intel ticket), which produces a lot of output, but possibly isn't complete.
Can you recreate this issue with the test kernels here? http://koji.fedoraproject.org/koji/buildinfo?buildID=49743
I won't be able to try until June 2 (I'm on holiday and not at the broken AP until then)
(In reply to comment #43) > Can you recreate this issue with the test kernels here? > > http://koji.fedoraproject.org/koji/buildinfo?buildID=49743 That kernel requires mkinitrd 6.0.39-1 installed. When I try to install 6.0.41 from development repo, it then requires an upgrade of many other packages from dev repo, and I'm not really that adventurous yet, to try it out on my working machine. Is there any way around this, so I could try this kernel out without actually putting many system packages into development state?
Sorry, that is an F9 kernel. I don't really have an equivalent F8 kernel ATM, but you might try this one: http://koji.fedoraproject.org/koji/buildinfo?buildID=48407 However, it is missing a lot of iwlwifi updates -- so YMMV...
(In reply to comment #46) > Sorry, that is an F9 kernel. I don't really have an equivalent F8 kernel ATM, > but you might try this one: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=48407 > > However, it is missing a lot of iwlwifi updates -- so YMMV... No luck - still code=18 :(
No luck with 2.6.25.4-26.fc9.x86_64 for me either; I'm still unable to connect to either set of WPA/WPA2 access points, and dmesg is still full of: wlan0: authenticated wlan0: associate with AP 00:19:aa:15:41:b0 wlan0: associate with AP 00:19:aa:15:41:b0 wlan0: RX deauthentication from 00:19:aa:15:41:b0 (reason=2) wlan0: deauthenticated
(In reply to comment #48) > No luck with 2.6.25.4-26.fc9.x86_64 for me either; I'm still unable to connect > to either set of WPA/WPA2 access points, and dmesg is still full of: > > wlan0: authenticated > wlan0: associate with AP 00:19:aa:15:41:b0 > wlan0: associate with AP 00:19:aa:15:41:b0 > wlan0: RX deauthentication from 00:19:aa:15:41:b0 (reason=2) > wlan0: deauthenticated Did you try to connect multiple times? I'm not sure right now, but I've started to get similar errors recently with 2.6.23, and after few tries I can finally connect.
FWIW, reason 2 is "Previous authentication no longer valid"...not sure what light that sheds on the issue...
Well, I'm really confused now. I'd tried connecting to each of the two WPA networks 3 times earlier, and it had failed every time. I just tried again, and this time it worked. I'm going to cross my fingers and hope it keeps working. Thanks!
(In reply to comment #51) > Well, I'm really confused now. I'd tried connecting to each of the two WPA > networks 3 times earlier, and it had failed every time. I just tried again, and > this time it worked. > > I'm going to cross my fingers and hope it keeps working. Thanks! However, that does mean 2.6.25.4-26.fc9 is actually able to connect, and does NOT throw code=18 error anymore? Right?
I was never seeing code=18; I was just unable to connect. I'm not sure if it was the same problem as other people were discussing - all I can say is that since a few months ago, I've been unable to connect to WPA networks at all. Right now is the first time it's worked since then.
Likewise. I have an HP2510p with iwl4965 * f8 at release - wireless worked * f8 after updates - wireless failed * f9 at release - wireless failed * f9 with kernel-2.6.25.4-30.fc9 from koji - wireless works again! So, in summary I think this update works at least superficially (there are still problems with loads of APs and NetworkManager, but those are for another time!)
I'm still seeing strange behavior. When I first tried -26 yesterday morning, I was unable to associate (after trying multiple times for each network). After seeing the message about trying again, I figured I'd give it another shot (while connected to the wired network), and it worked. After rebooting yesterday afternoon, it was unable to associate again. This morning, I tried connecting to each network 5 times, and had no luck. About 5 seconds after I gave up and plugged in an ethernet cable, the wireless connection started working. I can't think of any reason why the wireless network only seems to connect when there's also a wired connection, but it's happened twice now. The machine is a T61, and lspci claims the ethernet card is an Intel Corporation 82566MM Gigabit Network Connection (rev 03).
Guys at Intel claim they've fixed the issue. Could anyone confirm/deny? Details: http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1639
Please try these kernels, which are mostly up-to-date with upstream wireless: http://koji.fedoraproject.org/koji/buildinfo?buildID=50974
2.6.25.4-39.fc9.x86_64 fixes this now, thanks.
Hmm, may have spoken too soon. It works some times, but other times I get tons of: wlan0: RX deauthentication from 00:02:2d:65:0b:14 (reason=3) wlan0: RX deauthentication from 00:02:2d:65:0b:14 (reason=3) and it doesn't until I reboot. This happens with the older kernel too, so may be a separate bug.
(In reply to comment #57) > Please try these kernels, which are mostly up-to-date with upstream wireless: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=50974 I've finally managed to test it, and... it WORKS! :) When should we expect that kernel to be included into regular F9 updates? I'm really keen to install F9 on my work machine, that has iwl4965 on board.
It will take a little while for the normal updates process to push-out those (or later) kernels. You may want to watch for kernel package updates in Bodhi: https://admin.fedoraproject.org/updates When one shows-up you can add karma points in order to help get it pushed...thanks!
Kernel 2.6.25.4-30.fc9.i686 has just been thrown into regular F9 updates. Could someone confirm that iwl4965 does properly work and connects without code=18 error on that kernel?