wifi.sh does not connect wap frequency chosen in list

[Juanito]

If I use the wifi extension to connect to a wap with both 2.4ghz and 5ghz bands, where the ssid is the same for both bands, it looks like wifi.sh connects to the first matching ssid in the list rather than the one chosen.

This would seem likely to mean that the often stronger signal, but slower 2.4ghz connection is used rather than the often weaker signal, but faster 5ghz connection.

Has anybody seen the same issue?

Can anybody better at scripting/wifi than me propose a modification to wifi.sh to force it to use the ssid/frequency chosen from the list of available wap?

Note that this part of an ongoing campaign to find out why the throughput, as measured with iperf, is at least 3x faster under windows as compared to tinycore on the same machine in the same physical location.

Of course this could also be an issue with the iwlwifi driver...

[coreplayer2]

There's something amiss with that picture....  Having the same SSID for both bands isn't common AFAIK
Isn't it logical to isolate the bands by different SSID?

I'm not even sure if my router will allow same SSID, but I'm curious to try


Sent from my iPhone using Tapatalk

[Juanito]

I see that I can force the issue using the line "freq_list=5240" (corresponding to channel 48 on the wap) in a manual wpa_supplicant conf file.

My thinking on using the same ssid was that different devices could connect according to their capabilities and how far they were from the wap.

[Juanito]

ah-ha, with

Code: [Select]

# /etc/modprobe.conf: Modprobe config file.
#
options iwlmvm power_scheme=1
..and "freq_list=5240":

Code: [Select]

$ iw dev wlan0 link
...
        SSID: box
        freq: 5240
        RX: 728432 bytes (517 packets)
        TX: 31118 bytes (270 packets)
        signal: -66 dBm
        tx bitrate: 390.0 MBit/s VHT-MCS 4 80MHz short GI VHT-NSS 2
..things are looking up 

[coreplayer2]

   good job

We learn something new everyday right?   You can indeed use the same SSID on all Bands. There appears to be recommendations to use separate SSID's for identification and troubleshooting purposes at a minimum, but that as you say will prevent switching or reconnecting from the shorter range band to the greater range band.  I guess it depends on the size of your home??

Most Dual band routers will offer the most desirable band to the connecting equipment, at least mine does.

[hiro]

you said "same ssid", the only difference should thus be the bssid. it is possible to add one entry per bssid and prioritize the one you have figured out is more stable/faster.

[Juanito]

Hmm - I've now found examples where the 5ghz signal strength is both higher and lower than the 2.4ghz signal strength, but regardless of this, wifi.sh seems to always connect to the 2.4ghz channel.

One example:

Code: [Select]

$ sudo wifi.sh
...
Select Wifi Network

    ESSID                         Enc   Qual    Channel Type           
 1. AliNetwork                     on    63       5     
 2. dlink-EF18                     on    43       2     WPA
 3. box                            on    41      48     WPA
 4. Ellas Network                  on    39       1     WPA
 5. Omar                           on    38       6     WPA
 6. box                            on    30       8     WPA
 7. dlink101                       on    30      11     WPA
 8. CYX                            on    25       5     WPA

Enter selection ( 1 - 8 ) or (q)uit: 3


$ iwconfig wlan0
wlan0     IEEE 802.11abgn  ESSID:"box" 
          Mode:Managed  Frequency:2.447 GHz [i.e. channel 8]
I've looked at the wifi.sh script for a while now, but have still failed to spot why this should be.

On the upside, when I force things manually with with "options iwlmvm power_scheme=1" and "freq_list=5240":

Code: [Select]

$ iperf3 -s [other end]
...
Server listening on 5201

$ iperf3 -c 192.168.1.108
Connecting to host 192.168.1.108, port 5201
[  4] local 192.168.1.101 port 54396 connected to 192.168.1.108 port 5201
...
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   219 MBytes   184 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   217 MBytes   182 Mbits/sec                  receiver
..which is now consistent with what I see with windows on the same machine in the same location 

[Juanito]

It seems the problem may be with wpa_supplicant rather than wifi.sh

Except that, unless my laptop is next to the wap, wpa_supplicant seems to do the opposite of this:

Q: Does anybody know why wpa_supplicant seems to prefer 2.4GHz to 5GHz?

A: It should not; quite the opposite.. 5 GHz is preferred for the connection.
...
If you have BSSs from the same ESS (i.e., APs with same SSID) on multiple channels, wpa_supplicant tries to estimate the expected reliability and throughput of the connection through each available BSS and select the one that is likely to result in best connection. This determination is also taking into account the likelihood of less interference on the 5 GHz band and giving higher priority to it.

[hiro]

I have a setup where it connects to my 5GHz AP correctly, but only if I'm lucky
Because of this I have put a higher priority on the bssid manually:
        bssid=00:90::...
        priority=5

I always use wpa_gui as gui.

also i have this at the top, so that there is even a chance it would reconsider roaming to 5GHz when I get into reach:

bgscan="simple:5:-85:3600"

[Juanito]

After examining the wpa_supplicant log:

Code: [Select]

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

The wpa_supplicant people say:

According to the wpa_supplicant AP scoring, it would indeed seem that the 2.4GHz AP is prefered since it has better SNR (although the SNR for both is good. Generally, wpa_s considers any SNR above 30 as good).
...
perhaps the scoring can be tweaked to more aggressively favor 5.2 in case of close good SNR.

At the place where I usually sit/work, about 10m from the wap with a structural wall in between, wpa_supplicant almost always chooses 2.4ghz.

Using iperf to test, I got 4x the throughput when I forced wpa_supplicant to choose 5ghz.

Anyway - it would seem the issue is not with wifi.sh, but with wpa_supplicant.

This been said, wifi.sh does give the impression that it is going to connect to 5ghz, when in fact it allows wpa_supplicant to choose between 2.4ghz and 5ghz.

[Juanito]

Using this patch

Code: [Select]

--- 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)
..wifi.sh connects to the 5GHz band most of the time - I appear to be sitting at the edge of the area where it gets a s/n ratio of 25 

[hiro]

Code: [Select]

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


although the SNR for both is good. Generally, wpa_s considers any SNR above 30 as good).

the second one has snr 25, which is not above 30, so why do they claim it's "good" ?
your fix also seems to be based on this assumption, so i guess you agree.

[Juanito]

The patch was suggested by the wpa_supplicant people.

I get 4x the throughput with 5GHz as compared to 2.4GHz, which tends to support the changed s/n threshold.