[Solved] OpenWrt on MT7621/MT7615N devices with 5GHz problems

the best I have found for AC is the linksys EA8500
but I see lot of people switching between driver on that one as well CT or none CT
I would like to think thr MT7615 will still get better but i know they are manly working on the MT7915 atm
maybe some fixes will trickle down

Thanks for the update Luker. :frowning:

How many days?

3 days but it happened again but was left on all day so probably reached it's time
but it was 5 times a night etc
that's only the left connected with no internet access
it still goes off into la la land & I have to reload to finish a web page
I'm sure that's a DSA thing tho

1 Like

Thanks for the update. :frowning:

Something doesn't add up. I have a DIR-882 A1 that I've been daily driving for a little over an year now, always on snapshot build (updated monthly) and I never experienced this problem. In fact, I've just discovered this topic through the link added to DIR-882 ToH on the wiki, otherwise I wouldn't know.

The list of 5 GHz clients connected to the DIR-882 includes a laptop with an Intel 9260NGW card, two phones (Xperia X, Galaxy A71) and a Blu-ray player (Sony BDP-S6700 -- no ac through, just 802.11abgn).

All Wi-Fi settings for the 5 GHz network are the default ones apart from enabling WPA2-PSK/WPA3-SAE Mixed Mode and 802.11r Fast Transition between the 2.4 GHz and 5 GHz SSIDs. Here's the UCI config, if it helps debugging what's wrong (SSID and password were removed):

wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.hwmode='11g'
wireless.radio0.path='1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
wireless.radio0.htmode='HT40'
wireless.radio0.channel='3'
wireless.radio0.cell_density='0'
wireless.radio0.noscan='1'
wireless.radio0.disabled='0'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid=******
wireless.default_radio0.key=******
wireless.default_radio0.ieee80211r='1'
wireless.default_radio0.mobility_domain='8012'
wireless.default_radio0.ft_over_ds='1'
wireless.default_radio0.ft_psk_generate_local='1'
wireless.default_radio0.encryption='sae-mixed'
wireless.default_radio0.ieee80211w='1'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.channel='36'
wireless.radio1.hwmode='11a'
wireless.radio1.path='1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
wireless.radio1.htmode='VHT80'
wireless.radio1.cell_density='0'
wireless.radio1.noscan='1'
wireless.radio1.disabled='0'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid=******
wireless.default_radio1.key=******
wireless.default_radio1.ieee80211r='1'
wireless.default_radio1.mobility_domain='8012'
wireless.default_radio1.ft_over_ds='1'
wireless.default_radio1.ft_psk_generate_local='1'
wireless.default_radio1.encryption='sae-mixed'
wireless.default_radio1.ieee80211w='1'

there is something weird going on
if i remove option wpa_group_rekey
it beaks again
but if I have it there its good
I have change the value from 86400 to 60
expecting it to happen lots but just works
almost like not having the setting breaks it but adding it fixes it
only setup as WPA2-PSK

Hi, did the issue disappear after setting option wpa group rekey to 60?

setting it to 60 has removed at lest one fault
I'm no longer having to manually disconnected & reconnect :slight_smile:

I'm still seeing pages stop loading & sit there "like sudden packet loss"
but a reload in the browser brings it back
this may not be wifi tho

1 Like

I have the same issue on 1 picky WPA2 2.4Ghz IoT device with really low data activity (dir-1960, OpenWRT21).
When with OpenWRT default configuration, it happens once every 6-7 days that Wifi on that device freezes. The client device then claims that Wifi is still connected, but signal strength on the device shows strength 0, data transfer stalled. Disconnecting and reconnecting Wifi on the device side itself reestablishes the wifi connection. This restarts the 6-7 day cycle.
Rebooting OpenWRT does not fix it, once the IoT device is in that state.

So far, my test status is:

  1. proprietary access point
    An exclusive decade old Airport Express access point hosted for that picky device does not cause wifi errors.

  2. Timed reboot of OpenWRT
    A nightly reboot of the OpenWRT router via a power outlet timer clock seemed to avoid the issue as well. But so far, I have just tried that for 2 weeks and have since moved testing effort to the following parameters as of now.

  3. option disassoc_low_ack (default 1)
    setting this option to 0 has a noticable effect: It round about doubles the period of flawless operation for the picky device to around 2 weeks. So this setting helps, but does not fully fix it.

  4. skip_inactivity_poll (default 0)
    so far, changing this option set to 1 does not seem to have an effect for my device.
    (The disassoc_low_ack setting being 0 in parallel)

  5. option wpa_group_rekey
    Since I have set this to 86400, it is the first time, that my 1 picky WPA2 IoT device had a flawless WiFi connection for 38 consecutive days on OpenWRT 21.02, before WiFi connection crumbled away again.

Interesting. I also have this bug on another device (iPad (WPA3, 5Ghz, same dir-1960 with OpenWRT 21). It appears rarely, so I was not sure so far, whether browser, modem or OpenWRT were causing this. But it does appear a lot less often with the previously mentioned Wifi customizations, probably as of now once a week on a single random http request, with killing and reopening Safari on the iPad fixes it. With default OpenWRT Wifi setting, it felt like appearing at least daily. Not sure if that is due to the same bug, but likely related.

Also very interesting. I will put that on my test bucket list.

which channel you are using for 5ghz?

I managed to get Openwrt installed to my DIR-882 using this method D-LINK Recovery Mode (DIR-882 DIR-878 DIR-867)

Same issue with openwrt 21.02 on (Linksys WRT1900ACS)
macbook pro from 2012 not at all. But with new wifi card from apple model macbook 2018 and huawei p20 and above should works just after reconnect the wifi.
Channel 36, 42, 48 ...etc testes the same.

hey guys i saw this post after my product return period was over, so i cant do anything. i bought a d link dir 2660 router for an offer price. i just verified that it have an official openwrt but didnt saw this known issue post. Is this issue still persist or is it fixed. i heard its not universal so i wish i wont be affected. if anyone know that someone is working on this please tell.

With the current r18812-918d4ab41e snapshot, I have yet to encounter the 5 GHz issue.
With that said,
I've only been running it for a few hours, so will post again if problem is encountered.

Is this common to all MT7621/MT7615N devices? The 5GHz connection on my Netgear R6700v2, which is also mt7621/mt7615 is rock solid in OpenWrt since I started with it using version 21.02.

Is it possible this is inherent in older driver versions? Because I do notice that 5GHz is very erratic on this device when DD-WRT is installed. Erratic as in speed reegotiations every second or two, usually from good 80+80 modes to very slow legacy modes and back again. And this even when signal is high and signal to noise has a 40+ dB spread.

Possibly.
Encountered 5 GHz problem with the DIR-878 and DIR-882 around the time of 21.02.1 stable release. Stable and snapshots around that time had the problem.
Stopped using the MediaTek routers for a few months and just started testing them again the last two days.

Update.
Noticed one of the really old notebooks does not connect on 5 GHz at all.
No problems with the 2.4 GHz.
Will test later on with a clean install of the operating system on the notebook when I have the time.

I can confirm, there does appear to be an issue on my R6700v2 on firmware 21.02.1. I am using my device in client-bridge mode. Since it is the client, it is easy to monitor its link speed. I reverted to release 21.02.1 and noted wide and rapid fluctuations in link speed. Jumping from very slow legacy modes up to high-speed AC modes and back again on a 1-2 second cycle.

After upgrading back to the latest snapshot, the link was far more stable and remained at high-speed AC modes.

It was similar to what I experienced when running DD-WRT on this device.

Just did a quick test of the latest Stable 21.02.2 release.
The 5 GHz WiFi problems still present.

Reverted to testing/using current Snapshot release.
Will see if 5 GHz problems appears over the long term.