Description of problem: WPA2 Connection fails when AP is B/G/N with kernels newer than 2.6.25.14-28.fc8. All works fine when AP is set to B/G mode (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. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Set AP to B/G/N (I am using cisco /Linksys WRT160) 2. Boot kernel 2.6.26.x 3. Attempt a WPA2 connection with either wpa_supplicant or NM 4. Change AP setting to B/G - all works fine with newer kernels Actual results: Connects briefly (or not at all) - then ceases to work. Expected results: Should work whether the AP is in B/G or B/G/N mode. Additional info: Works fine with earlier kernels - 2.6.25.14-28.fc8 works fine.
Have you tried an F9 kernel?
I thought the 2.6.26.x kernels in F8 and F9 were the same ? I see a 2.6.27 in updates-testing for F9 - is that what you meant ?
Yes, please.
Ok when I try install the F9 kernel-PAE-2.6.27.4-26.fc9 kernel on F8 it tells me: Failed dependencies: mkinitrd >= 6.0.39-1 is needed by kernel-PAE-2.6.27.4-26.fc9.i686 kernel-firmware >= 2.6.27.4-26.fc9 is needed by kernel-PAE-2.6.27.4-2 Is it safe to install these 2 packages ? Is the mkinitrd backward compatible with the older F8 kernels so when I go back all will boot/work ok? I would imagine so but I'd like to check .. this laptop is rather important. As of now there is no such F8 kernel-firmware package and my mkinitrd is mkinitrd-6.0.19-4.fc8.
Pulling in mkinitrd will require a bunch of other bits -- nevermind.
sorry for the noise, trying to figure out why python-bugzilla chokes on this, I think the subject contained some unicode character or something.
Not too different, but can you add this to /etc/modprobe.conf? options iwlagn 11n_disable=1 Follow that with 'modprobe -r iwlagn ; modprobe iwlagn'. Now enable .11n on your AP. Are you able to associate (even though it is not in 11n mode)?
I will do this this when I get access to an N AP - (this evening east coast time) - however this machine is F8 and I do not have 2.6.27 yet - I believe the module is iwl4965 - is iwlagn the correct option for kernel 2.6.26.6-49.fc8PAE ? There's a possibility I can put F10 on this in the next few weeks as well - I will report on that when I am able. thanks.
In that case, use iwl4965 -- I think it has that option too.
Ok done. (i) Took me 7 tries before it connected to the N AP sitting next to the laptop - it insisted on sticking to the BG AP 100 feet away. (ii) Once connected to the AP set to BGN mode - (with 11n disabled) as above - I downloaded a 512 MiB file because the previous testing indicated it would connect but start failing fairly soon with traffic. So far this connection (over 3 mins) has remained solid. I used wpa_supplicant directly.
Hey, thanks for the test report. So it sounds like 11n_disable=1 has a similar effect as disabling .11n on the AP. That may help to narrow-down the fault.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
FWIW, the 2.6.27.x kernels (where x > 8?) should have a fix that corrects this issue. Of course, those are only built for Fedora 9 and 10. It doesn't look practical to backport that fix to the Fedora 8 kernels -- I'm sorry.