5 Common Questions from Users

5.1 Why is tcpreplay not sending all the packets?

Every now and then, someone emails the tcpreplay-users list, asking if there is a bug in tcpreplay which causes it not to send all the packets. This usually happens when the user uses the -t flag or is replaying a high-speed pcap file (> 50Mbps, although this number is dependant on the hardware in use).

The short version of the answer is: no, we are not aware of any bugs which might cause a few packets to not be sent.

The longer version goes something like this:

If you are running tcpreplay multiple times and are using tcpdump or other packet sniffer to count the number packets sent and are getting different numbers, it's not tcpreplay's fault. The problem lies in one of two places:

  1. It is well known that tcpdump and other sniffers have a problem keeping up with high-speed traffic. Furthermore, the OS in many cases lies about how many packets were dropped. Tcpdump will repeat this lie to you. In other words, tcpdump isn't seeing all the packets. Usually this is a problem with the network card, driver or OS kernel which may or may not be fixable. Try another network card/driver.
  2. When tcpreplay sends a packet, it actually gets copied to a send buffer in the kernel. If this buffer is full, the kernel is supposed to tell tcpreplay that it didn't copy the packet to this buffer. If the kernel has a bug which squelches this error, tcpreplay will not keep trying to send the packet and will move on to the next one. Currently I am not aware of any OS kernels with this bug, but it is possible that it exists. If you find out that your OS has this problem, please let me know so I can list it here.
If for some reason, you still think its a bug in tcpreplay, by all means read the code and tell me how stupid I am. The do_packets() function in do_packets.c is where tcpreplay processes the pcap file and sends all of the packets.

5.2 Can tcpreplay read gzip/bzip2 compressed files?

Yes, but not directly. Since tcpreplay can read data via STDIN, you can decompress the file on the fly like this:

gzcat myfile.pcap.gz | tcpreplay -i eth0 -

Note that decompressing on the fly will require additional CPU time and will likely reduce the overall performance of tcpreplay.

5.3 How fast can tcpreplay send packets?

First, if performance is important to you, then upgrading to tcpreplay 3.x is worthwhile since it is more optimized then the 1.x or 2.x series. After that, there are a number of variables which effect performance, including on how you measure it (packets/sec or bytes/sec). 100Mbps and 120K pps are quite doable. Generally speaking here are some points to consider:

5.4 Is tcpreplay stateful?

No. Tcpreplay processes each packet in the order it is stored in the pcap file. The default is to send each packet based on the timestamp stored in the pcap file. If your pcap file has packets out of order, tcpreplay will send them out of order. In certain situations a packet may have an earlier timestamp then the packet before it, tcpreplay will then send the second packet as soon as possible.

The basic point is that if your pcap file is well formed and has the packets in the correct order, then tcpreplay will create a ``stateful'' packet stream. If your pcap file has errors, then tcpreplay will repeat those errors. Garbage in, garbage out.

Aaron Turner 2006-07-17