rust-v0.53 WebRTC-direct connection timeout

[dhuseby]

Repo: libp2p/rust-libp2p
Source: local build (images/rust/v0.53, based on commit b7914e407da34c99fb76dcc300b3d44b9af97fac)
Transport: webrtc-direct

Summary

rust-v0.53 times out when establishing WebRTC-direct connections with go-v0.38 (as native dialer) and with rust-v0.53 itself (as WASM/Chromium dialer). Both containers start and connect to Redis via the proxy, but no WebRTC connection is ever established. The tests hit the 180-second timeout with no output from either the dialer or listener beyond initial startup.

Failing tests (2)

• rust-v0.53 x go-v0.38 (webrtc-direct) — rust-v0.53 native dials go-v0.38
• chromium-rust-v0.53 x rust-v0.53 (webrtc-direct) — rust-v0.53 WASM (Chromium) dials rust-v0.53 native

Error output

Both tests show identical behavior — timeout with no connection:

proxy  | redis-proxy: listening on :6379, upstream=transport-redis:6379, test_key=b29a1a36
proxy  | redis-proxy: new connection from 172.18.0.5:37462
listener  | My multiaddr is: [/ip4/172.18.0.5/udp/46178/webrtc-direct/certhash/uEiBR1dWw...]
proxy  | redis-proxy: new connection from 172.18.0.6:49296

[180 seconds of silence]

ERROR:   ✗ Test timed out after 180s

The go listener publishes its multiaddr. The rust dialer connects to the proxy. But no WebRTC signaling or connection attempt appears in the logs.

Root cause analysis

This is distinct from the rust-v056-webrtc-direct-srtp-panic.md bug (which is a SRTP key derivation crash in v0.56). Here, rust-v0.53 simply never initiates the WebRTC connection.

Possible causes:

• rust-v0.53's WebRTC-direct dialer may fail to parse the listener's multiaddr from Redis (legacy key format through proxy)
• The ICE candidate exchange may fail silently in the legacy Redis key translation
• The WASM (Chromium) build may have additional WebRTC API limitations

Note that rust-v0.53 is a legacy implementation connecting through the Redis proxy. The WebRTC-direct multiaddr includes a certhash component which the dialer must retrieve from Redis to initiate the connection. If the proxy's key translation loses or corrupts the certhash data, the dialer would silently fail to connect.

Notes

• rust-v0.53 is legacy: true and uses the Redis proxy for coordination
• Other rust-v0.53 webrtc-direct tests may also fail but were not included in this filtered test run
• The go-v0.38 listener starts correctly and publishes its multiaddr — the issue is on the dialer side
• No proxy hostname issues — correct proxy-<hash> format used