Tcpreplay version
4.6.1
Operating system
Linux
OS version / distro
Ubuntu 22.04.5 LTS
Exact command line
sudo /opt/tcpreplay-4.6.1/bin/tcpreplay --intf1=lo -q -T select --loop=0 --pps=1 --preload-pcap --duration=10 /home/gbritoda/repos/test-single.pcap
Expected behavior
>>> sudo /opt/tcpreplay-4.4.4/bin/tcpreplay --intf1=lo -q -T select --loop=0 --pps=1 --preload-pcap --duration=10 /home/gbritoda/repos/test-single.pcap
Warning: Unsupported physical layer type 0x0304 on lo. Maybe it works, maybe it won't. See tickets #123/318
Actual: 11 packets (4576 bytes) sent in 10.00 seconds
Rated: 457.5 Bps, 0.003 Mbps, 1.09 pps
Flows: 1 flows, 0.09 fps, 1 unique flow packets, 0 unique non-flow packets
Statistics for network device: lo
Successful packets: 11
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0Actual behavior
>>> sudo /opt/tcpreplay-4.6.1/bin/tcpreplay --intf1=lo -q -T select --loop=0 --pps=1 --preload-pcap --duration=10 /home/gbritoda/repos/test-single.pcap
Warning: Unsupported physical layer type 0x0304 on lo. Maybe it works, maybe it won't. See tickets #123/318
Actual: 1530241 packets (636580256 bytes) sent in 10.00 seconds
Rated: 63616274.2 Bps, 508.93 Mbps, 152923.73 pps
Flows: 1 flows, 0.09 fps, 1 unique flow packets, 0 unique non-flow packets
Statistics for network device: lo
Successful packets: 1530241
Failed packets: 0
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0How to reproduce it
tcpreplay 4.4.4 seems to be the last one that actually respects the --pps parameter, anything above that seems to silently ignore it. I have seen this issue back when I updated to tcpreplay 4.5.1 but I assumed that one of the open issues at the time was going to fix it. So it definitely seems to be something between the two versions.
Steps:
- Capture a single packet so it can be reproduced
sudo tcpdump -i lo -c 1 -w test-single.pcap
- On tcpreplay latest run tcpreplay --intf1=lo -q -T select --loop=0 --pps=1 --preload-pcap --duration=10 /home/gbritoda/repos/test-single.pcap
- You'd expect --duration=10 x --pps=1 to be around 10 Packets successfully sent, we get a lot more (in the example above, 1530241 packets)
- Run the same command for tcpreplay 4.4.4 and you won't see this. You will see 10 packets (or close)
See below confirming the versions I have used for the examples above:
>>> /opt/tcpreplay-4.6.1/bin/tcpreplay --version
Warning: May need to run as root to get access to all network interfaces.
tcpreplay version: 4.6.1 (build git:v4.6.1)
Copyright 2013-2026 by Fred Klassen <tcpreplay.dev at gmail dot com> - AppNeta by Broadcom
Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
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: disabled
Fragroute engine: disabled
Injection method: PF_PACKET / TX_RING
Not compiled with netmap
Not compiled with AF_XDP
Not compiled with io_uring
>>> /opt/tcpreplay-4.4.4/bin/tcpreplay --version
Warning: May need to run as root to get access to all network interfaces.
tcpreplay version: 4.4.4 (build git:v4.4.4)
Copyright 2013-2022 by Fred Klassen <tcpreplay at appneta dot com> - AppNeta
Copyright 2000-2012 by Aaron Turner <aturner at synfin dot net>
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: disabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
Not compiled with netmap
Before submitting
Tcpreplay version
4.6.1
Operating system
Linux
OS version / distro
Ubuntu 22.04.5 LTS
Exact command line
Expected behavior
Actual behavior
How to reproduce it
tcpreplay 4.4.4 seems to be the last one that actually respects the --pps parameter, anything above that seems to silently ignore it. I have seen this issue back when I updated to tcpreplay 4.5.1 but I assumed that one of the open issues at the time was going to fix it. So it definitely seems to be something between the two versions.
Steps:
sudo tcpdump -i lo -c 1 -w test-single.pcapSee below confirming the versions I have used for the examples above:
Before submitting
master, if intentionally testing an unreleased fix).