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

[Feature] More Information of Unsupported Tailscale Client #938

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

Originally created by @IamTaoChen on GitHub (Feb 5, 2025).

Use case

I have an older tailscale client, when I upgrade to v0.25.0-beta.1, there is an error.

headscale  | 2025/02/05 10:44:40 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305)
headscale  | 2025-02-05T10:44:40-05:00 ERR http internal server error error="noise upgrade failed: unsupported client version: 85" code=500
  1. If the error message can print the client information(name,IP .etc..), I can locate the client quickly.

Description

see up.

Contribution

  • I can write the design doc for this feature
  • I can contribute this feature

How can it be implemented?

No response

Originally created by @IamTaoChen on GitHub (Feb 5, 2025). ### Use case I have an older tailscale client, when I upgrade to `v0.25.0-beta.1`, there is an error. ```bash headscale | 2025/02/05 10:44:40 http: response.Write on hijacked connection from fmt.Fprintln (print.go:305) headscale | 2025-02-05T10:44:40-05:00 ERR http internal server error error="noise upgrade failed: unsupported client version: 85" code=500 ``` 1. If the error message can print the client information(name,IP .etc..), I can locate the client quickly. ### Description see up. ### Contribution - [ ] I can write the design doc for this feature - [ ] I can contribute this feature ### How can it be implemented? _No response_
adam added the enhancementbug labels 2025-12-29 02:26:27 +01:00
adam closed this issue 2025-12-29 02:26:27 +01:00
adam commented 2025-12-29 02:26:28 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 6, 2025):

Hi, this has already been added in the latest beta https://github.com/juanfont/headscale/pull/2391.

@kradalby commented on GitHub (Feb 6, 2025): Hi, this has already been added in the latest beta https://github.com/juanfont/headscale/pull/2391.
adam commented 2025-12-29 02:26:28 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 12, 2025):

I've opened another PR adding the version number so there is some more information, but unfortunately, at that part in the code we dont want to do any database lookup and we do not yet know any identifiers, so the version is what is available.

@kradalby commented on GitHub (Feb 12, 2025): I've opened another PR adding the version number so there is some more information, but unfortunately, at that part in the code we dont want to do any database lookup and we do not yet know any identifiers, so the version is what is available.
adam commented 2025-12-29 02:26:29 +01:00
Author
Owner
Copy Link

@mfld-pub commented on GitHub (Feb 14, 2025):

Was just about to open an issue for the same. I had a hunch which clients are doing this. It's openwrt / gl.inet devices. Their repos are stuck on a low rev of tailscale 1.6x. I was able to manually update them to stop the headscale log from being flooded. In this case theres only 90 machines on the tailnet but if you have hundreds it really would help to be able to know who is misbehaving. It makes sense that at this part of the session you don't want to to intensive lookups. Difficult to solve.

Good thing not many devices are 15 tailscale versions behind. @IamTaoChen if you are dealing with gl.inet devices you can see this solution for inspiration. Other ARM devices you can manually take the tailscale binaries, shrink them with upx and replace.

Edit: 💡 is it feasible to have an additional flag that has headscale nodes list return last seen client version ? This would prevent intensive lookups at each event but let the admin identify the devices as needed.

@mfld-pub commented on GitHub (Feb 14, 2025): Was just about to open an issue for the same. I had a hunch which clients are doing this. It's openwrt / gl.inet devices. Their repos are stuck on a low rev of tailscale 1.6x. I was able to manually update them to stop the headscale log from being flooded. In this case theres only 90 machines on the tailnet but if you have hundreds it really would help to be able to know who is misbehaving. It makes sense that at this part of the session you don't want to to intensive lookups. Difficult to solve. Good thing not many devices are 15 tailscale versions behind. @IamTaoChen if you are dealing with gl.inet devices you can see [this solution for inspiration](https://forum.gl-inet.com/t/script-update-tailscale-on-nearly-all-devices/37582). Other ARM devices you can manually take the tailscale binaries, shrink them with upx and replace. Edit: 💡 is it feasible to have an additional flag that has `headscale nodes list` return last seen client version ? This would prevent intensive lookups at each event but let the admin identify the devices as needed.
adam commented 2025-12-29 02:26:29 +01:00
Author
Owner
Copy Link

@dylangerdaly commented on GitHub (Feb 15, 2025):

Had to manually update a RPi I have running AlpineLinux, is is possible for this to be a WARN rather than not allowing the client to connect to the tailnet?

@dylangerdaly commented on GitHub (Feb 15, 2025): Had to manually update a RPi I have running AlpineLinux, is is possible for this to be a WARN rather than not allowing the client to connect to the tailnet?
adam commented 2025-12-29 02:26:29 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 16, 2025):

@dylangerdaly

No because we are actively removing old code paths to keep the codebase maintainable and healthy.

We cannot guarantee that the client works at all after it has been removed.

@kradalby commented on GitHub (Feb 16, 2025): @dylangerdaly No because we are actively removing old code paths to keep the codebase maintainable and healthy. We cannot guarantee that the client works at all after it has been removed.
adam commented 2025-12-29 02:26:29 +01:00
Author
Owner
Copy Link

@dylangerdaly commented on GitHub (Feb 16, 2025):

That's fair enough, cheers :)

@dylangerdaly commented on GitHub (Feb 16, 2025): That's fair enough, cheers :)
adam commented 2025-12-29 02:26:29 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Feb 16, 2025):

@mfld-pub

is it feasible to have an additional flag that has headscale nodes list return last seen client version ? This would prevent intensive lookups at each event but let the admin identify the devices as needed.

Would be happy to receive a PR for this!

@kradalby commented on GitHub (Feb 16, 2025): @mfld-pub > is it feasible to have an additional flag that has headscale nodes list return last seen client version ? This would prevent intensive lookups at each event but let the admin identify the devices as needed. Would be happy to receive a PR for this!
adam commented 2025-12-29 02:26:29 +01:00
Author
Owner
Copy Link

@nbp commented on GitHub (Jul 30, 2025):

I encountered this issue recently with a tailscale client on a Synology NAS.

The solution came from https://github.com/tailscale/tailscale/issues/8914#issuecomment-1683366265 , where one should run the following command to update the tailscale client on the Synology NAS:

tailscale update
@nbp commented on GitHub (Jul 30, 2025): I encountered this issue recently with a tailscale client on a Synology NAS. The solution came from https://github.com/tailscale/tailscale/issues/8914#issuecomment-1683366265 , where one should run the following command to update the tailscale client on the Synology NAS: ```sh tailscale update ```
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 enhancement
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#938
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?