libp2p / libp2p/unified-testing
c-v0.0.1 QUIC stream hang during multistream-select
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 7
- Forks
- 19
- PR merge metrics
- No merged PRs in 30d
Description
Repo: Pier-Two/c-libp2p
Commit: 23a617223a3bbfb4b2af8f219f389e440b9c1ac2
Transport: quic-v1
Summary
c-v0.0.1 completes the QUIC handshake and 1-RTT key establishment with go-v0.40, but hangs during multistream-select negotiation on stream 4. The dialer sends the multistream-select header (/multistream/1.0.0) but receives no response. The test times out after 180 seconds.
Failing tests (1)
c-v0.0.1 x go-v0.40 (quic-v1)
Error output
Dialer (c-v0.0.1): No explicit error message. The QUIC handshake completes successfully (1-RTT established, handshake_done received), connection IDs are exchanged, and then the dialer sends multistream-select on stream 4:
15f3f161f041eda3: stream 4, offset 0, length 20, fin = 0: 132f6d756c746973...
The hex 132f6d756c746973... decodes to the multistream-select header (\x13/multistream/1.0.0\n). After this packet, no further progress is made until the 180-second timeout.
Framework:
[2026-02-14 18:21:08] ERROR: Test timed out after 180 seconds
Timeline from logs
- T=0.000s: Initial QUIC packet sent (1252 bytes)
- T=0.002s: Server Initial + Handshake received, transport parameters exchanged
- T=0.003s: Client Handshake sent, 1-RTT packets begin
- T=0.005s:
handshake_donereceived, connection fully established - T=0.005s: Stream 4 opened, multistream-select header sent (20 bytes)
- T=180s: Timeout - no response to multistream-select
Notes
- The QUIC transport layer works correctly (handshake, crypto, connection ID management all succeed). The hang occurs at the application protocol layer (multistream-select over QUIC streams).
- The
stream 4is correct for QUIC client-initiated bidirectional streams (stream ID 4 = second client bidi stream after stream 0). - The multistream-select message appears correctly framed (length-prefixed with
\x13= 19 bytes for/multistream/1.0.0\n). - The go listener does not appear to acknowledge or respond to the stream data, suggesting a possible issue with how c-libp2p opens or signals new QUIC streams to the peer.
- Only tested against go-v0.40 in this configuration. Other go versions may exhibit the same behavior.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the failing c-v0.0.1 x go-v0.40 (quic-v1) test and its stream-4 logs first. Compare how c-libp2p opens and signals the QUIC stream with the go-v0.40 listener; done means multistream-select receives a response and the test no longer times out.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100