[Bug] tcprewrite on Linux Cooked Capture hits fatal error in edit_packet.c:fix_ipv4_checksums()

[msi3na]

Trying tcprewrite to remove Linux Cooked Capture, but it hits a fatal error with an apparently well formed TCP packet over IP (all checksums are correct). Output is an empty pcap.

Command tcprewrite --dlt=enet -i test_1.pcap -o test_2.pcap

Error Fatal Error: Error rewriting packets: From edit_packet.c:fix_ipv4_checksums() line 75: Invalid packet: Expected IPv4 packet: got 0: pkt=1

Attachments Archive 3.zip

Tried on both versions below:

-- MAC OS homebrew tcprewrite version: 4.4.3 (build git:v4.4.3) Copyright 2013-2022 by Fred Klassen - AppNeta Copyright 2000-2012 by Aaron Turner The entire Tcpreplay Suite is licensed under the GPLv3 Cache file supported: 04 Compiled against libdnet: 1.14 Compiled against libpcap: 1.10.1 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Fragroute engine: enabled

-- Ubuntu 20.4 LTS tcprewrite version: 4.4.1 (build git:v4.4.1) Copyright 2013-2022 by Fred Klassen - AppNeta Copyright 2000-2012 by Aaron Turner The entire Tcpreplay Suite is licensed under the GPLv3 Cache file supported: 04 Not compiled with libdnet. Compiled against libpcap: 1.9.1 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Fragroute engine: disabled

[bastienvty]

I have the same problem with raw ip packets. Did you find something @msi3na ?

[fklassen]

SLL is not currently supported. This is a feature, not a bug. We are targeting SLL for 4.5, and probably will include PR #728

[btriller]

Actually the input pcap does not have SLL2 dlt. Is has SLL dlt, which is supported. Using version 4.3.3 from Debian correctly rewrites provided pcap. It seems 6fc59305ef182e81d0e25561e0efc8672a8936f7 introduced this regression. In my tests, L3 proto isn't copied to ethernet header and L3 data points two bytes before original L3 data.

[fklassen]

Thanks for clarifying. Will reopen and target next release.

[fklassen]

Was able to reproduce. Fixed in PR #873