appneta / tcpreplay

Pcap editing and replay tools for *NIX and Windows - Users please download source from
http://tcpreplay.appneta.com/wiki/installation.html#downloads
1.16k stars 268 forks source link

[Bug] Repeated packet replay continually trims it by 4 bytes. #729

Closed lukashino closed 1 year ago

lukashino commented 2 years ago

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:

  1. sudo tcpreplay-edit --enet-vlan=add --enet-vlan-tag=14 --enet-vlan-pri=1 --enet-vlan-cfi=0 -i eno2 --enet-dmac="DST_MAC" --mbps 10 -l10 -K one-packetpcap
  2. sudo tcpdump -i ens1f1 -nnN

Expected behavior The same packet every iteration.

Screenshots image

System (please complete the following information):

Additional context Add any other context about the problem here.

fklassen commented 1 year ago

Fixed in PR #743.

When both replaying and editing packets, -l and -K options are ambiguous. These options are no longer allowed to be used together with tcpreplay_edit.