srv: look SRV records up through Android's resolver

asxpi commented

2026-10-17 07:52:38 +00:00

First-time contributor

Android has no /etc/resolv.conf, so the stub resolver cannot be
configured there and every SRV lookup fell back to the domain itself
on 5222. A domain whose server is elsewhere could not be signed in to
with the host left empty, which is what the sign-in form asks for:
narayana.im, served from xmpp.narayana.im, refused the connection.
Only typing the server's host in by hand worked.

On Android, ask the system's resolver through the NDK's DNS API
(android_res_nquery, <android/multinetwork.h>, API 29; the app's floor
is 30), which is netd's: the network's servers, Private DNS and the
cache, as every other app's lookups are. libandroid is looked up at run
time, so no embedder has a library to add; without the API the old
fallback stays. A query may take 2 s rather than 500 ms, since this
resolver is known to be there.

Tested on a Pixel 9: narayana.im resolves to xmpp.narayana.im:5222 and
:5223 and the account connects with the host left empty; without this
change it is refused.

Written and tested on v1.0.0-rc7 (b40975d6); rebased onto develop (7b31417d), where it applies cleanly.

🤖 Generated with Claude Code

Android has no /etc/resolv.conf, so the stub resolver cannot be configured there and every SRV lookup fell back to the domain itself on 5222. A domain whose server is elsewhere could not be signed in to with the host left empty, which is what the sign-in form asks for: narayana.im, served from xmpp.narayana.im, refused the connection. Only typing the server's host in by hand worked. On Android, ask the system's resolver through the NDK's DNS API (android_res_nquery, <android/multinetwork.h>, API 29; the app's floor is 30), which is netd's: the network's servers, Private DNS and the cache, as every other app's lookups are. libandroid is looked up at run time, so no embedder has a library to add; without the API the old fallback stays. A query may take 2 s rather than 500 ms, since this resolver is known to be there. Tested on a Pixel 9: narayana.im resolves to xmpp.narayana.im:5222 and :5223 and the account connects with the host left empty; without this change it is refused. Written and tested on v1.0.0-rc7 (b40975d6); rebased onto develop (7b31417d), where it applies cleanly. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

asxpi added 1 commit

2026-10-17 07:52:38 +00:00

srv: look SRV records up through Android's resolver a0ca48b318

Android has no /etc/resolv.conf, so the stub resolver cannot be
configured there and every SRV lookup fell back to the domain itself
on 5222. A domain whose server is elsewhere could not be signed in to
with the host left empty, which is what the sign-in form asks for:
narayana.im, served from xmpp.narayana.im, refused the connection.
Only typing the server's host in by hand worked.

On Android, ask the system's resolver through the NDK's DNS API
(android_res_nquery, <android/multinetwork.h>, API 29; the app's floor
is 30), which is netd's: the network's servers, Private DNS and the
cache, as every other app's lookups are. libandroid is looked up at run
time, so no embedder has a library to add; without the API the old
fallback stays. A query may take 2 s rather than 500 ms, since this
resolver is known to be there.

Tested on a Pixel 9: narayana.im resolves to xmpp.narayana.im:5222 and
:5223 and the account connects with the host left empty; without this
change it is refused.

Assisted-by: Claude:opus-5-5

ann referenced this pull request from a commit

2026-10-17 14:57:42 +00:00

Merge PR #10 (fix/android-srv) with the review's follow-up 6996b1f9: SRV records looked up through Android's own resolver (android_res_nquery), a deadline on the poll, the wire-answer parse under test.

ann referenced this pull request

2026-10-17 14:58:28 +00:00

framestream: rename the socket where link() is denied #8

ann referenced this pull request

2026-10-17 14:58:28 +00:00

calls: send session-terminate when the media path closes or fails #9

ann commented

2026-10-17 14:58:29 +00:00

Owner

Merged by hand into develop (merge commit in the 8411e18f line) and released in v1.0.0-rc10; thank you. PR #10 went in with a review follow-up (6996b1f9: the wire-answer parse under test, a deadline on the poll, the resolve() doc). Closing, since a hand merge is not marked merged here.

Merged by hand into develop (merge commit in the 8411e18f line) and released in v1.0.0-rc10; thank you. PR #10 went in with a review follow-up (6996b1f9: the wire-answer parse under test, a deadline on the poll, the resolve() doc). Closing, since a hand merge is not marked merged here.

ann closed this pull request

2026-10-17 14:58:29 +00:00

ann referenced this pull request from a commit

2026-10-25 23:27:10 +00:00

AUDIT-2026-10-25 #10 (Low): a second, separate hole in a Telegram secret chat's sequence no longer aborts the chat: tacky/xmpp/mtproto.tcl receive, with a hole already asked for, asks for every run of missing numbers past the last one asked for with a Resend of its own (as /api/end-to-end/seq_no's waiting queue and Telegram for Android's requested holes do) and holds the message, under the existing bounds (HELD_MAX held messages, the 120 s gap timer from the oldest open hole); a hole already asked for is not asked again, and the gap closes once every held message has drained. A gateway or network that reorders two pairs no longer ends the chat. Test: test_mtproto_protocol.tcl mtproto-protocol-a-second-hole-is-asked-for-too, replacing mtproto-protocol-a-second-hole-aborts (fails before: the second hole aborted with gap).

ann referenced this pull request from a commit

2026-10-25 23:27:10 +00:00

AUDIT-2026-10-25 #9 #10 #12: the protocol engine's header states the rules as they now are: each hole asked for with its own Resend, a 65th held message or a hole open for 120 s aborts, an unparsable message or one with under 15 random bytes uses its seq number and is dropped. Docs only.

ann referenced this pull request from a commit

2026-10-27 00:26:42 +00:00

messagestore: the poll-vote cap counts orphan votes only, 100 a voter and 500 a chat, and clearing a chat drops its votes (the audit of 2026-10-26 #10 and Low #30): applyVote's cap, run when a vote names no stored poll, deleted every vote of the chat past its newest 500, so 501 votes naming made-up poll ids from any contact or occupant (or, in a busy chat, one vote arriving before its poll) wiped the votes on real polls, ours included; it now caps as CapOrphanReactions does, OrphanVotes listing only votes whose poll_id names no stored message by stanza-id, origin-id or own id, MaxOrphanVotesPerVoter 100 then MaxOrphanVotes 500, oldest first, and ClearDelete (preserve_history off) deletes poll_vote with the rest; test_content's content-poll-orphan-cap-spares-votes-on-stored-polls (fails without the fix) files 780 orphans from six voters beside our vote and bob's on a stored poll and finds both votes, 500 orphans and 100 of the newest voter's.

ann referenced this pull request from a commit