Android: fix IPv6-only server connectivity #3045

Nardol · 2025-12-12T21:43:16Z

Fixes #1987

Context
The Android client could not connect to an IPv6-only TeamTalk server. On some Android devices/networks, name resolution via getaddrinfo() can also fail transiently (EAI_AGAIN), making connections unreliable even when IPv6 connectivity is available.

What this changes

Fix UDP socket creation to match the resolved address family (AF_INET/AF_INET6) instead of always forcing IPv4.
Make native resolution more robust on Android: retry on EAI_AGAIN, avoid problematic getaddrinfo() flags/constraints, and handle numeric IPv4/IPv6 literals without relying on the platform resolver.
On Android, prefer DnsResolver (system ordering) and only fall back to UDP/53 DNS as a last resort (resolver timeouts/failures), with caching and logs limited to the fallback path.

Compatibility / Risk

Keeps IPv4-only and dual-stack working.
The UDP/53 fallback is intentionally last-resort (unencrypted) to avoid total failure when the system/NDK resolver is flaky.

Testing

Verified on device: connects to IPv6-only server, dual-stack hostname (respects system preference), and IPv4-only server.

Copilot

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

Copilot

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 8 comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Library/TeamTalkLib/teamtalk/PacketHandler.cpp

Library/TeamTalkLib/myace/MyINet.cpp

Client/TeamTalkAndroid/src/main/java/dk/bearware/backend/TeamTalkService.java

- Fix native UDP socket family for IPv6 (Android) - Make address resolution robust on Android (IPv6 literals + getaddrinfo quirks) - Add Android-side DNS fallback for Private DNS resolver timeouts (udp/53) - Respect system address ordering and cache DNS results Signed-off-by: Patrick ZAJDA <patrick@zajda.fr>

Nardol · 2025-12-14T21:38:12Z

Copilot Review suggestions applied, except hostname and port are two different fields and a TeamTalk server can be on a local network.

bear101 · 2025-12-15T21:13:40Z

Is there a way to avoid changing files in TeamTalk DLL? It appears strange that it works on all other platform than Android.

Is it possible to make the DNS lookup in TeamTalkAndroid and always pass an IP-address (instead of a hostname) to TT_Connect()?

Nardol · 2025-12-15T23:45:00Z

I tried an Android-only approach (no changes in TeamTalk DLL / TeamTalkLib): resolve hostnames in TeamTalkAndroid (DnsResolver on API 29+, fallback to InetAddress) and always pass IP literals to TT_Connect().
Result: even when we successfully resolve and pass an IPv6 literal, the connection still fails on Android.
Example logs:

DNS: Candidates for ipv6.hostname.tld -> [2001:xxxx:yyyy:zzzz::]
connect() to 2001:xxxx:yyyy:zzzz:: ... -> false

And even when entering the IPv6 literal directly:

connect(): host=2001:xxxx:yyyy:zzzz:: candidates=[2001:xxxx:yyyy:zzzz::]
connect() ... -> false

So this is not just a hostname/DNS issue. The Android native layer (JNI / underlying socket/connect path) appears to fail for IPv6, meaning an Android-only DNS workaround cannot fix #1987 on its own.

I pushed a branch called android-ipv6-java-only to test.

Proposed compromise:
We could keep the Android-side hostname resolution as a fallback to improve dual-stack hostname handling (and avoid DNS issues/timeouts), but it won’t fix IPv6-only/IPv6 literal connects.
The actual fix should be in the native layer so that TT_Connect() works with IPv6 literals on Android (proper IPv6 parsing + socket connect), ideally with additional Android-native logging (errno/family/address) to validate the fix.

bear101 · 2025-12-21T07:46:14Z

Library/TeamTalkLib/myace/MyINet.cpp

+    const auto host_utf8_full = UnicodeToUtf8(host);
+    const char* host_utf8_cstr = host_utf8_full.c_str();
+    std::string host_utf8(host_utf8_cstr != nullptr ? host_utf8_cstr : "");
+    if (!host_utf8.empty() && host_utf8.front() == '[' && host_utf8.back() == ']')


Putting IPv6-address in brackets seems to be a Java-thing. The stripping should be done in Java, so host is just an IP-address. Should I look into fixing this or can you?

bear101 · 2025-12-21T07:47:43Z

Library/TeamTalkLib/myace/MyINet.cpp

        if (curr->ai_family == AF_INET6)
        {
-            addr.in6_.sin6_port = encode ? ACE_NTOHS(port) : port;
+            addr.in6_.sin6_port = encode ? ACE_HTONS(port) : port;


encode is always true, so it can be deleted.

bear101 · 2025-12-21T07:48:03Z

Library/TeamTalkLib/myace/MyINet.cpp

    {
        errno = ADDRINFOERROR;
+#if defined(ANDROID)
+        __android_log_print(ANDROID_LOG_WARN, "bearware-native",


Use MYTRACE instead. It goes to Android log.

bear101 · 2025-12-21T07:49:36Z

Library/TeamTalkLib/myace/MyINet.cpp

-    const int ADDRINFOERROR = ACE_OS::getaddrinfo(UnicodeToUtf8(host).c_str(), nullptr, &hints, &res);
+    // Android's resolver may return EAI_AGAIN transiently even when DNS works
+    // (e.g. during network transitions). Retry a few times before giving up.
+    int ADDRINFOERROR = 0;


Uppercase is for constants. ADDRINFOERROR is not a constant.

bear101 · 2025-12-21T08:05:17Z

Client/TeamTalkAndroid/src/main/java/dk/bearware/backend/TeamTalkService.java

 import java.io.FileWriter;
 import java.io.IOException;
 import java.io.StringReader;
+import java.net.DatagramPacket;


Please move the DNS code to a separate class in utils. It is unrelated to TeamTalkService.

Signed-off-by: Patrick ZAJDA <patrick@zajda.fr>

This change addresses the issue #3045 where getaddrinfo() may return EAI_AGAIN on Android. By continuously calling TeamTalk5.connect() in TeamTalkService it has the same effect as calling getaddrinfo() multiple times. Hopefully this change resolves #3045.

Nardol requested review from bear101, beqabeqa473 and poretsky as code owners December 12, 2025 21:43

Nardol force-pushed the android-ipv6-udp branch 2 times, most recently from 062df2a to d8224e4 Compare December 12, 2025 22:36

hwangsihu requested a review from Copilot December 13, 2025 06:35

Copilot AI reviewed Dec 13, 2025

View reviewed changes

Copilot started reviewing on behalf of hwangsihu December 13, 2025 07:47 View session

Nardol force-pushed the android-ipv6-udp branch 2 times, most recently from ebdf2b0 to df85703 Compare December 13, 2025 22:40

Nardol requested a review from a team as a code owner December 13, 2025 22:40

hwangsihu requested a review from Copilot December 14, 2025 08:26

Copilot started reviewing on behalf of hwangsihu December 14, 2025 08:27 View session

Copilot AI reviewed Dec 14, 2025

View reviewed changes

Nardol force-pushed the android-ipv6-udp branch from df85703 to 06f219e Compare December 14, 2025 11:10

bear101 requested changes Dec 21, 2025

View reviewed changes

bear101 and others added 3 commits December 21, 2025 09:14

Merge branch 'master' into android-ipv6-udp

0d80341

Merge branch 'master' into android-ipv6-udp

0c784d5

Apply code review suggestions

412a33e

Signed-off-by: Patrick ZAJDA <patrick@zajda.fr>

bear101 mentioned this pull request Dec 30, 2025

Continue to connect even when initial connection fails #3068

Open

Android: fix IPv6-only server connectivity #3045

Are you sure you want to change the base?

Android: fix IPv6-only server connectivity #3045

Conversation

Nardol commented Dec 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Nardol commented Dec 14, 2025

Uh oh!

bear101 commented Dec 15, 2025

Uh oh!

Nardol commented Dec 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bear101 Dec 21, 2025

Choose a reason for hiding this comment

Uh oh!

bear101 Dec 21, 2025

Choose a reason for hiding this comment

Uh oh!

bear101 Dec 21, 2025

Choose a reason for hiding this comment

Uh oh!

bear101 Dec 21, 2025

Choose a reason for hiding this comment

Uh oh!

bear101 Dec 21, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Nardol commented Dec 12, 2025 •

edited

Loading

Nardol commented Dec 15, 2025 •

edited

Loading