On Tue, 16 Jun 2026 18:37:05 +0200 David du Colombier <0intro@gmail.com> wrote:
tap4_handler() requires the L2 payload after the IP header to match the IP datagram length exactly. Guests whose drivers pad transmitted frames to the 60 byte Ethernet minimum, as real hardware requires and as drivers modelled on hardware do (Plan 9's virtio-net, for one), send pure ACK and FIN segments as 60 byte frames: 14 byte Ethernet header, 40 byte IPv4 datagram, 6 padding octets. Those frames fail the exact length check and are dropped without trace.
passt then never sees such a guest's acknowledgements: it retransmits from the lowest unacknowledged sequence with exponential backoff while the guest, which received and acknowledged everything, waits. Every fresh connection stalls for minutes (a 1 MiB HTTP fetch over --map-host-loopback measured 248 s before this change, 0.27 s after; bulk transfer over established connections, whose ACKs ride data segments above the padding threshold, is unaffected). FIN segments are padded too, so teardown hangs as well. Note that tap_send_single() pads passt's own outbound frames to ETH_ZLEN, so the receive path was already stricter than the send path.
Trim the trailing padding to the IP datagram length instead, using a new iov_tail_trim() helper, and keep dropping frames genuinely shorter than the datagram they claim to carry. IPv6 is unaffected: its minimal TCP frame is 74 bytes, above the padding threshold.
Signed-off-by: David du Colombier <0intro@gmail.com> --- v2: - store the iov_tail_size() result in a local variable instead of computing it twice - pass ARRAY_SIZE(trim_iov) instead of UIO_MAXIOV
Applied, thanks for fixing this, and welcome to the git log! -- Stefano