luci-mod-status: channel_analysis: detect 160 MHz capable AP

[abajk]

Implement a workaround to detect an 160MHz capable AP. It was introduced in the mac80211 in 2016 with 802.11ac Wave 2. APs capable of 160 MHz are detected by the shift of central frequencies. More detailed description in the link [1]. Every AP I have seen presents support for 160 MHz this way.

[1] torvalds/linux@23665aa
Fixes: #6262
Signed-off-by: Aleksander Jan Bajkowski [email protected]

• This PR is not from my main or master branch 💩, but a separate branch ✅
• Each commit has a valid ✒️ Signed-off-by: <[email protected]> row (via git commit --signoff)
• Each commit and PR title has a valid 📝 <package name>: title first line subject for packages
• Incremented 🆙 any PKG_VERSION in the Makefile
• Tested on: WAX206 (mediatek/mt7622), OpenWRT snapshot, Firefox 131.0.3 ✅
• ( Preferred ) Mention: @Ansuel the original code author for feedback
• ( Preferred ) Screenshot or mp4 of changes:
• ( Optional ) Closes: e.g. luci-mod-status: 160mhz channels are not properly displayed on the graph #6262
• Description: (describe the changes proposed in this PR)

[abajk]

These are my first lines of code in js, so any feedback welcome :D

[systemcrash]

Everything looks good, actually. Although what and where is the 'newer interop workaround'?

[systemcrash]

@knarrff I think you dabbled in this area also. Any thoughts?

[abajk]

I found that the issue was once reported by the @hnyman.

[abajk]

Everything looks good, actually. Although what and where is the 'newer interop workaround'?

The workaround is described in the linked commit description:

Number of deployed 80 MHz capable VHT stations that do not support 80+80
and 160 MHz bandwidths seem to misbehave when trying to connect to an AP
that advertises 80+80 or 160 MHz channel bandwidth in the VHT Operation
element. To avoid such issues with deployed devices, modify the design
based on recently accepted IEEE 802.11 standard changes (*).

This allows poorly implemented VHT 80 MHz stations to connect with the
AP in 80 MHz mode. 80+80 and 160 MHz capable stations need to support
the new workaround mechanism to allow full bandwidth to be used.
However, there are more or less no impacted station with 80+80/160
capability deployed.

[systemcrash]

So, your code is already 'adjusted' based on the workaround?

[systemcrash]

BTW: does this code depend on fixes which are already in iwinfo/master?

[abajk]

BTW: does this code depend on fixes which are already in iwinfo/master?

This code doesn't depend on other changes in iwinfo. As far as I've seen, both iwinfo and iw only display raw data from received IEs (802.11 Information Element).

Are you asking about other endianness issues described in the linked issue?

[systemcrash]

Are you asking about other endianness issues described in the linked issue?

No - just whether it's just this PR and no other requirements. I tested it but it appears that all my neighbours use 80 MHz only so could not verify :p

[castillofrancodamian]

Could you please check this which is related? Other than that, how is it possible to do a channel scan with an AP in DFS?

[systemcrash]

Likely a similar class of problem. Does iwinfo there report 2020 for dual bonded channels?