Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
lukashino opened this issue May 23, 2022 · 1 comment
Closed

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

lukashino opened this issue May 23, 2022 · 1 comment
Assignees
@fklassen

Comments

@lukashino
Copy link

lukashino commented May 23, 2022 •
edited
Loading

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):

  • 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.
@fklassen fklassen self-assigned this Aug 6, 2022
@fklassen
Copy link
Member

fklassen commented Aug 7, 2022

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.

@fklassen fklassen closed this as completed Aug 7, 2022
fklassen added a commit that referenced this issue Aug 26, 2022
@fklassen
Bug #729 tcpreplay_edit: disallow both -K and -l options
eaee06e 
Only for tcpreplay_edit. It is not well defined what should happen
when packets are both cached and edited. This forces packets to be
reloaded every loop iteration, resulting in edits on un-cached packets
every iteration.
fklassen added a commit that referenced this issue Aug 26, 2022
@fklassen
Merge pull request #743 from appneta/Bug_#729_loop_cached_packet_repl…
dc2cc31 
…ay_continually_edits

Bug #729 tcpreplay_edit: disallow both -K and -l options
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@fklassen fklassen

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@fklassen @lukashino