Offensive Security Researcher & Quantum Cryptography Analyst

tcpreplay: A tool to replay captured network traffic for testing purposes

Abdul Wahab Junaid
tcpreplay: A tool to replay captured network traffic for testing purposes

I first reached for tcpreplay when I needed to test whether a new IDS sensor would actually detect a known malicious traffic pattern before we put it in front of production traffic. Rather than trying to recreate the attack live, I just replayed a pcap of it. That’s the core value of tcpreplay in one sentence: it lets you take traffic you already captured and send it back out onto a real network, exactly as it happened (or faster, slower, or edited). Here’s a full, tested walkthrough of how it works and how to use it properly.

What Is Tcpreplay?

Tcpreplay is an open-source suite of Unix/Linux command-line utilities for editing and replaying previously captured network traffic. It takes standard pcap files — the same format produced by tcpdump, Wireshark, and most packet capture tools — and resends the packets out of a real network interface, either at the original recorded speed, a custom rate, or as fast as the hardware allows.

It’s not just one binary; it’s a small suite:

Why Replay Captured Traffic?

Live traffic generation is expensive and often impractical. Replaying a capture gives you:

Installing Tcpreplay

On Debian/Ubuntu:

sudo apt update
sudo apt install tcpreplay

Confirmed install:

Setting up tcpreplay (4.4.4-1build2) ...

Other platforms:

# Fedora / RHEL
sudo dnf install tcpreplay

# Arch Linux
sudo pacman -S tcpreplay

# macOS via Homebrew
brew install tcpreplay

Verify:

tcpreplay --version

Real output:

tcpreplay version: 4.4.4 (build git:v4.4.4) (debug)
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
Compiled against libdnet: 1.17.0 (libdumbnet)
Compiled against libpcap: 1.10.4
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: enabled
Injection method: PF_PACKET send()
Not compiled with netmap

Basic Syntax

tcpreplay [options] <pcap_file(s)> | <pcap_dir(s)>

Key options from tcpreplay --help:

-i, --intf1=str          Primary output interface
-I, --intf2=str          Secondary output interface (dual-interface replay)
-l, --loop=num            Loop through the capture file X times
-M, --mbps=num            Replay traffic at a fixed Mbps rate
--pps=num                Replay at a fixed packets-per-second rate
-t, --topspeed            Replay as fast as possible
-x, --multiplier=num      Replay at a multiple of the captured rate
-K, --preload-pcap        Preload the pcap into RAM before sending
-v, --verbose             Print decoded packets via tcpdump
-c, --cachefile=str       Use a tcpprep cache file to split traffic
-2, --dualfile            Replay two files simultaneously
--stats=num               Print periodic statistics
--listnics               List available network interfaces

Listing Available Interfaces

tcpreplay --listnics

Real output on my test system:

Available network interfaces:
eth0
any
bluetooth-monitor
nflog
nfqueue
dbus-system
dbus-session

Basic Replay

The simplest possible replay, sending a capture out a chosen interface once, at the speed it was originally recorded:

sudo tcpreplay -i eth0 capture.pcap

Tested against the loopback interface with a small synthetic pcap:

sudo tcpreplay -i lo --loop=1 test.pcap

Real output:

Warning in sendpacket.c:sendpacket_open_pf() line 953:
Unsupported physical layer type 0x0304 on lo.  Maybe it works, maybe it won't.  See tickets #123/318
Actual: 5 packets (360 bytes) sent in 0.001970 seconds
Rated: 182741.1 Bps, 1.46 Mbps, 2538.07 pps
Flows: 1 flows, 507.61 fps, 5 unique flow packets, 0 unique non-flow packets
Statistics for network device: lo
	Successful packets:        5
	Failed packets:            0
	Truncated packets:         0
	Retried packets (ENOBUFS): 0
	Retried packets (EAGAIN):  0

(That loopback warning is expected and harmless — loopback isn’t tcpreplay’s typical target; it’s meant for real Ethernet/Wi-Fi interfaces facing a switch, IDS tap, or lab segment. It still sends successfully, which is what matters for the test.)

Controlling Replay Speed

Fixed bandwidth (Mbps):

sudo tcpreplay -i eth0 --mbps=10 --loop=1 capture.pcap

Tested output confirms the rate is honored:

Actual: 5 packets (360 bytes) sent in 0.000290 seconds
Rated: 1241379.3 Bps, 9.93 Mbps, 17241.37 pps

Fixed packets-per-second:

sudo tcpreplay -i eth0 --pps=100 --loop=2 capture.pcap

Tested output:

Actual: 10 packets (720 bytes) sent in 0.090030 seconds
Rated: 7997.3 Bps, 0.063 Mbps, 111.07 pps

Top speed (as fast as hardware allows):

sudo tcpreplay -i eth0 --topspeed capture.pcap

Multiplier of original recorded rate:

sudo tcpreplay -i eth0 --multiplier=2.0 capture.pcap

This replays at exactly double the speed the traffic was originally captured at — useful for stress-testing without fully losing the original traffic’s relative timing pattern.

Looping

sudo tcpreplay -i eth0 --loop=100 capture.pcap

Replays the file 100 times back-to-back — useful for sustained load or IDS/IPS testing over a longer window than a single small pcap would provide.

Dual-Interface Replay (Client/Server Simulation)

For testing inline devices (firewalls, IPS, load balancers) that need to see both directions of a conversation on separate interfaces, tcpreplay can split traffic using tcpprep.

Step 1 — generate a cache file classifying client vs. server traffic:

tcpprep --auto=first --pcap=capture.pcap --cachefile=capture.cache

Tested and confirmed working — produced a valid cache file:

-rw-r--r-- 1 root root 104 Jul 30 10:03 test.cache

Step 2 — replay using the cache file across two interfaces:

sudo tcpreplay -c capture.cache -i eth0 -I eth1 capture.pcap

This sends “client” packets out eth0 and “server” packets out eth1, simulating a real two-sided conversation across an inline device under test.

Editing Packets Before Replay with Tcprewrite

Often you need to change source/destination IPs or MAC addresses before replaying into a different lab environment than where the traffic was originally captured:

tcprewrite \
  --infile=capture.pcap \
  --outfile=capture_rewritten.pcap \
  --enet-dmac=aa:bb:cc:dd:ee:ff

This was tested successfully against a sample pcap (exit code 0, valid output file produced). Common tcprewrite operations:

# Rewrite source/destination IP addresses (subnet remap)
tcprewrite --infile=in.pcap --outfile=out.pcap \
  --srcipmap=10.0.0.0/8:172.16.0.0/12 \
  --dstipmap=10.0.0.0/8:172.16.0.0/12

# Rewrite MAC addresses for both directions
tcprewrite --infile=in.pcap --outfile=out.pcap \
  --enet-dmac=aa:bb:cc:dd:ee:01 \
  --enet-smac=aa:bb:cc:dd:ee:02

# Fix checksums after editing
tcprewrite --infile=in.pcap --outfile=out.pcap --fixcsum

How Tcpreplay Works Internally

  1. Parsing: tcpreplay reads the pcap file’s global header (link-layer type, snaplen) and iterates its per-packet records (timestamp + captured bytes).
  2. Timing engine: for realistic replay, it calculates inter-packet delays from the recorded timestamps and sleeps between sends using one of several timer backends (select, ioport, gtod/gettimeofday, or nano for high-resolution timing) — selectable via -T.
  3. Injection: packets are written directly onto the wire using raw sockets — on Linux, the default injection method is PF_PACKET send(), which bypasses the normal TCP/IP stack and puts the exact captured bytes on the wire at layer 2.
  4. Rate control: when --mbps, --pps, or --multiplier is specified, the timing engine recalculates delays to hit the target rate instead of using the original timestamps.
  5. Optional preloading (-K): the entire pcap is read into RAM first, avoiding disk I/O jitter during high-speed replay — important when testing at multi-gigabit rates where disk read latency could otherwise distort timing.

Because injection happens at layer 2 with raw sockets, tcpreplay requires root or CAP_NET_RAW capability, and it needs a real, physical (or lab virtual) network interface — it doesn’t go through the kernel’s routing/socket stack the way a normal application would.

Real-World Use Cases (Authorized Lab Environments Only)

1. IDS/IPS and NGFW validation Replay a known-malicious pcap (e.g., a publicly available exploit capture from a malware research repository) against a sensor in an isolated lab segment to confirm signatures actually fire, without needing to run the live exploit.

2. Regression testing network monitoring tools Keep a library of “golden” pcaps representing known traffic patterns (normal baseline, known attack, known false-positive trigger) and replay them after every SIEM/IDS rule update to catch regressions before they hit production.

3. Load and performance testing Use --topspeed or --mbps to stress-test switches, taps, firewalls, or packet brokers at controlled or maximum throughput to validate hardware specs under realistic (not purely synthetic) traffic shapes.

4. Incident response and forensic reconstruction Replaying a capture associated with a past incident into a sandboxed analysis environment where other tools (IDS, DLP, EDR network sensors) can re-observe and re-analyze it under controlled conditions.

5. Training and tabletop exercises Feeding realistic traffic into a SOC training environment so analysts practice triage on genuine packet patterns rather than synthetic test data.

Integration with Other Tools

Performance Optimization

Troubleshooting and Common Mistakes

Best Practices

FAQ

Does tcpreplay modify the original pcap file? No, tcpreplay only reads and sends the packets; it never writes back to the source file. Editing is done separately with tcprewrite, which writes to a new output file.

Can tcpreplay replay encrypted traffic (e.g., TLS)? Yes, at the packet level it doesn’t care about payload content — it just resends the captured bytes. It can’t decrypt anything; it’s purely a bit-for-bit (or edited) replay of what was captured.

Do I need two network cards for dual-interface replay? Yes, -i/-I dual-interface mode requires two separate physical (or lab-virtual) interfaces connected to the two sides of whatever inline device you’re testing.

Is tcpreplay safe to run against a production network? Generally no — replaying captured traffic, especially at high speed or in a loop, can duplicate connections, confuse stateful devices, or (if it’s attack traffic) actually trigger the attack again. Always use an isolated lab.

What’s the difference between tcpreplay and tcpreplay-edit? tcpreplay-edit bakes tcprewrite’s header-editing capabilities directly into the replay command, so you can edit and replay in a single step instead of running tcprewrite first and tcpreplay second.

Summary

Tcpreplay turns a static pcap file into live network traffic again, giving you precise control over speed, direction, and packet content along the way. Whether you’re validating an IDS signature, load-testing a firewall, or reconstructing an incident in a sandbox, it’s the standard tool for the job — and because it works at the raw packet level, what comes out the other end is exactly what you intended to test with.

References

Exit mobile version