tcpreplay-edit incorrectly rewrites layer 3 length field to include Ethernet padding

[iczero]

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:

1. Start tcpdump on the interface where tcpreplay-edit will be run
2. tcpreplay-edit any pcap with ethernet padding bytes to the interface
3. 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

[iczero]

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.

[ChuckCottrill]

This is related to the issue #844
The defect was introduced in 4.4.1, and tcprewrite worked in 4.4.0.

[ChuckCottrill]

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.

[ChuckCottrill]

Please check whether PR #846 resolves your issue.

[iczero]

@ChuckCottrill Tested PR, looks like it fixes this issue. Thank you for the help.