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

[PR #31] [MERGED] Improving how headscale handles the client startup process #1210

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

📋 Pull Request Information

Original PR: https://github.com/juanfont/headscale/pull/31
Author: @juanfont
Created: 5/24/2021
Status: ✅ Merged
Merged: 5/30/2021
Merged by: @juanfont

Base: main ← Head: improving-client-startup

📝 Commits (2)

  • 064e448 Improved tailnode start up handling
  • 4be39f9 Improved log messages, and case That Should Never Happen

📊 Changes

1 file changed (+35 additions, -15 deletions)

View changed files

📝 api.go (+35 -15)

📄 Description

As discussed in Gitter (https://gitter.im/headscale-dev/community?at=60a9618c801b07264e631b7f), there is some weirdness in how the tailscale clients first interact with the control server in the /map endpoint.

The client uses tailcfg.MapRequest to indicate the different stages of its startup process. At the beginning of the interaction, the client just expects an updated tailcfg.DERPMap - not the full list of its peers. It will close the connection as soon as it receives the first tailcfg.MapResponse.

With this PR headscale closes the connection when the client is expecting so, in these initial interactions to /map. In these stages it does not start the keepAlives either.

I don't think this is completely solved, so I added a few more logging messages to track this.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/juanfont/headscale/pull/31 **Author:** [@juanfont](https://github.com/juanfont) **Created:** 5/24/2021 **Status:** ✅ Merged **Merged:** 5/30/2021 **Merged by:** [@juanfont](https://github.com/juanfont) **Base:** `main` ← **Head:** `improving-client-startup` --- ### 📝 Commits (2) - [`064e448`](https://github.com/juanfont/headscale/commit/064e448d2233ac81ca3e5787b96e355910e9902a) Improved tailnode start up handling - [`4be39f9`](https://github.com/juanfont/headscale/commit/4be39f9b83dbc4fe0757b837c3be02f977646370) Improved log messages, and case That Should Never Happen ### 📊 Changes **1 file changed** (+35 additions, -15 deletions) <details> <summary>View changed files</summary> 📝 `api.go` (+35 -15) </details> ### 📄 Description As discussed in Gitter (https://gitter.im/headscale-dev/community?at=60a9618c801b07264e631b7f), there is some weirdness in how the tailscale clients first interact with the control server in the `/map` endpoint. The client uses `tailcfg.MapRequest` to indicate the different stages of its startup process. At the beginning of the interaction, the client just expects an updated `tailcfg.DERPMap` - not the full list of its peers. It will close the connection as soon as it receives the first `tailcfg.MapResponse`. With this PR headscale closes the connection when the client is expecting so, in these initial interactions to `/map`. In these stages it does not start the keepAlives either. I don't think this is completely solved, so I added a few more logging messages to track this. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2025-12-29 02:29:14 +01:00
adam closed this issue 2025-12-29 02:29:14 +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 pull-request
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#1210
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?