Would not recommend installing OpenWrt on any routers with the MT7621/MT7615N combination, due to known 5 GHz Wifi problem.
e.g. DIR-878, DIR-882, DIR-2640...
Not uncommon for devices connecting to above routers via 5 GHz WiFi to display the following error: Connected, no internet.
or
Connection to the router is fine/excellent but trying to open a webpage resulting the following error: Address Not Found
This problem is as old as mt76 driver; will not be fixed.
Problem was definitely present in all the recent 22.03.0 RC releases, except RC6?
and
Problem is definitely still present in the current Stable 21.02.3 release.
For those who do not have time/interest going through this entire thread,
Currently,
The release - *now deleted by arinc9 appears to avoid the 5 GHz WiFi problems and increases routing performance.
EDIT: With the removal of arinc9 releases, Snapshots appear to have least amount of problems.
Note: As of August 21, 2022, hauke has applied arinc9's patch into master = Snapshots as of that date should include the patch.
With that said, arinc9 deleted the mt7621-dts-work branch August 24, 2022.
The current 22.03.0 stable release does not include all of arinc9's patches.
Well, I've got the thing and can't return it, as I've soldered a header to the serial pads on the board. So I'm likely to continue banging my head against the wall for a while, trying to get the firmware loaded. If there is a 5 Ghz problem with my unit (I understand the problem is not universal) I'll cross that bridge when I come to it.
Meanwhile, I'd like to hear from anyone who has succeeded in loading the firmware, via any method, from a Linux machine, just to give me some confidence that at least it's been done before.
I was just following your link to the other thread.
Are you referring to the issue that some WiFi clients experience a broken WiFi connection after a few hours?
Unfortunately some WiFi client devices have a low quality WiFi stack implementation, which causes issues with 2 default setting of OpenWRT (and its on other routers as well, not just MT76).
It depends on the client, whether you will experience this after a few minutes, hours or days.
So its a client issue, but you can improve the situation, by loosening some OpenWRT settings:
one is: option disassoc_low_ack '1' (default on)
the other „ Disable Inactivity Polling“ (default off)
both are available as checkmarks in LuCi in the WiFi advanced section. Try inverting the 2, to see if that helps. (milage with your clients may vary)
Thanks Pico but it's only the 5 GHz WiFi that has the problem.
The 2.4 GHz is perfectly fine so not sure if inactivity polling will make a difference...
I'll give it a try anyways.
Additional note,
Same device did not display 5 GHz problem with other routers running OpenWrt. e.g. Archer C2600
I to have these problems with 3 of my device
2 x dlink & 1x linksys all are MT7615 & I only use 5G
that is connected to 2 types of Intel wifi cards in laptops
my Qualcomm Atheros units don't have the same problem they just work
I have tried the disassoc_low_ack with no change
but I'll try the "Disable Inactivity Polling" as well
I'm also having other problems when they are just plugged into my network as AP's only
as in desktop 's that are only plugined into the same switch as the router & PC
web page's just stop loading & I have to hit reload
but if i remove the MT7621 device it go's away
seems like a DSA thing I'll give it more time
I don't have the 'connected, no internet problem', but I have clients frequently disconnecting on 5ghz.
I noticed some old clients don't work at all with 802.11w frame protection (even optional) and wpa3 (even wpa2+3), so I keep the 2.4ghz on wpa2, no 802.11w and 5ghz wpa2/3, 802.11w optional.
I tried reducing the fragmentation and RTS/CTS threshold down to 700/100. The retransmissions went down a lot after that on distant clients (check the counter with the last two lines of your interface in iwconfig), but it does not seem to help with the disconnections.
I tried lots of rc and snapshots, currently on the snapshot of 23/09/21. My phone (nexus 5x) keeps disconnecting at random intervals from the 5ghz, even when 1m away from the router.
Dmesg shows nothing on the router. I found a couple of stack traces of the mt driver, but they are generated only sometimes during network reload, not from normal usage
I guess I will research better the chip in the router next time before buying it.
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
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
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):
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
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:
proprietary access point
An exclusive decade old Airport Express access point hosted for that picky device does not cause wifi errors.
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.
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.
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)
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.
