Flint 2 IP change

I have a brand new Flint 2 I’m trying to set up. Firmware 4.8.3.

When I change the LAN IP to 10.1.1.1, things go sideways. Wifi clients work fine, but any clients plugged directly into the LAN ports won’t work. DHCP is working, they get IP assignments, DNS servers, all of it. But clients can’t ping 10.1.1.1 and can’t bring up the admin web page. I can even see those clients in the glinet app. Three different machines have the same issue.

I’ve tried multiple LAN ports, no good. I’m flushing dns cache and disabling/reenabling the NIC on clients, all the things you’d do to rule out client-side issues.

As a test, I tried changing the LAN IP to 192.168.1.1 (over wifi, of course) and things work fine. Clients connected to the LAN ports all work as you’d expect.

So it’s something about “10.1.1.1” it doesn’t like. Maybe it’ll seem silly, but I really need it to be that address.

Any ideas? Can anyone out there try this to see if they see similar behavior?

Thanks.

Hi

We conducted tests locally using Flint 2 v4.8.3. The LAN IP was successfully configured to 10.1.1.1 without any issues, and other devices were able to ping the device and access the Admin Panel normally.

Please check the following:

  1. Whether the MT6000’s WAN, Repeater, and other interfaces are on the same subnet, as this could cause a subnet conflict.
  2. Whether the client device is connected only to the MT6000, with no other interfaces on the same subnet.

I appreciate you replying, thank you. I have checked other interfaces and none have any IP addresses set. Before figuring out that wireless clients worked, I held the reset button for 10 seconds to reset the whole thing, which reverted the IP to 192.168.8.1. So factory settings, change LAN IP to 10.1.1.1, that’s it. So maybe you can simulate that test, as well?

I’m trying to set this up in isolation, before connecting it to an Internet connection. Is it possible it behaves differently that way?

Try disabling hardware acceleration?

I did just try disabling hardware acceleration. Rebooted, just in case. No good. What to try next?

Yes, you can give it a try. This method can help rule out any impact from the router’s WAN interface.


You should also check the client device’s network interfaces—for example, VPN adapters, virtual network interfaces created by virtual machines, and physical wired/wireless adapters—to ensure none of them are configured with IP addresses in the same subnet.

OK, good suggestions and I did find the problem, just not the solution. The cause seems to be my Tailscale agent, running on the various clients I’ve tried (only wired ones have this issue.) If I disable the Tailscale interface, it works normally. Just to mention again, the Flint 2 is offline, so before TS has any chance to phone home.

Suggestions for how I get it working with Tailscale for my wired clients?

Is there another node in your Tailnet advertising the same subnet route?
If so, there isn’t a good workaround other than:

  • Changing the subnet on the router, or
  • Cancelling the advertising subnet route on that node .

The issue did turn out to be an advertised route within my tailnet (10.1.1.0). I remain confused about why the issue only affected wired and not wireless clients. It really threw me off. But it’s not worth dwelling on.

Thanks again for taking a look at my issue. Excited to finally set up my new router.

1 Like