Describe the bug
Found while building the MTU-matrix integration tests for #1097: when a packet is larger than the interface's MTU, tcpreplay truncates it and sends the truncated frame onto the wire anyway, while counting it as a failed packet, not a successful one.
To Reproduce
$ sudo ip link add tcprsmall0 type dummy && sudo ip link set tcprsmall0 mtu 1280 up
$ sudo tcpreplay -i tcprsmall0 -l 1 -t test/test.pcap
test.pcap has packets up to 1514 bytes. Output (trimmed):
Warning in txring.c:txring_put() line 134:
[!] 186 bytes from 1514 byte packet truncated
Warning in send_packets.c:send_packets() line 623:
Unable to send packet: Only able to write 1328 bytes out of 1514 bytes total
...
Statistics for network device: tcprsmall0
Successful packets: 0
Failed packets: 176
but /sys/class/net/tcprsmall0/statistics/tx_packets advances by 4 over the run - meaning frames genuinely reached the wire while being counted as failures.
Expected behavior
Two defensible fixes, either is fine:
- Refuse an over-MTU packet outright (skip it, don't call
txring_put() at all) - "failed" then means what it says: nothing went out.
- Or count a truncated-but-transmitted frame as sent, since it did reach the wire, just corrupted.
What's happening now is neither: a caller reading "0 successful, 176 failed" reasonably concludes nothing was transmitted, when in fact partial, corrupted frames were injected onto the network.
Additional context
txring_put()'s truncation itself (src/common/txring.c around line 132) is old, pre-existing, and documented with a /* TODO Fragment packet */ comment - not new. What's new here is confirming, empirically, that send_packets.c's "count truncation as a failure" (src/send_packets.c line 623) doesn't stop the already-truncated frame from being queued and transmitted - the two checks are inconsistent with each other.
Not the #1078/#1090 failure mode (no phantom success is reported - "Successful packets: 0" is at least not a false claim), so it doesn't block #1097's MTU-matrix tests, which check for exactly that and pass. Filing separately since fixing which side is "right" - drop cleanly vs. count truncated-but-sent as success - is a design call, not obviously part of either #1090 or #1097's scope.
Describe the bug
Found while building the MTU-matrix integration tests for #1097: when a packet is larger than the interface's MTU, tcpreplay truncates it and sends the truncated frame onto the wire anyway, while counting it as a failed packet, not a successful one.
To Reproduce
test.pcap has packets up to 1514 bytes. Output (trimmed):
but
/sys/class/net/tcprsmall0/statistics/tx_packetsadvances by 4 over the run - meaning frames genuinely reached the wire while being counted as failures.Expected behavior
Two defensible fixes, either is fine:
txring_put()at all) - "failed" then means what it says: nothing went out.What's happening now is neither: a caller reading "0 successful, 176 failed" reasonably concludes nothing was transmitted, when in fact partial, corrupted frames were injected onto the network.
Additional context
txring_put()'s truncation itself (src/common/txring.caround line 132) is old, pre-existing, and documented with a/* TODO Fragment packet */comment - not new. What's new here is confirming, empirically, thatsend_packets.c's "count truncation as a failure" (src/send_packets.cline 623) doesn't stop the already-truncated frame from being queued and transmitted - the two checks are inconsistent with each other.Not the #1078/#1090 failure mode (no phantom success is reported - "Successful packets: 0" is at least not a false claim), so it doesn't block #1097's MTU-matrix tests, which check for exactly that and pass. Filing separately since fixing which side is "right" - drop cleanly vs. count truncated-but-sent as success - is a design call, not obviously part of either #1090 or #1097's scope.