It will work in the new rc. If you prefer, you can compile a snapshot for your device, which should fix this issue.
thanks
it's good it's fixed
I'll just wait for rc7 or .0 
I suspect usb 3 connector was left out of newer Tp-Link Archer AX20 Wifi 6 with MT7621A because they knew it would interfere with the 5ghz wifi. Stuck the ssd with extroot on my newifi d1 to usb 2.0 port instead.
I'm not 100% but from what I have read around
it's the 2.4G that's Mainly upset by USB 3.0
eg https://www.pcmag.com/opinions/wireless-witch-the-truth-about-usb-30-and-wi-fi-interference
Okay, can anyone explain me with as much detail as possible what exactly is the issue here? I initially reported back in October 2021 that I never experienced the issue with my DIR-882 A1 and that's still the case even nowadays, almost an year later. In all this time I've been running the snapshot builds (updated monthly -- currently running the September 5th, 2022 one).
My Wi-Fi settings are still the same from my previous post, but the list of 5 GHz clients connected to the DIR-882 changed a bit: three smartphones (Xperia X, Galaxy A71 and Galaxy S10e), one laptop (Intel Wi-Fi 6 AX201) and a Blu-ray player (Sony BDP-S6700 with 802.11abgn support -- no ac, aka Wi-Fi 5).
Although both 2.4 GHz and 5 GHz SSIDs are the same, the laptop is specifically configured to always prefer the 5 GHz band and even then I've never experienced the "Connected, no internet" many described here. The smartphones also keep connected to the 5 GHz 90% of the time since I live in a small apartment (enough to get full bars on the 5 GHz band in all rooms), they only switch to 2.4 GHz when I'm already out and relatively far from the router.
This time I'm including also the command line I use with the image builder and the extra packages I add to the snapshots, maybe something here helps identifying why I don't experience the issue:
make image PROFILE="dlink_dir-882-a1" PACKAGES="block-mount e2fsprogs ipset kmod-fs-ext4 kmod-usb-storage-uas libustream-openssl -libustream-wolfssl luci luci-app-samba4 luci-app-upnp wpad-basic-openssl -wpad-basic-wolfssl"
(I use libustream-openssl and wpad-basic-openssl instead of their default WolfSSL versions as a space saving measure, otherwise the resulting image is too big to fit on my DIR-882 -- Samba4 is the biggest package and requires OpenSSL anyway, can't switch to ksmbd because it doesn't work with Windows' File History, something I use extensively)
As already mentioned, USB 3.0 is known to cause interferences only on 2.4 GHz networks, 5 GHz networks are immune. Also, several routers have mitigated this problem either by shielding the USB 3.0 connector, by moving it away from the antennas, or by doing both (the case of DIR-882 and all other routers based on that same AP-MTKH7-002 board from SGE that includes USB 3.0 ports)...
Update,
Stable release 22.03.0 for MT7621 available for download.
Waiting on arinc9 to confirm patches are included or not.
Either way,
Keeping copies of arinc9 releases just in case!
Pretty sure the answer is 'no'. I reviewed the commit history for the 21.03.0 tag and those commits do not appear.
2 Likes
I saw that too. I found some clues that the ssd might be an issue(more stable without extroot). Upgraded to 22.03.0 and put extroot on tf card this time instead of ssd leaving both usb unused. Even though the ssd is rated 5V 1.7A it only draws less than 200ma measured. Interesting to see what happens.
Getting an excellent deal on Netgear r6800 router (MT7621AT and MT7615E). Will you guys suggest to go for it, since I see most of the things are now getting sorted out or should I pass. @Warlock / other's pls guide.
cyberdork33,
Thanks.
Personal experiences:
Netgear routers use nmrpflash for recovery.
When I had a Netgear router in the past for testing, I ended up bricking it several times during OpenWrt installation.
The first two/three? times I managed to recover it
However,
The final time, the nmrpflash did not work.
I could not bother trying to use solder/serial recovery method mentioned and never really liked the nmrpflash to being with, so I threw it out.
EDIT: For MT7621AT/MT7615N routers, I use/test with D-Link DIR-878 rev.A, DIR-882 rev.A and DIR-2640. Several years of testing, recovery method has never failed.
2 Likes
Others may want to know, which firmware were you using? How long before slow throughputs were noticed? How long before dis associations started?
arinc9 release or snapshot?
Cheers,
OpenWrt 21.02.3 r16554-1d4dea6d4f
I haven’t had a chance to upgrade yet.
I really don’t know how long everything was. It developed over a long period of time. I first noticed a few months ago on a laptop that I do not use regularly that updates were being incredibly slow. I messed with things then trying to narrow down the problem and I decided it must have been something about WiFi on that particular machine because I was not really having issues with anything else. But it started getting worse and worse and effecting more clients. All these things worked fine wired. My primary phone started getting disconnects eventually and I really dug into people having issues like mine and I was not finding much until I found this thread. After a week or so dealing with the disconnects on my everyday devices I finally broke down and bought a separate AP to tie into the network. Everything works great now on that AP and still having the same symptoms on the DIR-2640.
Thanks for the reply.
That release was reported with issues last April.
It goes without saying, not recommended to use that release.
Maybe this is worth a look, caught red-handed on OpenWrt 22.03.0
WiFi: mt76: mt7615: add mt7615_mutex_acquire/release in mt7615_sta_set_decap_offload
Noticed another commit authored by arinc9
Dated September 18, 2022
Two dumb routers fighting for one channel. The way I see it, there is very little point in manually selecting channel when anyone at any time can come over and start sending DFS radars refusing to leave the channel yielding a nice race condition. One way around it would be to replace the channel selector with a text entry e.g.: "36, 40, auto" would try 36 and 40 failing back to automatic and "36, 40" would only try 36 and 40 before giving up.
@ cyberdork33
I think you are being hit by DFA-radar as these debug messages were not in none of the RC releases.
1 Like
Not sure what debug messages you are referring to. I don't think I posted any. Maybe you meant someone else?
I was referring to the logs I posted which now have been expired and therefore gone.
Wed Sep 14 09:03:16 2022 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5500 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Wed Sep 14 09:03:17 2022 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Wed Sep 14 09:03:17 2022 daemon.notice hostapd: wlan1: AP-DISABLED
Wed Sep 14 09:03:18 2022 daemon.err hostapd: could not get valid channel
22.03.0 added some good new debug stuff that was not in RC releases. This behavior needs to be changed, it is causing ppl loose their hair over it.