tcpprep¶
Pre-processes a pcap into a cache file. It reads a capture once, decides for
each packet whether it's client-to-server or server-to-client, and writes a
compact cache file recording those decisions. tcpreplay and tcprewrite
then read that cache to make direction-aware choices — most importantly, which
NIC to send each packet out of during a two-NIC in-line test.
tcpprep only reads and analyses; it needs no privileges and touches no
network.
Why a separate step?¶
Splitting classification out of the replay has two benefits:
- Speed. The (potentially expensive) analysis happens once, offline. The real-time replay just reads a lookup table.
- Control. You can inspect, tweak, or hand-author the classification independently of the send.
See The tcpprep cache pipeline for the design.
Basic use¶
Then hand the cache to another tool with -c / --cachefile:
Classification modes¶
You pick how packets get split into client and server:
tcpprep builds a tree of the IPs it sees and infers roles. MODE is one
of:
| Mode | Heuristic |
|---|---|
bridge |
Split by MAC address (Layer 2). |
router |
Split by IP subnet, learning which side is which. |
client |
Ambiguous hosts are treated as clients. |
server |
Ambiguous hosts are treated as servers. |
first |
The first host seen in a conversation is the client. |
Everything in the given network(s) is the client side; everything else is
the server side. (-c is the short form — note this is not the same as
the --cachefile short flag on the consuming tools.)
Classify by well-known server ports (from /etc/services, or a file given
with --services).
Add --reverse to swap the client/server assignment.
Inspecting a cache¶
To see how packets were classified without running a replay:
You can also embed a note in the cache with --comment and read it back with
--print-comment — handy for recording how a cache was produced.
See also¶
- Splitting client/server traffic — the end-to-end two-NIC recipe.
- The tcpprep cache pipeline — the concept.
tcpprepman page — every option.