I am experiencing a persistent, intermittent issue on my Flint 2 (GL-MT6000) running the latest stable firmware where wireless devices randomly report "No Internet Connection."
During this blackout period:
Wired LAN clients work perfectly. (I can still access the internet and ping local wired devices, such as my NAS and my Pi-hole DNS server).
Wireless clients remain authenticated to the Wi-Fi radio but completely lose the ability to pass Layer-2/Layer-3 packets across the bridge (br-lan). They fail to reach local servers or resolve DNS.
Stationary wireless devices (such as a smart TV) suddenly drop internet, and toggling the Wi-Fi card on the client device temporarily forces a re-handshake that restores traffic.
I dug into the router's system log using logread right when the freeze occurred and isolated a clear driver-level error coming from the proprietary MediaTek SDK wireless driver framework:
text
kern.err kernel: [ 109.566482] 7986@C08L1,PeerAssocReqCmmSanity() 1501: IE_WLAN_EXTENSION: no handler for extension_id:137
Use code with caution.
Root Cause Breakdown:
The log shows that modern Wi-Fi 6/6E devices (such as a Pixel 9 Pro XL) are transmitting association frames containing specialized management frame extensions (extension_id:137). Because the MTK closed-source driver logic lacks an internal handler for this specific extension ID, the driver encounters a sanity check fault (PeerAssocReqCmmSanity).
Instead of gracefully dropping the unhandled packet, this driver glitch temporarily hangs packet processing across the local br-lan network bridge, dropping active states for passive wireless clients (like smart TVs) and causing DHCP packet loops for reconnecting clients.
Because this issue has spanned multiple firmware versions, it appears to be an unpatched edge case within the MediaTek driver stack or its integration into GL.iNet's OpenWrt build.
Could the R&D team please review this driver crash log trace? Let me know if you need me to export further diagnostic dumps or full kernel traces to help implement an official patch in an upcoming firmware release.
Could you please help check or provide the following information?
When the issue occurs, do all wireless devices remain connected to the MT6000 but lose Internet access?
At that point, if you disconnect and reconnect one affected client device, does it regain Internet access?
Does only that device recover, or do all wireless devices regain connectivity?
Are the MT6000's 2.4 GHz and 5 GHz networks configured with separate SSIDs, or do they share the same SSID?
If they use separate SSIDs, when the issue occurs, does the other SSID continue to work normally, or are both affected?
If using the same SSID, please try to change to separate SSIDs and see if issue resolved or only happened on one of band.
Does the behavior change if you switch between different Network Acceleration modes (for example, enabling hardware/software acceleration or disabling feature)?
Could you try fixing the Wi-Fi settings to a specific channel (for example, Channel 1 or 36), channel width (20 MHz or 80 MHz), and WPA2-only encryption, then see whether the issue still occurs?
Based on your observations, does the issue seem to be related to a particular wireless client? If so, does temporarily preventing that device from connecting help? You could also try disabling Randomized MAC Address, updating the device's operating system, or testing it separately on the 2.4 GHz and 5 GHz bands.
When the issue occurs, please export the complete router logs and send them to us via private message so that we can investigate further.
See responses in bold. Note that some I’ll still need to test, but I have a few answers here already as well as a question for test #4.
When the issue occurs, do all wireless devices remain connected to the MT6000 but lose Internet access? Yes.
At that point, if you disconnect and reconnect one affected client device, does it regain Internet access? Yes.
Does only that device recover, or do all wireless devices regain connectivity? Only the device that was disconnected reconnected.
Are the MT6000's 2.4 GHz and 5 GHz networks configured with separate SSIDs, or do they share the same SSID? Single SSID both both.
If they use separate SSIDs, when the issue occurs, does the other SSID continue to work normally, or are both affected?
If using the same SSID, please try to change to separate SSIDs and see if issue resolved or only happened on one of band. Will see if I can set up this test but will be a bit as I’m out of town and will need to reconfigure several clients for this test. Would an acceptable test be to switch impacted devices to a non-roaming/single-band guest network?
Does the behavior change if you switch between different Network Acceleration modes (for example, enabling hardware/software acceleration or disabling feature)? Will test.
Could you try fixing the Wi-Fi settings to a specific channel (for example, Channel 1 or 36), channel width (20 MHz or 80 MHz), and WPA2-only encryption, then see whether the issue still occurs? Will test.
Based on your observations, does the issue seem to be related to a particular wireless client? If so, does temporarily preventing that device from connecting help? You could also try disabling Randomized MAC Address, updating the device's operating system, or testing it separately on the 2.4 GHz and 5 GHz bands. Two networks (totally separate, but both using Flint 2s. On both this happens with Huawei TVs, one network has several Raspberry PIs where some are impacted (have to see which ones). Other devices seem unaffected. Worth noting the Huawei TVs don’t have this behavior on other routers (such as an eero 6).
When the issue occurs, please export the complete router logs and send them to us via private message so that we can investigate further. Will collect logs on next failure.
I think you're asking for suggection that how to change the SSID since your both frequency bands are using the same SSID.
In that case, you can simply change the SSID of one band while leaving the other unchanged. This allows you to test each band separately without having to reconfigure all of your wireless clients (assuming all clients support both bands and are within coverage).
Question 4 is mainly intended to determine whether the issue is related to 2.4 GHz and 5 GHz sharing the same SSID.
If you have a particular client device that you suspect may be involved, you could try connecting it to the Guest network on 2.4 GHz with a separate SSID and see whether the issue still occurs.
That said, we still recommend the previous approach—using different SSIDs for the Main Wi-Fi—as it provides a more controlled test. Otherwise, if the issue is actually being related to another device on the network, it may be much more difficult to identify the root cause.
