Well, I had to swap to MIR3G because I cannot directly upgrade MIR3P from 19.07.10 past 21.02 without losing configuration.
Seems MIR3G is enough for my usage.
Plan to upgrade MIR3P too and switch it back in a few days.
Forgot to disable ipv6. I cannot remember last time when disabling it did not solve some issues.
I have always just used the first block of https://superuser.com/questions/1104484/disable-ipv6-with-openwrt
uci set 'network.lan.ipv6=0'
uci set 'network.wan.ipv6=0'
uci set 'dhcp.lan.dhcpv6=disabled'
/etc/init.d/odhcpd disable
uci commit
/etc/init.d/network restart
In the year 2525... ipv6 will work out of the box...
ipv6 works well here 
can't wait until they kill ipv4
so many NAT problems just vanish
The issue this time was that the access point was up but I could not ssh neither my orangepi pc running armbian or rk3318 tv box also running armbian using the dhcp .lan name. So I connected eth to the rk3318 box and found wifi connected to the AP. Perhaps I am wrong about the ipv6 thing. I do find it little hard to believe that ipv6 would still have issues on fresh armbian releases. Perhaps it was the network restart that actually did the trick. So is this way of failing just another way wifi can fail on this device?
BTW, the rockchip rk3318 armbian support is at quite impressive stage these days. The situation with openwrt being designed to run on low resource systems is becoming increasingly strange when you can get a quadcore arm cpu, 4gb ram, 32gb emmc for less than 50 euro. Unfortunately these boxes only have one eth which is not ideal for theoretically running openwrt.
Yes I have had problems accessing SSH via the MT7615N
but via another access point it works fine
Wish I had searched with more care; did not find this thread until after I bought an EA7500 v2 (cheaply on eBay) to use as an AP + managed switch. (Note this post does not seem come up in searches for "MT7615N" by itself. Possibly need to tag it or edit the title to put spaces around that term)
Although the performance is mostly very good, I've had to stop using it because of 5GHz connection stability; with my workflow the dealbreaking issue is that when connected at 5GHz, directory listings from an NFS server made from a Macbook Air Finder window just give me a spinner that goes on for an indeterminate time -- if no other network activity, forever. If I make the link busy with other activity (e.g. iperf3 between the same two machines) it recovers and I get the listing. I'll experiment with modifying the wifi settings as discussed here, but for now I'm back to using a slightly slower (and also quirky in other ways) ipq4018-based EA6350, identically configured which does the job well.
Edit: Problem occurs using OpenWrt 21.02.3 release.
Since you've already purchased the Linksys,
You may want to try the release by arinc9 and/or the current 22.03.0-rc6.
Both include LuCI by default.
With that said,
Bugs/problems with Apple products and routers is nothing new.
e.g. I encountered Airprinter discovery failure with multiple routers and/or firmware. ASUS, Asuswrt-Merlin, FreshTomato, Netgear, OpenWrt ...
With rc6 and some tweaks to the 5GHz wifi settings I'm seeing improvement but not a complete elimination of the problem. @arinc9's release is more suited to routing use than AP/switch use, as it reduces switch performance in favor of routing performance. (Hope it gets into mainline release as that would make this device a good choice for a cold-spare router instead.)
My patch does not necessarily reduce switch performance to favor routing, it's not like a scale where I take from the switching side and put it to routing. It's just that the mt7621 CPU is not fast enough to switch frames at 1 Gbps. This was solved by offloading the frames to the switch hardware. But now, the wan port is not part of the switch hardware so it cannot be done.
For routing, packets are offloaded to the packet processing engine (PPE)
of the Ethernet MAC so you see no problems with routing performance.
2 Likes
I made this small script to try to get the 5ghz wifi back into sense whenever it goes down
Save as /root/wlan_watchdog, chmod +x /root/wlan_watchdog and put "/root/wlan_watchdog &" into /etc/rc.local . Unfortunately the problem with this is that it takes out other wifi as well and in my testing it still typically takes 10-30 minutes of network restarts until things start working again. Single reboot of the router would probably work but is very risky to even try because if the script malfunctions it can lead to a reboot loop. I do not if this calls mt76x2_reset_wlan(and I doubt it will work) but I'll email Felix Fietkau and John Crispin perhaps they can propose stronger measures to reset the wifi without rebooting.
WIFI="wlan1"
LOG=/tmp/wlan_watchdog
fail_count=0
echo "wlan watchdog started " > $LOG
date >> $LOG
while true; do
quality=`iwinfo $WIFI info | grep "Quality" | awk '{print $6}' | sed -e "s/\/.*//g"`
# echo "$quality"
if [ $quality == "unknown" ]; then
fail_count=$(( fail_count + 1 ))
fi
# echo "fail count $fail_count" >> $LOG
if [ $fail_count -ge 20 ]; then
date >> $LOG
echo "commencing network restart" >> $LOG
/etc/init.d/network restart
fail_count=0
fi
sleep 5s
done
Apologies if I oversimplified or misrepresented what your patch does. Linking to your comment where you discuss it more fully in case my comment misled anyone and they want more detail.
1 Like
Note: As of August 21, 2022, hauke has applied arinc9's patch into master = Snapshots as of that date should include the patch.
Reminder for those unfamiliar with OpenWrt: Snapshots do not include LuCI.
LuCI will need to be installed by the user.
LuCI should be installed almost immediately after snapshot installation, due to time limit.
With that said,
arinc9 deleted the mt7621-dts-work branch yesterday
4 Likes
This topic/thread is getting rather long so a quick summary for those who reported unresolved problems with MT7621/MT7615 routers.
Pico w/ DIR-1960
1 picky WPA2 2.4Ghz IoT device with really low data activity
Cheddoleum w/ EA7500 v2
directory listings from an NFS server made from a Macbook Air Finder window just give me a spinner that goes on for an indeterminate time
Mentioned fixes by some users,
NB: Fixes may/may not be necessary since OpenWrt snapshots may contain fixes already.
trinilopez
FWIW, I'm running a Netgear R6700 v2 and changing from WPA3 to WPA2 only fixed this for me
Lucky1
try temperately turning off "Enable SYN-flood protection"
under Firewall>General Settings
Note: My personal testing has arinc9 release (no longer available, since incorporated into snapshots) with an uptime of 25 days ... on a D-Link DIR-878 rev.A1
Will resume testing snapshots soon, unless a new 22.03.0 stable release comes out.
EDIT: Since not all the arinc9's patches were integrated into 22.03.0 stable release, sticking with snapshots.
1 Like
Just to add my experience also. I have a DIR-2640 that have been using for quite a while without any noticeable issues. I started seeing slow throughput (20 Mbps) in certain devices and could not figure out what was going on but others were just fine. Then more recently the disassociations started happening. In some of my debugging I “factory reset” openwrt but was getting the same issues. In setting things back up I did notice that messing with the 5Ghz radio settings were very quirky even causing things to freeze up and have to reboot router. I got things back limping along, but still have a number of devices that will just stop working all the time. Have to turn the client Wi-Fi off and the back on to get it to work again. I am patiently waiting for a new rc with these patches to test things. Meanwhile I got a new dedicated AP to add to my network to work around the WiFi problems.
just a note as well
connecting to a ssh console via a device over the MT7615's wifi
is sometimes impossible on it self or to another openwrt device
but on another access point it's fine to both devices
I have seen this a bit as well
note "using putty on windows 10"
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)...