Description
You can also check #14 (comment) this is a repost of it since I wasn't able to reopen the issue.
I'm seeing IPv6 addresses everywhere in the logs, my current location has no IPv6 support, so I'm getting the same errors, seeing lines like:
2024/04/28 21:41:53 control: bootstrapDNS("derp8b.tailscale.com", "2a03:b0c0:1:d0::ec1:e001") for "headscale.example.com" error: Get "https://derp8b.tailscale.com/bootstrap-dns?q=headscale.example.com": dial tcp [2a03:b0c0:1:d0::ec1:e001]:443: connect: network is unreachable
2024/04/28 21:41:53 [RATELIMIT] format("control: bootstrapDNS(%q, %q) for %q error: %v")
2024/04/28 21:41:55 Received error: fetch control key: Get "https://headscale.example.com/key?v=90": failed to resolve "headscale.example.com": no DNS fallback candidates remain for "headscale.example.com"
2024/04/28 21:42:12 [RATELIMIT] format("monitor: ip rule deleted; failed to parse netlink message: %v") (33 dropped)
2024/04/28 21:42:12 monitor: ip rule deleted; failed to parse netlink message: invalid route message attributes: netlink: attribute 20 is not a uint8; length: 8
2024/04/28 21:42:12 monitor: ip rule deleted; failed to parse netlink message: invalid route message attributes: netlink: attribute 20 is not a uint8; length: 8
2024/04/28 21:42:12 monitor: ip rule deleted; failed to parse netlink message: invalid route message attributes: netlink: attribute 20 is not a uint8; length: 8
2024/04/28 21:42:12 monitor: ip rule deleted; failed to parse netlink message: invalid route message attributes: netlink: attribute 20 is not a uint8; length: 8
2024/04/28 21:42:15 monitor: ip rule deleted; failed to parse netlink message: invalid route message attributes: netlink: attribute 20 is not a uint8; length: 8
2024/04/28 21:42:15 [RATELIMIT] format("monitor: ip rule deleted; failed to parse netlink message: %v")
2024/04/28 21:42:20 control: LoginInteractive -> regen=true
2024/04/28 21:42:20 control: doLogin(regen=true, hasUrl=false)
2024/04/28 21:42:20 [RATELIMIT] format("control: trying bootstrapDNS(%q, %q) for %q ...") (9 dropped)
2024/04/28 21:42:21 control: trying bootstrapDNS("derp1d.tailscale.com", "2604:a880:800:10::7fe:f001") for "headscale.example.com" ...
2024/04/28 21:42:21 [RATELIMIT] format("control: bootstrapDNS(%q, %q) for %q error: %v") (3 dropped)
2024/04/28 21:43:27 control: bootstrapDNS("derp8c.tailscale.com", "2a03:b0c0:1:d0::e1f:4001") for "headscale.example.com" error: Get "https://derp8c.tailscale.com/bootstrap-dns?q=headscale.example.com": dial tcp [2a03:b0c0:1:d0::e1f:4001]:443: connect: network is unreachable
2024/04/28 21:43:27 control: trying bootstrapDNS("derp1d.tailscale.com", "165.22.33.71") for "headscale.example.com" ...
2024/04/28 21:43:27 [RATELIMIT] format("control: trying bootstrapDNS(%q, %q) for %q ...")
headscale.example.com is for privacy of course. Even when having a hosts file entry in Android nothing seems to solve this issue.
The derp servers used in the 'trying bootstrapDNS' lines are returning IPv6 addresses first, the IPv4 addresses come later... A picture from the bootstrapDNS request:
First I thought this is a tailscale issue on its own, but since this does not happen on desktop clients I thought we can think of a workaround for the Magisk/KSU module. Things coming to my mind I still have to test:
- Reversing the bootstrap DNS results, so the IPv4 addresses would be on top of the list (?)
- Hardcoding the DERP servers with their IP's temporarily into the hosts file systemlessly until we register the device as a node on headscale.
- Telling Tailscale with a commandline switch (if this exists of course) that it should prefer IPv4 over IPv6.
- Using a HTTPS_PROXY or HTTPS_PROXY until registered as a node. Tailscale has issues from time to time recognizing these environment variables. See related Reddit Post with the same issue I have.
These are probably not that logical and promising but it's better than not being able to register the device at all. Also a related GitHub issue on tailscale/tailscale.