MT7621: WDS with channel width > 20 MHz and AX not working in newer snapshots

For Developers
1

Hi,

with the Zyxel WSM20 I've found an issue with newer snapshot builds and WDS (main and 23.05 tree).

Going with an older version (OpenWrt SNAPSHOT r22784-1645c34d56 / LuCI Master git-23.118.79121-6fb185f with Kernel 5.15.110) WDS was working fine in AX mode with 80 MHz channel width. Unfortunately I don't know the exact version which broke it.

After a few more tests, I was able to narrow down the error. The tests where performed with the latest 23.05 snapshot version:

openwrt-imagebuilder-23.05-SNAPSHOT-ramips-mt7621.Linux-x86_64.tar.xz	7ff041a9227dc05c64607dc5531642425c2e2226fab279467e024f2dc1afccbc	185206.1 KB	Fri Jun 2 23:00:44 2023

Used devices:

Test environment:

Asus RT-AX53U (WDS AP) <-----> Zyxel WSM20 (WDS client)
Asus RT-AX53U (WDS AP) <-----> Xiaomi Mi 4A Gigabit Edition (WDS client)

PC connected via ethernet to (br-)lan at the WDS client

Used WiFi config on WDS AP:

 config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option channel '1'
        option band '2g'
        option htmode 'HE40'
        option country 'DE'
        option cell_density '1'
        option he_bss_color '42'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0+1'
        option channel '52'
        option band '5g'
        option htmode 'HE80'
        option country 'DE'
        option cell_density '1'
        option he_bss_color '42'

config wifi-iface 'wifinet4'
        option device 'radio0'                    # or radio1, depending if 2.4 or 5 GHz
        option mode 'ap'
        option ssid 'TopSecret'
        option encryption 'sae-mixed'
        option multicast_to_unicast '1'
        option key 'HighSecurityKeyPlaceholder'
        option ieee80211k '1'
        option time_advertisement '2'
        option time_zone 'CET-1CEST,M3.5.0,M10.5.0/3'
        option wnm_sleep_mode '1'
        option wnm_sleep_mode_no_keys '1'
        option bss_transition '1'
        option proxy_arp '1'
        option wpa_disable_eapol_key_retries '1'
        option network 'lan'
        option wds '1'

Example configuration from WDS Client (Basically following the LuCI guide for WDS):

config wifi-iface 'wifinet2'
        option device 'radio1'
        option mode 'sta'
        option network 'lan'
        option ssid 'TopSecret'
        option bssid 'MAC FROM ASUS WiFi AP'
        option encryption 'sae'
        option key 'HighSecurityKeyPlaceholder'
        option wds '1'

I've not tested every possible combination, but here is a list if WDS is working or not:

  • WDS AP 2.4 GHz at HE40 mode but 40 MHz not enforced (20 MHz channel width)
    Zyxel: yes
    Xiaomi: not tested

  • WDS AP 2.4 GHz HE40, 40 MHz channel width enforced
    Zyxel: no
    Xiaomi: not tested

  • WDS AP 5 GHz HE20 Mode
    Zyxel: no
    Xiaomi: not tested

  • WDS AP 5 GHz HE80 Mode
    Zyxel: yes
    Xiaomi: yes, but as the HW is limited to VHT of course only with 866 Mbit/s AC connection

  • WDS AP 5 GHz VHT80 Mode
    Zyxel: yes, with 866 Mbit/s AC connection
    Xiaomi: yes, but as the HW is limited to VHT of course only with 866 Mbit/s AC connection

No means there's a connection listed in LuCI, but the TX rate stucks at 6 Mbit/s (2.4 or 5 GHz) and no ping command (from the PC connected via Ethernet or from a ssh session at the Zyxel WDS client) to the Asus WDS AP or any (wired) device connected to the Asus router is answered.

Edit: I forgot to mention that a WDS connection between two Zyxel WSM20 devices is not working as well at 5GHz 80 MHz HE mode.

2

I have a similar problem.

I use Mesh 5 GHz on the following routers:
Xiaomi Redmi Router AX6000
Xiaomi Redmi Router AX6S
Xiaomi Mi 4A Gigabit Edition (works sometimes)

On snapshots from mid May Mesh is working only on 20 MHz.
The last working snapshot where mesh works at 80 MHz was released May 18 (kernel 5.15.111).
On 5.15.112, 5.15.113 and 5.15.114 only 20MHz
Tried a clean install with minimum settings for Mesh only. It did not work.
On 22.03.5 everything also works fine.

These are my Mesh settings:

config wifi-iface 'mesh0'
	option device 'radio1'
	option mode 'mesh'
	option key '<my_pass>'
	option mesh_fwding '1'
	option mesh_rssi_threshold '0'
	option encryption 'sae'
	option network 'lan'
	option mesh_id '<my_mesh_id>'
	option ifname 'wlan1-0'
	option disabled '0'
3

I have been experiencing an issue on recent builds with mt76 devices where simultaneous STA plus AP on one radio does not work but only on WDS channels. It makes me wonder if it is part of a larger WDS issue with firmware.

4

I'm having similar fails with 23.05.RC1 on MediaTek MT7915E 802.11acaxn.

23.05.RC1 WDS station does connect to 22.03.5 WDS client.
23.05.RC1 WDS station does not connect to 23.05.RC1 WDS client.

I did not try
22.03.5 WDS station to 23.05.RC1 WDS client

5

Still open with the newest Snapshot and Kernel 5.15.116.

In my original post there's an error about what's working and what's faling, here is a table:

grafik
grafik1052×108 5.41 KB

6

@iamunknown Thank you for posting your config. I found some inefficiencies.

        option he_bss_color '42'

radio0 and radio1 are expected to have different numbers and hence a different color, so try not to use the same number for both radios. If you remove option he_bss_color '42' from your config files completely, using the 802.11ax protocol, option he_bss_color will automatically be enabled and the radios will be given a randomized number between 1-63. So that's fine too.

        option encryption 'sae-mixed'

Try to stay from mixed encryption protocols. Not all client devices support mixed mode. If you can, use one of the newer encryption protocols like wpa3 and if your client devices do not support wp3 yet, then fall back to wpa2, but avoid mixed. If you have very old devices that do not support wpa2, you can create a separate network (SSID) just for these devices.

        option multicast_to_unicast '1'

multicast_to_unicast is not enabled by default. Have you tried disabling this option? What is your reason for having enabled this option?

        option wnm_sleep_mode '1'

You have enabled the extended sleep mode for stations, so experiencing lower channel bandwidth might be a result of those client devices using power safe mode. Disable wnm_sleep_mode, to check if it fixes your problem.

All those things I listed may not really fix the channel width > 20 Mhz problem, but it would be good to have them addressed nevertheless.

7

I was never reading the standard and with 2.4 and 5 GHz at least I was thinking it doesn't matter. Do you have a source where to find a good overview? I was searching for some parts of my WiFi configuration and found interesting papers and presentations, but finding the root source is not easy.

After searching the status of beamforming I found in /var/run/hostapd-phy0/1.conf that the he_bss_color was set on my Asus and Zyxel Devices to 128 (still so at the WSM20 with the first Snapshot with Kernel 5.15.116) and that's why I decided to go to a different value. This seems at all a bug as only 1-63 is a valid number.
See the update about random he_bss_color.

No as it is still working with this option enabled perfectly on the older Snapshot version.

If I understood it correctly it will use less air time to transport the converted messages. In my WiFi environment the impact should be ~0 with enabled or disabled the option but it's running with this configuration since 22.x without issues.

The idea behind it is to maximize the power savings for all mobile devices. I don't have an option to measure the impact, but also this feature is running for a longer time now without a negative observed impact.

Thank you for your feedback and your suggestions. Right now I'm happy with my WiFi setup (I've running multiple APs on every Radio with different configurations mapped to different VLANs and features like 802.11r/v/k (not all in every WiFi)) and also one WSM20 is running with the older Snapshot version as WDS repeater.

In the system and kernel log from Luci I couldn't find an entry why it's not working and I don't know where to start the search why WDS seems broken (as also other people can reproduce this issue it should not be limited to my specific configuration). I also have one WSM20 in spare which I'm also using to test if with a newer kernel version the issue is fixed (as I couldn't see a specific commit at github what could have changed the status of WDS) but I'm not too experienced in network or driver/kernel debugging in Linux on console level.
If more information is needed I'm happy to support with testing, logs and/or other output :slight_smile:

8

Oh right, yes that could be. My bad, did not see it was two different bands.

I guess the original root source would be the IEEE standard as marketed by the Wifi-Alliance? - https://en.wikipedia.org/wiki/Wi-Fi_6

thank you for the other explanations too.

9
10

Thank you. Unfortunately my french is very very bad.

11

in english

1 Like
12

Hi, I tested the latest snapshot (r23401-a860e439ed) with Kernel 5.15.117 and as the problem is for me only reproducible with HE / AX WiFi I also commented out the he_bss_color at my Asus router followed by a reboot but both things are not solving it.

1 Like
13

Any ideas how to start debugging?

14

If you are able to compile OpenWrt from source (how do I compile OpenWrt?) then you could try to find the regression window via https://git-scm.com/docs/git-bisect

15

The build environment is working, but I will need some time to start with the search for the commit - maybe next week.

16

@Wiz Found the commit which is responsible for the issue: Wireless client mode broken on WAX206 post r22866

2 Likes
17

@nbd The WDS issue is still open - with reverting the commit from May 18 it's working again - with your mt76 commit from yesterday it's still not working.

My test environment is simple: I've set the 2.4 GHz radio to 40 MHz and for the test I enforce the 40 MHz channel width on the WDS access point with uci set wireless.radio0.noscan='1'.

With the commit from yesterday there's one change in behaviour: TX stays at 6 mbit/s connection speed, but also RX is now limited to 20 MHz. Before this commit the TX rate was fixed at 6 mbit/s but the RX rate was using the full 40 MHz channel bandwidth with about 500 mbit/s. (TX/RX rates from the perspective of the WDS client)

The picture is from the Asus WDS AP so TX/RX is reversed. The Asus is right now at 23.05-RC1, I will repeat this test with updated image for the Asus in some minutes.
grafik

Edit: Running the Asus WDS AP with the same mt-76 commit, the RX rate is again at 40 MHz and ~500 mbit/s but TX is still at 6 mbit/s and no communication is possible:
grafik

1 Like
18

The solution lies in git bisecting the mt76 update from mid-May as I don’t believe the latest update is causing this regression.

1 Like
19

Please try the latest version from mt76.git

4 Likes
20

With changing this lines from the Makefile in package/kernel/mt76 to your latest commit in a clean git repo
PKG_SOURCE_DATE:=2023-06-29 PKG_SOURCE_VERSION:=c50be0b54cddba864637bc0a5b13be2d89494103 #PKG_MIRROR_HASH:=c26dea3a58ba03d539c8e6cc2d3c99ce0cb5bb3b1aac76cab7fea689b6a86e4c
and rebuilding the image it works for me (2.4 and 5 GHz radios).

Thank you for fixing it!

3 Likes