Hide Forgot
Description of problem: 802.11n APs do not appear under iwlist scan, and are not available. Version-Release number of selected component (if applicable): How reproducible: NetworkManager start. "iwlist wlan0 scan" fails to show 802.11n APs. Only shows 802.11g APs. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Split off from Bug #699434 https://bugzilla.redhat.com/show_bug.cgi?id=699434
If you do: iw reg set US does it show 802.11a APs ?
Not sure about 11a, but that command suddenly makes it seem to see the 802.11n networks now... and I can connect (!). For example, now I can connect to a 5.745 GHz (Channel 149) 802.11n AP network. Does that fix it somehow / is that command needed now? [root@willow ~]# tail -f /var/log/messages & [root@willow ~]# iw reg set US [root@willow ~]# (here's /var/log/messages:) Aug 17 01:52:35 willow kernel: [ 232.364975] cfg80211: Calling CRDA for country: US Aug 17 01:52:35 willow kernel: [ 232.388674] cfg80211: Regulatory domain changed to country: US Aug 17 01:52:35 willow kernel: [ 232.388678] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) Aug 17 01:52:35 willow kernel: [ 232.388681] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2700 mBm) Aug 17 01:52:35 willow kernel: [ 232.388684] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 1700 mBm) Aug 17 01:52:35 willow kernel: [ 232.388687] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Aug 17 01:52:35 willow kernel: [ 232.388690] cfg80211: (5490000 KHz - 5600000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Aug 17 01:52:35 willow kernel: [ 232.388692] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 2000 mBm) Aug 17 01:52:35 willow kernel: [ 232.388695] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 3000 mBm) [root@willow ~]# iwlist wlan0 scan | grep -B 4 ESSID Channel:2 Frequency:2.417 GHz (Channel 2) Quality=39/70 Signal level=-71 dBm Encryption key:on ESSID:"CoolestApartmentontheBlock" -- Channel:1 Frequency:2.412 GHz (Channel 1) Quality=26/70 Signal level=-84 dBm Encryption key:on ESSID:"Dublin" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=60/70 Signal level=-50 dBm Encryption key:on ESSID:"daimonia" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=35/70 Signal level=-75 dBm Encryption key:on ESSID:"11FX02176527" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=47/70 Signal level=-63 dBm Encryption key:on ESSID:"kathleen" -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=30/70 Signal level=-80 dBm Encryption key:on ESSID:"Binx" -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=24/70 Signal level=-86 dBm Encryption key:on ESSID:"OneOhFour" -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=42/70 Signal level=-68 dBm Encryption key:on ESSID:"Adrienne" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=30/70 Signal level=-80 dBm Encryption key:on ESSID:"badcats" -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=24/70 Signal level=-86 dBm Encryption key:on ESSID:"TQQMB" -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=32/70 Signal level=-78 dBm Encryption key:on ESSID:"YPBLB" -- Channel:149 Frequency:5.745 GHz (Channel 149) Quality=42/70 Signal level=-68 dBm Encryption key:on ESSID:"ouranos" -- Channel:11 Frequency:2.462 GHz (Channel 11) Quality=60/70 Signal level=-50 dBm Encryption key:on ESSID:"ProNet" -- Channel:1 Frequency:2.412 GHz (Channel 1) Quality=26/70 Signal level=-84 dBm Encryption key:on ESSID:"fuenfnullvier" -- Channel:1 Frequency:2.412 GHz (Channel 1) Quality=18/70 Signal level=-92 dBm Encryption key:off ESSID:"Free Public WiFi" -- Channel:1 Frequency:2.412 GHz (Channel 1) Quality=20/70 Signal level=-90 dBm Encryption key:on ESSID:"9134" -- Channel:3 Frequency:2.422 GHz (Channel 3) Quality=27/70 Signal level=-83 dBm Encryption key:on ESSID:"frognet" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=23/70 Signal level=-87 dBm Encryption key:on ESSID:"Artemis" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=18/70 Signal level=-92 dBm Encryption key:on ESSID:"drizzy" -- Channel:6 Frequency:2.437 GHz (Channel 6) Quality=22/70 Signal level=-88 dBm Encryption key:on ESSID:"473LB" -- Channel:10 Frequency:2.457 GHz (Channel 10) Quality=31/70 Signal level=-79 dBm Encryption key:on ESSID:"magicanne" --
Ehh, I meant 11n (11a is kind a old, but it also works an 5GHz) What show "iw reg get" when you reboot the system? Also please provide dmesg.txt from following commands: modprobe -r iwl4965 modprobe iwl4965 debug=0x4041 dmesg > dmesg.txt
Created attachment 518794 [details] dmesg.txt Result of: modprobe -r iwl4965 modprobe iwl4965 debug=0x4041 dmesg > dmesg.txt
Ok, so: (1) Rebooted the machine, back to original issue, no 802.11n APs visible or available. (2) Result of "iw reg get": [root@willow ~]# iw reg get country GB: (2402 - 2482 @ 40), (N/A, 20) (5170 - 5250 @ 40), (N/A, 20) (5250 - 5330 @ 40), (N/A, 20), DFS (5490 - 5710 @ 40), (N/A, 27), DFS PS, I'm in the U.S. by the way, if this is a symptom of the issue here(?) (3) Result of modprobe attached, above, in dmesg.txt Thanks, TL
Yes, this is regulatory issue, seems all your n-capable APs transmit on channels that are not available in GB regulatory domain. I'm not sure if regulatory information is properly read from card eeprom, or we do not have some other bug. Unfortunately dmesg buffer was too small and messages overwrite so I do not see all needed information. Please do the following: Add this line in /etc/rsyslog.conf kern.* /var/log/kernel Restart syslog service: /etc/init.d/rsyslog restart Gather debug messages: modprobe -r iwl4965 echo > /var/log/kernel modprobe iwl4965 debug=0x4041 modprobe -r iwl4965 and attach /var/log/kernel file.
Created attachment 518966 [details] output of /var/log/kernel Done -- attached file /var/log/kernel, results of: # line added to /etc/rsyslog.conf kern.* /var/log/kernel /etc/init.d/rsyslog restart modprobe -r iwl4965 echo > /var/log/kernel modprobe iwl4965 debug=0x4041 modprobe -r iwl4965
I do not see anything wrong in debug messages. I think bad regulatory domain come from user space. Regdomain is setup by /sbin/setregdomain script. It read files /etc/sysconfig/regdomain file or if it is empty, use time zone information from /etc/sysconfig/clock. To solve this problem you can add "COUNTRY=US" line to /etc/sysconfig/regdomain or configure time zone corresponding to your geographical location (preferred), you can do it using system-config-date command (as root)
I'm closing bug as seems issue here is bad time zone setting. Reopen bug if correcting zone setting do not help.