Skip to content

v0.3.3

Choose a tag to compare

@steeb-k steeb-k released this 13 Jul 20:32
· 36 commits to main since this release

Custom relay rework

Behaviour change. preferred — the default relay policy — now keeps the public iroh relays in the relay map alongside your custom relay instead of replacing them. Devices that were on a custom relay become reachable again to peers that lack the relay or its token. That is the fix. If you want the old "never touch third-party infrastructure" behaviour, use only.

Fixed

  • A self-hosted relay on some devices but not others silently cut the network in half. Under preferred, configuring a custom relay removed the public relays from that device's relay map. The configured device then advertised the custom relay as its only home relay and had no transport that could reach a peer homed on a public one; a peer without the token dialled the custom relay, got 401, and — hole-punching being relay-coordinated — had no direct path either. The two groups went mutually invisible while the relay was up and authenticating normally. preferred was, in effect, identical to only. It now keeps both sets in the map, with the path selector biasing traffic onto your relay, so partial deployment is no longer fatal.
  • nullgate-cli relay add hung indefinitely, and a new relay only took effect after a daemon restart. insert_relay/remove_relay await iroh's bounded socket-actor channel, which a peer stuck sending to an unreachable relay can block indefinitely — so the call blocked for 20+ minutes on a live mesh, after writing the config but before swapping the in-memory settings. Disk, path selector, endpoint map and reported settings all disagreed, and relay show truthfully reported the stale value. Settings are now saved, applied and reported atomically and return immediately (~20 ms); the endpoint map is updated by a background task with per-call timeouts.
  • The relay watchdog could never have helped, and is gone. It fired on "can I reach my relay" — always yes — and could not observe "my peers can't reach my relay", which was the actual failure.
  • The daemon kept working on requests from clients that had gone away, stranding the task. It now cancels an in-flight request when the client disconnects.
  • A non-root daemon crashed instead of falling back to a writable log directory (it accepted an existing but root-owned /var/log/nullgate, then panicked with PermissionDenied). It now probes writability first.

Added

  • Relay settings on Android (⋮ → Relay servers): add a relay with an optional access token, remove one, and choose whether the public relays stay as a backup. The phone had no relay surface at all before — the only reason it stayed reachable through the outage above. Reachable before joining a network, since a token-gated relay may be exactly what a device needs in order to join.
  • Relay changes now report whether they were actually applied, rather than unconditionally claiming "no restart needed". Note that iroh keeps a home relay that has left the map until another relay takes over, so switching to only while your custom relay is unreachable genuinely does need a restart — and now says so.
  • Both UIs warn that relay settings are per-device and must be set on every member with the same URL and token.

Upgrading

If you run your own relay: put it on every device, with the same address and token, or on none. Half-and-half is the one configuration that cannot work. After updating, devices that were stranded should find each other again without any change on your part.


Windows: install the MSI. Linux: curl -fsSL https://raw.githubusercontent.com/steeb-k/nullgate/main/install.sh | sh (or nullgatectl --update). Android: install the APK (updates in place). macOS is unchanged from 0.3.2 apart from the shared relay fixes; a macOS artifact will follow.