GL-RM1 v1.10.1: Tailscale bind hangs when NTP fails behind Slate AX

I am reporting a reproducible failure involving a Comet GL-RM1 connected behind a Slate AX GL-AXT1800. The immediate workaround is successful, but it requires disabling the Slate's client DNS-enforcement feature. This also exposes a Comet error-handling problem that leaves users with an indefinite spinner and no useful diagnosis.

Environment

  • Comet GL-RM1
  • Comet firmware: V1.10.1 release1 (RM1)
  • Slate AX GL-AXT1800
  • Slate firmware: V4.8.3
  • Slate operating as a Wi-Fi repeater/router, with the Comet connected to its LAN at 192.168.8.233
  • Slate LAN/gateway: 192.168.8.1
  • Slate DNS mode: Encrypted DNS / DNS-over-HTTPS using Cloudflare
  • "Override DNS Settings of All Clients" was enabled
  • Comet accessed locally with Chrome on macOS

User-visible symptoms

  1. The GLKVM Mac application initially stalled at 99% while connecting.
  2. The Comet's local web console remained reachable.
  3. In Apps Center > Tailscale, clicking "Bind Device" displayed an indefinite spinner and never opened the Tailscale authorization page.
  4. The UI did not report a DNS, clock, TLS, or Tailscale service error.

Comet diagnostics

  • General IP connectivity worked; the Comet could reach 8.8.8.8.
  • DNS resolution failed, including pool.ntp.org.
  • The Comet clock remained at 1969-12-31 because NTP could not resolve its servers.
  • "tailscale status" reported NoState/logged out.
  • The recorded Tailscale error was:

fetch control key: Get "https://controlplane.tailscale.com/key?v=138": x509: certificate has expired or is not yet valid: current time 1969-12-31...

  • ConnMan reported the Ethernet service as ethernet_9483c4c288a6_cable, using gateway/DNS 192.168.8.1.
  • Configuring Comet DNS to 1.1.1.1 and 8.8.8.8 did not initially help while the Slate DNS override was enabled.

Slate AX diagnostics
With "Override DNS Settings of All Clients" enabled:

  • dig @192.168.8.1 pool.ntp.org timed out.
  • dig @1.1.1.1 pool.ntp.org also timed out. Direct DNS appeared to be intercepted but was not answered.
  • AdGuard Home was disabled.
  • dnscrypt-proxy appeared healthy and able to reach Cloudflare.
  • dnsmasq repeatedly logged:

Conntrack connection mark retrieval failed: No such file or directory

Workaround and verification

  1. Disabled only "Override DNS Settings of All Clients" on the Slate AX. Encrypted DNS remained enabled.
  2. DNS immediately began working:
  3. Ran "ntpd -gq" on the Comet. Its clock immediately corrected to the current date/time.
  4. Restarted the Comet Tailscale service.
  5. "tailscale status" then cleanly reported "Logged out" without the TLS/certificate error.
  6. Clicking "Bind Device" immediately opened Tailscale authorization, and the Comet appeared in the Tailscale admin console.

Expected behavior

  • Slate AX DNS enforcement should forward or redirect client DNS successfully, including when Encrypted DNS is selected.
  • Comet should detect an invalid/un synchronized clock before attempting Tailscale authentication.
  • The Comet UI should display an actionable error such as "DNS unavailable" or "Time synchronization failed," rather than spinning indefinitely.
  • Tailscale should retry or recover automatically after DNS and time synchronization recover.

Impact
This makes the documented Tailscale setup appear broken and is extremely difficult to diagnose without shell access. The clock/TLS failure is hidden from the user. The present workaround also requires leaving the Slate's DNS-enforcement feature disabled.

Could you please:

  1. Confirm whether the GL-AXT1800 V4.8.3 DNS-enforcement/conntrack behavior is a known issue?
  2. Confirm whether it is safe to re-enable "Override DNS Settings of All Clients," and provide a supported configuration or fix?
  3. Add explicit DNS/NTP/TLS error handling to the Comet Tailscale Bind flow?
  4. Confirm whether a Comet firmware fix is planned, since this still occurs on V1.10.1 release1?

This appears related to the existing forum report:

I can't reproduce it using my MT6000

Hi, we're currently investigating this issue. Sorry for the inconvenience!