Routers · GL.iNet
GL.iNet Flint 2 (GL-MT6000) Wi-Fi Keeps Dropping
If your GL.iNet Flint 2 (GL-MT6000) keeps dropping Wi-Fi mid-stream, driver panics, hardware acceleration bugs, or DFS channel switching are likely responsible.
Symptoms
- Wi-Fi SSID disappears entirely for 30–60 seconds before broadcasting again
- Devices remain connected to Wi-Fi but show 'Connected, no internet'
- 5GHz band crashes repeatedly while the 2.4GHz band remains working
- Wired Ethernet connections stay solid while wireless clients get dropped
- Wi-Fi drops specifically during heavy traffic like 4K streaming or Zoom calls
- Router log reports MediaTek wireless driver resets (mt7986 errors)
Quick troubleshooting
Step 1
Disable Hardware Acceleration / Packet Steering
Log into the GL.iNet Admin Panel, navigate to Network Settings, and locate Network Acceleration. Turn off Network Acceleration (or Packet Steering) to test if Wi-Fi stability improves. Hardware offloading bugs in certain kernel versions can cause sudden wireless radio restarts under high throughput.
Step 2
Set Static non-DFS 5GHz Wi-Fi Channels
In the Admin Panel under Wireless settings, change the 5GHz Wi-Fi channel from 'Auto' to a static lower channel such as 36, 40, 44, or 48. Dynamic Frequency Selection (DFS) channels (52–144) will automatically shut off the radio when detecting potential radar signals, creating unexpected disconnects.
Step 3
Perform a Clean Firmware Update (No Settings Kept)
Go to System > Firmware in the GL.iNet panel. Download the latest official stable release for the GL-MT6000, and re-flash it while unchecking 'Keep Settings'. Retaining corrupted configuration files across major OpenWrt builds frequently causes persistent wireless radio panics.
Step 4
Verify Power Supply and Outlet Voltage
Ensure the original 12V power adapter is connected directly to a reliable wall socket or surge protector. Momentary voltage dips when high-power Wi-Fi 6 radios burst can trigger localized chip resets on the board without rebooting the main system kernel.
Step 5
Inspect System Logs via LuCI for Driver Crashes
Access Advanced Settings to enter LuCI, then navigate to Status > System Log. Search for 'mt798x' or 'MAC reset' entries around the time the drop occurred to confirm whether it is a software driver panic or a physical hardware fault.
Likely causes
- Hardware Acceleration / Packet Steering instability in GL.iNet firmware
- DFS (Dynamic Frequency Selection) channel jumping due to radar detection
- MediaTek MT7986 Wi-Fi driver crash in older or beta OpenWrt builds
- Under-voltage or power fluctuations from a loose or failing power adapter
- Overheating caused by blocked air vents or excessive continuous load
- Corrupted overlay configurations following an over-the-air firmware update
What's going on
The GL.iNet Flint 2 (GL-MT6000) is a powerhouse Wi-Fi 6 router running on open-source OpenWrt software paired with a MediaTek Filogic 830 chipset. However, when wireless connections abruptly die mid-call or during gaming, the fault is rarely a complete physical breakdown.
Instead, Wi-Fi dropouts on this specific router usually trace back to software driver conflicts, aggressive hardware network acceleration, or automatic channel switches. Because GL.iNet overlays a custom interface on top of standard OpenWrt, kernel updates and packet steering optimizations can occasionally introduce wireless radio instability.
Symptoms people notice
- The 5GHz SSID vanishes without warning, leaving high-speed devices disconnected while 2.4GHz devices remain online.
- Ethernet-connected PCs stay online, proving the internet service and main CPU are fine while the Wi-Fi subsystem crashes.
- System logs inside the LuCI panel report repeated wireless driver crash logs (
mt7986_phyorwedoffloading reset errors). - Wi-Fi cuts out momentarily every time a high-bandwidth task like a multi-gig file transfer or Zoom call begins.
- Dynamic channel changes force devices off the network for up to a minute while radar checks complete.
Likely causes
- Hardware Acceleration (WED) Conflicts: Packet steering and hardware offloading can overload the Wi-Fi driver under specific traffic types, causing the radios to crash and reset.
- DFS Channel Radar Interruption: Setting 5GHz channels to 'Auto' often places the router on DFS frequencies, which temporarily disable themselves when detecting radar interference.
- Firmware Configuration Bloat: Upgrading the GL.iNet firmware while preserving old settings can leave stale overlay scripts that conflict with new radio drivers.
- Power Supply Instability: A loose power jack or faulty 12V adapter can fail to supply sufficient amperage during heavy transmit bursts, causing localized radio chip resets.
- Thermal Throttling: Placing the unit in an unventilated cabinet can cause the MediaTek Wi-Fi radios to overheat and reset to protect internal silicon.
Quick checks first
Start with non-destructive, quick fixes before touching advanced settings:
- Check thermal conditions: Feel the chassis. Ensure the side and bottom vents are clear of dust and the device isn't sitting on fabric or inside a closed cabinet.
- Verify the power connection: Unplug the power adapter from both the wall and the router, re-seat it firmly, and avoid using unrated third-party power bricks.
- Disable Band Steering: Separate the 2.4GHz and 5GHz Wi-Fi networks into distinct SSIDs in the Admin Panel to isolate which radio is failing.
- Lock in non-DFS channels: Manually select Channel 36, 40, 44, or 48 for the 5GHz network instead of letting it choose automatically.
For broader diagnostic tips across other network hardware, explore our router problem guide.
When it's a real hardware fault
If you have flashed a clean factory firmware image without preserving settings, verified a stable 12V power supply, and disabled hardware acceleration, yet the Wi-Fi continues to drop every few minutes, you may be facing a hardware-level failure.
Hardware faults on the GL-MT6000 generally involve failure of the onboard MediaTek radio power rails or thermal degradation of the internal power amplifier modules (FEMs). If the system logs report continuous hardware watchdog timeout or phy reset failed errors even on stock firmware, the internal wireless module is physically failing.
Soft resets vs board/panel work
Soft resets, configuration wipes, and setting adjustments through the GL.iNet web GUI or LuCI interface resolve the vast majority of Flint 2 connection issues. Adjusting Wi-Fi channels, disabling network acceleration, or re-flashing official firmware images requires no technical disassembly and poses no risk to the device.
Attempting board-level repairs—such as replacing surface-mount power capacitors or soldering replacement Wi-Fi chips—is not practical or cost-effective for consumer routers. If clean software reinstallation does not resolve physical radio drops, replacing the unit under warranty or consulting hardware reviews for a replacement router is the safest route.
Next steps
- Access the Admin Panel at
192.168.8.1and disable Network Acceleration under Network Settings. - Assign static, non-DFS channels (Channels 36–48) to the 5GHz radio band.
- If drops persist, back up critical settings and perform a full Factory Reset under System settings.
- Download the latest stable GL-MT6000 image from the official GL.iNet portal and perform a clean re-flash.
- If wireless radios remain offline while wired ports function, check warranty options on the GL.iNet Flint 2 (GL-MT6000) or check out alternative models in the GL.iNet Travel Routers series.
Next steps
Try the DIY guide if you're comfortable opening the device. Still stuck? Browse related problems for similar symptoms.

