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

Tailscale status strange IP display #477

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

Originally created by @qzydustin on GitHub (Apr 16, 2023).

Bug description

When I run "Tailscale status," some nodes show ipv6 ip, and some nodes show ipv4 ip.

And ipv4 and ipv6 both work on these nodes.

For example, I can use fd7a:115c:a1e0::3 and 100.64.0.3 to connect the 2nd node in the pic, and I can use fd7a:115c:a1e0::c and 100.64.0.12 to connect the 3rd node too.

screenshot

To Reproduce

I removed and re-added the nodes, but it still shows the same.

Context info

In the screenshot,
1st Ubuntu shows ipv6
2nd Debian shows ipv6
3rd iOS shows ipv4
4th Android shows ipv4
5th Windows shows ipv4
6th iOS shows ipv6
7th macOS show sipv6

Out the screenshot,
9th Windows shows ipv6

That is so strange.

Originally created by @qzydustin on GitHub (Apr 16, 2023). **Bug description** When I run "Tailscale status," some nodes show ipv6 ip, and some nodes show ipv4 ip. And ipv4 and ipv6 both work on these nodes. For example, I can use fd7a:115c:a1e0::3 and 100.64.0.3 to connect the 2nd node in the pic, and I can use fd7a:115c:a1e0::c and 100.64.0.12 to connect the 3rd node too. ![screenshot](https://i.imgur.com/bhpB5Pz.png) **To Reproduce** I removed and re-added the nodes, but it still shows the same. **Context info** In the screenshot, 1st Ubuntu shows ipv6 2nd Debian shows ipv6 3rd iOS shows ipv4 4th Android shows ipv4 5th Windows shows ipv4 6th iOS shows ipv6 7th macOS show sipv6 Out the screenshot, 9th Windows shows ipv6 That is so strange.
adam added the buggood first issue labels 2025-12-29 01:30:07 +01:00
adam closed this issue 2025-12-29 01:30:07 +01:00
adam commented 2025-12-29 02:18:38 +01:00
Author
Owner
Copy Link

@PureTryOut commented on GitHub (Apr 17, 2023):

I can reproduce this. I don't have so many devices (only 2 right now) but both of them only show ipv6 addresses. By guessing the ipv4 addresses I found out they work just fine though.

@PureTryOut commented on GitHub (Apr 17, 2023): I can reproduce this. I don't have so many devices (only 2 right now) but both of them only show ipv6 addresses. By guessing the ipv4 addresses I found out they work just fine though.
adam commented 2025-12-29 02:18:38 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Apr 18, 2023):

I suspect this is that we dont sort the list sent to the client, and it seems mostly cosmetic. This should be a "good starter issue" for anyone who wants to find where we send the NetMap to Tailscale and sort the ips so that ipv4 is always first.

@kradalby commented on GitHub (Apr 18, 2023): I suspect this is that we dont sort the list sent to the client, and it seems mostly cosmetic. This should be a "good starter issue" for anyone who wants to find where we send the NetMap to Tailscale and sort the ips so that ipv4 is always first.
adam commented 2025-12-29 02:18:38 +01:00
Author
Owner
Copy Link

@qzydustin commented on GitHub (Apr 19, 2023):

I suspect this is that we dont sort the list sent to the client, and it seems mostly cosmetic. This should be a "good starter issue" for anyone who wants to find where we send the NetMap to Tailscale and sort the ips so that ipv4 is always first.

That's the right reason. I use tailscale status --json. Here is the difference.

  • This node shows ipv4 in status
    screenshot

  • This node shows ipv6 in status
    screenshot

@qzydustin commented on GitHub (Apr 19, 2023): > I suspect this is that we dont sort the list sent to the client, and it seems mostly cosmetic. This should be a "good starter issue" for anyone who wants to find where we send the NetMap to Tailscale and sort the ips so that ipv4 is always first. That's the right reason. I use `tailscale status --json`. Here is the difference. - This node shows ipv4 in status ![screenshot](https://i.imgur.com/MjJXvOs.png ) - This node shows ipv6 in status ![screenshot](https://i.imgur.com/t1WjRyR.png )
adam commented 2025-12-29 02:18:38 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Apr 19, 2023):

Sounds good, perfect first issue for someone to write a patch that makes sure IPv4 is always first in the list.

@kradalby commented on GitHub (Apr 19, 2023): Sounds good, perfect first issue for someone to write a patch that makes sure IPv4 is always first in the list.
adam commented 2025-12-29 02:18:38 +01:00
Author
Owner
Copy Link

@loprima-l commented on GitHub (Apr 30, 2023):

I've taken a look at it and as I can see, the status command just returns the ipn status from the tailscale lib, should we fix it there or address a PR to tailscale ?

@loprima-l commented on GitHub (Apr 30, 2023): I've taken a look at it and as I can see, the status command just returns the ipn status from the tailscale lib, should we fix it there or address a PR to tailscale ?
adam commented 2025-12-29 02:18:39 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (May 1, 2023):

It should be fixed where Headscale builds the MapResponse, make sure IPv4 is always first in the list if present.

@kradalby commented on GitHub (May 1, 2023): It should be fixed where Headscale builds the MapResponse, make sure IPv4 is always first in the list if present.
adam commented 2025-12-29 02:18:39 +01:00
Author
Owner
Copy Link

@threerog commented on GitHub (May 4, 2023):

Have you found another issue where IP cannot be displayed when ip_prefixes is not 100.64.0.0
#1409

@threerog commented on GitHub (May 4, 2023): Have you found another issue where IP cannot be displayed when `ip_prefixes` is not `100.64.0.0` #1409
adam commented 2025-12-29 02:18:39 +01:00
Author
Owner
Copy Link

@juanfont commented on GitHub (May 4, 2023):

That's a known issue with the tailscale client. Please use 100.64.0.0/10,
or a subnet of it.

On Thu, May 4, 2023, 16:57 threerog @.***> wrote:

Have you found another issue where IP cannot be displayed when ip_prefixes
is not 100.64.0.0
#1409 https://github.com/juanfont/headscale/issues/1409

—
Reply to this email directly, view it on GitHub
https://github.com/juanfont/headscale/issues/1344#issuecomment-1534931626,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABMGQ7MFKJFETT7TDJH6NDXEO7U5ANCNFSM6AAAAAAXAIPWKY
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@juanfont commented on GitHub (May 4, 2023): That's a known issue with the tailscale client. Please use 100.64.0.0/10, or a subnet of it. On Thu, May 4, 2023, 16:57 threerog ***@***.***> wrote: > Have you found another issue where IP cannot be displayed when ip_prefixes > is not 100.64.0.0 > #1409 <https://github.com/juanfont/headscale/issues/1409> > > — > Reply to this email directly, view it on GitHub > <https://github.com/juanfont/headscale/issues/1344#issuecomment-1534931626>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AABMGQ7MFKJFETT7TDJH6NDXEO7U5ANCNFSM6AAAAAAXAIPWKY> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >
adam commented 2025-12-29 02:18:39 +01:00
Author
Owner
Copy Link

@gbraad commented on GitHub (Jul 3, 2023):

Also, the order is something the Tailscale client should handle; it should consistently show the addresses by type/version and not just in the order received.

@gbraad commented on GitHub (Jul 3, 2023): Also, the order is something the Tailscale client should handle; it should consistently show the addresses by type/version and not just in the order received.
adam commented 2025-12-29 02:18:40 +01:00
Author
Owner
Copy Link

@kradalby commented on GitHub (Jul 3, 2023):

@gbraad I disagree with that, while I do not know the reason for the original decission, I suspect it is intentional to allow the control server to change the behaviour without having to wait for all clients to upgrade.

It is a perfectly viable design to accept a list that has stable order.

@kradalby commented on GitHub (Jul 3, 2023): @gbraad I disagree with that, while I do not know the reason for the original decission, I suspect it is intentional to allow the control server to change the behaviour without having to wait for all clients to upgrade. It is a perfectly viable design to accept a list that has stable order.
adam commented 2025-12-29 02:18:40 +01:00
Author
Owner
Copy Link

@gbraad commented on GitHub (Jul 3, 2023):

We can't say if that is the case... but it does make their implementation easier (centralized). If so, perhaps this order might also be dependent on how the prefixes are stated in the config?

ip_prefixes:
  - fd7a:115c:a1e0::/48
  - 100.64.0.0/10

or

ip_prefixes:
  - 100.64.0.0/10
  - fd7a:115c:a1e0::/48

Note: upon registration, as addresses are fixed/set during that phase. and remain even when the config has changed. Ref: https://github.com/juanfont/headscale/issues/614#issuecomment-1617997758

@gbraad commented on GitHub (Jul 3, 2023): We can't say if that is the case... but it does make their implementation easier (centralized). If so, perhaps this order might also be dependent on how the prefixes are stated in the config? ``` ip_prefixes: - fd7a:115c:a1e0::/48 - 100.64.0.0/10 ``` or ``` ip_prefixes: - 100.64.0.0/10 - fd7a:115c:a1e0::/48 ``` Note: upon registration, as addresses are fixed/set during that phase. and remain even when the config has changed. Ref: https://github.com/juanfont/headscale/issues/614#issuecomment-1617997758
adam commented 2025-12-29 02:18:40 +01:00
Author
Owner
Copy Link

@gbraad commented on GitHub (Jul 3, 2023):

@juanfont

That's a known issue with the tailscale client. Please use 100.64.0.0/10, or a subnet of it.

Is that filed? I experienced the same and decided to revert to the suggested subnet for now.

@gbraad commented on GitHub (Jul 3, 2023): @juanfont > That's a known issue with the tailscale client. Please use 100.64.0.0/10, or a subnet of it. Is that filed? I experienced the same and decided to revert to the suggested subnet for now.
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 good first issue
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#477
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?