Hi everyone,
Sharing two reproducible bugs I've confirmed across V1.7.0 release2 and V1.8.0 release4 on the GL-RM10, in case others are hitting the same issues and to get visibility from the GL.iNet team.
Bug #1 — "Paste To Remote Device" silently drops Spanish accented characters and symbols
Category: Toolbox → Clipboard → Paste To Remote Device
When pasting to a remote Windows machine using the clipboard "Paste To Remote Device" function, many characters are silently dropped — not substituted, just missing. This includes:
All accented vowels: á é í ó ú ñ (and uppercase)
Various symbols: < > ¿ ¡ and others
This happens even when the language selector is set to Spanish (Español). The selector appears to have no effect on which characters are transmitted.
Test string to reproduce:
áéíóúñÁÉÍÓÚÑ (á) [é] {í} <ó> "ú" 'ñ' <> {} () ¿? ¡! ,.;
Expected output in Notepad: identical to the above.
Actual output: multiple characters missing (accents and symbols).
My suspicion: The paste implementation converts to HID keystrokes using a fixed US/QWERTY keymap, regardless of the language selector. Characters that don't exist in that base map are silently dropped. This is consistent with what others have reported for live keyboard input (see
#63520
and
#64235
), but specifically affects the clipboard paste pipeline.
Confirmed on: V1.7.0 release2 and V1.8.0 release4 — no improvement between versions.
Bug #2 — Default route stays permanently "dead" after upstream gateway recovers, no auto-recovery
Category: Network / WiFi connectivity
When the upstream router/gateway has a brief interruption (reboot, power cut) and comes back online, the GL-RM10 does not automatically restore internet connectivity. The default route stays marked as dead indefinitely:
$ ip route show
default via 192.168.x.1 dev wlan0 dead ← stuck here
The gateway itself is pingable, but any traffic to the internet fails with Network is unreachable. A manual fix is required every time:
ip neigh flush dev wlan0
ip route del default
ip route add default via 192.168.x.1 dev wlan0
Root cause: /etc/connman/main.conf ships with:
OnlineCheckMode = none
This disables ConnMan's reachability monitoring entirely. When the ARP cache for the gateway enters a FAILED state, the kernel marks the route as dead and ConnMan never notices or recovers it.
Workaround: Changing OnlineCheckMode to continuous and adding an ARP flush watchdog resolves the issue, but this shouldn't be needed out of the box.
Request: Could the default OnlineCheckMode be changed to at least one-shot in a future firmware update, or alternatively add a route recovery script to the WiFi bring-up sequence?
Confirmed on: V1.8.0 release4, Kernel 6.1.118, aarch64.
Anyone else hitting these? Happy to share full logs if the team needs them.