Flint 2 (GL-MT6000) - 2.5G ports dead on new device / Firewall lockout on second device

Hi everyone,

I am facing a critical issue with a newly set up GL.iNet GL-MT6000 (Flint 2) and could really use some advice.

My Goal & Setup

I own two Flint 2 routers. I am using them purely as Home Access Points / Switches (one for each floor) to distribute Wi-Fi and LAN. DHCP, DNS, and the internet connection are handled by a separate main router.


Device 1: New Flint 2 (2.5G Ports Dead)

I recently bought and flashed this unit with OpenWrt 25.12.4 r32933-4ccb782af7.

  • The Problem: Both 2.5G ports (WAN and LAN) are completely dead. There are no link status changes, no LEDs, and no signs of life.
  • Tested Link Partners (1G): Connected to my other Flint 2, a Cisco switch, and a Netgear switch. No link.
  • Tested Link Partners (2.5G): Connected to a TP-Link switch. No link.
  • Troubleshooting tried:
    • I tried flashing older OpenWrt versions (I don't recall the exact build numbers, but the issue persisted).
    • I tried rolling back to stock GL.iNet firmware (v4.8.3-op24 and v4.8.4), but the installation failed, and I could not complete the flash.

Device 2: Old Flint 2 (Firewall Lockout but 2.5G works)

My second Flint 2 has been running perfectly for about a year. On this device, the 2.5G ports work flawlessly at full speed.

  • The Problem: I messed up the firewall settings on this router, and I am now locked out (no SSH, no Web UI access).
  • The Dilemma: I don't remember which older OpenWrt version is currently installed on it. I am afraid to perform a factory reset because I worry that after resetting or upgrading to a newer OpenWrt version, its 2.5G ports might break just like on my new router.

Questions:

  1. Is there a known bug or regression with the 2.5G PHY drivers/firmware in OpenWrt 25.12 or recent snapshots for the MT6000? Could this be a hardware revision change?
  2. Is there a safe way to recover access to Device 2 without wiping the firmware/partition, or should I risk the reset?

I don't understand this rationale. Resetting should be just fine.

Yes.

(Hopefully someone has more suggestions regarding device 1.)

  1. Failsafe mode, to regain access to device ?

Okay, you convinced me. :slight_smile: I'm just worried about erasing the installed OpenWrt and getting stuck in U-Boot failsafe, as I wouldn't know which version works perfectly with the 2.5G ports. It's a shame, I assumed the Flint 2 had full stable support, which is why I got a second unit.

I just found out that I can do a factory reset without losing the OS by holding the reset button for 10 seconds while it's fully booted, until the LED blinks. I hope this works.


The MT6000 does have stable support and is a very popular device.

There are a few possibilities as to what is wrong with your current device:

  • A faulty configuration
    • This could happen for a number of reasons, but is guaranteed to be an issue if you kept the settings from the GL-inet firmware when you flashed to official OpenWrt.
    • Reset to defaults and see if that fixes things.
  • Faulty hardware
    • this is always a possibile situation, but not terribly common. The best way to verify the hardware is working (if you continue to have issues with official OpenWrt) is to flash back to the vendor firmware.
    • If the vendor firmware works, something is wrong with the OpenWrt installation (maybe per the above points, maybe something else)
  • A new variant of the MT6000 with different internal hardware.
    • Sometimes vendors make minor (or major) modifications to the hardware but keep the same model number. Usually it will be indicated by "v2" or similar if there are changes. But those could require new firmware images to accommodate the changes.

I try this tomorrow. It would be no problem to reset the settings. But i dont want to loose the working Openwrt Version.

When you reset, the only thing that is lost/reset are the settings (and user-installed packages). The firmware image stays in place (it's in read-only memory).

After I figured out the port problem, I reset the configuration and flashed new OpenWrt versions. For me, the only possible explanation is a hardware defect. But on both WAN and LAN together? I read that there are different chips behind those ports.

Yes, it's possible. But you will find out for sure if the hardware is bad by reinstalling the vendor OS since that should yield a known good firmware+configuration.

Since its still operating on the other ports, what does dmesg output?

dmesg | grep -iE '2.5'
...
...1f lan1 (uninitialized): PHY [mdio-bus:07] driver [RTL8221B-VB-CG 2.5Gbps PHY (C45)] (irq=62)
... PHY [mdio-bus:01] driver [RTL8221B-VB-CG 2.5Gbps PHY (C45)] (irq=61)
... Link is Up - 2.5Gbps/Full - flow control rx/tx
... Link is Up - 2.5Gbps/Full - flow control off

Thats odd... check switch section on this link:

Every 2.5 LAN port use independent PHY chips and different connections to CPU, so i think that chances that both have a hardware malfunction are very slim. Try reinstalling original firmware (Glinet stable).

No

Assuming the firmware partition is not corrupted, yes, use the uboot-webui.

Instructions on how to get into it are here:

Use the downloads site or the Firmware Selector to get the sysupgrade image to your computer.
Follow the instructions to get to the uboot-webui page and upload the image file, following any instuctions the webui page gives you.

Wait a few minutes, change your computer back to dhcp. You should get an ipv4 address 192.168.1.xx

If this fails, you might have a corrupted flash partition. If so, repeat but using the factory image.

With regards to the other unit with the 2.5Gb/s ports not working, this is typical when flashing from the GL-web-ui and keeping configuraton (I think it is default to keep, so an easy mistake to make). The oem firmware, I think uses mediatek sdk drivers for the 2.5Gb/s ethernet ports so the config is invalid after reflash.

If this is the case, you can fix it by using the uboot-webui to reflash in the same way as you did with the other one. This will clear any oem configs that might be hanging around.

I have used/configured many of these for customer systems, so done this many times.

If all this fails then it will then be most likely that this is a faulty unit.
I have never seen a faulty one, at least not yet, but it is not impossible I guess.

So, I managed to install the stock firmware on device no. 1. The secret was not only that I had to change the IP address, but also that I had to do a reset again after installing the stock firmware. It has now turned out that the WAN and LAN01 ports are actually defective. I have now reset and reconfigured the other router, router 2. Thank you again for your support. It's a shame that I'm dealing with a defective router now."