Hi GLiNet Forum,
Since 2022 I have been using 2x GL.iNet AX-1800 Flint devices in AP mode for a subnet on my home network. Overall I've been impressed with the Wifi performance and stability, but recently, a strange incident occurred that caused me a lot of headache. I wonder if there are other observations of similar behavior / known issues with GL.iNet devices.
Sadly my ISP does not support IPv6 (even in 2025!), so I have it turned off on my gateway router running OPNsense. I keep it turned off because most consumer electronics, if given a DHCPv6 lease from a gateway where upstream IPv6 doesn't actually work, will exhibit network connectivity problems that cannot be worked around. At least this is the default behavior I've seen in Windows, MacOS, Android, and iOS - When these things think they can use IPv6 to connect to the internet, they will often not fall back to IPv4 if the IPv6 connection fails.
A power outage occurred a couple weeks ago. As a result, a lot of things on my network couldn't connect to the internet. While investigating this, I eventually discovered the root cause was my GL.iNet devices were handing out IPv6 leases. This was with GL.iNet firmware version 4.5.0.
For example, one of my Linux workstations reported all of these IPv6 leases:
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether c0:18:03:83:7e:e6 brd ff:ff:ff:ff:ff:ff
altname enp5s0f1
inet 192.168.1.187/24 brd 192.168.1.255 scope global dynamic noprefixroute eno1
valid_lft 3116sec preferred_lft 3116sec
inet6 fddb:3c66:f8ad:0:bc31:392e:9f10:3c0/64 scope global temporary dynamic
valid_lft 599974sec preferred_lft 81081sec
inet6 dde6:94ff:eff3:0:27:56bb:a795:3d31/64 scope global temporary dynamic
valid_lft 599930sec preferred_lft 81037sec
inet6 fddb:3c66:f8ad:0:a69e:5fd:410b:292/64 scope global temporary deprecated dynamic
valid_lft 514068sec preferred_lft 0sec
inet6 dde6:94ff:eff3:0:5e66:106d:612c:209f/64 scope global temporary deprecated dynamic
valid_lft 514025sec preferred_lft 0sec
inet6 fddb:3c66:f8ad:0:a29:904a:a9c9:2f64/64 scope global temporary deprecated dynamic
valid_lft 428163sec preferred_lft 0sec
inet6 dde6:94ff:eff3:0:1d9f:ee85:fefe:7da4/64 scope global temporary deprecated dynamic
valid_lft 428119sec preferred_lft 0sec
inet6 fddb:3c66:f8ad:0:759f:27b0:6d3b:c938/64 scope global temporary deprecated dynamic
valid_lft 342258sec preferred_lft 0sec
inet6 dde6:94ff:eff3:0:2ae:2f47:fbb0:f5bb/64 scope global temporary deprecated dynamic
valid_lft 342214sec preferred_lft 0sec
inet6 fddb:3c66:f8ad:0:4764:a871:56ce:5049/64 scope global temporary deprecated dynamic
valid_lft 256351sec preferred_lft 0sec
inet6 fddb:3c66:f8ad:0:c218:3ff:fe83:7ee6/64 scope global dynamic mngtmpaddr
valid_lft forever preferred_lft forever
inet6 dde6:94ff:eff3:0:984c:5b7a:bca1:1970/64 scope global temporary deprecated dynamic
valid_lft 256308sec preferred_lft 0sec
inet6 dde6:94ff:eff3:0:c218:3ff:fe83:7ee6/64 scope global dynamic mngtmpaddr
valid_lft forever preferred_lft forever
inet6 fe80::c218:3ff:fe83:7ee6/64 scope link
valid_lft forever preferred_lft forever
Additionally, another Linux system's Tailscale logs showed the IPv6 address for a GL.iNet device as a DNS server
2025-01-21T16:14:12.006258-05:00 kali tailscaled[869]: trample: resolv.conf changed from what w
e expected. did some other program interfere? current contents: "# Generated by NetworkManager\
nsearch tail9f83e.ts.net\nnameserver 192.168.100.1\nnameserver dde6:94ff:eff3::1\nnameserver 10
0.100.100.100\n# NOTE: the libc resolver may not support more than 3 nameservers.\n# The namese
rvers listed below may not be recognized.\nnameserver 192.168.1.1\n"
I never enabled IPv6 on the the GL.iNet devices, so this was puzzling to me how a full-blown DHCPv6 configuration got loaded and enabled. Because both APs seemed to be providing this, I suspect it's possible one got a DHCPv6 lease from the other, which may have caused some broken cyclical flows on the network.
On my first attempt to disable this, I went into LuCi > Network > Interfaces and tried to uncheck "Disable IPv6 Delegation" for each of the interfaces on one of these GL.iNet devices. Attempting to apply these settings caused the device to become unreachable, so I performed a reset of the firmware to begin re-configuring it. After it came back online, I let it update itself to 4.6.11, verified that IPv6 was disabled in the GL.iNet firmware interface, changed the network mode to AP, set the Wifi SSID and passwords, and then dropped into LuCi to check the interface configuration.
Here's how the fresh AP configuration compared to the the one from the network outage:
-
Interfaces -> LAN -> DHCP Server -> General Setup -> Ignore Interface
Checked on the fresh config, unchecked on the incident config. -
Interfaces -> LAN -> DHCP Server -> IPv6 Settings -> Announced IPv6 DNS Servers
Not present on the fresh config, populated on the incident config. -
Interfaces -> LAN -> DHCP Server -> IPv6 Settings -> Local IPv6 DNS Server
Not present on the fresh config, populated on the incident config. -
Interfaces -> LAN -> DHCP Server -> IPv6 Settings -> RA-Service
Set to disabled on the fresh config, populated on the incident config. -
Interfaces -> LAN -> DHCP Server -> IPv6 Settings -> DHCPv6 Service
Set to disabled on the fresh config, populated on the incident config. -
Interfaces -> LAN -> DHCP Server -> IPv6 Settings -> NDP Proxy
Set to disabled on the fresh config, populated on the incident config.
Unfortunately I didn't look deeper than this. I was under pressure to get things working again, so I didn't take any logs / config files from the AP where the incident occurred.
This does leave me with some questions:
- Has anyone else here had their GL.iNet APs start giving out DHCPv6 addresses after a power outage?
- Perhaps it's possible for GL.iNet devices to auto-update, causing a re-write of configuration files that may trigger this?
- What is the likelihood of this scenario only affecting GL.iNet devices that had been configured as APs with firmware versions less than or equal to 4.5.0? I guess what I mean is, would this not have occurred if I had reset the device configuration after updating, removing the possibility of old configs conflicting with newer firmware logic?