starred/headscale
1
0
Fork 0
mirror of https://github.com/juanfont/headscale.git synced 2026-01-12 04:10:32 +01:00
Code Issues 98 Packages Projects Releases 10 Wiki Activity

[Bug] CurAddr isn't updated on Windows clients when a Linux client is restarted #1178

New Issue
Open
opened 2025-12-29 02:28:44 +01:00 by adam · 0 comments
adam commented 2025-12-29 02:28:44 +01:00
Owner
Copy Link

Originally created by @rittycat on GitHub (Dec 18, 2025).

Is this a support request?

  • This is not a support request

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

When a given linux client restarts their tailscale service, their current address is left blank on Windows based tailscale clients until the windows client is restarted. Linux-to-Linux does not appear to be affected.

Expected Behavior

The current address is propagated so that traffic can resume.

When using tailscale's own SaaS, the windows client works as expected, so I suspect this is somehow headscale related despite it looking like a client-sided issue.

Steps To Reproduce

  1. Start pinging a linux client from a windows client
  2. Restart the linux client with systemd or tailscale down; tailscale up
  3. Pinging should stop
  4. Restart the windows client from systray
  5. Pinging should resume

Environment

- OS: Ubuntu 24.04.3 LTS - 6.8.0-71-generic Kernel
- Headscale version: V0.27.1
    headscale version v0.27.1+dirty
    commit: f658a8eacd4d86edc65424b50635afed46ca4b2a
    build time: 2025-11-11T19:17:02Z
    built with: go1.25.1 linux/amd64
- Tailscale version (windows): 1.92.1
    tailscale commit: fb55d39055de6bb41a76cefebc923f2a7fe3dfec
    long version: 1.92.1-tfb55d3905-g9ac7fadc0
    other commit: 9ac7fadc0bb77ed38a4c7ca463af06e21002bbdb
    go version: go1.25.5
- Tailscale version (linux):  1.92.1
    tailscale commit: fb55d39055de6bb41a76cefebc923f2a7fe3dfec
    long version: 1.92.1-tfb55d3905-g9ac7fadc0
    other commit: 9ac7fadc0bb77ed38a4c7ca463af06e21002bbdb
    go version: go1.25.5

Runtime environment

  • Headscale is behind a (reverse) proxy
  • Headscale runs in a container

Debug information

I generated a bunch of debug logs at various points during reproduction while connected to headscale, then again after being connected to tailscale SaaS

Test to Headscale

tailscale status --json outputs:

The only changes occurred were timestamps and CurAddr on the target's peer object:

Before target restart: "CurAddr": "135.148.74.172:41641",
After target restart: "CurAddr": "",
After local restart: "CurAddr": "135.148.74.172:41641",

tailscale debug netmap outputs:

The disokey with the remote changed each time

Test to Tailscale Official

tailscale status --json outputs:

No change, though I presume if I took a report right during the ~1.5s that the pinging timed out, it might also show CurAddr as empty

tailscale debug netmap outputs:

The disokey with the remote changed each time

Originally created by @rittycat on GitHub (Dec 18, 2025). ### Is this a support request? - [x] This is not a support request ### Is there an existing issue for this? - [x] I have searched the existing issues ### Current Behavior When a given linux client restarts their tailscale service, their current address is left blank on Windows based tailscale clients until the windows client is restarted. Linux-to-Linux does not appear to be affected. ### Expected Behavior The current address is propagated so that traffic can resume. When using tailscale's own SaaS, the windows client works as expected, so I suspect this is somehow headscale related despite it looking like a client-sided issue. ### Steps To Reproduce 1. Start pinging a linux client from a windows client 2. Restart the linux client with systemd or `tailscale down; tailscale up` 3. Pinging should stop 4. Restart the windows client from systray 5. Pinging should resume ### Environment ```markdown - OS: Ubuntu 24.04.3 LTS - 6.8.0-71-generic Kernel - Headscale version: V0.27.1 headscale version v0.27.1+dirty commit: f658a8eacd4d86edc65424b50635afed46ca4b2a build time: 2025-11-11T19:17:02Z built with: go1.25.1 linux/amd64 - Tailscale version (windows): 1.92.1 tailscale commit: fb55d39055de6bb41a76cefebc923f2a7fe3dfec long version: 1.92.1-tfb55d3905-g9ac7fadc0 other commit: 9ac7fadc0bb77ed38a4c7ca463af06e21002bbdb go version: go1.25.5 - Tailscale version (linux): 1.92.1 tailscale commit: fb55d39055de6bb41a76cefebc923f2a7fe3dfec long version: 1.92.1-tfb55d3905-g9ac7fadc0 other commit: 9ac7fadc0bb77ed38a4c7ca463af06e21002bbdb go version: go1.25.5 ``` ### Runtime environment - [x] Headscale is behind a (reverse) proxy - [x] Headscale runs in a container ### Debug information I generated a bunch of debug logs at various points during reproduction while connected to headscale, then again after being connected to tailscale SaaS ## Test to Headscale ### tailscale status --json outputs: The only changes occurred were timestamps and CurAddr on the target's peer object: Before target restart: "CurAddr": "135.148.74.172:41641", After target restart: "CurAddr": "", After local restart: "CurAddr": "135.148.74.172:41641", ### tailscale debug netmap outputs: The disokey with the remote changed each time ## Test to Tailscale Official ### tailscale status --json outputs: No change, though I presume if I took a report right during the ~1.5s that the pinging timed out, it might also show CurAddr as empty ### tailscale debug netmap outputs: The disokey with the remote changed each time
adam added the bug label 2025-12-29 02:28:44 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
CLI
DERP
DNS
Nix
OIDC
SSH
bug
database
documentation
duplicate
enhancement
faq
good first issue
grants
help wanted
might-come
needs design doc
needs investigation
no-stale-bot
out of scope
performance
policy 📝
pull-request
Mirrored from GitHub Pull Request
 question
regression
routes
stale
tags
tailscale-feature-gap
well described ❤️
wontfix
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/headscale#1178
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?