Skip to content

Usage Examples

Jump to bottom
Fred Klassen edited this page Jul 21, 2026 · 1 revision

Usage Examples

New users often ask how to accomplish specific real-world tasks with the Tcpreplay suite. This page walks through a few common ones, chaining tcpprep → tcprewrite → tcpreplay together. Commands and flags below are verified against 4.6.0-beta1.

(For flow-rate/performance testing setups — netmap, AF_XDP, flows-per-second tuning — see tcpreplay.appneta.com's How To page instead; this page is about workflow, not performance tuning.)

See also: Common Arguments for the flags shared across every tool below.

Replaying through an IPS or other transparent inline device

Problem: you have a pcap of client/server traffic captured on a different network, and want to replay it through an IPS (or any transparent inline device) for testing.

Step 1 — classify client vs. server traffic. tcpprep's port mode classifies each packet by destination port against the system's known-service list (/etc/services-derived — see src/common/services.c), not a fixed port number:

$ tcpprep --port --cachefile=example.cache --pcap=example.pcap

This writes the client/server classification to example.cache for reuse in later steps. (tcpprep supports several other classification modes besides --port — see tcpprep --help.)

Step 2 — rewrite the IP addresses to your test network.

$ tcprewrite --endpoints=172.16.0.1:172.16.5.35 --cachefile=example.cache \
             --infile=example.pcap --outfile=new.pcap

--endpoints takes <client-ip>:<server-ip>; because we passed --cachefile, tcprewrite knows which direction each packet is and rewrites source/destination accordingly.

Step 3 — replay it through the device.

# tcpreplay --intf1=eth0 --intf2=eth1 --cachefile=example.cache new.pcap

--intf1 sends primary (client→server) traffic, --intf2 sends secondary (server→client) traffic — the same cache file from Step 1 still applies, since rewriting IPs in Step 2 didn't change packet order or direction.

Replaying through a firewall/router/NAT device

Same idea, but when the device under test also translates addresses, you need an extra step to compute the post-NAT addresses before replay.

Step 1 — classify traffic (same as above):

$ tcpprep --port --cachefile=example.cache --pcap=example.pcap

Step 2 — work out the new IP/MAC values for your topology. For example: an "Untrust" interface at MAC 00:22:22:22:22:22, a "DMZ" interface at 00:11:11:11:11:11, and the firewall NAT'ing traffic destined to 2.2.2.1 (Untrust) through to 1.1.1.5 (DMZ). Avoid picking a destination that's the tcpreplay box's own IP stack, or the OS will intercept the traffic instead of the DUT.

Step 3 — rewrite the IPs. Because the client-side destination differs from the server-side source under NAT, use --srcipmap/--dstipmap (each takes a comma-separated list of <old-cidr>:<new-cidr> pairs) instead of --endpoints:

$ tcprewrite --srcipmap=10.10.0.1/32:2.2.2.5/32,10.20.0.1/32:1.1.1.5/32 \
             --infile=example.pcap --outfile=new.pcap
$ tcprewrite --dstipmap=10.10.0.1/32:2.2.2.5/32,10.20.0.1/32:2.2.2.1/32 \
             --infile=new.pcap --outfile=new2.pcap

Step 4 — rewrite the MAC addresses to match the firewall's interfaces. --enet-dmac takes <server-to-client-mac>,<client-to-server-mac> (the DLT-plugin-specific option, part of the dlt_en10mb plugin — see src/tcpedit/plugins/dlt_en10mb/en10mb_opts.def):

$ tcprewrite --enet-dmac=00:11:11:11:11:11,00:22:22:22:22:22 \
             --cachefile=example.cache --infile=new2.pcap --outfile=new3.pcap

Step 5 — replay:

# tcpreplay --intf1=eth0 --intf2=eth1 --cachefile=example.cache new3.pcap

Rewriting TCP/UDP ports

$ tcprewrite --infile=example.pcap --outfile=new.pcap --portmap=80:8080

--portmap takes a comma-delimited list of <oldport>:<newport> pairs and is protocol independent — it rewrites both TCP and UDP packets.

Removing specific packets from a capture before replay

Tcpreplay doesn't have its own packet-removal filter — use tcpdump first:

$ tcpdump -r example.pcap -w http_only.pcap -s0 tcp port 80

Adjust the BPF filter to taste.

Sending traffic at a live server

Tcpreplay can send ICMP and UDP traffic at a real server, but not TCP — it doesn't synchronize sequence/ack numbers with a live TCP stack, so a real server will just reset replayed TCP connections. For ICMP/UDP, rewrite the destination IP and MAC to the target:

$ tcprewrite --infile=example.pcap --outfile=new.pcap \
             --dstipmap=0.0.0.0/0:10.10.1.1/32 --enet-dmac=00:01:02:03:04:05

(For actually establishing new TCP connections against a live server, see tcpliveplay instead, which handles the handshake — it isn't limited to raw pcap replay.)

Adapted from the old usage page on the legacy Trac wiki (tcpreplay.synfin.net, no longer reachable), re-verified against the current tree — notably, tcpprep --port's classification rule and the --enet-dmac/--enet-smac option names both checked out unchanged, but the port-classification logic itself now uses a services-file lookup rather than a fixed "port < 1024" rule.

Clone this wiki locally