GL-MT6000 (Flint 2) — recurring random reboots, matches known mtk_soc_eth watchdog-timeout bug (other threads: #45134, #64666)

Router
1

Router: GL-MT6000 (Flint 2)
Firmware: 4.9.1 (issue also present on 4.9.0 — updated firmware did not resolve it)
Kernel: 5.4.238

**Symptom:**
Router reboots spontaneously and unpredictably — anywhere from several times a day to once every day or two. When it happens, WAN/LAN/WiFi all drop simultaneously, the admin session is lost, and uptime resets to 0. No pattern I can find tied to time of day, traffic load, or any single client device.

**What I've already ruled out:**

  • A USB-powered Zigbee coordinator was drawing power from the router's USB port; moved it to an independent power source. Reboots continued afterward, so this was not the (sole) cause.
  • Checked for a stuck/misconfigured repeater service, disabled it. Reboots continued afterward.
  • Updated from firmware 4.9.0 to 4.9.1. Reboots continued afterward (recurred within hours of the update).
  • Initially suspected WiFi client instability (some devices reconnecting frequently on 5GHz), but this looks like a downstream symptom, not the root cause — same pattern reported and ruled out in the threads below.

**What I found in the boot log after the most recent reboot:**
```
WiFi@C00L1,set_datcfg_ack_cts_timeout() 13594: DAT config band(0) cck_timeout Fail!
WiFi@C00L1,set_datcfg_ack_cts_timeout() 13605: DAT config band(0) ofdm_timeout Fail!
WiFi@C00L1,set_datcfg_ack_cts_timeout() 13616: DAT config band(0) ofdma_timeout Fail!
WiFi@C00L1,set_datcfg_ack_cts_timeout() 13594: DAT config band(1) cck_timeout Fail!
WiFi@C00L1,set_datcfg_ack_cts_timeout() 13605: DAT config band(1) ofdm_timeout Fail!
WiFi@C00L1,set_datcfg_ack_cts_timeout() 13616: DAT config band(1) ofdma_timeout Fail!
warp_probe(): probe fail since warp is full!
warp_dev0: probe of 15010000.wed2 failed with error -1
```
I haven't been able to capture the log right at the moment of an actual crash — the log buffer doesn't survive the reboot, so I only ever see the fresh boot afterward, not the failure itself.

**Two other users reporting what looks like the same issue:**

  • forum.gl-inet.com/t/mt6000-crashing-kernel-core-dump/45134 — same router, crashes 1-2x/day, full network failure until reboot. Root cause identified there as `NETDEV WATCHDOG: eth1 (mtk_soc_eth): transmit queue timed out` — a MediaTek Ethernet driver bug fixed upstream in Linux kernel 6.6, but this firmware ships kernel 5.4.238.
  • forum.gl-inet.com/t/gl-mt6000-flint-2-randomly-stops-working/64666 — same `netdev watchdog transmit timed out, resetting` signature on the 2.5G port. No official fix confirmed; one community suggestion was trying the OP24 firmware build (OpenWrt 24.10 base, newer ethernet drivers), unconfirmed by that poster.

**My questions:**

  1. Is the `mtk_soc_eth` watchdog-timeout bug from those threads the confirmed cause here, or is there a different explanation for the WiFi DAT-config failures I'm seeing at boot?
  2. Is OP24 (or another firmware build with a newer kernel/ethernet driver) the recommended fix, and is migrating to it safe/reversible on this router?
  3. Is there a way to capture a crash-time log (not just the post-reboot boot log) that would help pin this down further — e.g. persistent/remote logging, or a debug build?

Happy to provide anything else that would help — full boot logs, wireless config dump, etc.

4

Hi,

Thank you for the detailed information and for referencing the previous reports.

To help capture what happens immediately before the next reboot, could you please SSH into the router and configure the system log to be stored in Flash with the following commands?

uci set system.@system[0].log_size='512'
uci set system.@system[0].log_file='/root/system.log'
uci commit system
/etc/init.d/log restart

After the issue occurs again, please retrieve /root/system.log and send it to us via private message.

image
image497×183 13.2 KB

Thank you for your support and understanding.