libp2p / libp2p/unified-testing

c-v0.0.1 QUIC stream hang during multistream-select

Open
#11 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

c quic
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

  1. T=0.000s: Initial QUIC packet sent (1252 bytes)
  2. T=0.002s: Server Initial + Handshake received, transport parameters exchanged
  3. T=0.003s: Client Handshake sent, 1-RTT packets begin
  4. T=0.005s: handshake_done received, connection fully established
  5. T=0.005s: Stream 4 opened, multistream-select header sent (20 bytes)
  6. 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 4 is 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.