Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect signal values and SNR in the negative range #221

Open
nightcore500 opened this issue Feb 3, 2025 · 2 comments
Open

Incorrect signal values and SNR in the negative range #221

nightcore500 opened this issue Feb 3, 2025 · 2 comments

Comments

@nightcore500
Copy link

Hey,
I am currently running OpenWRT 23.05.3 with kernel version 5.15.150 on a Ubiquiti NanoBeam AC Gen2 (WA) (Atheros AR9342 rev 3). I use the packages ath10k-firmware-qca988x-ct-full-htt and kmod-ath10k-ct-smallbuffers. I am currently using firmware 10.1-ct-8x-__fH-022-ecad3248.
The Nanobeam is in client (WDS) mode and connected to a LANCOM access point.

In the OpenWRT menu under Network -> Wireless, the signal strength of the device always fluctuates by exactly 10 dBm. The background noise does not change. The Nanobeam and the access point have a fixed location and have visual contact with each other without any obstacles in the vicinity. I am currently observing this problem on all 10 Nanobeams that I have in operation.
The same behavior can be observed with "iw dev phy0-sta0 station dump":

Station 02:a0:57:38:08:38 (on phy0-sta0)
inactive time: 10 ms
rx bytes: 22862039373
rx packets: 32301874
tx bytes: 1468030950
tx packets: 7044183
tx retries: 15167
tx failed: 892
beacon loss: 1
beacon rx: 1454721
rx drop misc: 6722421
signal: -63 [-69, -64] dBm
signal avg: -60 [-67, -62] dBm
beacon signal avg: -54 dBm
tx bitrate: 173.3 MBit/s VHT-MCS 8 short GI VHT-NSS 2
tx duration: 3016454036 us
rx bitrate: 173.3 MBit/s VHT-MCS 8 short GI VHT-NSS 2
rx duration: 0 us
airtime weight: 256
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 1
beacon interval:100
short slot time:yes
connected time: 149856 seconds
associated at [boottime]: 628049.839s
associated at: 1738426795340 ms
current time: 1738576650849 ms

A few seconds later:

Station 02:a0:57:38:08:38 (on phy0-sta0)
inactive time: 10 ms
rx bytes: 22875341142
rx packets: 32316414
tx bytes: 1471062753
tx packets: 7049513
tx retries: 15170
tx failed: 892
beacon loss: 1
beacon rx: 1455091
rx drop misc: 6723991
signal: -53 [-68, -64] dBm
signal avg: -57 [-63, -59] dBm
beacon signal avg: -54 dBm
tx bitrate: 173.3 MBit/s VHT-MCS 8 short GI VHT-NSS 2
tx duration: 3021297839 us
rx bitrate: 173.3 MBit/s VHT-MCS 8 short GI VHT-NSS 2
rx duration: 0 us
airtime weight: 256
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
DTIM period: 1
beacon interval:100
short slot time:yes
connected time: 149894 seconds
associated at [boottime]: 628049.839s
associated at: 1738426795338 ms
current time: 1738576688837 ms

In addition, roaming via the bgscan "simple" module causes problems. The client occasionally makes pointless roaming to a neighboring AP due to incorrect SNR values:

Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Scan results matching the currently selected network
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: 0: 02:a0:57:3f:33:15 freq=5680 level=-54 snr=51 est_throughput=78001
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: 12: 02:a0:57:38:08:38 freq=5660 level=-55 snr=-55 est_throughput=1000
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Selecting BSS from priority group 0
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: 0: 02:a0:57:3f:33:15 ssid='XXXXXXX' wpa_ie_len=0 rsn_ie_len=20 caps=0x1011 level=-54 freq=5680
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: selected based on RSN IE
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: selected BSS 02:a0:57:3f:33:15 ssid='XXXXXXX'
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Considering within-ESS reassociation
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Current BSS: 02:a0:57:38:08:38 freq=5660 level=-55 snr=-55 est_throughput=1000
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Selected BSS: 02:a0:57:3f:33:15 freq=5680 level=-54 snr=51 est_throughput=78001
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Using signal poll values for the current BSS: level=-54 snr=-54 est_throughput=1000
Fri Jan 31 18:15:40 2025 daemon.debug wpa_supplicant[1287]: phy0-sta0: Allow reassociation - selected BSS has better estimated throughput

You can see that the SNR of 02:a0:57:3f:33:15 is 51 and of 02:a0:57:38:08:38 is -55. According to wpa_supplicant, the SNR should therefore be in the negative range.
Is this a bug in the 10.1-ct-8x-__fH-022-ecad3248 firmware?

@greearb
Copy link
Owner

greearb commented Feb 3, 2025

I am not aware of any problem with ath10k reporting different RSSI values as you report, though ath10k radios in general do not do a good job of reporting RSSI like other radios report it.

SNR is difference between signal and noise, so it should always be a positive number. Something showing -SNR looks like a bug, maybe in how radio reports values, but maybe also in hostap somehow.

And probably you need to dampen supplicant's roaming logic. I posted some patches in this area in the past but I don't think they made it upstream, and maybe it wouldn't do exactly what you want anyway. But, might at least provide some hints on where to look at the code. You can find our hostap repo here: https://github.com/greearb/hostap-ct

@nightcore500
Copy link
Author

@greearb
Thank you for your response!
I'll clone your repo in the next few days and give it a test—maybe that will already help me.
I just ran some additional tests regarding signal strength, but I can't reproduce the issue at home.
However, what stands out is that the problem only occurs with devices where the "beacon signal avg" differs significantly from the "signal" value.
That can also be seen in the iw output posted above.
Strangely, the difference is almost exactly 10 dB every time.
It almost looks like iw sometimes displays the beacon signal as "signal." Maybe the issue only occurs at greater distances?
The affected devices are about 100-300m away from the AP. Both the Nanobeam and the AP use directional antennas.

I also only observe the SNR issue with these devices.
To get roaming under control for now, I’ve added a small workaround in wpa_supplicant:

--- a/wpa_supplicant/events.c
+++ b/wpa_supplicant/events.c
@@ -2013,6 +2013,14 @@ int wpa_supplicant_need_to_roam_within_e
                return 1;
        }

+       if (selected->snr < 0 || current_bss->snr < 0) {
+               wpa_dbg(wpa_s, MSG_DEBUG, "Skip roam - Negative SNR detected");
+               return 0;
+       }
+
        cur_level = current_bss->level;
        cur_est = current_bss->est_throughput;
        sel_est = selected->est_throughput;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants