Description of problem: On kernel 2.6.24.3-50, the iwl3945 driver fails association with AP. See the attached dmesg output. When I try to setup the connection manually (i.e. I stop the NM and type "ifup wlan0"), I get: Error for wireless request "Set Encode" (8B2A) : SET failed on device wlan0 ; No such file or directory. I didn't touch anything manually, except that after an upgrade to 2.6.24.3-34 I renamed wlan0_rename back to wlan0 (under /etc/sysconfig/...). The last working (concerning wireless) kernel for me is still 2.6.23.15-137. Version-Release number of selected component (if applicable): 2.6.24.3-50 How reproducible: Just boot up, try to setup the wifi either by NM or manually as described. Actual results: The association request is timed out. Expected results: It will associate to the AP, get IP address...work:)
Created attachment 298953 [details] dmesg output
Please attach the output of "iwlist wlan0 scan", and of "iwconfig wlan0". Thanks!
>iwlist wlan0 scan wlan0 No scan results >iwconfig wlan0 wlan0 IEEE 802.11 ESSID:"wlan_fi" Mode:Managed Frequency:2.442 GHz Access Point: 00:02:2D:1B:42:F6 Bit Rate=11 Mb/s Tx-Power=15 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Link Quality=68/100 Signal level=-65 dBm Noise level=-127 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 !!! I've tried this on a different network (cannot do it today on the same as when filing this bug) and checked also the dmesg output which is quite different -- there is some additional info, so I attach this dmesg too. Thank you in advance!
Created attachment 299145 [details] Another dmesg output on a different network.
Honestly, it looks like you have wpa_supplicant and NetworkManager fighting over control of your wireless device. Please make sure that the wpa_supplicant server is not running -- NetworkManager will start its own copy as necessary. service wpa_supplicant stop chkconfig wpa_supplicant off You probably want to make sure NetworkManager is set to start automatically as well: chkconfig NetworkManager on Also, make sure to run system-config-network and make sure "Activate device when computer starts" is _not_ selected for your wireless devices. Be sure to save the configuration when quitting system-config-network! After completing the steps above (as root, of course) then please reboot. Is your wireless connection behaving better now?
I'm afraid it's not the case. wpa_supplicant is (and has ever been) disabled: >chkconfig --list wpa_supplicant wpa_supplicant 0:off 1:off 2:off 3:off 4:off 5:off 6:off NM is enabled: >chkconfig --list NetworkManager NetworkManager 0:off 1:off 2:off 3:on 4:on 5:on 6:off "Activate device when computer starts" has not been selected. However, "Controlled by NM" has also not been selected -- I've selected it, saved, reboot, no change. If I can supply any additional debug information, just let me know. Maybe a dmesg from the working 2.6.23.15-137 kernel?
Please post the contents of your /etc/modprobe.conf. The iwconfig output in comment 3 shows an association. Is this problem intermittent? Does it depend on the type of encryption involved? Could there just be a weak signal? When you have problems, could you try 'modprobe -r iwl3945 ; modprobe iwl3945' -- does that change things?
>Please post the contents of your /etc/modprobe.conf. alias scsi_hostadapter ata_piix alias scsi_hostadapter1 ahci alias snd-card-0 snd-hda-intel options snd-card-0 index=0 options snd-hda-intel index=0 remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-hda-intel # added by kvpnc, do not edit it. alias ppp-compress-18 ppp_mppe alias eth0 sky2 >The iwconfig output in comment 3 shows an association. Is this problem intermittent? I don't think so: I tried it many times, it has never suceeded. >Does it depend on the type of encryption involved? I don't know since none of the networks I've tested uses encryption. >Could there just be a weak signal? Surely no (tested 3 networks, in 2 of them the distance between my laptop and the AP was < 5m). >When you have problems, could you try 'modprobe -r iwl3945 ; modprobe >iwl3945' -- does that change things? That's what I try everytime (sometimes also restarting NM after rmmod&modprobe helps), in this case without any success. But I have to correct myself concerning the latest working kernel: I found out that 2.6.24.2-4 works for me, but only before suspend&resume to RAM. After STR it works in about 25% of cases (and it will be surely a completely different problem as usually in STR issues). When I tested this kernel before, I didn't realize that my laptop has been resumed from RAM before, sorry for that. So I tried all the kernels after 2.6.24.2-4 and here is what I found out. 2.6.24.2-4 - works, sometimes also after STR 2.6.24.2-5 - N/A (Koji build failed) 2.6.24.2-6 - works, works after STR & rmmod & modprobe 2.6.24.2-7 - works like a charm, even after STR! 2.6.24.2-8 - N/A (not in Koji) 2.6.24.2-9 - N/A (not in Koji) 2.6.24.2-10 - NEVER works (again, association timed out) So probably the problem is between the release 7 and 10. I also posted dmesg from 2.6.24.2-10, though I doubt there will be any new information.
Created attachment 299713 [details] dmesg output with 2.6.24.2-10
Just see that even 2.6.24.2-7 has a small issue -- it's not possible to bring up the wifi manually as "ifup wlan0" results in: >ifup wlan0 Error for wireless request "Set Mode" (8B06) : SET failed on device wlan0 ; Invalid argument.
Please try 2.6.24.4-69.fc8: http://koji.fedoraproject.org/koji/buildinfo?buildID=44648 Does that work any better for you?
Sorry for late answer, I Tested -64, -69, -74 with no success. But the problem seems to depend on what AP is used as I found a network where I CAN connect with no problems with these kernels. Currently I know the results from following AP's: Asus WL-550gE (works) Ovislink WL-5460AP (does NOT work) D-Link DAP-1160 (does NOT work) I also tested on f9 (on another partition, fresh install f9 beta and update to latest rawhide) with the Ovislink, it didn't work too. Is there any way how to further debug these things on those non-working AP's?
One more AP notice: Ovislink WT-2000R with WPA PSK works...
Today I tried kernel-2.6.25-0.224.rc9.fc9.x86_64 and it works perfectly with both of the previously non-working AP's. Looking into its changelog, I see: * Sat Apr 12 2008 Chuck Ebbert <cebbert> - 2.6.25-rc9 - Temporarily disabled wireless patches. I guess this is why it works now:) Please could you review these patches, especially those added between the 2.6.24.2-7 and 2.6.24.2-10 when it stopped working for me?
Fine, after reenabling the patches, it didn't work again (as expected), but now the D-link works with both kernel-2.6.25-10.fc9.x86_64 on rawhide/F9 and kernel-2.6.24.5-87.fc8.x86_64 on F8. On wednesday I'll be able to test also the Ovislink AP, if it will work, I'll be happy to be able to close this bug:)
I look forward to your report! :-)
Sorry for a small delay and bad news: I'm very sorry but with the Ovislink it still doesn't work. Neither it doesn't see the network (i.e. "iwlist wlan0 scan" doesn't show it), nor it is listed in the output from "iwconfig wlan0". Just to be sure that there is no other problem, I tried (again) to connect to that network with kernel-2.6.24.2-7 and with another laptop which has an Atheros and uses the madwifi driver, both solutions work fine.
Not showing up in "iwconfig wlan0" cannot be related to the AP. Are you sure it the driver is loaded?
OK, I think I've found the reason -- the network runs on channel 13 which has been obviously disabled in the driver. I've attached the outputs from "iwlist wlan0 freq" (2.6.24.2-7.fc8.freq and 2.6.24.5-87.fc8.freq), please look at the differences. This explains, why I can connect with kernel-2.6.24.2-7 without any problems, but don't see the network with kernel-2.6.24.5-87.fc8 -- after changing the channel on the AP to 10, I can connect too. Is there any reason why some of the channels are disabled now or is it just a bug?
Created attachment 304453 [details] Output of "iwlist wlan0 freq" on kernel-2.6.24.2-7.fc8
Created attachment 304454 [details] Output of "iwlist wlan0 freq" on kernel-2.6.24.5-87.fc8
The kernel defaults to the US regulatory domain, which excludes channel 13. The only other regulatory domain the kernel currently knows about is for Japan ("JP"), which you can select in /etc/modprobe.conf: options cfg80211 ieee80211_regdom="JP" Please ensure that you do not use any wireless configuration disallowed by local regulations. BTW, there used to be a similar option for the mac80211 module. The related functionality got moved to cfg80211. Perhaps you already have a similar option in modprobe.conf? That would explain why older kernels work for you.
No, I don't think my modprobe.conf contains something related (see attached). If it is by default set to US regulatory domain constraints, then it seems to be a bug for me, because I've found following regulatory domain constraints which differ a lot: USA (FCC): Channels 1-11 Canada (IC): Channels 1-11 Europe (ETSI): Channels 1-13 Japan (TELEK): Channels 1-13 Japan (MKK): Channel 14 France: Channels 10-13 Spain: Channels 10-11 In Europe we have some additional constraints, as mentioned e.g. here: "The channels that are available for use in a particular country differ according to the regulations of that country. In the United States, for example, FCC regulations only allow channels 1 through 11 to be used. In Europe channels 1-13 are licensed for 802.11b operation but only allow lower transmitted power (only 100 mW) to reduce the interference with other ISM band users." (http://wiki.freeradius.org/IEEE_802.11) Moreover, if I've understood it right, then according to IEEE 802.11d standard it should be possible to determine current regulatory constraints runtime, is it not implemented yet? Anyway, restricting some channels apriori doesn't seem to be a good idea for me (just notice that on that AP channel 13 has been preset as default from factory!), as it may really confuse users (like I was) when they do not see their network at all:) It could be also probably worth investigating why older kernels worked for me, i.e. where is the change. But this is definitely a completely different problem, so I'll file a new bug, ok? I'm also changing the state to MODIFIED and assume that you'll set this bug to be autoclosed when a new update will be pushed. Thanks for all the work!
Created attachment 304548 [details] modprobe.conf
Actually setting it to MODIFIED makes it drop off my radar. I'm going to go ahead and close it as NOTABUG as it is actually working as currently designed, even if the current design is a bit flawed. :-) There are plans to implement a more flexible regulatory scheme upstream, but it is not yet implemented.
Eh...sorry for bothering you with one more post: ok, but we're mixing two different things together: - the first problem concerns the failing association with D-Link AP. This is FIXED, CURRENTRELEASE (2.6.24.5-85 and higher, in my experience). - the second concerns the regulatory stuff, it's NOTABUG in respect to your previous comment. I've just one more question: wouldn't it be better to completely DISABLE this regulatory constraints until it will be implemented properly?! Again: it can prevent users from using their wireless connection. The very simple fix might be to set "options cfg80211 ieee80211_regdom="JP" by default -- if it doesn't have any side-effects.
FYI: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/13803 If it really depends on you as mentioned, then here is a tiny unimportant vote for it:)
Something has to be the default and from a legal perspective it is probably better to default to not doing something you are allowed to do than the other way around. As for the "EU" domain, it is still under consideration. Apparently not all of the EU is under ETSI's jurisdiction, so there was some objection to the naming. Also there is still the hope of moving to regulatory policing done in userland.