`tcpreplay-edit` incorrectly rewrites layer 3 length field to include Ethernet padding
iczero opened this issue · 6 comments
Describe the bug
Ethernet has a 64-byte minimum frame size. Frames smaller than this (for example, plain TCP ACK without options on IPv4) need to be padded to 64 bytes (60 bytes excluding FCS). tcpreplay-edit
(but not tcpreplay
) will incorrectly include Ethernet padding bytes in the IP length field.
To Reproduce
Steps to reproduce the behavior:
- Start
tcpdump
on the interface wheretcpreplay-edit
will be run tcpreplay-edit
any pcap with ethernet padding bytes to the interface- Observe that the replayed packets have the IP length field modified to include padding bytes (Wireshark should complain a lot)
Expected behavior
tcpreplay-edit
(like tcpreplay
) does not modify the IP length field and keeps the padding.
System (please complete the following information):
- OS: Fedora 39 (Linux 6.6.9-200.fc39.x86_64)
- Tcpreplay Version: latest master, currently 43693c4
Additional context
None
To get a pcap with the padding, it's likely easiest to do sysctl -w net.ipv4.tcp_timestamps=0
and do a capture of a TCP connection.
This is related to the issue #844
The defect was introduced in 4.4.1, and tcprewrite worked in 4.4.0.
Based upon my investigation, the packet length "fix" was introduced due to issue #703.
Although the function fix_ipv4_length()
existed previously, it was not called.
Our organization had a similar issue with the step from version 4.4.0 to version 4.4.1
This does not fix the length calculation, but does avoid the problem.
Please check whether PR #846 resolves your issue.
@ChuckCottrill Tested PR, looks like it fixes this issue. Thank you for the help.