Summary
After some period of uptime, the GLKVM web console becomes unreachable over IPv4 — the URL simply times out. The device is not down: its Wi-Fi link, kernel, and every service remain fully healthy, and the console is still reachable over IPv6 on its link-local address.
Because the device continues to answer ARP, it still appears "present" on the network, which makes this look like a hung or crashed appliance. It is not.
Environment
| Item | Value |
|---|---|
| Device | GL-RM10 (Comet Pro) |
| Firmware | 1.10.0 release4 when the fault occurred; 1.10.1 installed afterwards (see Firmware status below) |
| Network path | Wi-Fi only (5 GHz), no Ethernet connected |
| Addressing | DHCP with a static reservation on the router |
| Client used for diagnosis | Linux, same L2 segment |
Symptoms
https://<KVM-IP>/times out. HTTP and HTTPS both fail.ping <KVM-IP>→ 100% packet loss.- The device looks powered and healthy otherwise (video passthrough works, touchscreen responds).
- Recovery previously required a physical power cycle.
Diagnosis
1. The device is present at layer 2
ARP resolves promptly and consistently (~2 ms), and re-resolves correctly after the local neighbor entry is deleted. The router also holds a valid ARP entry for the device.
2. Nothing above layer 2 responds — IPv4
Packet capture while probing shows:
- ICMP echo requests → no reply
- TCP SYN to 443 and 80 → no reply, no RST (timeouts, not refusals)
- UDP mDNS (5353) and DNS (53) → no reply
No TCP RST is significant: a refused connection would prove a live IP stack with no listener. Silence means the IPv4 input path is not processing packets at all.
3. It is not a client or router problem
Two independent IPv4 clients fail identically — a host on the LAN and the router itself. Other wireless clients on the same LAN are reachable normally from the same client, ruling out client isolation or an ACL.
4. IPv6 is completely unaffected
The device's IPv6 link-local address answers normally:
- ICMPv6 echo → 0% loss
- TCP 443 → open, serves the full GLKVM web app (HTTP 200, main JS bundle loads in full)
- Protected API paths → correct
401while unauthenticated - TCP 22 → open
- TLS certificate and fingerprint unchanged from before the fault
So the kernel, the network driver, and every application service are alive. Only IPv4 forwarding/input has stopped.
Why this matters
The combination "ARP answers + IPv4 silent" is easy to misdiagnose as a hung device, which pushes people to a physical power cycle. That is unnecessary, and on this device a long press of the physical reset button erases the configuration.
Workaround: reach the console over IPv6
From any machine on the same L2 segment, open the link-local address. In a browser the zone separator must be percent-encoded:
https://[<KVM-IPV6-LINK-LOCAL>%25<interface>]/
<interface>is the client's interface name on Linux (e.g.eth0,en0) or the interface index on Windows (e.g.%2).- No router IPv6 support is needed — the address is link-local.
- Verify the TLS fingerprint against the value you recorded previously before logging in.
From there the console works normally, and the IPv4 path can be recovered by a soft reboot from the UI or by fixing the network state via Toolbox → Terminal — no physical access required.
To find the device's link-local address before you can reach it: it is EUI-64 derived from the device MAC, so fe80:: + the MAC with the 7th bit flipped and ff:fe inserted in the middle.
Firmware status
The fault occurred on 1.10.0 release4. The device was subsequently rebooted and updated to 1.10.1 (released 2026-09-28), which is the current release for this model.
The 1.10.1 changelog is cumulative — it repeats the 1.10.0 items and adds a single new line, "Added two-way video support." It contains no network, IPv4, or connectivity fix. So this behaviour is not addressed by upgrading, and the reboot that restored connectivity is the mechanism that recovers it.
Getting the release information right is itself a trap: the vendor's docs page and search-engine snippets both lag behind the actual release. The authoritative source is the machine-readable release record — for this model, rm10.release.version in the firmware overview API — and a docs snippet should never be quoted as the current version.
Log evidence and a standing defect
The appliance's own log export (Help → Export Log Files) confirms the version from the device side — RK_MODEL=RM10, RK_VERSION=V1.10.1 release2 after the update, V1.10.0 release4 before it.
Worth knowing: the device retains only one previous boot in its log buffer (logread_last_boot). Rebooting to recover destroys the fault window. On this occasion the reboot happened before the logs were exported, so the onset was lost — a sequencing problem, not a data problem. Export the log archive while the device is still wedged, then reboot.
The export did surface a defect that persists across both firmware versions:
connmand: Interface wlan0 [ wifi ] IPv4 online check to
http://ipv4.connman.net/online/status.html failed: no valid proxy
The Wi-Fi service reports Proxy = [ URL=, Method=auto ] with Proxy.Configuration = [ ] — method auto with an empty PAC URL — so every online check fails and the interface is never marked online.
This is offered as the leading hypothesis, not a proven cause, for the reason above: the onset was lost to the reboot. It is worth checking because connman is the only network manager on the device (there is no udhcpc, dhcpcd, or dhclient process — connman performs DHCP itself), the firmware advertises Wi-Fi/Ethernet failover behaviour, and a connectivity daemon that permanently believes it is offline is a plausible driver of repeated interface reconfiguration. The failure signature — L2 and ARP alive, IPv4 ingress dead, IPv6 untouched — is consistent with IPv4 configuration being torn down and not restored.
Device-side findings from inspecting the appliance directly
Read-only inspection of the device (over its IPv6 link-local path) turned up several things worth sharing, plus two suspects.
A route-managing daemon is running. gl-route-monitor (/usr/sbin/gl-route-monitor, started by /etc/init.d/S99gl-route-monitor when the hardware model reports rm10) was live on the device. Given the fault is a routing/IPv4-stack failure, a daemon whose job is to manage routes is an obvious place to look.
Multi-WAN failover is not a suspect. /usr/sbin/glmwan (S98multi-wan) was not running. This rules out the theory that failover logic moved the default route onto the cable-less Ethernet port.
ps is unreliable on this device — use /proc. ps w lists almost nothing (just the shell), so a ps | grep <name> that returns empty proves nothing. Process names are also truncated to 15 characters, so gl-route-monitor appears as gl-route-monito. Enumerate properly:
for p in /proc/[0-9]*; do printf '%5s %s\n' "${p#/proc/}" "$(cat $p/comm 2>/dev/null)"; done | sort -k2
Init scripts use GL.iNet naming, not the daemon name. The connectivity manager is /etc/init.d/S45connman (which does support restart). There is no /etc/init.d/connman — an easy wrong guess that silently skips a network restart.
A network restart is not risk-free on a Wi-Fi-only unit. Because there is no cable, bouncing the Wi-Fi stack risks leaving the appliance with no network at all — and then no remote access and no remote reboot, which is worse than the original fault. If you build an automated recovery around a network restart, arm a device-side failsafe first: a detached watcher that reboots the unit if the default gateway stays unreachable for a few minutes. Testing the gateway (rather than the console port) means it cannot misfire on the wedge itself, because the device's outbound IPv4 keeps working while its inbound path is dead.
What to capture while it is wedged. If you can still reach the device over IPv6, capture this before rebooting:
ip -4 addr ; ip -4 route ; ip -4 rule ; ip -6 addr ; ip neigh
cat /proc/sys/net/ipv4/conf/*/rp_filter
iptables -L -n -v ; iptables -t nat -L -n -v
connmanctl services ; connmanctl technologies
logread | tail -800 ; dmesg | tail -300
That set is exactly what distinguishes "IPv4 configuration was torn down" from "packets are being filtered", and it is what the reboot destroys.
The device's own connectivity watchdog: /usr/bin/repeater
The appliance ships a daemon that watches connectivity and reconnects Wi-Fi on its own initiative. It is started by /etc/init.d/S80repeater as /usr/bin/eco /usr/bin/repeater, and it was running on the affected unit (confirmed via /proc, since ps is not usable here). Its configuration is /etc/glinet/gl-repeater.conf, whose entire contents are:
{"enable":true}
Its strings reveal what it does:
ping -I wlan0 -c 1 -W 1 <gateway>
ping -I wlan0 -c 2 -W 2 <gateway>
GW_PING_ATTEMPTS gw_fail_rounds GW_FAIL_ROUNDS_MAX
ping_ok last_reconnect_bssid auto_reconnect
"rounds, reconnect as last resort"
wpa_cli_disconnect_network
In other words: it pings the default gateway; when that fails enough consecutive rounds, it calls wpa_cli_disconnect_network and re-associates. The only tunable setting is enable — the failure thresholds are compiled in and not exposed to the user.
This matters because of what it is: a component that, on its own judgement, tears down the Wi-Fi link on a device where Wi-Fi is the only link. If a reconfigure of that kind is ever left half-finished, the observable result would be exactly this fault — L2/ARP alive, IPv4 ingress dead, IPv6 link-local untouched.
A closely related report, and an inconsistency worth noting
A separate thread — "Comet Pro reconnects Wi-Fi every 25 s when the gateway doesn't answer ping" (topic 71610, opened 2026-09-27 on V1.10.0 release4, the same firmware as this fault) — identified this same daemon as the cause of periodic Wi-Fi drops:
- A contributor's advice there was to stop the repeater and rename it as a workaround.
- GL.iNet's reply was that the feature would be evaluated in future updates.
- The original reporter's final post states that V1.10.1 release2 fixed it.
That last point is worth flagging: the 1.10.1 changelog contains no network-related entry at all, yet a user reports a network defect being fixed by that release. If 1.10.1 did change repeater behaviour, the changelog should say so — users are making upgrade decisions on it, and a silent network fix is also a silent network change.
Whether the 1.10.1 fix is complete is not something a user can determine from outside, which is precisely why the request below asks GL.iNet to confirm it.
Requests to GL.iNet
- Reproduce it. A soak test on a Wi-Fi-only GL-RM10 with the console idle for a long period may surface this. Both of my occurrences followed extended uptime.
- Inspect the IPv4 input path on the wedge. Specifically the IPv4 neighbor/route state and any packet filtering applied to the LAN interface, since ARP continues to work while ICMP and TCP are dropped silently.
- Add a self-heal. A watchdog that detects "ARP answers but the console's TCP services are unreachable from the LAN" and restarts the network stack would turn a field-site power cycle into an automatic recovery.
- Keep services listening on IPv6 and document it. The IPv6 path is what made remote recovery possible here; documenting it as a supported fallback path would help other users.
- Log network-state transitions. Any log entry recording the IPv4 interface/route changing state at the moment the console became unreachable would help pin down the trigger.
- Fix the connman proxy configuration. The Wi-Fi service ships with
Proxy Method=autoand an empty PAC URL, so the online check can never succeed. Setting the proxy method todirect(or supplying a valid PAC URL) would let the interface actually reach an online state. Please also confirm whether a persistently not-online interface can trigger failover reconfiguration on a Wi-Fi-only unit. - Retain more than one previous boot.
logread_last_bootkeeps exactly one boot back, so a routine reboot erases the evidence of the fault being investigated. Retaining a small ring of prior boots (or letting the user export before rebooting, which is not obvious) would make these reports actionable. - Review
gl-route-monitor's interaction with the IPv4 routing table. It was running on the affected unit, and the failure is a routing/IPv4-stack fault. Does it ever remove or reprogram the IPv4 default route, and what happens if it does so while an interface reconfigures? - Provide a documented, safe way to restart only the network stack. On a Wi-Fi-only unit there is no second path, so restarting networking can strand the appliance entirely — which currently makes "reboot" the only safe recovery. A supported, failsafe network restart (or automatic rollback if connectivity does not return) would be a real improvement for remote sites.
- Surface the IPv4 wedge state instead of hiding it. The appliance already runs monitors and has a web UI; detecting "my IPv4 stack is not answering inbound traffic" and either self-healing or warning the user would prevent the physical power cycles this report is about.
- Make
repeatersafe on a Wi-Fi-only unit, or make it configurable. Right now it will disconnect the Wi-Fi link on repeated gateway-ping failures, on a device with no other network path, and the only exposed setting isenable. Please confirm (a) what the compiled-in thresholds are, (b) whether a reconnect it initiates can leave IPv4 unconfigured, and (c) whether the 1.10.1 changes to this daemon (reported fixed in topic 71610 but absent from the changelog) close that window. Exposing the thresholds, and arming the reconnect with an automatic rollback or reboot if the interface does not come back, would remove the failure mode entirely. - State network changes in the changelog. If 1.10.1 altered connectivity-monitor behaviour, that belongs in the release notes alongside the video feature. A user upgrading for an unrelated reason is otherwise unaware that their network watchdog changed.