Re: [PATCH v2] tap: Trim Ethernet padding from short IPv4 frames instead of dropping them

[Stefano Brivio <sbrivio@redhat.com>]

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