[kasper0406]

Problem. Control takes the endpoints of every endpoint update as the node's endpoints. An endpoint update is a map request with OmitPeers, without Stream and without ReadOnly (tailcfg MapRequest.OmitPeers). In ts_control/src/tokio/client.rs, only SetEndpoints set them.

• These requests sent none, so control dropped the node's endpoints:
  • the Hostinfo update after each (re)connect;
  • SetDerpHomeRegion, which follows every reconnect because the reconnect brings a derp map;
  • SetRoutableIPs and SetHostname.
• The runtime advertises endpoints again only when the set changes. On a stable network they stay gone.
• A peer that starts from a fresh netmap then has no candidate to ping. Go sends a CallMeMaybe only after a ping (endpoint.go:1446-1462), so that peer cannot start a direct path.

Seen on an exit node. After a map-poll reconnect, a Go client's netmap listed the node with HomeDERP but no Endpoints. A peer whose Tailscale had restarted did not get back to a direct path until the node was restarted. Its first packet after the restart was a direct ping to the re-advertised endpoint. That restart also reset other state, so this is supporting context, not proof of the whole outage.

Fix:

• CarriedNetInfo keeps the endpoints from the last SetEndpoints, and apply attaches them to every request. Go attaches c.endpoints to each request too (direct.go:1048-1104). Because the carried state outlives the poll, endpoints whose SetEndpoints request was lost are sent again on the next reconnect.
• A side command records its state, then waits for any still-pending post-connect Hostinfo update before sending its own. That update carries the state from the start of the poll; without the wait it could land last and clear the endpoints again. Go sends these updates one at a time from updateRoutine (auto.go:61-109).

Tests:

• every_request_carries_the_last_advertised_endpoints fails if apply drops the endpoints or set_endpoints does not store them.
• startup_update_is_applied_before_a_side_update fails without the wait.
• side_command_state_survives_a_watchdog_restart_while_waiting_for_startup (real watchdog, paused clock) fails if the state is recorded after the wait.
• On main, the SetDerpHomeRegion request after a SetEndpoints serializes no Endpoints.
• cargo test -p geiserx_ts_control --all-features, clippy -D warnings and fmt pass.

Not in this PR:

• Runtime SetRoutableIPs and SetHostname values are not carried, so later updates revert them to the start-up config.
• register sends no NetInfo.
• Side updates still block reading the map stream (Go runs them in updateRoutine).

Go references are at tailscale/tailscale 3bb8a906.

Created using Claude Code. Reviewed with Codex (GPT-6.1) before opening; the tests above were run locally.

🤖 Generated with Claude Code

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

Run configuration

• Source mode: Auto
• Repository: GeiserX/tailscale-rs
• Branch: main
• File: .coderabbit.yaml
• Commit: be522d3
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 85830c90-8944-486a-99d9-1cc155bec05f

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[GeiserX]

Thanks, this looks right to us and we'll merge it as is.

We checked it against the Go client. Go's Direct.sendMapRequest copies the current endpoints into every map request, streaming and lite alike, and tailcfg treats a request with OmitPeers set and neither Stream nor ReadOnly as an endpoint update. So a lite request without endpoints does clear them, and carrying the last SetEndpoints value in every request fixes that. Holding side commands until the post-connect Hostinfo update has gone out matches Go's one-at-a-time update loop. Recording the endpoints before that wait means a watchdog restart doesn't lose them, and your test covers that case.

We aren't changing anything here:

• The CHANGELOG entry stays. The file and CONTRIBUTING.md still ask for it. Whether release-please makes the hand-written Unreleased section redundant is a repo housekeeping question for us, not something this PR should settle.
• While a side command waits for the startup Hostinfo request, the map stream isn't read. If that request hangs, the 120 s watchdog restarts the poll and the carried endpoints are resent. That's a bounded cost, and main already stops reading the stream during every side request.

We'll take this up separately: routes and hostname set at runtime still aren't carried, the same way endpoints weren't. SetRoutableIPs and SetHostname record nothing (

tailscale-rs/ts_control/src/tokio/client.rs

Line 1039 in c4e03e1

Command::SetRoutableIPs { .. } | Command::SetHostname { .. } => {}

), and the other requests rebuild from config.advertised_routes() and config.hostname (

tailscale-rs/ts_control/src/tokio/client.rs

Line 921 in c4e03e1

.routable_ips(config.advertised_routes());

,

tailscale-rs/ts_control/src/tokio/client.rs

Line 980 in c4e03e1

.routable_ips(config.advertised_routes())

). We'll open an issue to move them into the carried state, at which point CarriedNetInfo (

tailscale-rs/ts_control/src/tokio/client.rs

Line 43 in c4e03e1

struct CarriedNetInfo {

) should probably get a broader name.

[GeiserX]

Merged as 4168e0a. Thanks for the careful write-up and the tests, @kasper0406. The follow-ups you listed (carrying runtime routes and hostname) will go in a separate issue.