4.1 max bitrate on loop

[lancasrj]

As of version 4.1.0 running the following command:
tcpreplay -i eth0 -l 0 capture.pcap

The first time through everything plays as expected. Upon looping the bitrate jumps to the maximum rate for the interface and the following message is repeated in the log:

Warning: Packet #9513 has gone back in time!
Warning: Packet #9514 has gone back in time!
Warning: Packet #9515 has gone back in time!
Warning: Packet #9516 has gone back in time!

[rdiggz]

Hello,

Im new to tcpreplay but i have been given the task to get 8 captures to play on CentOS 6.6. I am having this same issue. If I play the captures on Ubuntu server 14.04, i do not get the error. There is also a big CPU usage difference between the 2 but thats another issue.

I was check to see if there is any update on this?

Thank you for your time and great work!

[abiryukov]

Looks similar to #85

[fklassen]

@abiryukov you are correct. This was fixed in #85. Fixed in version 4.1

[rafafade]

Hello

Sorry if this is mark as closed and that I am missing something, but I have the same problem of "Warning: Packet #XXXX has gone back in time!" with v4.1.0

The command I execute:
tcpreplay --pid -i eth1 --loop=2 capture_UDP_9760only.pcap

About the .pcap file:
-The packets were captured and filtered with Wireshark
-Then I changed source MAC and IP using tcprewrite
-It contains only UDP traffic (dst port 9760), destination is broadcast (IP and MAC)

tcpreplay version:
[root@localhost pcap_traces]# tcpreplay -V
tcpreplay version: 4.1.0 (build git:v4.1.0)
Copyright 2013-2014 by Fred Klassen - AppNeta Inc.
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.4.0
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

Running under CentOS 6:
[root@localhost pcap_traces]# cat /etc/redhat-release
CentOS release 6.7 (Final)

Thanks in advance

Rafael

[fklassen]

I'll reopen this issue again so that we can review.

Sometimes this is an issue with reordered timestamps in the pcap file. Can you supply a failing pcap file?

[rafafade]

Hi

I can't give you the trace I was using yesterday due to confidentiality, but I have tested another capture I had and was able to reproduce the problem (Warning: Packet # has gone back in time!)

I'm not able to upload the failing .pcap here, how should I proceed?

Command executed:
tcpreplay --pid -i eth1 --loop=2 capture_jperf_UDP_port_dest_6000_only_rewritten.pcap

About the capture:
-The original file is an iperf test between two machines, iperf server is listening on port 6000
-Then I filtered the traces using wireshark. I applied the filter "udp.dstport eq 6000"
-Then I changed the source and destination addresses (MAC and IP) using tcprewrite:
tcprewrite --enet-smac=00:0c:29:0f:08:4f --enet-dmac=00:50:56:c0:00:01 --srcipmap=192.168.20.172/32:192.168.33.200/32 --dstipmap=192.168.20.161/32:192.168.33.1/32 --fixcsum -i capture_jperf_UDP_port_dest_6000_only.pcap -o capture_jperf_UDP_port_dest_6000_only_rewritten.pcap

[fklassen]

Thanks for the detail. I plan to work on this in December. I'll try to reproduce.

[fklassen]

Right you are, this is a bug. I missed it because it only shows up if not using some other options. Duplicate of #191 and fixed with PR #229