Repository navigation
Conversation
The federation send path only looked up dest:9191 in children_ss and dialed a new outbound DTLS connection on a miss. When our egress NAT rewrites the source port, the peer keys our tunnel under the rewritten port, so its own send path misses and it dials back into us. That dial is redundant (a healthy tunnel between the two coturns already exists) and it is exactly the handshake that fails: our conntrack entry for the dial occupies the local:9191->peer:9191 tuple, so the kernel's clash resolution rewrites the inbound ClientHello fragments to a fresh source port each, and the handshake can never complete (one-way media, paired 10s handshake timeouts on the receiving side). Maintain a peers-by-ip index (peer IP, port zeroed -> established federation socket), registered when any federation handshake completes and unregistered in delete_socket_from_map so entries can never dangle. On a send-path miss of dest:9191, reuse any established tunnel to that peer IP instead of dialing; DTLS application data flows both ways regardless of client/server role (the server-side PONG already proves this path). Only dial when no established tunnel exists at all. One side deploying this heals a pairing: the redundant dial never happens, and the clash precondition is never created on the peer's node. Same thread model as children_ss (federation listener thread). (cherry picked from commit 4304282)
bsinou
force-pushed
the
WPB-26951_federation-tunnel-reuse-dev
branch
from
November 11, 2026 12:11
81853e6 to
610fcb1
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Port of #59 to
dev. The commit is cherry-picked from #59 unchanged and applies cleanly.When egress NAT rewrites the source port of our federation dial, the peer misses
dest:9191in its send path and dials back into us. That redundant dial clashes with our conntrack entry, the kernel splits the inbound ClientHello across fresh source ports, and the handshake times out: one-way media in federated calls.The send path now looks up an established tunnel to the peer IP (new peers-by-IP index, registered at handshake completion, unregistered in
delete_socket_from_map) and only dials when there is none. One side deploying this heals a pairing.See #59 for the full analysis, the thread model and the known simultaneous-dial limitation.
Testing
Built on Ubuntu 24.04 as in CI:
make checkpasses, and the TCP, TLS, UDP and DTLS client tests pass. The federation path itself is not covered by these tests; #59 has the staging validation plan.