[Bug] MTU trunc not showing in tcpreplay-edit statistics

[alebarrancoledesma]

We are experimenting a strange behavior when reproducing pcaps with mtu > 1500.

Steps to reproduce the behavior:

1. Download an example pcap file with frames bigger than 1500 bytes: https://github.com/cisco-system-traffic-generator/trex-core/blob/master/scripts/cap2/jumbo.pcap
2. In the same folder, place an .sh file with the next command: find . -type f -name '*.pcap*' | xargs -I {} sudo tcpreplay-edit -i ens224 -C -M 20 --enet-vlan=del --mtu-trunc {}
3. Execute the bash script as sudo and check the statistics: Actual: 22 packets (15805 bytes) sent in 0.006325 seconds Rated: 2498814.2 Bps, 19.99 Mbps, 3478.26 pps Flows: 2 flows, 316.20 fps, 22 flow packets, 0 non-flow Statistics for network device: ens224 Successful packets: 22 Failed packets: 0 Truncated packets: 0 Retried packets (ENOBUFS): 0 Retried packets (EAGAIN): 0
4. Modify the .sh file removing --mtu-trunc flag: find . -type f -name '*.pcap*' | xargs -I {} sudo tcpreplay-edit -i ens224 -C -M 20 --enet-vlan=del {}
5. Execute the bash script as sudo and check the statistics Warning in send_packets.c:send_packets() line 486: Unable to send packet: Error with PF_PACKET send() [16]: Message too long (errno = 90) Actual: 15 packets (11116 bytes) sent in 0.005572 seconds Rated: 1994974.8 Bps, 15.95 Mbps, 2692.03 pps Flows: 2 flows, 358.93 fps, 16 flow packets, 0 non-flow Statistics for network device: ens224 Successful packets: 15 Failed packets: 1 Truncated packets: 0 Retried packets (ENOBUFS): 0 Retried packets (EAGAIN): 0

It seems that tcpreplay-edit truncates packets, because if you don't use the --mtu-trunc flag it turns into an error indicating the message is too long, but if you use the flag the stats indicate that 0 packets were truncated.

You can check in Wireshark that the size of some packets, including some fragments, are bigger than 1500:

tcpreplay version: 4.3.4 (build git:v4.3.4) (debug) Copyright 2013-2018 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.10.1 64 bit packet counters: enabled Verbose printing via tcpdump: enabled Packet editing: enabled Fragroute engine: disabled Injection method: PF_PACKET send() Not compiled with netmap

Linux mint-virtual-machine 5.15.0-60-generic # 66-Ubuntu x86_64 GNU/Linux

We are using this kind of pcap files in some security analysis, and we have found that when we launch these files using tcpreplay-edit, our analysis software detects fewer assets than when we import the pcap file directly into the analysis solution. We believe that tcpreplay-edit may not be properly truncating frames, which could result in checksums not being recalculated or other issues that cause the loss of assets during analysis. is It possible that the analysis software is dismissing these packets due to checksum errors?

Thanks for your time

[fklassen]

I verified on my Debian 11 Linux machine that the 2 packets were too large to send on a 1500 MTU interface. The truncated counter is reserved for packets that were partially sent, not completely dropped. In this case the 2 packets were dropped due to an error reported by the kernel, and therefore the reporting is correct.

Closing as "not a bug"

[xinfasheng]

你好，我在使用tcpreplay-edit -m 1500 --mtu-trunc时遇到了一个问题咨询您一下，PCAP报文中存在超过mtu 1500的报文，当使用了tcpreplay-edit -m 1500 --mtu-trunc命令时，这段超过1500的报文会被截断，但是后面的报文内容丢失了。感谢您的宝贵时间。