This is a follow-up to the (now closed) thread WAN connection continuously drop (GL-MT3000 Beryl AX). I had the same symptom on my GL-MT3000 in a student dorm network and tracked it down over a few evenings. Measured and tested on my own unit, remote via ssh.
Symptom
eth0: Link is Down → 3–4 s → Link is Up, irregularly (~0.75/h on average, up to 7/h during video calls), on a GL-MT3000 with firmware 4.11 behind a 1 GbE campus switch.
Cable, PSU and load were ruled out: rx_crc_errors/rx_errors on eth0 stayed at 0 over 36 drops, a speedtest run on the router itself gave 926/885 Mbit/s with 0 % loss, and the drops also happened at night with zero traffic. The same router had been rock solid at home on a different switch.
Root cause: Energy-Efficient Ethernet (802.3az)
The 2.5G WAN port is an external PHY (MaxLinear GPY211, at MDIO address 5 on my unit) negotiating down to 1000BASE-T. Both the PHY and the switch advertised EEE, so Low Power Idle was active on the link. The PHY occasionally lost sync on the LPI sleep/refresh/wake transitions and reported link loss → renegotiation. EEE interop is partner-dependent, which is why this shows up only with "certain switches", as a moderator put it in the old thread.
Check whether EEE is active on your link (read-only; mii_mgr/mii_mgr_cl45 are MediaTek tools shipped in the GL firmware; ls /sys/bus/mdio_bus/devices/ shows the PHY addresses — on the MT3000, mdio-bus:00 is the internal 1G PHY for the LAN port, the other entry is the 2.5G WAN PHY):
mii_mgr_cl45 -g -p 5 -d 7 -r 0x3c # own EEE advertisement (MMD 7 reg 60); 0x0006 = 100/1000BASE-T EEE offered
mii_mgr_cl45 -g -p 5 -d 7 -r 0x3d # link partner EEE ability (MMD 7 reg 61); bit 2 set = switch offers 1000BASE-T EEE
If both are non-zero, EEE is negotiated and you are a candidate for this fix.
Fix
Clear the EEE advertisement and restart auto-negotiation. ethtool --set-eee does not work here because eth0 is a fixed link to the external PHY, so the PHY registers are written directly. The registers are IEEE-standard (Clause 45 MMD 7.60, Clause 22 BMCR bit 9); only the MDIO address may differ between units. Put this in /etc/rc.local before exit 0 — it survives firmware upgrades and only renegotiates when the register is not already cleared:
# Disable EEE (802.3az) on the 2.5G WAN PHY (MaxLinear GPY211, MDIO addr 5) - caused link drops with some switches
if [ "$(mii_mgr_cl45 -g -p 5 -d 7 -r 0x3c | sed 's/.*= *//')" != "0x0000" ]; then
mii_mgr_cl45 -s -p 5 -d 7 -r 0x3c -v 0x0000 # MMD 7 reg 0x3c: EEE advertisement off
mii_mgr -s -p 5 -r 0 -v 0x3240 # BMCR 0x3040 | bit 9: restart auto-negotiation (one 3 s link flap)
logger -t eee "EEE advertisement disabled on WAN PHY, autoneg restarted"
sleep 8
fi
Read your BMCR first (mii_mgr -g -p 5 -r 0; mine is 0x3040) and OR 0x0200 onto that value instead of blindly writing 0x3240. Careful: the tool prints the value without the 0x prefix. If you let the shell do the math, prepend 0x yourself — $((0x3040 | 0x200)) gives the correct 0x3240, whereas $((3040 | 0x200)) treats 3040 as decimal and yields 0x0BE0, which has the power-down bit (bit 11) set and would switch the PHY off.
The switch keeps advertising EEE (reg 0x3d stays non-zero), but without a matching offer from our side it is never negotiated.
Result
Zero link drops since the change (36 in the 48 h before), confirmed across a reboot. Power cost is well under 0.5 W. Revert: remove the block and reboot; the PHY returns to its defaults. No port swap and no extra switch needed.