Flint2 lasts about 10 days then crashes, needing full reset

Router
1

Hi GL.iNet Team,

I’m seeking assistance with my Flint 2 (purchased via AliExpress in December). Despite my background in IT and extensive troubleshooting, the unit remains unreliable for production use.

The Issue: Every 7–10 days, the router enters a "zombie" state:

  • LED Status: Flashing (indicating no internet).

  • Connectivity: SSIDs are visible/connectable, but there is no data throughput.

  • Management: Web UI and SSH are inaccessible via both Wi-Fi and Ethernet.

  • Recovery: A standard reboot fails; only a full firmware reset restores functionality.

My Environment:

  • Connection: 1000/1000 Mbps.

  • Clients: ~30 Wi-Fi, 4 Wired.

  • Packages: Only Tailscale (tried both stock and optimized GitHub builds).

  • Thermals: Unit is well-ventilated, tried both lying flat & wall-mounted, always cool to the touch.

Troubleshooting Performed:

  • Firmware: Tested v4.8.3, v4.9.9 beta, and v4.8.3opn24.

  • Modes: Issue persists even when configured strictly as an Access Point (AP).

  • Settings: Disabled Hardware NAT to rule out chip-level processing errors.

Given that the device fails even in AP mode with minimal load, I suspect a hardware defect. How can I formally validate this for an RMA, or is there a specific debug log I should capture before the next 10-day crash cycle? (However, my lack of confidence in the device would prefer not to have to use it in production any more)

Thanks in advance.

2

Reddit seems to suggest 4.7.7 and schedule weekly reboots.

Is this the norm? I've never had to run not-the-latest and force a reboot on any routers before.

3

Hi

From your description:

  • Flint 2 itself appears to be working normally, since the SSID is visible and clients can connect to it.
  • The issue seems to be that Flint 2 has lost its connection to the upstream router, as it cannot obtain an IP address via DHCP or access the network.

After the issue occurs, please check the following:

  1. Verify that the cable connected to Flint 2’s WAN port is working properly. You can try connecting another device with the same cable to see whether it can obtain an IP address and access the internet.
  2. Reboot Flint 2 and unplug/replug the WAN cable. Also, check the upstream router’s logs or capture packets to confirm whether Flint 2 is sending DHCP requests and whether the upstream router is correctly assigning an IP address.
4

Well, you’re half right.

When running in router mode, the Flint2, when in its ‘zombie’ state, would claim that no cable is connected to the WAN port.

I tried different cables, even tried enabling the second WAN port - it would just say there’s no cable connected.

Then, with the same cable still attached, firmware reset and it’s immediately connected and online.

I’ve triple-checked everything connected and upstream from the Flint2, they’re all sound. It’s something internal in the Flint2 that just decides enough is enough and won’t come back until it’s factory reset.

6

So you have already tested the device in Router mode (not AP mode), and the issue still occurs — specifically, the Flint 2 shows “no cable connected” on the port configured as the WAN port, and it returns to normal after a reset.

Is our understanding correct?

Could you please further check the following:

  1. If you simply reboot the router, does the WAN port start working again?

  2. After the issue occurs, SSH into the router and run the following command to check the port status:

    ethtool eth1

  3. After the issue occurs, export the device logs and send them to us via private message.

How to export logs:

image
image1430×911 87 KB

How to send private messages:

image
image632×233 19.1 KB

7

Thanks, Will.
Last night I wiped the Flint2 again and have returned it to Router mode. It’s running firmware 4.7.7 and I’ve configured everything as I need it. I’ve just taken a full config backup from the LuCi interface too.

The router is set to schedule reboot every Saturday morning (@3.33am).

I’ll monitor how things go and if the error does occur, I’ll capture the logs and send them over to you.

Thank you for your support.

1 Like
8

However, I may have traced the issue - I use Tailscale and have an IPv6 network. It seems this causes tailscaled to bombard the system.log every few seconds. I suspect that would take it toll over a few days….

Wed Feb 11 11:31:53 2026 daemon.err tailscaled[23890]: 2026/02/11 11:31:53 monitor: RTM_NEWROUTE: src=, dst=2a0e:xxxx:xxxx:xxxx::/64, gw=, outif=11, table=254
Wed Feb 11 11:31:55 2026 daemon.err tailscaled[23890]: 2026/02/11 11:31:55 monitor: RTM_NEWROUTE: src=, dst=2a0e:xxxx:xxxx:xxxx::/64, gw=, outif=11, table=254
Wed Feb 11 11:31:58 2026 daemon.err tailscaled[23890]: 2026/02/11 11:31:58 monitor: RTM_NEWROUTE: src=, dst=2a0e:xxxx:xxxx:xxxx::/64, gw=, outif=11, table=254
Wed Feb 11 11:32:01 2026 daemon.err tailscaled[23890]: 2026/02/11 11:32:01 monitor: RTM_NEWROUTE: src=, dst=2a0e:xxxx:xxxx:xxxx::/64, gw=, outif=11, table=254
...
Wed Feb 11 11:49:53 2026 daemon.err tailscaled[23890]: 2026/02/11 11:49:53 wg: [+d9D2] - Failed to derive keypair: invalid state for keypair derivation: handshakeZeroed

So, I have disabled Tailscale (I have it elsewhere on my network) and enabled Wireguard instead. Will see if that sorts it…

1 Like
10

Did this resolve your issue?

11

Unfortunately not.

It crashed again. I performed another firmware reset, and it lasted less than 8 hours before crashing again. I returned the unit as faulty and received a refund.

I don't believe it was any software in particular, despite the apparent errors above. I sadly had a duff unit.