Skip to main content
Sometimes the traffic you need to reproduce is traffic you already caught. Point Wireblast at a capture and it replays the frames exactly as they were recorded.
--pcap implies --mode pcap, so you can leave --mode off.

​
What gets sent

Frames go out byte for byte as captured. Wireblast doesn’t rewrite addresses, recompute checksums, or renumber anything. What you captured is what leaves the NIC. The one exception is opt-in: give --src-mac or --dst-mac and the first 12 bytes of every frame are overwritten, so you can retarget a capture at a different next hop without editing the file. --packet-size is ignored entirely. The capture decides the sizes.

​
File support

Both .pcap and .pcapng, read with a pure-Go parser. No libpcap, no cgo. The whole file is read and validated before anything is attached to your NIC, so a bad file fails immediately rather than halfway through a run. Wireblast summarises what it loaded:
It has to be an Ethernet capture. A capture taken on a tunnel, a loopback, or with a link type Wireblast can’t put on a wire is refused:
If packets were truncated by the capture’s snapshot length, you get told, because they’ll go out short:

​
Timing

Two modes, and the choice matters more than it looks.
Ignores the capture’s timestamps and sends as fast as --pps and --bps allow. The capture becomes a source of packet content; you control the pace.
This is what you want for load testing with realistic packets.
Measured: a 300-packet capture spanning 2.99s replays in 3.03s with --pcap-timing original. Add --pps 50 and it takes 6.7s, because the rate limit is now the slower constraint.

​
Looping

--pcap-loop is on by default: the capture repeats until --duration expires. That’s what makes a short capture useful as a traffic source. With looping on, every queue replays the whole capture independently, so throughput scales with queue count. Turn it off to send the capture exactly once:
A one-pass replay runs on queue 0 only, so packets go out in capture order. That’s the point: order is what you’re preserving. It costs you the parallelism, which is the right trade when replaying a specific scenario.The run ends when the capture is exhausted, whatever --duration says.

​
Receiving replayed traffic

--rx-mode generated-flow can’t work here, because there are no generated flows to infer a return filter from:
Use an explicit filter that matches what’s in the capture.

​
Trimming a big capture

If a file is over the two-million-packet limit, Wireblast tells you how to cut it down:
editcap ships with Wireshark. Since looping is on by default, a few thousand representative packets usually beats a giant file anyway.

​
A ready-made example

The examples directory ships a small sample.pcap and two runnable scripts: 015-pcap-replay for rate-paced replay, and 016-pcap-original-timing for the recorded timing.