tap: Trim Ethernet padding from short IPv4 frames instead of dropping them

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>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>

0 files changed, 0 insertions, 0 deletions