Describe the bug
Having a PCAP file with one packet and replaying transmit of the packet results in packet 4 bytes shorter than the packet in the previous iteration. Prior to the transmission, the packet is cached and the packet's destination MAC address is altered and a VLAN is added.
So say we have a packet of size 1300B, receiving side will receive 1 packet 1300B, 2. packet 1296B, 3. packet 1292B...
The information about reduced packet length is reported both by tcpdump and my network application on multiple NICs - Mellanox mlx5 and Intel igb. The packet trimming continues until only the VLAN layer is left - after N iterations, only the VLAN layer is received.
Crucial things for reproduction are the packet caching (-K) and adding a VLAN id. Packet count should not matter but it is easier to see on 1 packet. I've tested the bug in direction of IGB -> MLX and MLX -> IGB. When packets were sent through different means, I had no problem receiving them.
Expected behavior
The same packet every iteration.
Screenshots
System (please complete the following information):
OS: Oracle Linux 8
Kernel: 4.18.0-240.el8.x86_64
tcpreplay version: 4.4.0 (build git:v4.4.0)
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
Packet editing: enabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
Not compiled with netmap
Additional context
Add any other context about the problem here.
Describe the bug Having a PCAP file with one packet and replaying transmit of the packet results in packet 4 bytes shorter than the packet in the previous iteration. Prior to the transmission, the packet is cached and the packet's destination MAC address is altered and a VLAN is added. So say we have a packet of size 1300B, receiving side will receive 1 packet 1300B, 2. packet 1296B, 3. packet 1292B... The information about reduced packet length is reported both by tcpdump and my network application on multiple NICs - Mellanox mlx5 and Intel igb. The packet trimming continues until only the VLAN layer is left - after N iterations, only the VLAN layer is received.
Crucial things for reproduction are the packet caching (-K) and adding a VLAN id. Packet count should not matter but it is easier to see on 1 packet. I've tested the bug in direction of IGB -> MLX and MLX -> IGB. When packets were sent through different means, I had no problem receiving them.
To Reproduce Steps to reproduce the behavior:
Expected behavior The same packet every iteration.
Screenshots
System (please complete the following information):
Additional context Add any other context about the problem here.