CONNECT-IP: Packet Too Big for an oversized HTTP/3 packet never reaches the gVPC sender #1255

Activity

1. privateip

   self-assigned this

   on Oct 29, 2026
2. privateip

   added the

   Bug

   issue type on Oct 29, 2026
3. privateip

   added a parent issue on Oct 29, 2026

   • MASQUE Connector for gVPC #970
4. privateip commented on Oct 29, 2026

   

   privateip

   on Oct 29, 2026

   CollaboratorAuthor

   More actions

   Verdict: the Packet Too Big reaches the sender. The mtu-live-drop row can't see it, so the fix belongs in the row, not the datapath.

   Checked on main at 0558ab4, with a containerlab gVPC lab run of the MASQUE service suite whose provider and datapath match 32704f5.

   What the lab showed

   During the mtu-live-drop row:

   • The workload's capture recorded exactly one ICMPv6 Packet Too Big, reporting MTU 1280, from the connector's address. It arrived with the first oversized packet.
   • Afterwards the workload's kernel had a cached route toward the connector with mtu 1280 and a 600-second expiry. Its Icmp6InPktTooBigs counter was 1.

   So the server builds the error for a packet read from the TUN device, the packet policy and the TUN backend pass it, and the edge attachment, traffic policy and return path deliver it. Of the three places listed in the issue, the third is where it goes missing.

   Why the row reports 0

   1. Path MTU discovery (RFC 8201) caches the reported MTU. After one Packet Too Big, the sender stops putting oversized packets on the wire for that destination until the cache entry expires: its kernel either fragments them or refuses the send locally. A correct sender therefore gets one Packet Too Big per cache lifetime, not one per step. The row expects one in every step.
   2. That single Packet Too Big arrives with the first oversized ping, just after the ping starts. Each step's window opens 1 s after the step begins, so even a captured Packet Too Big falls outside step 0's window and is never counted.
   3. The row starts the capture and the ping one immediately after the other, without waiting for tcpdump to report that it is listening. The one message can arrive before the capture is ready, which matches the run in the issue, where nothing was captured at all.

   For the same reason, the "1400-byte packets delivered" column is 0 by design over HTTP/3. A fixed 1350-byte QUIC packet carries at most about 1310 inner bytes.

   #1247 (the steps below 1360) is unaffected.
5. privateip commented on Oct 29, 2026

   

   privateip

   on Oct 29, 2026

   CollaboratorAuthor

   More actions

   Approved fix plan

   The fix is test-only, in the mtu-live-drop row of tests/edgeconformance/masque_service_rows_test.go:

   1. Start the workload's Packet Too Big capture and wait until tcpdump reports that it is listening before the oversized ping starts.
   2. At each step, after the MTU change, flush the workload's cached path MTU in its network namespace before that step's window opens. The next oversized packet then reaches the provider and draws a fresh Packet Too Big, so every step from 1500 down to 1360 can show one.
   3. Keep the failure condition: a step that carries 1280-byte replies but shows no Packet Too Big fails the row.

   Risk: this changes no runtime behavior. The assertions for the steps below the floor (#1247) are unchanged.

   Verification: task lint, task ci, and the MASQUE service suite's mtu-live-drop row in the containerlab lab.
6. privateip commented on Oct 29, 2026

   

   privateip

   on Oct 29, 2026

   CollaboratorAuthor

   More actions

   Change to the plan: the row's ping also stops after the first Packet Too Big

   With the capture and cache-flush changes alone, the lab row still counted no Packet Too Big at any step. Captures inside the workload and the provider pod showed why: during the whole row, the workload sent exactly one oversized packet. The provider returned exactly one Packet Too Big for it, and the workload received it.

   The row runs iputils ping with -w, and with a deadline set, iputils ping exits at its first error. A three-namespace reproduction outside the lab (a sender, a router with a smaller next-hop MTU, and a receiver) confirms this:

   Ping	Cache flushes	Oversized packets sent	Packet Too Big received
   -w 6	2	1	1
   timeout 6	0	1	1
   timeout 6	2	3	3

   So the row also bounds the ping with timeout instead of -w. With both changes, each step gets a fresh oversized packet and a fresh Packet Too Big. The fix is still test-only.
7. privateip

   closed this as completedin #1259on Oct 30, 2026
8. privateip

   added a commit that references this issue on Oct 30, 2026

   test(edge): Count each step's Packet Too Big in mtu-live-drop

   ...

   This issue will close once commit ba40632 is merged into the 'main' branch.

   ba40632