A most elegant TCP hole punching algorithm
Uptrenda
16 points
2 comments
March 15, 2026
Related Discussions
Found 5 related stories in 47.0ms across 3,471 title embeddings via pgvector HNSW
- The inner workings of TCP zero-copy mfrw · 49 pts · March 02, 2026 · 47% similar
- WolfIP: Lightweight TCP/IP stack with no dynamic memory allocations 789c789c789c · 114 pts · March 12, 2026 · 40% similar
- TPM-Sniffing LUKS Keys on an Embedded Linux Device [CVE-2026-0714] Tiberium · 19 pts · March 01, 2026 · 38% similar
- From Oscilloscope to Wireshark: A UDP Story (2022) ofrzeta · 100 pts · March 19, 2026 · 38% similar
- Show HN: Mtproto.zig – High-performance Telegram proxy with DPI evasion slp3r · 12 pts · April 03, 2026 · 38% similar
Discussion Highlights (2 comments)
jcalvinowens
If you're asking "where is the listener", you don't need one: https://datatracker.ietf.org/doc/html/rfc9293#simul_connect
EnigmaCurry
> Many home routers try to preserve the source port in external mappings. This is a property called “equal delta mapping” – it won’t work on all routers but for our algorithm we’re sacrificing coverage for simplicity. It is precisely this point that has flummoxed me when connecting my p2p wireguard config[1] with a friend that uses a pfsense router, no matter what we tried, pfsense always chooses a random source port. But in the simple case this blog outlines, if both ends use the same source port, this method punches through 2 firewalls effortlessly: [1] https://blog.rymcg.tech/blog/linux/wireguard_p2p/