tsnet: control accepts node key (machineAuthorized=true) but serves a netmap with no addresses, client hangs in Starting forever

Open
  • Is something wrong?
#22,276 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
networking

Research direction

Start from the logs attached to the report, looking for the netmap: self line and the active login: <missing-profile> line that follow a registration with machineAuthorized=true. The payload does not name the source files, so trace the path from Server.Up() through the state transition from NoState to Starting. Done means either that copied state with an expired or mismatched key ends in NeedsLogin with a visible error, or that the netmap includes addresses and the client reaches Running.

Written by the indexing model from the issue text.

Description

bug OS-linux tsnet
What is the issue?

tsnet: node key accepted (machineAuthorized=true) but control returns a netmap with no addresses, client stuck in Starting forever

What I did

  • I have a tsnet app that ran on my Mac for about 2 weeks. It was last online Oct 28.
  • I stopped it, copied its tsnet state dir (tailscaled.state, profile-data/, certs/) over to a Linux box, and started the same app there with the same Hostname and Dir. tailscale.com v1.104.2.

What happened

  • RegisterReq: onode= node=[hFfst] got back nodeKeyExpired=false, machineAuthorized=true, authURL=false, so control accepted the key.
  • The netmap that came back had nothing in it for me: netmap: self: [hFfst] auth=machine-authorized u=userid:… [], then active login: <missing-profile> and netmap: suggested exit node: no preferred DERP.
  • State went NoState -> Starting and stayed there. Never hit Running, so Server.Up() just blocks forever.
  • The admin console kept showing the device as last seen Oct 28 and "Machine not connected", even though the node key it listed was the same one my client was sending.
  • I tried this 3 times over about 15 minutes, same thing every time.

Workaround

  • TSNET_FORCE_LOGIN=1 with a reusable auth key fixed it right away: RegisterReq: onode=[hFfst] node=[xh+EY], the map came back with addresses, Starting -> Running in about a second, and the console updated the same device with the same IP.

What I'd expect

  • Either reject the old key so the client lands in NeedsLogin and I can actually see something is wrong, or send the full map. Accepting the registration and then sending an empty map just leaves tsnet apps hanging in Up() with no error anywhere.

Logs attached (tsnet Logf output) for the stuck run and the forced-login run.

relayd-debug.log
relayd-debug2.log

Steps to reproduce
  1. Run a tsnet app with a fixed Hostname and Dir on machine A (mine was a Mac, tailscale.com v1.104.2). Let it join the tailnet and run for a while. Mine ran about 2 weeks and was last online Oct 28.
  2. Stop it.
  3. Copy the state dir (tailscaled.state, profile-data/, certs/) to machine B (mine was Arch Linux).
  4. Start the same app on machine B with the same Hostname and Dir, and TS_AUTHKEY set to a reusable key.

What happens:

  • tsnet logs Authkey is set; but state is NoState. Ignoring authkey and uses the copied state.
  • RegisterReq: onode= node=[hFfst] comes back nodeKeyExpired=false, machineAuthorized=true, authURL=false.
  • The netmap has nothing for me: netmap: self: [hFfst] auth=machine-authorized u=userid:… [], then active login: <missing-profile> and netmap: suggested exit node: no preferred DERP.
  • State goes NoState -> Starting and stays there. Never Running, so Server.Up() blocks forever.
  • The admin console keeps showing the device as last seen Oct 28, "Machine not connected", even though the node key it lists is the one my client is sending.
  • Tried 3 times over about 15 minutes, same every time.
Are there any recent changes that introduced the issue?

All I did was move from a Mac to a Linux box.

OS

Linux

OS version

Arch Linux, kernel 7.2.2-arch1-1

Tailscale version

tailscale.com v1.104.2 via tsnet (Go 1.27.3)

Other software

This was found on Linux but the state came from macOS 26.6.2.

Bug report

No tailscale CLI (tsnet). BackendLogID from the tsnet log: 76bd57ac7c85a9644f4ffd673b43fe99d6ccc88c6aace6ca41f86eb73cfcfccb

Dominant language
Go
Stars
38.8k
Forks
3.4k
Avg merge
2d 7h
Merged PRs (30d)
194

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from tailscale/tailscale

All issues in tailscale/tailscale

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.