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:

• tcpreplay — the core replay engine
• tcpprep — pre-processes a pcap to classify packets as “client” or “server” traffic for dual-interface replay
• tcprewrite — edits packet headers (IPs, MACs, TTLs, checksums) in a pcap before replay
• tcpreplay-edit — a variant with tcprewrite’s editing capabilities built directly into the replay step
• tcpliveplay — replays TCP traffic with full three-way handshakes against a live listening host

Why Replay Captured Traffic?

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

• Reproducibility: the exact same traffic pattern, every time, for regression testing.
• Realism: it’s real, previously-observed traffic (or a known attack sample) rather than synthetic traffic that may not stress a device the same way.
• Safety: replaying in an isolated lab avoids re-triggering the actual attack against production systems.
• Speed control: you can slow traffic down to inspect it more easily, or speed it up to stress-test hardware.

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

• Wireshark/tshark: used both to prepare pcaps for replay (filtering down to relevant traffic with a display filter, then exporting) and to capture/verify what tcpreplay actually sent on the receiving end.
• Suricata / Snort: the most common “device under test” — replay known-attack pcaps and check the alert log for expected signature hits.
• tcpdump: often run simultaneously on a receiving interface to confirm packets arrived as expected.
• netsniff-ng: an alternative high-performance capture/replay tool that can complement tcpreplay in high-throughput testing pipelines.

Performance Optimization

• Use -K/--preload-pcap for high-rate replay to eliminate disk I/O as a bottleneck.
• Use -T gtod or -T nano for more accurate timing at high packet rates; select is lower overhead but less precise.
• For genuinely high-throughput testing (multi-gig), consider building tcpreplay with netmap or DPDK support, which bypasses the standard kernel networking stack entirely for much higher achievable rates than plain PF_PACKET.
• Split very large pcaps into smaller chunks if you’re hitting memory limits with --preload-pcap.

Troubleshooting and Common Mistakes

• “only one intf2 option allowed” — you passed -I more than once, or combined it incorrectly with -2/dualfile mode; check your flag combination against tcpreplay --help.
• “Unsupported physical layer type” warning on loopback — expected; tcpreplay is designed for real Ethernet-type interfaces, not lo. It’s a warning, not necessarily a fatal error, but you should always test against a real or lab-virtual Ethernet interface for meaningful results.
• Replay “succeeds” but nothing shows up on the receiving end — check that source/destination MACs in the pcap actually route correctly on your test segment; a pcap captured elsewhere often has stale MAC addresses that a real switch will silently drop or mishandle. This is exactly what tcprewrite --enet-dmac/--enet-smac is for.
• Permission denied — tcpreplay needs raw socket access; run with sudo or grant the binary CAP_NET_RAW/CAP_NET_ADMIN via setcap.
• Checksums wrong after editing with tcprewrite — always follow header edits with --fixcsum, or IP/TCP checksums will be invalid and many devices will silently drop the packets.
• Timing looks off at very high pps — the select-based timer has coarser resolution; switch to -T nano for tighter timing accuracy.

Best Practices

• Always replay into an isolated, non-production lab segment — never toward a live production network, especially with known-malicious pcaps.
• Keep a versioned library of test pcaps with clear naming (e.g., 2024-log4shell-sample.pcap) so tests are reproducible and auditable.
• Rewrite MACs/IPs with tcprewrite to match your actual lab topology before replaying captures sourced from a different network.
• Use tcpprep cache files for anything requiring realistic bidirectional traffic through an inline device.
• Document expected results (which alerts/signatures should fire) alongside each pcap so regression testing is meaningful over time.

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

• Official documentation: https://tcpreplay.appneta.com/
• GitHub repository: https://github.com/appneta/tcpreplay
• Man pages: man tcpreplay, man tcpprep, man tcprewrite