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.

Library/TeamTalkLib/myace/MyINet.cpp

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

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.

Library/TeamTalkLib/myace/MyINet.cpp

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.

bear101 · 2026-01-07T07:14:42Z

I'll resolve the conflicts with master but I plan to put #ifdef ANDROID around the new code in this merge-request. The new code complicates the code a lot and the problems with IPv6 are only related to Android.

Should there also be a check on Android platform level? In other words does newer Android devices also have this issue?

bear101 · 2026-01-07T08:23:55Z

Library/TeamTalkLib/myace/MyINet.cpp

+    // IPv6 literals may include a zone index, e.g. "fe80::1%wlan0".
+    std::string v6addr = host_utf8;
+    std::string v6scope;
+    auto percent = host_utf8.find('%');


v6addr and v6scope extraction could be simplified a lot by using a regular expression.

Regex would add complexity and has known perf/portability issues on Android/NDK; I’d prefer the current simple split.

Nardol · 2026-01-07T09:29:40Z

Should there also be a check on Android platform level? In other words does newer Android devices also have this issue?

Yes, I’m using a Pixel 8a running Android 16, and I’m experiencing this issue.

bear101 · 2026-01-07T11:48:28Z

@beqabeqa473 are you ok with the changes in this PR? In the TeamTalk DLL I've isolated the Android code, so none of the other platforms are affected.

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

Fix bug where only first resolved IP-address was tried in connect attempt #3068

Merged

bear101 requested changes Dec 31, 2025

View reviewed changes

Library/TeamTalkLib/myace/MyINet.cpp Show resolved Hide resolved

Merge branch 'master' into android-ipv6-udp

64dba28

bear101 mentioned this pull request Jan 4, 2026

Change TeamTalkService.reconnect() to TeamTalkService.initConnection(ServerEntry) #3078

Draft

Merge branch 'master' into android-ipv6-udp

f4bd091

bear101 force-pushed the android-ipv6-udp branch from 8ee4eff to f4bd091 Compare January 7, 2026 07:53

bear101 reviewed Jan 7, 2026

View reviewed changes

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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bear101 commented Jan 7, 2026

Uh oh!

bear101 Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Nardol Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Nardol commented Jan 7, 2026

Uh oh!

bear101 commented Jan 7, 2026

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

bear101 Jan 7, 2026 •

edited

Loading