luci-mod-status: channel_analysis: detect 160 MHz capable AP #7367
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
These are my first lines of code in js, so any feedback welcome :D |
|
Everything looks good, actually. Although what and where is the 'newer interop workaround'? |
|
@knarrff I think you dabbled in this area also. Any thoughts? |
|
I found that the issue was once reported by the @hnyman. |
The workaround is described in the linked commit description: |
|
So, your code is already 'adjusted' based on the workaround? |
|
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? |
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 |
|
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? |
|
Likely a similar class of problem. Does iwinfo there report 2020 for dual
bonded channels?
|
dannil
reviewed
Nov 1, 2024
modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js
Outdated
Show resolved
Hide resolved
Without testing: looks good to me, apart from the minor cosmetics issue on line 321. |
knarrff
reviewed
Nov 1, 2024
modules/luci-mod-status/htdocs/luci-static/resources/view/status/channel_analysis.js
Outdated
Show resolved
Hide resolved
abajk
force-pushed
the
channel-160mhz
branch
3 times, most recently
from
aa745f7 to
3c8ead2
Compare
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 in this way. [1] torvalds/linux@23665aa Fixes: openwrt#6262 Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
Just changed the comment to describe more precisely what is the newer interop workaround. |
|
Hope to have one day the fix! |
|
@Neustradamus are you able to verify that the fix works for you? I've tested it, but apparently nobody nearby yet uses 160MHz. 🤷♂️ |
|
The patch looks good, I configured both of my routers for 160 MHz and patched LuCI in them. Before: (from MT6000) After patch (MT6000): My other router (WPA2RKOE, E8450/RT3200) is still shown as only 80 MHz, but some other (unfamiliar) routers are shown as 160 MHz But from the RT3200, both routers look like 160 MHz. MT6000 seen from RT3200: But this is apparently not LuCI's fault, as iwinfo reports only 80 MHz (no secondary center frequency), while local iwinfo in RT3200 thinks that it is 160 MHz: |
|
I wonder how iwinfo results might vary if you put one AP in client mode, and join the two, to see how readings change (this might be a way to verify readings when connectivity works). They possibly depend on firmware (ath10k, ath11k, whatever). So if you think this is OK, we can merge it. |
|
@hnyman: Thanks for your results :) |
I'm curious what the |
You mean as seen from MT6000 ? And what the device RT3200 itself thinks about itself: |
|
RT3200 is the compiled case. It supports MIMO 4x4 80MHz or MIMO 2x2 160MHz. As far as I can see it exposes support for 160 MHz in 802.11ax mode (HE) , but only 80 MHz in 802.11ac (VHT). VHT does not allow for different bandwidths for different MIMO configurations. Iwinfo currently does not display 802.11ax (HE mode) information. |
|
However, maybe I am wrong and 1/2 NSS (spatial streams) can also be defined in VHT. I have a Netgear WAX206 that has the same radio, so I have a test enviroment. |
|
@hnyman I can't enable VHT160 on WAX206. Do you know how luci detects hardware capabilities? |
|
It gets the info from iwinfo via rpcd. The key question is that can you successfully enable that manually, by editing WiFi config file? |
|
It turns out that it doesn't. I have changed HE160 to VHT160 in /etc/config/wireless and executed wifi reload. It did not throw any error, but the network does not come up. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 olek2@wp.pl
Signed-off-by: <my@email.address>row (viagit commit --signoff)<package name>: titlefirst line subject for packagesPKG_VERSIONin the Makefile