Bug 175401
Summary: | iwlwifi intel 7260ac will not connect in 802.11ac | ||
---|---|---|---|
Product: | Drivers | Reporter: | john.frankish |
Component: | network-wireless | Assignee: | DO NOT USE - assign "network-wireless-intel" component instead (linuxwifi) |
Status: | CLOSED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | ilan.peer, linuxwifi, luca |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 4.2.9 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg
wpa_supplicant log wpa_supplicant-2.6 log wpa_supplicant log |
Description
john.frankish
2016-10-02 13:01:14 UTC
I check again using crda - the previous tests were made without crda loaded - but it does not make any difference. Under linux I cannot connect at anything greater than 6Mb/s on either 2.4GHz or 5GHz, whereas windows shows 867Mb/s (the theoretical maximum I guess) and appears to communicate at +/- 500Mb/s. From the dmesg output it appears that connecting to the WAP forces a crda change to Germany - I am in the UAE with the locale set to US. ---------- Intel(R) Wireless WiFi driver for Linux Copyright(c) 2003- 2015 Intel Corporation iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-7260-15.ucode failed with error -2 iwlwifi 0000:02:00.0: Falling back to user helper cfg80211: World regulatory domain updated: cfg80211: DFS Master region: unset cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz, 92000 KHz AUTO), (N/A, 2000 mBm), (N/A) cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) iwlwifi 0000:02:00.0: loaded firmware version 15.227938.0 op_mode iwlmvm iwlwifi 0000:02:00.0: Detected Intel(R) Dual Band Wireless AC 7260, REV=0x144 iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled iwlwifi 0000:02:00.0: L1 Enabled - LTR Enabled wlan0: authenticate with a0:55:4f:66:d5:18 wlan0: send auth to a0:55:4f:66:d5:18 (try 1/3) wlan0: authenticated wlan0: associate with a0:55:4f:66:d5:18 (try 1/3) wlan0: RX AssocResp from a0:55:4f:66:d5:18 (capab=0x411 status=0 aid=4) wlan0: associated cfg80211: Regulatory domain changed to country: DE cfg80211: DFS Master region: ETSI cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) cfg80211: (2400000 KHz - 2483500 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) cfg80211: (5150000 KHz - 5250000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (N/A) cfg80211: (5250000 KHz - 5350000 KHz @ 80000 KHz, 200000 KHz AUTO), (N/A, 2000 mBm), (0 s) cfg80211: (5470000 KHz - 5725000 KHz @ 160000 KHz), (N/A, 2698 mBm), (0 s) cfg80211: (5725000 KHz - 5875000 KHz @ 80000 KHz), (N/A, 1397 mBm), (N/A) cfg80211: (57000000 KHz - 66000000 KHz @ 2160000 KHz), (N/A, 4000 mBm), (N/A) $ iw reg get global country DE: DFS-ETSI (2400 - 2483 @ 40), (N/A, 20), (N/A) (5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW (5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW (5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS (5725 - 5875 @ 80), (N/A, 13), (N/A) (57000 - 66000 @ 2160), (N/A, 40), (N/A) $ iw dev wlan0 link Connected to a0:55:4f:66:d5:18 (on wlan0) SSID: bobnet freq: 2462 RX: 11879 bytes (100 packets) TX: 1373 bytes (9 packets) signal: -57 dBm tx bitrate: 6.0 MBit/s bss flags: short-preamble short-slot-time dtim period: 2 beacon int: 100 Sorry for the delay in replying. A couple of things here. First of all, how are you checking that you're not getting the expected bitrate? The value shown in "iw dev wlan0 link" only reflects the bitrate used in the last frame sent or so. The TX bitrate is changing all the time, to adjust to the RF environment you are in. Additionally, management frames can only be sent a lower bitrates (e.g. 6 Mbit/s). This problem explains why you only see 6.0 Mbit/s in the wlan0 link report. Try to check the actual throughput with a tool like iperf or such. Or you can try to use a sniffer to check the bitrate of more than just the last frame sent. Second, about regulatory. My guess is that your AP is reporting as being in Germany, thus the regulatory change after association. This should not affect bitrates at all, but it's not a very good idea to run an AP set to the wrong country, because you may break local regulations. If I check two locations using iperf-3.1.3 for linux and windows on the same hardware, I get: location 1 linux 49Mb/s windows 142Mb/s location 2 linux 92Mb/s windows 303Mb/s ..so whilst this is better than 6Mb/s, windows is consistently finding 3x the bandwidth on the same hardware in the same location. ..which makes me think windows is using 802.11ac and linux is using 802.11a/b/g/n, but how to tell and how to force linux to use 802.11ac? ---------- iperf results from linux: Location 1 $ iperf3 -c 192.168.1.200 Connecting to host 192.168.1.200, port 5201 [ 4] local 192.168.1.102 port 54168 connected to 192.168.1.200 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 5.28 MBytes 44.3 Mbits/sec 0 120 KBytes [ 4] 1.00-2.00 sec 6.64 MBytes 55.7 Mbits/sec 0 189 KBytes [ 4] 2.00-3.00 sec 5.91 MBytes 49.6 Mbits/sec 0 209 KBytes [ 4] 3.00-4.00 sec 5.74 MBytes 48.2 Mbits/sec 0 245 KBytes [ 4] 4.00-5.00 sec 6.52 MBytes 54.7 Mbits/sec 0 270 KBytes [ 4] 5.00-6.00 sec 6.22 MBytes 52.2 Mbits/sec 0 283 KBytes [ 4] 6.00-7.00 sec 5.60 MBytes 47.0 Mbits/sec 0 313 KBytes [ 4] 7.00-8.00 sec 6.29 MBytes 52.7 Mbits/sec 0 329 KBytes [ 4] 8.00-9.00 sec 5.52 MBytes 46.3 Mbits/sec 0 345 KBytes [ 4] 9.00-10.00 sec 5.64 MBytes 47.3 Mbits/sec 0 413 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 59.4 MBytes 49.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 57.9 MBytes 48.6 Mbits/sec receiver Location 2 $ iperf3 -c 192.168.1.200 Connecting to host 192.168.1.200, port 5201 [ 4] local 192.168.1.102 port 54198 connected to 192.168.1.200 port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 9.28 MBytes 77.8 Mbits/sec 0 141 KBytes [ 4] 1.00-2.00 sec 11.5 MBytes 96.2 Mbits/sec 0 209 KBytes [ 4] 2.00-3.00 sec 11.8 MBytes 98.7 Mbits/sec 0 256 KBytes [ 4] 3.00-4.00 sec 11.3 MBytes 95.0 Mbits/sec 0 363 KBytes [ 4] 4.00-5.00 sec 10.8 MBytes 90.9 Mbits/sec 0 444 KBytes [ 4] 5.00-6.00 sec 10.6 MBytes 88.7 Mbits/sec 0 467 KBytes [ 4] 6.00-7.00 sec 11.0 MBytes 92.4 Mbits/sec 0 467 KBytes [ 4] 7.00-8.00 sec 11.1 MBytes 93.0 Mbits/sec 0 467 KBytes [ 4] 8.00-9.00 sec 11.6 MBytes 97.6 Mbits/sec 0 467 KBytes [ 4] 9.00-10.00 sec 11.2 MBytes 94.3 Mbits/sec 0 467 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 110 MBytes 92.5 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 109 MBytes 91.1 Mbits/sec receiver iperf results from windows 10: Location Microsoft Windows [Version 10.0.14393] (c) 2016 Microsoft Corporation. All rights reserved. C:\WINDOWS\system32>C:\Users\J\Downloads\iperf\iperf-3.1.3-win64\iperf3 -c 192.168.1.200 Connecting to host 192.168.1.200, port 5201 [ 4] local 192.168.1.102 port 49824 connected to 192.168.1.200 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.01 sec 14.4 MBytes 120 Mbits/sec [ 4] 1.01-2.01 sec 17.9 MBytes 150 Mbits/sec [ 4] 2.01-3.00 sec 17.8 MBytes 150 Mbits/sec [ 4] 3.00-4.00 sec 16.2 MBytes 137 Mbits/sec [ 4] 4.00-5.00 sec 17.6 MBytes 148 Mbits/sec [ 4] 5.00-6.00 sec 18.2 MBytes 153 Mbits/sec [ 4] 6.00-7.00 sec 17.2 MBytes 145 Mbits/sec [ 4] 7.00-8.00 sec 16.4 MBytes 137 Mbits/sec [ 4] 8.00-9.00 sec 17.1 MBytes 144 Mbits/sec [ 4] 9.00-10.01 sec 16.8 MBytes 140 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.01 sec 170 MBytes 142 Mbits/sec sender [ 4] 0.00-10.01 sec 170 MBytes 142 Mbits/sec receiver Location 2 [ 4] local 192.168.1.102 port 49855 connected to 192.168.1.200 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 36.2 MBytes 303 Mbits/sec [ 4] 1.00-2.01 sec 35.2 MBytes 295 Mbits/sec [ 4] 2.01-3.00 sec 34.5 MBytes 291 Mbits/sec [ 4] 3.00-4.01 sec 37.1 MBytes 310 Mbits/sec [ 4] 4.01-5.00 sec 35.8 MBytes 301 Mbits/sec [ 4] 5.00-6.00 sec 32.5 MBytes 273 Mbits/sec [ 4] 6.00-7.00 sec 37.6 MBytes 316 Mbits/sec [ 4] 7.00-8.00 sec 37.9 MBytes 317 Mbits/sec [ 4] 8.00-9.00 sec 37.0 MBytes 311 Mbits/sec [ 4] 9.00-10.00 sec 37.5 MBytes 314 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth [ 4] 0.00-10.00 sec 361 MBytes 303 Mbits/sec sender [ 4] 0.00-10.00 sec 361 MBytes 303 Mbits/sec receiver Are you able to provide a sniffer capture of this? Just the connection and some data flow should be enough. Also, if you could capture trace-cmd logs as described here, it would be helpful: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging Could you explain what you mean by "sniffer capture" please? By "sniffer capture" I meant that you could use wireshark (or another so-called packet analyzer tool) on a different machine that has a WiFi NIC. You need to put its interface in monitor mode, e.g. "iw wlan0 set type monitor" and use wireshark to "sniff" on that interface. This should give us a capture of all the WiFi packets going out in the air so we can check what is going on. Let me know if you have a separate machine to run this and I can give you more detailed instructions. My colleague, Emmanuel, also suggested that you could try to disable power save mode. Windows doesn't have PS mode, so this could explain why you get better throughput there. You can disable PS mode by loading the iwlmvm module with "power_scheme=1". I tried loading the iwlmvm module with "power_scheme=1", but it did not appear to change anything - how do I verify the switch was accepted? I believe I can make a set up to monitor wlan0 with wireshark on another machine, but wouldn't I need to force iwlwifi to attempt to connect with 802.11ac - how do I do that? At the moment, I almost always get a connection in the 2.4GHz band. finally - using: "options iwlmvm power_scheme=1" in /etc/modprobe.conf "freq_list=5240" in the network section of the wpa_supplicant conf file ..I get iperf results consistant with those I see in windows. so apparently the supplicant was preferring the 2.4GHz somehow. I've noticed that if I move around so that in some cases the 2.4ghz signal strength is greater than the 5ghz signal strength and in other cases it is weaker, wpa_supplicant will almost always connect to 2.4ghz no matter what. In fact I have only seen one case (in many, many attempts) where wpa_supplicant connected to the 5ghz signal without forcing the issue in the conf file. In contrast, windows almost always connects to the 5ghz signal. This is an interesting finding. I suggest you ask the question on the hostap mailing list [1]. If you do, please CC me :) [1] - http://lists.infradead.org/mailman/listinfo/hostap It would be useful if you could share the wpa_supplicant log. It might help understand why one AP is preferred over the other. If you can, please run wpa_supplicant with -dd option. Created attachment 254765 [details]
wpa_supplicant log
To go with the log above. In this case the 2.4GHz signal was stronger, but it still connects to 2.4GHz if the 5GHz signal is stronger. $ sudo iwlist wlan0 scanning | egrep 'Cell |Channel|Encryption|Quality|Last beacon|ESSID' Cell 01 - Address: A0:55:4F:66:D5:18 Channel:8 Frequency:2.447 GHz (Channel 8) Quality=59/70 Signal level=-51 dBm Encryption key:on ESSID:"box" Extra: Last beacon: 86ms ago ... Cell 06 - Address: A0:55:4F:66:D5:10 Channel:48 Frequency:5.24 GHz (Channel 48) Quality=42/70 Signal level=-68 dBm Encryption key:on ESSID:"box" Extra: Last beacon: 86ms ago ... Created attachment 254769 [details]
wpa_supplicant-2.6 log
using sudo wpa_supplicant -dd -Dnl80211 -i wlan0 -c/etc/wpa_configure.conf
can you please rerun with -ddd? The sorted scan results are only printed in the highest debug level. Created attachment 254783 [details]
wpa_supplicant log
sudo wpa_supplicant -ddd -Dnl80211 -i wlan0 -c/etc/wpa_configure.conf
Note that after getting the log above, I killed wpa_supplicant, forced 5GHz and restarted. As per iperf (results at the end of the log), leaving wpa_supplicant to its own choice have a throughput of +/- 50mb/s whereas forcing 5GHz gave a throughput of +/- 200mb/s Hi, According to the wpa_supplicant AP scoring, it would indeed seem that the 2.4GHz AP is proffered since it has better SNR (although the SNR for both is good). a0:55:4f:66:d5:18 freq=2447 qual=0 noise=-89~ level=-49 snr=40* flags=0xb age=0 est=65000 a0:55:4f:66:d5:10 freq=5240 qual=0 noise=-92~ level=-67 snr=25 flags=0xb age=0 est=390001 Regards, Ilan. The fact that I get four times the throughput without changing anything except the frequency would seem to indicate that the wpa_supplicant algorithm could use some adjustment? Using: --- wpa_supplicant/scan.c.orig 2017-02-16 13:39:16.809997441 +0000 +++ wpa_supplicant/scan.c 2017-02-16 13:39:53.536663769 +0000 @@ -1738,7 +1738,7 @@ * recommends 25 as a minimum SNR for 54 Mbps data rate. 30 is chosen here as a * conservative value. */ -#define GREAT_SNR 30 +#define GREAT_SNR 25 #define IS_5GHZ(n) (n > 4000) ..wpa_supplicant now chooses the 5GHz connection where it previously chose 2.4GHz |