webrtc: support wildcard listen addresses - #640
Conversation
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
dmitry-markin
changed the title
gab8i
left a comment
gab8i
left a comment
There was a problem hiding this comment.
It took me a while to understand effectively how does this work but if I got this right this is a great way of using the fact that the ICE candidates IP doesn't really need to be the same as the reachable address
Correct me if I'm wrong:
- listener addresses for wildcards are expanded into multiple multiaddress, one per effectively reachable interface (ip)
- using
quinn_udp::UdpSocketStateallow and auto set up ofIP_PKTINFOThere is a difference between the reachable ip and what needs to be used within str0m, the latter just needs to stay stable over the connection. This makes possible to keep a node under a proxy, the reachable addr is A but internally the first message arrives at ip B (known thanks toIP_PKTINFO), - An
AddrsPaircan be build knowing B, the first ip a message arrive at, and the remote addr. This pair is now used to force always the usage of B as ip source for sent messages and to internally dispatch messages to the right webrtc instances
One thing I didn't understand though is: what if the destination address changes mid-session?
Behind a wildcard, peers reach the node at A and the internally A → B.
With more than one internal address that can resolve to B1 at handshake time and B2 later,
how is this addressed? It this not possible?
| /// | ||
| /// A wildcard listen address is advertised as all matching interface addresses (link-local IPv6 | ||
| /// excluded). | ||
| fn build_listen_addresses(sockaddr: SocketAddr, certhash: Multihash<64>) -> Vec<Multiaddr> { |
There was a problem hiding this comment.
loopback addresses are not filtered out here, is this made on purpose?
There was a problem hiding this comment.
This matches our approach with TCP/WebSocket. Loopback addresses deprioritized later in DHT, but we advertise them over Identify protocol.
|
Yes, everything works as you described.
This is not possible if the routing is stable. Even if the routing changes mid-session, this requires at least two local addresses/interfaces B1 B2 both reachable from the public IP A, which is a very weird setup. |
## [0.15.0] - 2026-08-17 This release focuses on WebRTC. It is the first release with official WebRTC support. Expect things to break and get fixed in subsequent point releases. This release is also semver breaking on the error API. `Error::CannotReadSystemDnsConfig` now carries an opaque `DnsInitError` instead of a `hickory-resolver` error type, and the new `Error::DnsResolverInit` variant reports resolver construction failures. `Error` is now `#[non_exhaustive]`, so external `match` expressions over it require a wildcard arm. Together these changes keep `hickory-resolver` out of the public API, making future resolver bumps semver compatible. ### Added - webrtc: support wildcard listen addresses ([#640](#640)) - bitswap: enable Keccak and BLAKE2b hashers for CIDs ([#641](#641)) ### Changed - deps: bump hickory-resolver and str0m ([#642](#642)) - deps: bump str0m to 0.22 ([#639](#639)) - webrtc: use a shared 16 KiB buffer for the `WebRtcTransport` stream ([#623](#623)) ### Fixed - dns: stop leaking hickory error types in litep2p's public API ([#643](#643)) - webrtc: enforce strict client network identity verification ([#637](#637)) - webrtc: fix input backpressure ([#626](#626)) - webrtc: properly handle `str0m::Event::Closed` ([#627](#627)) --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Dmitry Markin <dmitry@markin.tech>
2 participants
Allow wildcard IPv4 & IPv6 WebRTC listen addresses, taking care of local addresses of inbound/outbound UDP packets.
Resolves #638.