User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3) Gecko/20090327 Fedora/3.1-0.11.beta3.fc11 Firefox/3.1b3 Try to connect to a channel 13 wlan with NetworkManager cause an Microcode SW error in the first time. The connection seam to be establish (e. g. NW shows up all information like bit rate, link quality and so on) also an ip address will provided trough dhcp, but I can not ping any device in the network. If I do a reconnect over NW (click again on the already used wireless network) brings back the connection (and also a new ip by dhcp). But after a couple of hours the connection fails with the same behavior. Connection to wlan in the us channel range (1-11) has not the problem and is stable over all. Reproducible: Always Steps to Reproduce: 1. Start up the system and try to connect to a channel 13 wlan Actual Results: NW try to access to the wlan over channel 13, after received the offer from dhcp the connection gets broken with an "Microcode SW error detected" message in dmesg. Expected Results: Connect to WLAN over Channel 13 should work without problems, like connection to channel 1 to 11 module iwlagn runs with the debug option "debug50=0x43fff" so the attached "microcode_sw_error" contains the IWL Error Log Dump and the IWL Event Log Dump.
Created attachment 338667 [details] iwlagn debug50=0x43fff output with IWL error and event log
Created attachment 338668 [details] dmesg from start up with "Microcode SW error detected" message
If I may ask, where (i.e. in what country) did you acquire your iwlagn device?
Thanks for the quick response! It's a Dell Latitude E6400 with I bought in Germany. I think I know why you ask. If I understand this correct, the iwlagn device has an option (with is hidden or not changeable by user) to lock or unlock the frequencies for other regions like Europe or Japan. I also read sometimes that no way exist to determine witch channels are usable or not. Or I completely wrong? Anyway, it seams that the driver set the region correct: Apr 8 09:50:45 venetus kernel: cfg80211: Calling CRDA for country: DE Apr 8 09:50:45 venetus kernel: cfg80211: Regulatory domain changed to country: DE Apr 8 09:50:45 venetus kernel: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Apr 8 09:50:45 venetus kernel: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm) Apr 8 09:50:45 venetus kernel: (5150000 KHz - 5255000 KHz @ 40000 KHz), (N/A, 2301 mBm) Apr 8 09:50:45 venetus kernel: (5470000 KHz - 5650000 KHz @ 40000 KHz), (N/A, 3000 mBm) And I'm also able do use the connection over Channel 13 (in the second try of course), therefore I think that my iwlagn device is "unlocked" for theses Channels. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes, the Intel wireless hardware will refuse to operate on channels for which it was not certified. So if you were using a USA device then you would not be able to use channel 13. I have no other suggestions ATM. Hopefully Reinette will have an idea...
(In reply to comment #4) > Thanks for the quick response! > > It's a Dell Latitude E6400 with I bought in Germany. > > I think I know why you ask. If I understand this correct, the iwlagn device has > an option (with is hidden or not changeable by user) to lock or unlock the > frequencies for other regions like Europe or Japan. There is no secret option. The regulatory information is programmed into the eeprom during manufacturing and cannot be changed. > I also read sometimes that > no way exist to determine witch channels are usable or not. Or I completely > wrong? You can see what is read from eeprom when you load the driver with debug50=0x1. See information printed when you bring interface up. > > Anyway, it seams that the driver set the region correct: > > Apr 8 09:50:45 venetus kernel: cfg80211: Calling CRDA for country: DE > Apr 8 09:50:45 venetus kernel: cfg80211: Regulatory domain changed to country: > DE > Apr 8 09:50:45 venetus kernel: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp) > Apr 8 09:50:45 venetus kernel: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, > 2000 mBm) > Apr 8 09:50:45 venetus kernel: (5150000 KHz - 5255000 KHz @ 40000 KHz), (N/A, > 2301 mBm) > Apr 8 09:50:45 venetus kernel: (5470000 KHz - 5650000 KHz @ 40000 KHz), (N/A, > 3000 mBm) crda is not able to override what is programmed into eeprom.
Thanks for this detailed information. I'm sure that I never seen this information about the regulatory information before. So if i understand this correct, the following message (after bringing up the device with debug=50x1): ieee80211 phy1: U iwl_init_channel_map Ch. 13 [2.4GHz] VALID WIDE (0x61 15dBm): Ad-Hoc not supported ieee80211 phy1: U iwl_init_channel_map Ch. 14 Flags 0 [2.4GHz] - No traffic Means that channel 13 can be used with my iwlagn, but channel 14 not. After the end of showing up many combination's of channels and frequencies: iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels What confirms the messages above. So it seams, in relation to this but, that my iwlagn hardware is able to use the channel 13. But fails there with a firmware error. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #7) > Thanks for this detailed information. I'm sure that I never seen this > information about the regulatory information before. > > So if i understand this correct, the following message (after bringing up the > device with debug=50x1): > > ieee80211 phy1: U iwl_init_channel_map Ch. 13 [2.4GHz] VALID WIDE (0x61 15dBm): > Ad-Hoc not supported > ieee80211 phy1: U iwl_init_channel_map Ch. 14 Flags 0 [2.4GHz] - No traffic > > Means that channel 13 can be used with my iwlagn, but channel 14 not. > > After the end of showing up many combination's of channels and frequencies: > iwlagn: Tunable channels: 13 802.11bg, 24 802.11a channels > What confirms the messages above. > > So it seams, in relation to this but, that my iwlagn hardware is able to use > the channel 13. But fails there with a firmware error. > indeed it allows using those channels, but not for active scanning or beaconing. The "no beaconing" restriction prevents you from running ad-hoc on that channel and the "no active scanning" restriction prevents you from discovering the neighborhood from probe requests as is done in the driver and mac80211.
It sounds like things are actually working more-or-less as designed...
Currently yes. The new mac80211 ability to specify multiple ssids for scanning does create the ability to request passive scanning. We do have patches pending to support true passive scanning. It is currently in our repo but we have some issues getting our acceptance tests to pass in -rc1. We will send those to wireless-testing as soon as our general acceptance test passes.
(In reply to comment #10) > Currently yes. The new mac80211 ability to specify multiple ssids for scanning > does create the ability to request passive scanning. We do have patches pending > to support true passive scanning. It is currently in our repo but we have some > issues getting our acceptance tests to pass in -rc1. We will send those to > wireless-testing as soon as our general acceptance test passes. Thanks for the details. I'm very interesting to help for testing these patch(es) (of course only if testing help is needed and you have enough patience to help me a little bit). Did you mean the commit c64cdcd51c7846375bea6e0b992f709d362ea802 for "iwlwifi: support truly passive scanning" that should fix the problem? Would it help to get kernel-2.6.30-rc2 + the /drivers/net/wireless/iwlwifi/iwl-scan.c from the commit above compiled for a quick test ? @John: To do this if prefer to work with the guide[1] and kernel-2.6.30-0.57.rc2.fc12.src.rpm from koji + change of iwl-scan.c . Right? Again, thank you for your time and work on this! [1] https://fedoraproject.org/wiki/Building_a_custom_kernel -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Niels, yes I think that will get you a properly changed kernel.
(In reply to comment #11) > (In reply to comment #10) > > Currently yes. The new mac80211 ability to specify multiple ssids for scanning > > does create the ability to request passive scanning. We do have patches pending > > to support true passive scanning. It is currently in our repo but we have some > > issues getting our acceptance tests to pass in -rc1. We will send those to > > wireless-testing as soon as our general acceptance test passes. > > Thanks for the details. I'm very interesting to help for testing these > patch(es) (of course only if testing help is needed and you have enough > patience to help me a little bit). > > Did you mean the commit c64cdcd51c7846375bea6e0b992f709d362ea802 for "iwlwifi: > support truly passive scanning" that should fix the problem? Would it help to > get kernel-2.6.30-rc2 + the /drivers/net/wireless/iwlwifi/iwl-scan.c from the > commit above compiled for a quick test ? You also need bde3e6ab1ccfb62b486bb1dbda989a46131fcd22 "iwlwifi: improve scan support" and perhaps 5a62e51aff70ea644e9a71980e980c6999dec474 "iwlwifi: rename PROBE_OPTION_MAX_API1 to PROBE_OPTION_MAX_3945". You also need a way from userspace to request a "true passive scan", which I think is only possible with nl80211 (not with "iwlist"). I also do not think iw supports this at this time.
Just for information. The new firmware for the Intel 5300AGN (iwlwifi-5000-ucode-8.24.2.12.tgz) don't fix the problem, the error is the same. But I try it again with the compat-wireless release from 2009-06-01. And it work like a charm. After hours of stress testing the wireless link stays stable an no firmware error occurs. John, is it possible to back port the changes who are done in compat-wireless (I only give it a try with 2009-06-01, no older one) to F11. Or did you know if these changes are already in the upcoming 2.6.30 kernel are available? Thanks anyone who as accomplished this. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
There are several hundred changes between 2.6.30 and what is currently in wireless-testing/compat-wireless. I used to push that volume of changes into Fedora, but not anymore. :-) I would of course consider a handful of changes, but I'm not sure we have identified specific patches that solve this issue.
After reading http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1988 it seems that the patch below could be the one. commit 83acd0f2b1eb9c12d51b43a630c5e4b7971e8b11 Author: Wey-Yi Guy <wey-yi.w.guy> Date: Fri May 22 11:01:49 2009 -0700 iwlwifi: support "pure 40MHz" in RXON command Fix the bug when using 11n "pure 40MHz" mode cause uCode crashing by adding support for "pure 40MHz" in RX_ON command flag. the "mode" field (bits 25:26) has value of 0-3 0 = 20 MHz only 1 = 40MHz only 2 = Mixed 3 = Reserved Control Channel ID (bit 22) is valid only in Mixed mode. Signed-off-by: Wey-Yi Guy <wey-yi.w.guy> Signed-off-by: Reinette Chatre <reinette.chatre> Signed-off-by: John W. Linville <linville>
Created attachment 346941 [details] check for valid 40MHz fat channel We have this additional patch for this issue that is not upstream yet.