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

unfortunately for me any version of this firwmare have bad wifi 5 performance, i will continue with stock firmware.

1 Like

rakantoh
Thanks for the feedback.

Just to confirm,
Issue was performance,
not
Connected, no internet or Address Not Found error(s)?

In my case, after a MINUTES, no hours, or maximum a one hour, the wifi 5 have very bad "performance", in other words, the internet is very slow, and after a while, nothing load, i must disconnect and reconnect to the wifi 5 to have again internet, this in both my phone and my pc, i comment that my wifi pc card is an intel 9260 wifi 5 160Mhz card, then my pc wifi card isn't the problem, anyway, in my phone persist the same, i dont know if in my device appears the message "connected, no internet", never watch if that message appears, but at least for me the problem is the same... if i have very slow/no internet in wifi 5, then is the same problem, with the stock firmware, at leasat the wifi 5 is very stable... other thing, with openwrt, some wifi 5 bands/channels dont works, if i select certain band/channel, the wifi 5 stop working, only works with certain bands/channels...

2 Likes

Thanks for the feedback.

Running rc6 on EA8100. So far no issue and Wifi strength seems good! (21.02.03 was not too good).

2 Likes

if anyone is still having trouble with it saying connect & no internet
try temperately turning off "Enable SYN-flood protection"
under Firewall>General Settings
is seems to still suffer missing packets for a bit but then at lest fixes itself
just seeing if it's the same for others

2 Likes

I started having daily issues with 22.03.0-rc4 after I managed to install home assistant on the newifi d1 router. HA takes quite a bit of cpu resources to even run. Compiled 22.03.0-rc6 from git now 5 ghz still goes down if it is under heavy stress(mjpg_streamer for a 3d printer webcam takes alot of traffic). So I just cut the 12V power input cable and did a extremely shady job of stealing power for 120mm fan to cool the router. Sorry router but my patience is starting to end. So I am now testing if this is a over heating issue. I found out that I can bring the 5ghz wifi up again without rebooting by changing the bandwith 20mhz, 40mhz, 80mhz until it works again. Implication being that it would be possible to make a very simple script that wiggles the wifi back up whenever it fails effectively making the hole issue manageable. As I recall some people have had issues where it is impossible to connect to the router even if it is up, that is a different story.

BTW, I moved to compiling from sources in hopes of having move of a rolling release instead of resetting the setting every time. Getting https://github.com/openlumi/homeassistant_on_openwrt configured is a fairly lengthy process.

Just got MIR3Gv1 today, plan to replace MIR3P this evening.
Current: MIR3P 19.07.10, wireguard, ksmbd, vsftpd, minidlna
New: MIR3G 22.03-RC6, wireguard, samba4, vsftpd, minidlna, 802.11s, DAWN
Will report back.

this is a bad idea.

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 :slight_smile:
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