Unable to open subsequent data channels if the WebRTC Direct initial handshake channel has been closed #5986
Comments
|
|
Hi Alex, thanks for opening this. |
|
Likely related to #5877 ? |
Yes, and in the current I am curious if your test would pass if you used this patch: master...DougAnderson444:rust-libp2p:core-v0.42-webrtc-utils-0.3.0 |
Actually I'm not sure this would make any difference - if the server does the final write and then closes the connection, the client should still be able to read the data before reading the FIN. The client doing the close might be "safer" in that it would dodge problems we've seen in the past, but the underlying channel should preserve the order of
Unfortunately no, this doesn't seem to make any difference. One thing I've noticed is that since the handshake datachannel ( It's supposed to be possible to specify an arbitrary channel id but from what I can see both Firefox and Chrome ignore this option. |
|
Waiting for 10+s between the dial and opening the ping stream doesn't help either. What I see on the JS side is that the outgoing datachannel is created, the |
|
When running against go-libp2p I notice that the channel ids increment rather than being reused: Looking more closely at the js logs vs rust-libp2p it seems the datachannel opened for the ping stream ends up with the same channel id as the negotiated handshake datachannel. Here |
achingbrain
added a commit
to libp2p/js-libp2p
that referenced
this issue
Apr 16, 2025
Removes the closing of the handshake datachannel after the connection has been opened because it breaks compatibility with rust-libp2p 53. This can be revisited after libp2p/rust-libp2p#5986 is resolved.
3 tasks
achingbrain
added a commit
to libp2p/js-libp2p
that referenced
this issue
Apr 16, 2025
Removes the closing of the handshake datachannel after the connection has been opened because it breaks compatibility with rust-libp2p 53. This can be revisited after libp2p/rust-libp2p#5986 is resolved.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Summary
The WebRTC Direct spec says:
https://github.com/libp2p/specs/blob/master/webrtc/webrtc-direct.md#connection-security
At the moment the js-libp2p implementation does not close the handshake datachannel, leaving it open for the duration of the connection.
Given that the final data read from the channel during the noise handshake is done by the client, it would be the one to close the connection.
I am trying to update the js-libp2p implementation to close the handshake datachannel as per the spec but if I do, the transport interop tests start to fail against rust-libp2p with Chrome/Firefox/WebKit being the diallers (go & Node.js work fine).
From what I can see, after the handshake channel has been closed, opening the subsequent outbound channel to send the ping message never completes.
Inbound datachannels are still opened correctly as I can see from the logs that rust-libp2p pings js-libp2p during the test.
I believe @sukunrt observed something similar with rust-libp2p while working on go-libp2p, though he elected to just not close the handshake datachannel.
rust-libp2p logs from the test run in Docker are pasted below.
Expected behavior
Outbound datachannels should open correctly after the initial handshake datachannel has been closed.
Actual behavior
Outbound datachannels fail to open after the initial handshake datachannel has been closed.
Relevant log output
Logs from the Docker test run are below (GitHub complains it's too long to be pasted here).
Possible Solution
No response
Version
0.54
Would you like to work on fixing this bug?
I'd like some help resolving it
The text was updated successfully, but these errors were encountered: