I added the j2fs utils to my snapshot, flashed, rebooted and it immediately fixed the problem with a proper overlay so now I probably don’t need the tools, but interesting all the same
1 Like
Thanks. I might end up going for one of these two approaches. However...
I found that too, the hard way (I should probably read more and tinker less). That's why this config ended with a WPA3 SSID for most workstations and a hidden WPA2 SSID for those that can't handle it.
And that's really what frames the problem to the GL-MT6000. If I take it out and put back the ipq806x TP-Link C2600 it replaced this config works, including fast roaming and WPA3.
I don't think it's DAWN because workstations are not disassociating. There is no flapping between different AP either. Don't think it's WAP3 either because the WAP2 SSID fails too. I think even 2.4GHz SSIDs fail also.
I'll go through those in any case.
That's next... it's worth a try and will take 10 minutes to set up.
I wish there was something on logs to show what is breaking. At least now I have a mechanism to know exactly when it does, so maybe combing through logs might point to something.
Thanks for all the pointers and good suggestions.
2 Likes
Does anyone use VLANs with this device and pppoe on WAN with a vlan tag by any chance?
1 Like
I use a similar device, Asus tuf ax4200, with pppoe with vlan tag 20.
1 Like
has this happened more than once?
first thing id do is turn off all the k/v/r bits, as well as 80211w, etc.
just vanilla wpa2 ssids with nothing else.
next, if you truly suspect its wpad / hostapd related, try swapping it out for wpad-openssl.
I'm pretty sure there would be no difference between wpad-mbedtls and wpad-openssl if you are on WPA2 and not using EAP or SAE.
In fact I think if you are on WPA2 you can just use the non-TLS variant wpad package, e.g. append -libustream-mbedtls -wpad-basic-mbedtls wpad in the firmware selector.
Could you please take a look at my DSA thread and provide some input? I'm kinda lost with DSA and could take a helping hand.
https://forum.openwrt.org/t/gl-mt6000-dsa-config/193307
Yes. Varies. Sometimes we get a few days out of it, some others it dies within 11h.
I'm sure that will work. Don't want to go back to WPA2 if WPA3 was working before.
Done. Issue persisted. It was a long shot anyways. Failed in a slightly different way. iwinfo and luci both stopped refreshing list of associated clients.
As before, clients could still be booted out via luci and would regain network access when associating to a different AP. Booting clients from other APs made them lose network access when they landed on this AP. wifi down/up radio1 brought it back to normal.
I'll kill the WPA3 SSID for a week on this router and let the old APs cover... should still see roaming in the WPA2 SSID and in the 2.4GHz bands (WPA2 & WPA3) and remain stable past a few days.
Have you checked that firewall and dnsmasq are switched off on your dump WAPs? It can be an issue if they're still on. You'll find it under system >> startup
Happy
Thanks! Indeed, I have checked and confirmed this. In my custom image, I do not even include dnsmasq. But the firewall service is disabled:
The following services are available:
/etc/init.d/boot enabled stopped
/etc/init.d/bootcount enabled stopped
/etc/init.d/bridger enabled running
/etc/init.d/cron enabled running
/etc/init.d/done enabled stopped
/etc/init.d/firewall disabled stopped
...
1 Like
yeah, in situations like this thats the name of the game.
reduce complexity as much as possible and go from there.
i wont go too deep into it all but if you were inclined to investigate:
-
you say the devices remain associated + authed just no traffic passes... what happens when you disassociate (on the ap end or on the sta end)... will they reassoc + reauth?
-
is any traffic coming in from the stations? eg: tcpdump? maybe this is an issue with the routing / firewalling? do they ping back? while this is taking place, try flushing all your nftables rules and see if they ping back then. on the same page, instead of
running wifi to reinit the wifi adapters, try doing a firewall restart instead. -
you already took the step of logging the interrupts / second... your 'baseline' is that with zero associated clients? if so, log 20 mins or so without hostapd even running eg: kernel modules loaded, but adapters uninitialized (disabled '1' in the wireless config, fresh boot)... does the baseline stay the same (probably not...)? if it does, and it drops below this while you issue is taking place, you can be fairly certain this is a lower level eg: hardware / firmware / module "driver" etc issue eg: not in user space.
-
as a mickey mouse solution, and this is mega bandaid... i am unsure how used / unused these aps are... but if they frequently reach zero clients you can script together something that does the following:
when clients go from 1+ to zero
if we have not reinited
reinit ("wifi") and set "we have reinited" to true
on client connect, set "we have reinited" to false
essentially forcing a "wifi" everytime you go from associated clients to zero associated clients.
why do this? well maybe this some sort of leak somewhere and doing a wifi reinit forces a flush / teardown + rebuild.
enjoy!
side rant : i find it infuriating that the only 2 viable 802.11ax somewhat open solutions are both plagued with issues. these mediatek devices as well as the qca 807X devices both have many issues... and as far as i know, as far as open source solutions with somewhat stable hardware + drivers these are the only 2... bcm and rtl both have 802.11ax adapters but all prop drivers. sigh...
3 Likes
Hi guys,
I've been having issues with the wifi signal strength and coverage with my Linksys MR8300 and I'm wondering if this would make a decent replacement.
It's a shame that it's only dual-band whereas my MR8300 is tri-band. It's quite disappointing that many decent routers are still dual-band.
Would you recommend this to replace my MR8300?
Yes big upgrade to that. Solid wifi 6 performance and very easy sysupgrade install to OpenWrt.
1 Like
I have replaced three of my R7800 AP with MT6000. Can confirm that range is as good as R7800.
3 Likes
Yay... another WiFi crash, just when I had walked out. This is fun.
Thank you for your comments.
STAs reassociate if their radio is powered down, but they reassociate to the dead AP when coming back up if it is the most enticing one, which usually is unless they move.
If they are kicked out from the AP, they associate to a different AP and work fine. If they get kicked out of the other AP and reassociate the the dead AP, they stop working. It's the AP.
No traffic. Haven't looked at tcpdump. Can't be a firewall issue as it is stopped because it's an AP. Good ideas but not applicable with no router.
The SNMP console logged that. I was planning on using it as some kind of a health check but it is inconclusive and messy. The 2.4GHz radio still works if something is associated there (don't have much roaming there, but happens).
Interrupts are definitely correlated with radio activity. If WiFi stops then volume plummets. If STAs roam away or get kicked out it plummets too.
This may be a low level issue as you point, as after it locks up, if associated stations see no traffic and can push no traffic, but remain happily associated. Almost like the radio part of it is healthy but something is disconnected at network layers 2 or 3.
Thank you for the suggestion. I just put in place something completely mickey mouse. Every minute a script runs that:
- checks what STAs are associated to radio1
- gets the IP addresses of them from ARP cache
- pings them
If there are STAs associated and all pings fail, it does a wifi down radio1 && wifi up radio1 and logs a timestamp. That kicks all the STAs out, forcing them to any of the other APs, and makes it work again. Since failures are aprox every 11h or more I don't expect too much ill effects and that means when this thing becomes a black hole capturing and silencing anything that falls into it, after one minute max everyone will be released. Might cause a WebEx to freeze or fail and I will hear about it, but it will self heal in less than a minute.
This will also give me a chance to check the logs after every incident. My guess is that one particular workstation is causing this... I think it's the same MAC over & over.
Again, thanks for all the pointer and the great idea for a watchdog.
While the gl-mt6000 would certainly be around the top of my personal choices for new devices right now, be aware that it is still a relatively new device, so the honeymoon phase of its perception might not quite be over for its users, yet.
9 Likes
With the release of a stable build for the GL-MT6000 I have setup the two I've had since December.
The are working great, but I've noticed the maximum transmit power on channel 36 is 199mW and for 149 it is 1W.
Can the channel 36 power be changed to the updated maximum power of 1W for the US?
2 Likes
After you flash OpenWrt, you will be restricted to 200 mW (23 dBm) on U-NII-1 (channel 36-48) in the US. See: here and here for details.
4 Likes
VERY interesting. Thank you.
So what I've done is set the GL-MT6000 router to 149, and the GL-MT6000 that is setup as dumb AP on the other side of the house to "Auto"
The result is the dumb AP eventually picked a DFS channel, that it is staying on, at 251 mW.
My old WRT1900 ACS and WAC-104 would never stay on any DFS channel. They would jump around until they ended up on a non-DFS channel. The radar detection on those old devices was awful.
Okay, so I figured out that the worse TX rates are caused by this commit...
@nbd With the change reverted I consistently achieved much better TX rates when using 160MHz on DFS channel 120.
After looking at the code it seems like someone made a mistake, since using || in the if statement will result in the return happening even when vif == NL80211_IFTYPE_AP. So I tested this patch and it fixed everything...
--- a/mt7915/init.c
+++ b/mt7915/init.c
@@ -936,7 +936,7 @@ mt7915_set_stream_he_txbf_caps(struct mt7915_phy *phy,
/* the maximum cap is 4 x 3, (Nr, Nc) = (3, 2) */
elem->phy_cap_info[7] |= min_t(int, sts - 1, 2) << 3;
- if (vif != NL80211_IFTYPE_AP || vif != NL80211_IFTYPE_STATION)
+ if (vif != NL80211_IFTYPE_AP && vif != NL80211_IFTYPE_STATION)
return;
elem->phy_cap_info[3] |= IEEE80211_HE_PHY_CAP3_SU_BEAMFORMER;
This might need to be submitted as a pull request if Felix doesn't pick up on this message.
14 Likes