linuxquic server bugs in handling multi-packet ClientHello

[larseggert]

Two linuxquic bugs combine to cause all failures when neqo's ClientHello spans two Initial packets (~1538 bytes).

Bug 1: Duplicate Initial packet number (pn=0)

The linuxquic server sends two separate Initial packets both with pn=0 but with different ACK contents — one ACKing the first client Initial, one ACKing the second. Reusing packet numbers is a QUIC protocol violation.

Bug 2: Multiple unique SCIDs for a single connection

The QNS runner (quic-interop-runner/testcase.py) counts handshakes by counting unique SCIDs from server Initial packets:

len(set([p.scid for p in tr.get_initial(Direction.FROM_SERVER)]))

Since the count is always exactly N+1, linuxquic sends Initial packets with two different SCIDs for what should be a single connection.

The sequence (identical across all 20+ failing tests):

1. Neqo client sends ClientHello spanning two Initial packets (e.g., pn=19 with crypto offset 0-1213, pn=20 with crypto offset 1213-1538).
2. linuxquic server sends Initial pn=0 (SCID_A) containing ACK for only the first client packet (e.g., ACK largest=19). This arrives at ~0.043s.
3. Neqo correctly switches DCID to the server's chosen CID after receiving this first server Initial (per RFC 9000 Section 17.2.2).
4. linuxquic sends ANOTHER Initial pn=0 (SCID_B) containing ACK for the second client packet (e.g., ACK largest=20). This arrives ~1ms later at ~0.044s.
5. Neqo correctly discards this as a duplicate ("Duplicate packet Recvd-in-0") — the packet number was already seen.
6. The ACK for the second client Initial is lost, so the PTO fires (~0.128s) and neqo retransmits the remaining ClientHello fragment with the new DCID.
7. The QNS runner sees 2 unique SCIDs in the server-side pcap (SCID_A and SCID_B from step 2 and 4) and reports "Expected exactly 1 handshake. Got: 2".

[lxin]

Hi, @larseggert,

Thanks for catching this, it's a regression caused by commit 01b437a , where it moves the change of skb->sk from the UDP socket to the QUIC listen socket early.

quic_accept_sock_exists() expects skb->sk to still point to the UDP socket to find an existing accepted socket. If it’s changed too early, the lookup fails and a new connection might be created if it's a initial packet.

A revert is done by 526564b , please feel free to re-run the test.

Thanks.

[lxin]

A workflow is added to prevent such regressions: https://github.com/lxin/quic/blob/main/.github/workflows/interop.yml