OpenWrt 23.05.0-rc4 - Fourth Release Candidate

Thanks for correcting me. According to the regulatory rules printed by iw reg get, 160 MHz bandwidth is only allowed in the 5 GHz band if the whole transmission (not just the center frequency) fits into the interval between 5470 and 5725 MHz. This means "channel 100".

I could not find anything in the output of iw phy that would have disallowed the 160 MHz operation.

Please try again, wait 10 minutes again, and provide the whole system log (logread) via the pastebin.

Thank you very much. The funny thing is that the WAX220 (my other Netgear device, also running rc4) is giving me the exatly same output for "iw reg get" but decides to open up a 5GHz WiFi with 160 MHz on channel 36 with automatic channel selection. :thinking:

What exactly do you want me to do before waiting for another 10 minutes? The WAX206 is still on channel 100 and I just checked and it still provides 80 MHz of channel width.

For a good measure, please reboot it with the following settings (AFAIK, these are the same as the current ones): channel 100, bandwidth 160 MHz, mode ax, country DE. Then wait 10 minutes. Then provide the whole system log.

1 Like

There you go:

There is no smart or intelligent automatic channel selection at this time. This does stick to the lowest channel as long as there are no DFS events. I recommend to manually select a channel that fits the channel usage in your individual environment.

By the way this almost eliminates the usage of 160 MHz channels in dense city environments because you both receive interference from a lot of other 5G networks and generate interference for others at the same time. There is only one 160 MHz channel that does not interfere with weather radar in EU. Does not make sense if all SSIDs in one location try to talk to their stations on only one channel and you guarantee to collect the most interference from other SSIDs.

And yes 802.11ax coloring will help but more in the future where AX SSIDs and AX capable stations will get higher adoption rates.

1 Like

Thanks for the log. This line proves (via chan_width=5) that nothing prohibits the radio from coming up at 160 MHz bandwidth:

Fri Oct 13 11:29:47 2023 daemon.notice hostapd: wl1-ap0: DFS-CAC-COMPLETED success=1 freq=5500 ht_enabled=0 chan_offset=0 chan_width=5 cf1=5570 cf2=0

Therefore, my gut feeling is that the downgrade to 80 MHz is a client-side issue.

Are you sure that the client supports 802.11ax? The not-so-recent change disabled 160 MHz bandwidth for 802.11ac clients, because this would break Apple 802.11ax clients. In any case, as already mentioned, the 160 MHz bandwidth on mt7915e is out-of-spec even for 802.11ax.

I would agree if it would be the same with rc2. I just downgraded to rc2 with keeping the settings, restarted and now my 5GHz WiFi is up and running with 160MHz channel wide again

Here is the system log with rc2:

Thank you for this information. I wasn't aware that I should pick a channel manually.

I'm aware of the problems with wide channels but here are more or less no other WiFis within the 5GHz range. Sometimes I can see a very low signal from the neighbours but is not a crowded neighbourhood and I can afford to pick channel 100 without disturbing others.

I did some history digging, and your observations are perfectly explainable:

  • the patch that disables 160 MHz bandwidth for 802.11ac clients got merged on 26 Jul 2023
  • OpenWrt 23.05.0-rc2 was published on 29 Jun 2023, i.e., before the patch
  • OpenWrt 23.05.0-rc3 was published on 23 Aug 2023, i.e., after the patch

Please get an 802.11ax capable client (or, even better, a router for which 160 MHz is not out-of-spec, e.g. Mercusys MR90X or Acer Predator W6 or ZyXEL EX5700) to continue using the 160 MHz bandwidth.

1 Like

Thank you for your efforts but my client is a Samsung S21 Ultra 5G that supports WiFi 6(E) and 160 MHz channels

That is coming from the technical data published by Samsung: 802.11 a/b/g/n/ac/ax 2.4G+5GHz, HE160, MIMO, 1024-QAM

It also still works fine with my Netgear WAX220 that is also running rc4. Therefore I don't think that it is directly related to the fact that rc3 stopped using 160MHz with WiFi 5 clients but maybe it's an unexpected side effect.

Netgear WAX206 and Netgear WAX220 use different WiFi chipsets. WAX206 uses MT7915. WAX220 uses MT7976CN. The removal of the 802.11ac 160 MHz capability only affects MT7915.

To avoid any doubt, could you please post a screenshot of the Network Wireless page (the part with associated stations)? You can discern 802.11ac clients from 802.11ax because 802.11ac clients will say something about VHT-NSS and 802.11ax clients will mention HE-NSS.

Here is my screenshot. You can see that my Poco phone is an 802.11ac client, while the Dell laptop uses 802.11ax. Both are on 80 MHz because I configured my router that way - the resulting bandwidth is still sufficient to get the full speed of my fiber ISP or to access my SSD with speeds limited by its USB2 connection.

Netgear WAX220 is next gen Mediatek Wifi: MT7986 aka Filogic 830 with official 160 MHz channel support from the vendor.

MT7915 in Netgear WAX206 does not have 160 MHz channel support from the vendor. OpenWrt support for 160 MHz channels on MT7915 is experimental. If 160 MHz channels work on MT7915: fine. If not: disable it, problems with 160 MHz channels on MT7915 are expected as this controller was not built and not advertised for 160 MHz channels. MT7915 is built for 80 MHz channels maximum.

Okay, that explains why only the WAX206 is affected. I cross-checked it with a WiFi scanner on my PC (using an Intel AX210 WiFi adapter) and I came to the same results:

RC2 shows 160 MHz

While RC4 is showing 80 MHz:

But I think you are right, it's actually using 160MHz with AX clients, at least that is what it shows on the associated stations list:

So most likely the AC fix changed the way the WiFi is shown in the WiFi scanners, right?

Yes, this looks like it - a cosmetic issue, I would say.

1 Like

Yes, definitely. Thank you very much for your time and efforts and sorry for not realizing earlier that it actually uses 160 MHz

Another possibility may be that the WiFi scanner software on your PC does not recognize ax? For example, the linux utility linssid does not recognize ax on my PC, despite having an AX WiFi card in the PC and the PC connecting over ax to my AP. Granted, linssid hasn't been updated in a long time.

Stable release thread: OpenWrt 23.05.0 - First stable release

1 Like