Android: DNS lookup failure for custom control servers on 1.31.40-t2aade349f-g033f7d87b43 #5698
Comments
|
When DNS lookup is failing, do you see logcat messages like this: Does it find any DNS servers? |
DentonGentry
added
OS-android
L1 Very few
|
@DentonGentry thanks for the hint! I have a similar setup (with headscale as control node) and I started experiencing the issue described by @PeterCxy after updating the latest tailscale android version from Play Store: 1.32.0-tfc688fe02-g13fc35a8bd5. Looking at logcat logs while trying to log in from android I did not see messages like these: only messages like the ones reported by @PeterCxy. Downgrading to F-Droid build 1.29.194-t70f9fc8c7-gd0812b9476b solved the issue for me. Hope this help. |
|
I can confirm too that there is no logcat messages like what is given and the issue seems to be present for builds after 1.31 with self-hosted Headscale servers (because with the official control plane, it will fall back to the DERP servers for name resolution and everything will be fine) |
|
I'm running into this issue on Android 13 with the Play Store app too. I believe I'm also experiencing this on MacOS via the App Store app and the https://pkgs.tailscale.com bundles. Any version before 1.32.0 works, but any version after and including 1.32.0 fails to connect to the custom control plane. On Mac, I see The domain I'm using for the control server does in fact resolve and works with the earlier releases as mentioned. |
|
Update: It seems that this error only happens when IPv6 is not available, at least on my devices. My home Wi-Fi has IPv6, so it works fine with home Wi-Fi, but when outside on data or on a Wi-Fi AP without IPv6, it fails with the error log given in the original bug report. I'm not sure whether this is related to all the connection failures in bootstrapDNS, because I'm assuming those should fail either way, with or without a IPv6 connection? (because self-hosted Headscale servers are not whitelisted by DERP nodes) EDIT: However, in the IPv6 environment, the bootstrapDNS logs simply do not show up, but I still do not have when it is working with an IPv6 address and DNS |
|
I believe that those |
Confirming this behaviour here too. My home ISP doesn't have IPv6 enabled yet, and fails. If I switch to my phones 5G connection (which does have IPv6), the client works as expected. |
On Android, the system resolver can return IPv4 addresses as IPv6-mapped addresses (i.e. `::ffff:a.b.c.d`). After the switch to `net/netip` (19008a3), this case is no longer handled and a response like this will be seen as failure to resolve any IPv4 addresses. Handle this case by simply calling `Unmap()` on the returned IP when it is a 4-in-6 address. Fixes tailscale#5698.
On Android, the system resolver can return IPv4 addresses as IPv6-mapped addresses (i.e. `::ffff:a.b.c.d`). After the switch to `net/netip` (19008a3), this case is no longer handled and a response like this will be seen as failure to resolve any IPv4 addresses. Handle this case by simply calling `Unmap()` on the returned IP when it is a 4-in-6 address. Fixes tailscale#5698. Signed-off-by: Peter Cai <peter@typeblog.net>
|
Following the IPv6 clue, it turns out that this is another case of unexpected system resolver behavior (returning IPv4 mapped in IPv6, i.e. |
On Android, the system resolver can return IPv4 addresses as IPv6-mapped addresses (i.e. `::ffff:a.b.c.d`). After the switch to `net/netip` (19008a3), this case is no longer handled and a response like this will be seen as failure to resolve any IPv4 addresses. Handle this case by simply calling `Unmap()` on the returned IP when it is a 4-in-6 address. Fixes tailscale#5698. Signed-off-by: Peter Cai <peter@typeblog.net>
On Android, the system resolver can return IPv4 addresses as IPv6-mapped addresses (i.e. `::ffff:a.b.c.d`). After the switch to `net/netip` (19008a3), this case is no longer handled and a response like this will be seen as failure to resolve any IPv4 addresses. Handle this case by simply calling `Unmap()` on the returned IPs. Fixes tailscale#5698. Signed-off-by: Peter Cai <peter@typeblog.net>
On Android, the system resolver can return IPv4 addresses as IPv6-mapped addresses (i.e. `::ffff:a.b.c.d`). After the switch to `net/netip` (19008a3), this case is no longer handled and a response like this will be seen as failure to resolve any IPv4 addresses. Handle this case by simply calling `Unmap()` on the returned IPs. Fixes #5698. Signed-off-by: Peter Cai <peter@typeblog.net>
On Android, the system resolver can return IPv4 addresses as IPv6-mapped addresses (i.e. `::ffff:a.b.c.d`). After the switch to `net/netip` (19008a3), this case is no longer handled and a response like this will be seen as failure to resolve any IPv4 addresses. Handle this case by simply calling `Unmap()` on the returned IPs. Fixes #5698. Signed-off-by: Peter Cai <peter@typeblog.net> (cherry picked from commit 4597ec1)
|
Android app 1.32.2 has been released in the Play Store containing this fix. |
What is the issue?
Using the F-Droid build version 1.31.40-t2aade349f-g033f7d87b43 of the Android client, I am unable to connect to my custom Headscale control server. The log shows DNS lookup failures, and because the control server is not an allowed domain in the DNS fallback servers, the client is unable to resolve the IP address in any way, and is stuck in the loading state. The previous F-Droid build (1.29.194-t70f9fc8c7-gd0812b9476b) and the Play Store build (1.30.2) do not have the same issue.
A sample of the logs:
The connection failures to IPv6 fallback DNS can be safely ignored (I think). And here is a sample of the logs when it works (on older / Play Store builds):
Note that in this case, the fallback resolvers do not seem to be used whatsoever. In both cases, the
DefaultResolversarray is empty.Steps to reproduce
Are there any recent changes that introduced the issue?
No response
OS
Android
OS version
AOSP 13
Tailscale version
1.31.40-t2aade349f-g033f7d87b43
Bug report
No response
The text was updated successfully, but these errors were encountered: