MT7615E 5 GHz radio current snapshots and 22.03-snapshots get RX limited to 54.0 Mbit/s, 20 MHz and bad performance using DFS channels

[howl]

When using 21.02.3, or any other in the series, connecting via 5 GHz radio speedtests can obtain the full Internet speed I have. When 22.03 series or snapshots are in use the 5 GHz radio drops performance a lot and also behaves erratically with connection drops.

I first thought this was a nftables bug but is not, ethernet and wifi 2.4 GHz remains working openwrt/openwrt#9676.

The router is an ASUS RT-AC85P.

Is an important issue for 22.03 issue I think as the maximum upload speed slows down to 10-20 Mbit and download over 90 Mbit and also the intermittent connection lockouts openwrt/openwrt#9248.

UPDATE: This issue only happens when any DFS channel is used. When no DFS channels is set up it works as it should. Probably the root cause is this change e0f9479.

UPDATE2: As @cmonroe noticed, RX stays at max 54.0 Mbit/s, 20 MHz despite the devices are capable of more speed standards, TX seems to be fine.

UPDATE3: @cmonroe checked that reverting e0f9479 the issue disappears.

[DragonBluep]

Disable WPA3 encryption may help.

[howl]

@DragonBluep I'm not using it as my main router, but if I did the way to go actually for a production one is to stay with 21.02 , but then there is the 2.4 GHz disconnect bug.

It works in 21.02 no matter how you configure the radio and wifi settings, the issue is in following versions.

[viniribeirossa]

Show your wireless settings

[howl]

That's the relevant 5 GHz:

config wifi-device 'radio1'
    option type 'mac80211'
    option hwmode '11a'
    option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
    option htmode 'VHT80'
    option channel '36'
    option country 'ES'
    option cell_density '3'
    option noscan '1'

config wifi-iface 'default_radio1'
    option device 'radio1'
    option network 'lan'
    option mode 'ap'
    option wds '1'
    option ssid 'WiFi5'
    option encryption 'sae-mixed'
    option key 'AreYouSerious?,YouPastedMe?'
    option ieee80211w '2'

With 21.02 that settings works right.

[howl]

I made a mistake in the configuration file, I wasn't using a non-DFS channel that was the test I was about to do. The configuration I pasted then is the usual I have but, channel 36 instead an upper one.

I have done the following tests, WPA2 only, still there, no w extension, still there, disable wds (I used because the 2.4 GHz disconnections to bridge another router). I have also migrated from hwmode to band, still the same (this one expected).

But now the interesting change, I set channel 36 and it works, not smooth as before but need to do more test when my lan is less loaded, anyway uploads peeks with the total bandwith.

So it could be something with DFS channels, is the background radar checking enabled actually in the mt76 module for 22.03 and snapshot?

[howl]

@viniribeirossa I have finish testing different frequencies.

Under ETSI regulation, I have tested all the 80 MHz possible channels, so: 36, 40, 44 and 48: 80 Mhz non DFS, OK 52, 56, 60 and 64: 80 MHz DFS, Bad Performance 100,104, 108 and 112: 80 MHz DFS, Bad Performance 116, 120, 124 and 128: 80 MHz DFS, Bad Performance 132, 136, 140 and 144: 80 MHz DFS, Bad Performance 149, 153, 157 and 161: 80 Mhz non DFS, OK

And I wanted to add as bonus 165 and 169: 40 MHz and 173: 20 MHz, but I have no devices that can connect to that frequencies, despite they should be able to.

So I think there is no doubt that the issue show up when DFS channels are in use and the guilty must be a change that is not present in 21.02 but there is in 22.03 and snapshot.

I'm going to update the issue description and title.

[howl]

There are three commits more in 22.03 than 21.02. Some changes contain radar and dfs in their description.

In https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=e045e40671ab6f689b79a2b51ec9eb9461423d46 there are: fae295af31eb mt76: mt7915: fix/rewrite the dfs state handling logic e0f9479bf893 mt76: mt7615: fix/rewrite the dfs state handling logic

And in https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=da2b97210cdcee893a59628455b595d6c69544f6 594ee03d5a11 mt76: mt7915: fix DFS no radar detection event

but there is no fix for mt7615, not sure if it could be the problem, just guessing, there are more changes in dfs also for mt76 in general.

Have to say that I also have a mt7915 and it works, and mt7615e is affected. I have no more mediatek chipsets to test.

[howl]

@airend did this comment in https://github.com/openwrt/mt76/commit/e0f9479bf8937bc0ff7322043a7a0554b44af29f#commitcomment-66173238 seems it could be the same issue.

[viniribeirossa]

Try this in stable and snapshots builds

Disable option cell_density '3' Disable option ieee80211w '2' Disable option noscan '1' Disable option wds '1'

Remove option hwmode is deprecated since 21.02, replace band Specifies the band, possible values are 2g for 2.4 GHz, 5g for 5 GHz, 6g for 6 GHz and 60g for 60 GHz. (NEW since 21.02.2, replaces hwmode)

Set channel 48 Set encryption pass psk (auto)

Are you trying to create a WDS network? Try creating a mesh network (802.11s). There are videos on YouTube that explain how to create a mesh network, better than WDS

[howl]

@viniribeirossa read me, I have done all tests you ask and even the band change. Yes WDS was for a bridge because the other issue about 2.4 GHz lost of connectivity, I had a wds bridge to make that band with another router.

The issue is 100% sure that is because something in the DFS code path. And seems to be the same issue @airend experienced.

[howl]

@viniribeirossa about the mesh I did even two at the same time, one for lan and one for iot, they worked but the bandwidth was poor in comparison to wds. Actually I don't need the bridge anyway, the 2.4 GHz issue is solved as yourself appointed me #672 :)

[viniribeirossa]

Remove option hwmode is deprecated since 21.02, replace band

[howl]

@viniribeirossa read me, I did it. All you say, even a test with all the 80 MHz available channels in my regulation territory.

More exactly, this comment https://github.com/openwrt/mt76/issues/676#issuecomment-1140509317 and this one https://github.com/openwrt/mt76/issues/676#issuecomment-1140518444. And anyway hwmode -> band shouldn't be a significant change anyway because till hwmode gets totally dropped it will work.

The issue is DFS code path, read me please.

[viniribeirossa]

What is your location?

It seems to be a bug!

[howl]

Earth, and yes, it's a bug caused by this change e0f9479.

[viniribeirossa]

HAHAHAHAHAHA You have to keep track of the snapshot builds

[howl]

@viniribeirossa I was thinking about telling you the living room, but it's just because I told even the regulatory organization ETSI, don't take it personally but all you have asked me I have done time before so seems you don't want to read me. I know it's cumbersome because I was commenting while testing, but take your time reading my poor english before replying.

Snapshot is hit with the same issue, at least for 22.03 that commit should be reverted or if the change is important to find the exact issue there, but that it's out of my abilities.

[viniribeirossa]

A new snapshot build has been released, try...

[howl]

According to buildbot the last snapshot is r19709-4bed263af7, the last one I tried. Is due to even start a new one with only one change for realtek cpu controller, so it's going to be the same when the last last snapshot is tested.

[viniribeirossa]

https://github.com/openwrt/openwrt/commit/275a76e59a37114dce4fdedbadabd73d5558abc8

[howl]

That change only affect that two particular models, the dtsi/dts for this router remains unchanged.

[cmonroe]

When operating on a DFS channel are your rates limited? e.g. your client supports 11n or 11ac rates but the connected station reports a max tx/rx link rate of 54Mbps? You can check station connect rates with: iw dev wlanX station dump

If yes, I think I've run into this as well and have been meaning to open an issue. I'll test reverting the commit you mentioned and see if it resolves the issue.

[howl]

Indeed, I didn't show it. RX stays at 54.0 Mbit/s, 20 MHz when demanding lots of bandwitdh, it can be lower is in standby. TX seems to be normal.

This is the same bug you have found, let me update the initial message.

[howl]

Have tested again non-DFS and then it get more speed standard rates.

@cmonroe it's a guess that the commit is the cause, could be another ones because there are more changes to dfs between working and not working revisions, but for mt7615 not so much changes and that one have the comment describing the download part of the issue.

[howl]

Have just tested 2022-06-02 but is still hit by the issue.

[viniribeirossa]

The mt76 firmware has been updated, try

[howl]

@viniribeirossa try to read. And also, the firmware for mt7615 hasn't been update. You have show several times in this issue your empty talking. It's totally pointless to dialogue with you.

[viniribeirossa]

'mt76' it encompasses every chipset that openwrt supports from ralink/mediatek. Read the changlog and you will see that it has updates for several versions https://github.com/openwrt/openwrt/commit/4e1916f71aece40a3b5e8dd8328110fb74c48928

[howl]

6da21a0b7280 linux-firmware: update firmware for MT7921 WiFi device 4876688c41dc linux-firmware: update firmware for MT7915 79b1b86040de linux-firmware: add firmware for MT7986 784c27b159b9 linux-firmware: add firmware for MT7922

Pointless, totally pointless.

Anyway, I tested hours before you suggested, but you don't want to read at all.

Ah, and I saw this just when opened the changes hours before your suggestion 1d8af168e86f mt76: mt7615: add missing bh-disable around rx napi enable/schedule more suitable to fix this issue than the firmwares for other different chipsets.

[DragonBluep]

@howl Hey! Can you try set "cell_density" to zero? I meet the 20MHz issue after resetting my mt7610 router, but when I changed the settings LuCI added the option cell_density '0' by default, and then it worked fine. Not this reason. I noticed that when the channel is configured as 36, sometimes it fails to become channel 40, at which point there is a 20MHz problem.

[howl]

@DragonBluep the only affecting thing seems to be the channel, all other settings doesn't matter how are configured.

@cmonroe could you test reverting the commit? I was thinking about setting in dts disabled the background radar but I don't know how it could be defined for my router. What router do you have?

[cmonroe]

Yes.. I was able to test this finally and can confirm that reverting e0f9479b restores rates/throughput to expected levels.

[howl]

Tested with 2022-06-21 still present.

[nbd168]

Please try the latest version from master

[rmilecki]

For a reference: b6e865e2cc7080c91ec34a9dd3648d25f7ce04c6 ("mt76: mt7615: fix throughput regression on DFS channels")

[rmilecki]

OpenWrt relevant commit https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=29ed58c8bee1de5b1779494e88620862edc44700 ("mt76: update to the latest version master")

[cmonroe]

Confirmed b6e865e fixes the issue for me.

I haven't verified that radar detection is still working but will put a unit in the chamber where I have a radar generator and double check now.

[cmonroe]

Spot check of FCC0 radar on channel 100.. detection still works great. It was detected and jumped to channel 155:

[  362.634779] mt7615e 0000:01:00.0: mt7615_mcu_rx_radar_detected: RADAR DETECTED
[  362.642029] mt7615e 0000:01:00.0: mt7615_mcu_rx_radar_detected: n_pulses=0 long_detected=0 constant_prf_detected=1 staggered_prf_detected=0
[  362.654556] mt7615e 0000:01:00.0: mt7615_mcu_rx_radar_detected: radar_type_idx=0 periodic_pulse_num=16 long_pulse_num=0 hw_pulse_num=16

The debug prints above are not in upstream mt76.

I think we can mark this one fixed. Thanks @nbd168!

[viniribeirossa]

Looks like the problem has been fixed https://github.com/openwrt/openwrt/commit/29ed58c8bee1de5b1779494e88620862edc44700

[nbd168]

thanks for testing

[howl]

@nbd168 thanks to you for the job you do.