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

WiFi Scan shows channel -4 on 2.4ghz nodes at 5mhz channel width #414

Closed
ab7pa opened this issue Jun 26, 2022 · 14 comments
Closed

WiFi Scan shows channel -4 on 2.4ghz nodes at 5mhz channel width #414

ab7pa opened this issue Jun 26, 2022 · 14 comments
Labels
bug Something isn't working

Comments

@ab7pa
Copy link
Contributor

ab7pa commented Jun 26, 2022

When running a 2.4ghz node at 5mhz channel width, the WiFi Scan table shows an entry for channel -4 even when channel -4 is not in use on the node. It occurs on firmware 3.22.6.0+, whether or not LQM is enabled, and it occurs across manufacturers (gl.inet, mikrotik, & ubiquiti). It also occurs for both single radio and dual radio nodes. iw dev wlanX scan passive reports an entry for channel -4 in its scan results even though channel -4 is not in use.

If channel -4 were actually in use, we would expect to see entries for it in the WiFi Scans on other associated nodes, but it does not appear in their scan lists -- leading to the assumption that channel -4 is not actually valid. The channel -4 entry only appears for the node on which the scan is being run. On the example node in the screenshot below, there is an entry for the valid channel -2 as well as an invalid entry for channel -4 having the same BSSID as the valid channel -2 entry. This behavior was not evident on nodes running pre-PR#390 code, but it's not clear whether there is any correlation.

Screen Shot 2022-07-14 at 8 11 25 AM

@aanon4
Copy link
Contributor

aanon4 commented Jun 26, 2022

We're fairly sure this isn't an artifact of the spectral scan display as other things line up correctly. Also, the passive scan is detecting the beacons on -4. It's unclear how long this has always been going on as, before 22.6, channel -4 wasn't accessible so the a node probably couldn't detect or report the signal.

@ab7pa
Copy link
Contributor Author

ab7pa commented Jun 26, 2022

Agree... it was happening on 3.22.6.0 before the Spectral View was introduced. So the Spectral View only served to highlight the issue visually.

This screenshot is from a node running 3.22.6.0, and it shows the channel -4 entry even before the Spectral View was introduced into the firmware.
2022-06-28_06-57

@ae6xe
Copy link
Contributor

ae6xe commented Jun 26, 2022

Please upload the support data -- specifically what the iw scan returns to show this signal on ch -4. The fact that we are seeing the same BSSID is a red flag -- this MAC like # represents the given 802.11 adhoc network that all the devices communicating are connecting to, then each station has it's own MAC address on this ad-hoc network. A given ad-hoc network can't be simultaneously on 2 channels. There may be multiple issues here: A) the scan for ch -4 and ch -2 are really the same thing; B) there could be another device (wireless phone handset, etc.) that spectra data is finding.

What do other locations find? Do both the foreign ad-hoc network and the spectra scan data on ch -4 (which is not a alias of another signal) show up? Just one of the two?

@ab7pa
Copy link
Contributor Author

ab7pa commented Jun 26, 2022

IW scan results: iw-scan.txt

As mentioned above, other nodes scanning on 5mhz channel widths do not see channel -4 on this node -- they only list a channel -4 entry for their own node. If the channel -4 entry was from a different device (wireless phone, etc) then it should have a different BSSID. As you said, same BSSID is a red flag -- and other nodes never see two entries for that BSSID in their scans.

@ae6xe
Copy link
Contributor

ae6xe commented Jun 26, 2022

Do other nodes show any energy in ch -4 in the spectral scan?

@AJ6GZ
Copy link

AJ6GZ commented Jun 26, 2022

Seeing the phantom -4 listing on a Nano XW 2Ghz, but little energy even in this heavily polluted RF environment. 5MHz wide here as well.
image1

@ab7pa
Copy link
Contributor Author

ab7pa commented Jul 1, 2022

Since the WiFi Scan results are simply the web presentation of the iw dev wlanX scan passive command, the question of root cause seems to be “What is causing the iw results to contain a bogus channel?”

@ab7pa
Copy link
Contributor Author

ab7pa commented Jul 12, 2022

Switching my 2.4ghz nodes to 10MHZ channel width also produces a bogus entry in the table for channel -1 as shown below. It should not be possible to have two channel widths in use on a single BSSID.

2022-07-12_07-33

@ab7pa
Copy link
Contributor Author

ab7pa commented Jul 20, 2022

@pmilazzo Paul reported last night that during his testing the root cause of the bogus scan table entries appeared to be related to collocated node proximity -- possibly receiver overloading. Paul can elaborate more on his discoveries. Thanks, Paul!

@ae6xe
Copy link
Contributor

ae6xe commented Jul 25, 2022

@pmilazzo if you lower the power way down on the co-located nodes, do the symptoms go away? Theoretically, I'm trying to understand how the receiver could decode the signal on a different channel. The frequency is mixed down to a 'baseband' inside the chips. This baseband signal ("BB" in the chip architecture just before analog/digital conversions) would have to bleed through from chip to chip. Not sure if there's any other way to explain this.

Capture

@pmilazzo
Copy link
Contributor

pmilazzo commented Jul 25, 2022 via email

@ae6xe
Copy link
Contributor

ae6xe commented Jul 25, 2022

"One possibility is some sort of intermodulation distortion" or clipping.

The 64 subcarriers across the 10MHz channel in 2GHz would have to (mostly) all be precisely and linearly shifted to another channel for the radio to to be able to decode and reassemble the data stream. I just don't see how this could happen -- too much distortion occurring. This baseband frequency is common across all radios -- It would be like an analog Intermediate Frequency being the same across 2 radios and the signal bleeding across. But all this should be highly shielded inside the chip.

If the distance can be slightly increased, to be out of near field, and power dropped, then if these symptoms go completely away, then we'd be able to establish cause and effect.

@pmilazzo
Copy link
Contributor

pmilazzo commented Oct 11, 2022 via email

@ae6xe ae6xe added the bug Something isn't working label Nov 16, 2022
@ae6xe
Copy link
Contributor

ae6xe commented Feb 18, 2023

Fixed in 8bed661

@ae6xe ae6xe closed this as completed Feb 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants