<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<!--Converted with LaTeX2HTML 2002-2-1 (1.70)
original version by:  Nikos Drakos, CBLU, University of Leeds
* revised and updated by:  Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
  Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>Tcpreplay 3.x Manual (BETA)</TITLE>
<META NAME="description" CONTENT="Tcpreplay 3.x Manual (BETA)">
<META NAME="keywords" CONTENT="manual">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="LaTeX2HTML v2002-2-1">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

<LINK REL="STYLESHEET" HREF="manual.css">

<LINK REL="next" HREF="node1.html">
</HEAD>

<BODY >

<DIV CLASS="navigation"><!--Navigation Panel-->
<A NAME="tex2html13"
  HREF="node1.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_g.png"> 
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev_g.png">   
<BR>
<B> Next:</B> <A NAME="tex2html14"
  HREF="node1.html">Other Resources</A>
<BR>
<BR></DIV>
<!--End of Navigation Panel-->

<P>

<P>

<P>
<H1 ALIGN="CENTER">Tcpreplay 3.x Manual (BETA)</H1>
<DIV CLASS="author_info">

<P ALIGN="CENTER"><STRONG>Aaron Turner</STRONG></P>
<P ALIGN="CENTER"><I>http://tcpreplay.sourceforge.net/</I></P>
</DIV>

<P>

<H1><A NAME="SECTION00010000000000000000">
Notice</A>
</H1>

<P>
This document is still in the process of being re-written due to the
significant CLI and configuration file changes between versions 2.x
and 3.x. For the definative source of configuration options, please
see the tcpprep, tcprewrite, tcpreplay and tcpbridge man pages.

<P>

<H1><A NAME="SECTION00020000000000000000">
Overview</A>
</H1>

<P>
Tcpreplay is a suite of utilities for UNIX systems for editing and
replaying network traffic which was previously captured by tools like
tcpdump and ethereal. The goal of tcpreplay is to provide the means
for providing reliable and repeatible means for testing a variety
of network devices such as switches, router, firewalls, network intrusion
detection and prevention systems (IDS and IPS). 

<P>
Tcpreplay provides the ability to classify traffic as client or server,
edit packets at layers 2-4 and replay the traffic at arbitrary speeds
onto a network for sniffing or through a device.

<P>
Some of the advantages of using tcpreplay over using ``exploit
code'' are:

<P>

<UL>
<LI>Since tcpreplay emulates the victim and the attacker, you generally
only need a tcpreplay box and the device under test (DUT)
</LI>
<LI>Tests can include background traffic of entire networks without the
cost and effort of setting up dozens of hosts or costly emulators
</LI>
<LI>No need to have a ``victim'' host which needs to have the appropriate
software installed, properly configured and rebuilt after compromise
</LI>
<LI>Less chance that a virus or trojan might escape your network and wreak
havoc on your systems
</LI>
<LI>Uses the open standard pcap file format for which dozens of command
line and GUI utilities exist
</LI>
<LI>Tests are fully repeatable without a complex test harnesses or network
configuration
</LI>
<LI>Tests can be replayed at arbitrary speeds
</LI>
<LI>Single command-line interface to learn and integrate into test harness
</LI>
<LI>You only need to audit tcpreplay, rather then each and every exploit
individually
</LI>
<LI>Actively developed and supported by it's author
</LI>
</UL>

<P>

<H2><A NAME="SECTION00021000000000000000">
Using this manual</A>
</H2>

<P>
The goal of this manual is to provide an idea of what tcpreplay and
it's utilities can do. It is not however intended to be a complete
document which covers every possible use case or situation. It is
also very much a work in progress and is far from complete and has
numerous errors since a lot of things have changed since tcpreplay
2.x. It is expected that most of these issues will be ironed out before
the offical 3.0 release is made. You should keep in mind the following
conventions when reading this document:

<P>

<UL>
<LI>Commands you should run from the command line <TT>are in monotype</TT>.
</LI>
<LI>Commands that should be run as root will have a '#' in front of them.
</LI>
<LI>Commands that should be run as an unprivelged user will have a '$'
in front of them.
</LI>
<LI>Text that should be placed in a file <TT>is in monospace.</TT>
</LI>
</UL>
All of the applications shipped with tcpreplay support both short
(a single dash followed by a single character) and long (two dashes
followed by multiple characters) arguments. For consistancy, this
document uses the long option format. Please review the man pages
for the short argument equivalents.

<P>

<H2><A NAME="SECTION00022000000000000000">
Getting Help</A>
</H2>

<P>
If you still have a question after reading the Tcpreplay manual, man
pages and FAQ, please contact the Tcpreplay-Users &lt;tcpreplay-users@lists.sourceforge.net&gt;
mailing list. Note that if you ask a question which has clearly been
covered in either the manual or FAQ, you will most likely be told
to RTFM. Also, please try to explain your problem in detail. It is
very difficult and fustrating to get requests from people seeking
help who only provide vague and incomplete information.

<P>

<H2><A NAME="SECTION00023000000000000000">
Corrections and additions to the manual</A>
</H2>

<P>
I've tried to keep this document up to date with the changes in tcpreplay,
but occasionally I get too busy, make a mistake or just forget something.
If you find anything in this document which could be improved upon,
please let me know.

<P>

<H1><A NAME="SECTION00030000000000000000">
Getting Tcpreplay working on your system</A>
</H1>

<P>

<H2><A NAME="SECTION00031000000000000000">
Getting the source code</A>
</H2>

<P>
The source code is available as a tarball on the tcpreplay homepage:
http://tcpreplay.sourceforge.net/ I also encourage users familiar
with Subversion to try checking out the latest code as it often has
additional features and bugfixes not yet found in the offical releases.

<P>

<DL COMPACT>
<DT>
<DD>$&nbsp;svn&nbsp;checkout&nbsp;https://www.synfin.net:444/svn/tcpreplay/trunk&nbsp;tcpreplay
</DD>
</DL>
<P>

<H2><A NAME="SECTION00032000000000000000">
Requirements</A>
</H2>

<P>

<OL>
<LI>Libnet<A NAME="tex2html1"
  HREF="#foot56"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A> 1.1.x or better (1.1.3 fixes a checksum bug which effects tcprewrite)
</LI>
<LI>Libpcap<A NAME="tex2html2"
  HREF="#foot57"><SUP><SPAN CLASS="arabic">2</SPAN></SUP></A> 0.6.x or better (0.8.3 or better recommended)
</LI>
<LI>To support the packet decoding feature you'll need tcpdump<A NAME="tex2html3"
  HREF="#foot58"><SUP><SPAN CLASS="arabic">3</SPAN></SUP></A> binary installed.
</LI>
<LI>You'll also need a compatible operating system. Basically, any *NIX
operating system should work. Linux, *BSD, Solaris, OS X and others
should all work. If you find any compatibility issues with any *NIX
OS, please let me know.
</LI>
</OL>

<P>

<H2><A NAME="SECTION00033000000000000000">
Compiling Tcpreplay</A>
</H2>

<P>
Two easy steps:

<P>

<DL COMPACT>
<DT>
<DD><SPAN  CLASS="textit">$</SPAN>&nbsp;./configure&nbsp;&amp;&amp;&nbsp;make&nbsp;<SPAN  CLASS="textit"></SPAN>

<P>
<SPAN  CLASS="textit">#</SPAN>&nbsp;make&nbsp;install
</DD>
</DL>There are some optional arguments which can be passed to the 'configure'
script which may help in cases where your libnet, libpcap or tcpdump
installation is not standard or if it can't determine the correct
network interface card to use for testing. I also recommend that for
beta code you specify <SPAN  CLASS="textbf">-enable-debug</SPAN>
to the configure script in case you find any bugs. If you find that
configure isn't completing correctly, run: <SPAN  CLASS="textit">./configure -help</SPAN>
for more information.

<P>
You may also choose to run: 

<P>

<DL COMPACT>
<DT>
<DD>#&nbsp;<SPAN  CLASS="textit">make&nbsp;test&nbsp;-i</SPAN>
</DD>
</DL>
<UL>
<LI>make test is just a series of sanity checks which try to find serious
bugs (crashes) in tcpprep and tcpreplay.
</LI>
<LI>make test requires at least one properly configured network interface.
If the configure script can't guess what a valid interface is you
can specify it with the -with-testnic and -with-testnic2
arguments.
</LI>
<LI>If make test fails, often you can find details in test/test.log.
</LI>
<LI>OpenBSD's make has a bug where it ignores the MAKEFLAGS variable in
the Makefile, hence you'll probably want to run: <SPAN  CLASS="textit">make -is test</SPAN>
instead.
</LI>
</UL>

<P>

<H1><A NAME="SECTION00040000000000000000">
Basic Tcpreplay Usage</A>
</H1>

<P>

<H2><A NAME="SECTION00041000000000000000">
Replaying the traffic</A>
</H2>

<P>
To replay a given pcap as it was captured all you need to do is specify
the pcap file and the interface to send the traffic out interface
'eth0':

<P>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00042000000000000000">
Replaying at different speeds</A>
</H2>

<P>
You can also replay the traffic at different speeds then it was originally
captured<A NAME="tex2html4"
  HREF="#foot507"><SUP><SPAN CLASS="arabic">4</SPAN></SUP></A>. 

<P>
Some examples:

<P>

<UL>
<LI>To replay traffic as quickly as possible:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-topspeed&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To replay traffic at a rate of 10Mbps:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-mbps=10.0&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To replay traffic 7.3 times as fast as it was captured:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-multiplier=7.3&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To replay traffic at half-speed:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-multiplier=0.5&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To replay at 25 packets per second:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-pps=25&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00043000000000000000">
Replaying files multiple times</A>
</H2>

<P>
Using the loop flag you can specify that a pcap file will be sent
two or more times<A NAME="tex2html5"
  HREF="#foot118"><SUP><SPAN CLASS="arabic">5</SPAN></SUP></A>:

<P>
To replay the sample.pcap file 10 times:

<P>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-loop=10&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>To replay the sample.pcap an infinitely or until CTRL-C is pressed:

<P>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-loop=0&nbsp;-intf1=eth0&nbsp;sample.pcap
</DD>
</DL>
<P>

<H1><A NAME="SECTION00050000000000000000">
Editing Packets</A>
</H1>

<P>
There are a number of ways you can edit packets stored in a pcap file:

<P>

<OL>
<LI>Rewriting IP addresses so that they appear to be sent from and to
different hosts
</LI>
<LI>Fixing corrupted packets which were truncated by tcpdump or had bad
checksums
</LI>
<LI>Adding, removing or changing 802.1q VLAN tags on frames
</LI>
<LI>Rewriting traffic so that it no longer uses ``standard'' TCP or
UDP ports for the given service
</LI>
<LI>Changing ethernet MAC addresses so that packets will be accepted by
a router or firewall
</LI>
</OL>

<P>

<H1><A NAME="SECTION00060000000000000000">
Splitting Traffic</A>
</H1>

<P>
Anything other then just replaying packets at different speeds requires
additional work and CPU cycles. While older versions of tcpreplay
allowed you to do many of these calculations while replaying traffic,
it had a negative effect on the overall throughput and performance
of tcpreplay. Hence, these secondary features have been placed in
two utilities:

<P>

<UL>
<LI>tcpprep - Used to categorize packets as originating from clients or
servers
</LI>
<LI>tcprewrite - Used to edit packets
</LI>
</UL>
By using tcpprep and tcprewrite on a pcap file before sending it using
tcpreplay, many possibilities open up. A few of these possibilities
are:

<P>

<H2><A NAME="SECTION00061000000000000000">
Classifying client and servers with tcpprep</A>
</H2>

<P>
Both tcpreplay and tcprewrite process a single pcap file and generate
output. Some features, such as rewriting IP or MAC addresses or sending
traffic out two different interfaces, require tcpreplay and tcprewrite
to have some basic knowledge about which packets were sent by ``clients''
and ``servers''. Such classification is often rather arbitrary
since for example a SMTP mail server both accepts inbound email (acts
as a server) and forwards mail to other mail servers (acts as a client).
A webserver might accept inbound HTTP requests, but make client connections
to a SQL server. 

<P>
To deal with this problem, tcpreplay comes with tcpprep which provides
a number of manual and automatic classification methods which cover
a variety of situations. 

<P>

<H3><A NAME="SECTION00061100000000000000">
Seperating clients and servers automatically</A>
</H3>

<P>
The easiest way to split clients and servers is to let tcpprep do
the classification for you. Tcpprep examines the pcap file for TCP
three-way handshakes, DNS lookups and other types of traffic to figure
out which IP's mostly act like clients and which mostly act like servers.
There are four different automatic modes that you can choose between:

<P>

<OL>
<LI>Bridge - This is the simplest mode. Each IP is individually tracked
and ranked as a client or server. However, if any of the hosts do
not generate enough ``client'' or ``server'' traffic then
tcpprep will abort complaining that it was unable to determine its
classification. This works best when clients and servers are intermixed
on the same subnet.
</LI>
<LI>Client - This works just like bridge mode, except that unknown hosts
will be marked a client.
</LI>
<LI>Server - This works just like bridge mode, except that unknown hosts
will be marked a server.
</LI>
<LI>Router - Hosts are first ranked as client or server. Then each host
is placed in a subnet which is expanded until either all the unknown
hosts are included or the -maxmask is reached. This works best when
clients and servers are on diffierent networks.
</LI>
</OL>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER" COLSPAN=2><SPAN>TCPPREP AUTOMATIC ROUTER MODE PROCESS</SPAN>
<BR>
S<SMALL>TEP 1:</SMALL> Categorize Clients, Servers and Unknowns</TD>
</TR>
</TABLE>
</DIV>

<P>
&nbsp;&nbsp;&nbsp;

<P>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3>
<TR><TD ALIGN="CENTER">S<SMALL>TEP 3:</SMALL> Unknowns Now Marked as Clients and Servers
<BR></SMALL>
<BR></TD>
</TR>
</TABLE>
</DIV>

<P>
Classifying clients and servers in automatic mode is as easy as choosing
a pcap file, an output ``tcpprep cache file'' and the mode to
use:

<P>

<DL COMPACT>
<DT>
<DD><SPAN  CLASS="textit">$</SPAN>&nbsp;tcpprep&nbsp;-auto=bridge&nbsp;-pcap=input.pcap&nbsp;-cachefile=input.cache
</DD>
</DL>The above example would split traffic in bridge mode. Other modes
are ``router'', ``client'' and ``server''. If you wish,
you can override the default 2:1 ratio of server vs. client traffic
required to classify an IP as a server. If for example you wanted
to require 3.5 times as much server to client traffic you would specify
it like:

<P>

<DL COMPACT>
<DT>
<DD><SPAN  CLASS="textit">$</SPAN>&nbsp;tcpprep&nbsp;-auto=bridge&nbsp;-ratio=3.5&nbsp;-pcap=input.pcap&nbsp;-cachefile=input.cache
</DD>
</DL>
<P>

<H3><A NAME="SECTION00061200000000000000">
Seperating clients and servers manually by subnet</A>
</H3>

<P>
Sometimes, you may not want to split traffic based on clients and
servers. The alternative to using on of the automatic modes in this
case, is to use one of the manual modes. One manual way of differentiating
between clients and servers using tcpprep is by specifying a list
of networks in CIDR notation which contain ``servers''. Of course
the specified CIDR netblocks don't have to contain 

<P>

<H2><A NAME="SECTION00062000000000000000">
Replaying on multiple interfaces</A>
</H2>

<P>
Tcpreplay can also split traffic so that each side of a connection
is sent out a different interface<A NAME="tex2html6"
  HREF="#foot182"><SUP><SPAN CLASS="arabic">6</SPAN></SUP></A>. In order to do this, tcpreplay needs the name of the second interface
(-j) and a way to split the traffic. Currently, there are two ways
to split traffic:

<P>

<OL>
<LI>-C = split traffic by source IP address which is specified in CIDR
notation
</LI>
<LI>-c = split traffic according to a tcpprep cachefile<A NAME="tex2html7"
  HREF="#foot184"><SUP><SPAN CLASS="arabic">7</SPAN></SUP></A>
</LI>
</OL>
When splitting traffic, it is important to remember that traffic that
matches the filter is sent out the primary interface (-intf1). In
this case, when splitting traffic by source IP address, you provide
a list of networks in CIDR notation. For example:

<P>

<UL>
<LI>To send traffic from 10.0.0.0/8 out eth0 and everything else out eth1:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-C&nbsp;10.0.0.0/8&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To send traffic from 10.1.0.0/24 and 10.2.0.0/20 out eth0 and everything
else out eth1:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-C&nbsp;10.1.0.0/24,10.2.0.0/20&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>After using tcpprep to generate a cache file, you can use it to split
traffic between two interfaces like this:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-c&nbsp;sample.cache&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00063000000000000000">
Selectively sending or dropping packets</A>
</H2>

<P>
Sometimes, you want to do some post-capture filtering of packets.
Tcpreplay let's you have some control over which packets get sent.

<P>

<OL>
<LI>-M = disables sending of martian packets. By definition, martian packets
have a source IP of 0.x.x.x, 127.x.x.x, or 255.x.x.x
</LI>
<LI>-x = send packets which match a specific pattern
</LI>
<LI>-X = send packets which do not match a specific pattern
</LI>
</OL>
Both -x and -X support a variety of pattern matching types. These
types are specified by a single character, followed by a colon, followed
by the pattern. The following pattern matching types are available:

<P>

<OL>
<LI>S - Source IP
<BR>
Pattern is a comma delimited CIDR notation
</LI>
<LI>D - Destination IP
<BR>
Pattern is a comma delimited CIDR notation
</LI>
<LI>B - Both source and destination IP must match
<BR>
Pattern is a comma delimited CIDR notation
</LI>
<LI>E - Either source or destination IP must match
<BR>
Pattern is a comma delimited CIDR notation
</LI>
<LI>P - A list of packet numbers from the pcap file.
<BR>
Pattern is a series of numbers, separated by commas or dashes.
</LI>
<LI>F - BPF syntax (same as used in tcpdump).
<BR>
Filter must be quoted and is only supported with -x<A NAME="tex2html8"
  HREF="#foot208"><SUP><SPAN CLASS="arabic">8</SPAN></SUP></A>.
</LI>
</OL>
Examples:

<P>

<UL>
<LI>To only send traffic that is too and from a host in 10.0.0.0/8:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-x&nbsp;B:10.0.0.0/8&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To not send traffic that is too or from a host in 10.0.0.0/8:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-X&nbsp;E:10.0.0.0/8&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To send every packet except the first 10 packets:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-X&nbsp;P:1-10&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To only send the first 50 packets followed by packets: 100, 150, 200
and 250:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-x&nbsp;P:1-50,100,150,200,250&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To only send TCP packets from 10.0.0.1:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD><SPAN  CLASS="textit">tcpreplay&nbsp;-x&nbsp;F:'tcp&nbsp;and&nbsp;host&nbsp;10.0.0.1'&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap</SPAN>
</DD>
</DL>
<P>

<H2><A NAME="SECTION00064000000000000000">
Replaying only a few packets</A>
</H2>

<P>
Using the limit packets flag (-L) you can specify that tcpreplay will
only send at most a specified number of packets.

<P>

<UL>
<LI>To send at most 100 packets:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-L&nbsp;100&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00065000000000000000">
Skipping the first bytes in a pcap file</A>
</H2>

<P>
If you want to skip the beginning of a pcap file, you can use the
offset flag (-o) to skip a specified number of bytes and start sending
on the next packet.

<P>

<UL>
<LI>To skip 15Kb into the pcap file and start sending packets from there:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-o&nbsp;15000&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00066000000000000000">
Replaying packets which are bigger then the MTU</A>
</H2>

<P>
Occasionally, you might find yourself trying to replay a pcap file
which contains packets which are larger then the MTU for the sending
interface. This might be due to the packets being captured on the
loopback interface or on a 1000Mbps ethernet interface supporting
``jumbo frames''. I've even seen packets which are 1500 bytes
but contain both an ethernet header and trailer which bumps the total
frame size to 1518 which is 4 bytes too large.

<P>
By default, tcpreplay will skip these packets and not send them. Alternatively,
you can specify the -T flag to truncate these packets to the MTU and
then send them. Of course this may invalidate your testing, but it
has proven useful in certain situations. Also, when this feature is
enabled, tcpreplay will automatically recalculate the IP and TCP,
UDP or ICMP checksums as needed. Example:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-T&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00067000000000000000">
Writing packets to a file</A>
</H2>

<P>
It's not always necessary to write packets to the network. Since tcpreplay
has so many features which modify and select which packets are sent,
it is occasionally useful to save these changes to another pcap file
for comparison. Rather then running a separate tcpdump process to
capture the packets, tcpreplay now supports output directly to a file.
Example:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-w&nbsp;output.pcap&nbsp;-F&nbsp;-u&nbsp;pad&nbsp;-x&nbsp;E:10.0.0.0/8&nbsp;input1.pcap&nbsp;input2.pcap&nbsp;input3.pcap
</DD>
</DL>Notice that specifying an interface is still required (required for
various internal functions), but all the packets will be written to
<SPAN  CLASS="textit">output.pcap</SPAN>.

<P>
You can also split traffic into two files by using -W &lt;2nd output
file&gt;.

<P>

<H2><A NAME="SECTION00068000000000000000">
Extracting Application Data (Layer 7)</A>
</H2>

<P>
New to version 2.0 is the ability to extract the application layer
data from the packets and write them to a file. In the man page, we
call this ``data dump mode'' which is enabled with -D. It's important
to specify -D before -w (and -W if you're splitting data into two
files). Example:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-D&nbsp;-intf1&nbsp;eth0&nbsp;-j&nbsp;eth0&nbsp;-w&nbsp;clientdata&nbsp;-W&nbsp;serverdata&nbsp;-C&nbsp;10.0.0.0/24&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00069000000000000000">
Replaying Live Traffic</A>
</H2>

<P>
You can now replay live traffic sniffed on one network interface and
replay it on another interface using the -S flag to indicate sniff
mode and the appropriate snaplen in bytes (0 denotes the entire packet).
You can also enabling bi-directional traffic using the bridge mode
flag: -b.

<P>
N<SMALL>OTE:</SMALL> It is critical for your sanity (and to prevent your
murder by your network administrators) that the input interface and
the output interface be on separate networks and additionally that
no other network devices (such as bridges, switches, routers, etc)
be connecting the two networks, else you will surely get a networkstorm
the likes that have not been seen for years.

<P>

<UL>
<LI>Send packets sniffed on eth0 out eth1:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth1&nbsp;-S&nbsp;0&nbsp;eth0
</DD>
</DL>
<UL>
<LI>Bridge two subnets connected to eth0 and eth1:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-intf2=eth1&nbsp;-b&nbsp;-S&nbsp;0
</DD>
</DL>By default, tcpreplay listens in promiscuous mode on the specified
interface, however if you only want to send unicasts directed for
the local system and broadcasts, you can specify the ``not_nosy''
option in the configuration file or -n on the command line. Note that
if another program has already placed the interface in promiscuous
mode, the -n flag will have no effect, so you may want to use the
-x or -X argument to limit packets.

<P>

<H2><A NAME="SECTION000610000000000000000">
Replaying Packet Capture Formats Other Than Libpcap</A>
</H2>

<P>
There are about as many different capture file formats as there are
sniffers. In the interest of simplicity, tcpreplay only supports libpcap<A NAME="tex2html9"
  HREF="#foot277"><SUP><SPAN CLASS="arabic">9</SPAN></SUP></A>. If you would like to replay a file in one of these multitude of
formats, the excellent open source tool Ethereal easily allows you
to convert it to libpcap. For instance, to convert a file in Sun's
snoop format to libpcap, issue the command: 

<P>

<DL COMPACT>
<DT>
<DD>tethereal&nbsp;-r&nbsp;blah.snoop&nbsp;-w&nbsp;blah.pcap
</DD>
</DL>and replay the resulting file. 

<P>

<H2><A NAME="SECTION000611000000000000000">
Replaying Client Traffic to a Server</A>
</H2>

<P>
A common question on the tcpreplay-users list is how does one replay
the client side of a connection back to a server. Unfortunately, tcpreplay
doesn't support this right now. The major problem concerns syncing
up TCP Seq/Ack numbers which will be different. ICMP also often contains
IP header information which would need to be adjusted. About the only
thing that could be easy to do is UDP, which isn't usually requested.

<P>
This is however a feature that we're looking into implementing in
the flowreplay utility. If you're interested in helping work on this
feature, please contact us and we'd be more then happy to work with
you. At this time however, we don't have an ETA when this will be
implemented, so don't bother asking.

<P>

<H2><A NAME="SECTION000612000000000000000">
Decoding Packets</A>
</H2>

<P>
If the tcpdump binary is installed on your system when tcpreplay is
compiled, it will allow you to decode packets as they are sent without
running tcpdump in a separate window or worrying about it capturing
packets which weren't sent by tcpreplay.

<P>

<UL>
<LI>Decode packets as they are sent:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-v&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>Decode packets with the link level header:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-v&nbsp;-A&nbsp;``-e''&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>Fully decode and send one packet at a time:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-v&nbsp;-1&nbsp;-A&nbsp;``-s0&nbsp;-evvvxX''&nbsp;sample.pcap
</DD>
</DL>Note that tcpreplay automatically applies the -n flag to disable DNS
lookups which would slow down tcpdump too much to make it effective.

<P>

<H1><A NAME="SECTION00070000000000000000">
Packet Editing</A>
</H1>

<P>

<H2><A NAME="SECTION00071000000000000000">
Rewriting MAC addresses</A>
</H2>

<P>
If you ever want to send traffic to another device on a switched LAN,
you may need to change the destination MAC address of the packets.
Tcpreplay allows you to set the destination MAC for each interface
independently using the -I and -J switches. As of version 2.1.0, you
can also specify the source MAC via -k and -K. Example:

<P>

<UL>
<LI>To send traffic out eth0 with a destination MAC of your router (00:00:01:02:03:04)
and the source MAC of the server (00:20:30:40:50:60):
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-I&nbsp;00:00:01:02:03:04&nbsp;-k&nbsp;00:20:30:40:50:60&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>To split traffic between internal (10.0.0.0/24) and external addresses
and to send that traffic to the two interfaces of a firewall:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;-I&nbsp;00:01:00:00:AA:01&nbsp;-J&nbsp;00:01:00:00:AA:02&nbsp;-C&nbsp;10.0.0.0/24&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00072000000000000000">
Randomizing IP addresses</A>
</H2>

<P>
Occasionally, it is necessary to have tcpreplay rewrite the source
and destination IP addresses, yet maintain the client/server relationship.
Such a case might be having multiple copies of tcpreplay running at
the same time using the same pcap file while trying to stress test
firewall, IDS or other stateful device. If you didn't change the source
and destination IP addresses, the device under test would get confused
since it would see multiple copies of the same connection occurring
at the same time. In order to accomplish this, tcpreplay accepts a
user specified seed which is used to generate pseudo-random IP addresses.
Also, when this feature is enabled, tcpreplay will automatically recalculate
the IP and TCP, UDP or ICMP checksums as needed. Example:

<P>

<DL COMPACT>
<DT>
<DD><SPAN  CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;-s&nbsp;1239&nbsp;sample.pcap&nbsp;&amp;</SPAN>&nbsp;
<BR><SPAN  CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;-s&nbsp;76&nbsp;sample.pcap&nbsp;&amp;</SPAN>&nbsp;
<BR><SPAN  CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;-s&nbsp;239&nbsp;sample.pcap&nbsp;&amp;</SPAN>&nbsp;
<BR><SPAN  CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;sample.pcap</SPAN>
</DD>
</DL>
<P>

<H2><A NAME="SECTION00073000000000000000">
Replaying (de)truncated packets</A>
</H2>

<P>
Occasionally, it is necessary to replay traffic which has been truncated
by tcpdump. This occurs when the tcpdump snaplen is smaller then the
actual packet size. Since this will create problems for devices which
are expecting a full-sized packet or attempting checksum calculations,
tcpreplay allows you to either pad the packet with zeros or reset
the packet length in the headers to the actual packet size. In either
case, the IP and TCP, UDP or ICMP checksums are recalculated. Examples:

<P>

<UL>
<LI>Pad truncated packets:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-u&nbsp;pad&nbsp;sample.pcap
</DD>
</DL>
<UL>
<LI>Rewrite packet header lengths to the actual packet size:
</LI>
</UL>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-u&nbsp;trunc&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00074000000000000000">
Rewriting Layer 2 with -2</A>
</H2>

<P>
Starting in the 2.0.x branch, tcpreplay can replace the existing layer
2 header with one of your choosing. This is useful for when you want
to change the layer 2 header type or add a header for pcap files without
one. Each pcap file tells the type of frame. Currently tcpreplay knows
how to deal with the following pcap(3) frame types:

<P>

<UL>
<LI>DLT_EN10MB
<BR>
Replace existing 802.3/Ethernet II header
</LI>
<LI>DLT_RAW
<BR>
Frame has no Layer 2 header, so we can add one.
</LI>
<LI>DLT_LINUX_SLL
<BR>
Frame uses the Linux Cooked Socket header which is most commonly created
with <SPAN  CLASS="textit">tcpdump -i any</SPAN> on a Linux system.
</LI>
</UL>
Tcpreplay accepts the new Layer 2 header as a string of comma separated
hex values such as: 0xff,0xac,0x00,0x01,0xc0,0x64. Note that the leading
'0x' is <SPAN  CLASS="textit">not</SPAN> required.

<P>
Potential uses for this are to add a layer 2 header for DLT_RAW captures
or add/remove ethernet tags or QoS features.

<P>

<H2><A NAME="SECTION00075000000000000000">
Rewriting DLT_LINUX_SLL (Linux Cooked Socket) captures</A>
</H2>

<P>
Tcpdump uses a special frame type to store captures created with the
``-i any'' argument. This frame type uses a custom 16 byte layer
2 header which tracks which interface captured the packet and often
the source MAC address of the original ethernet frame. Unfortunately,
it never stores the destination MAC address and it doesn't store a
source MAC when the packet is captured on the loopback interface.
Normally, tcpreplay can't replay these pcap files because there isn't
enough information in the LINUX_SLL header to do so; however two
options do exist:

<P>

<OL>
<LI>You can send these packets with -2 which will replace the LINUX_SLL
header with an ethernet header of your choosing.
</LI>
<LI>You can specify a destination MAC via -I and -J in which case tcpreplay
will use the stored source MAC and create a new 802.3 Ethernet header.
Note that if the pcap contains loopback packets, you will also need
to specify -k and/or -K to specify the source MAC as well or they
will be skipped.
</LI>
</OL>

<P>

<H2><A NAME="SECTION00076000000000000000">
Rewriting IP Addresses (pseudo-NAT)</A>
</H2>

<P>
Pseudo-NAT allows the mapping of IP addresses in IPv4 and ARP packets
from one subnet to another subnet of the same or different size. This
allows some or all the traffic sent to appear to come from a different
IP subnet then it actually was captured on.

<P>
The mapping is done through a user specified translation table comprised
of one or more source and destination network(s) in the format of
&lt;srcnet&gt;/&lt;masklen&gt;:&lt;dstnet&gt;/&lt;masklen&gt; deliminated by a comma. Mapping
is done by matching IP addresses to the source subnet and rewriting
the most significant bits with the destination subnet. For example:

<P>
<SPAN  CLASS="textit">tcpreplay -intf1=eth0 -N 10.100.0.0/16:172.16.10.0/24 sample.pcap</SPAN>

<P>
would match any IP in the 10.100.0.0/16 subnet and rewrite it as if
it came from or sent to the 172.16.10.0/24 subnet. Ie: 10.100.5.88
would become 172.16.10.88 and 10.100.99.45 would become 172.16.10.45.
But 10.150.7.44 would not be rewritten.

<P>
For any given IP address, the translation table is applied in order
(so if there are multiple mappings, earlier maps take precedence)
and occurs only once per IP (no risk of an address getting rewritten
a second time).

<P>

<H2><A NAME="SECTION00077000000000000000">
Advanced pseudo-NAT</A>
</H2>

<P>
Pseudo-NAT also works with traffic splitting (using two interfaces
or output files) but with a few important differences. First you have
the option of specifying one or two pseudo-NAT tables. Using a single
pseudo-NAT table means that the source and destination IP addresses
of both interfaces are rewritten using the same rules. Using two pseudo-NAT
tables (specifying -N &lt;Table1&gt; -N &lt;Table2&gt;) will cause the source
and destination IP addresses to be rewritten differently for each
interface using the following matrix:

<P>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 BORDER="1">
<TR><TD ALIGN="CENTER">&nbsp;</TD>
<TD ALIGN="CENTER">Out Primary Interface</TD>
<TD ALIGN="CENTER">Out Secondary Interface
<BR>
Src IP</TD>
</TR>
</TABLE>
</DIV>

<P>
While seemingly a bit confusing, this feature provides a number of
interesting possibilities such as the ability to rewrite the IP headers
of packets in the case where traffic is captured on the loopback interface
(and the source and destination address is always 127.0.0.1) so that
tcpreplay can make it look like two different systems are talking
to each other (you'll probably also need to specify the source and
destination MAC addresses via -I, -J, -k and -K).

<P>

<H2><A NAME="SECTION00078000000000000000">
IP Endpoints</A>
</H2>

<P>
While pseudo-NAT provides a great deal of flexibility, it is often
more complicated then is necessary for testing of inline devices.
As a simplier alternative, tcpreplay supports the concept of rewriting
all traffic to so that it appears to be between two IP addresses:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;-c&nbsp;sample.cache&nbsp;-e&nbsp;10.0.0.1:10.1.1.1&nbsp;sample.pcap
</DD>
</DL>Will rewrite all the traffic so that it is between 10.0.0.1 and 10.1.1.1.
The equivalent command using -N would be:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;-c&nbsp;sample.cache&nbsp;-N&nbsp;0.0.0.0/0:10.0.0.1&nbsp;-N&nbsp;0.0.0.0/0:10.1.1.1&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00079000000000000000">
Unifying Dual-Outputs</A>
</H2>

<P>
Since a number of tcpreplay's packet editing functions require splitting
traffic between client and servers, one problem that may arrise is
needing to edit packets but still output to a single interface or
file. The solution to this is to use the one output option -O which
causes packets to be processed as if they will be split between the
interfaces/files, but then always go out the primary interface or
file. Note that even though only one interface/file will be written
to, both -i and -j must be specified; although they can be the same
physical interface.

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-j&nbsp;eth0&nbsp;-O&nbsp;-c&nbsp;sample.cache&nbsp;-e&nbsp;10.0.0.1:10.1.1.1&nbsp;sample.pcap
</DD>
</DL>Merging the output to a single file:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-j&nbsp;eth0&nbsp;-w&nbsp;rewrite.pcap&nbsp;-c&nbsp;sample.cache&nbsp;-e&nbsp;10.0.0.1:10.1.1.1&nbsp;sample.pcap
</DD>
</DL>
<P>

<H1><A NAME="SECTION00080000000000000000">
Tcpprep Usage</A>
</H1>

<P>

<H2><A NAME="SECTION00081000000000000000">
What is tcpprep?</A>
</H2>

<P>
Tcpreplay can send traffic out two network cards, however it requires
the calculations be done in real-time. These calculations can be expensive
and can significantly reduce the throughput of tcpreplay.

<P>
Tcpprep is a libpcap pre-processor for tcpreplay which enables using
two network cards to send traffic without the performance hit of doing
the calculations in real-time.

<P>

<H2><A NAME="SECTION00082000000000000000">
What are these 'modes' tcpprep has? </A>
</H2>

<P>
Tcpprep has three basic modes which require the user to specify how
to split traffic.

<P>

<UL>
<LI>CIDR (-cidr) mode requires the user to provide
a list of networks. Any packet with a source IP in one of these networks
gets sent out the primary interface.
</LI>
<LI>Regex (-regex) mode requires the user to provide
a regular expression. Any packet with a source IP matching the regex
gets sent out the primary interface.
</LI>
<LI>Port (-port) mode splits TCP/UDP traffic based
on the destination port in the header. Normally, ports 0-1023 are
considered ``server'' ports and everything else a client port.
You can create your own custom mapping file in the same format as
/etc/services (see the services(5) man page for details) by specifying
-services &lt;file&gt;.
</LI>
</UL>
And four auto modes in which tcpprep decides how to split traffic.
Auto modes are useful for when you don't know much about the contents
of the dump file in question and you want to split traffic up based
upon servers and clients.

<P>

<UL>
<LI>Auto/Router (-auto router) mode trys to find
the largest network(s) that contain all the servers and no clients.
Any unknown system is automatically re-classified as servers if it's
inside the server network(s), otherwise it is classified as a client.
</LI>
<LI>Auto/Bridge (-auto bridge) mode makes the assumption
that the clients and servers are horribly intermixed on the network
and there's no way to subnet them. While this takes less processing
time to create the cache file it is unable to deal with unknown systems.
</LI>
<LI>Auto/Client (-auto client) mode which works just
like Auto/Bridge mode, except that any system it can't figure out
is treated like a client.
</LI>
<LI>Auto/Server (-auto server) mode which works just
like Auto/Bridge mode, except that any system it can't figure out
is treated like a server.
</LI>
</UL>

<P>

<H2><A NAME="SECTION00083000000000000000">
Splitting traffic based upon IP address</A>
</H2>

<P>
Tcpprep supports the same CIDR mode that tcpreplay supports using
the -cidr flag. Additionally, tcpprep also supports
regex(7) regular expressions to match source IP addresses using the
-regex flag.

<P>

<H2><A NAME="SECTION00084000000000000000">
Auto Mode</A>
</H2>

<P>

<H3><A NAME="SECTION00084100000000000000">
How does Auto/Bridge mode work? </A>
</H3>

<P>
Tcpprep does an initial pass over the libpcap file to build a binary
tree (one node per IP). For each IP, it keeps track of how many times
it was a client or server. It then does a second pass of the file
using the data in the tree and the ratio to determine if an IP is
a client or server. If tcpprep is unable to determine the type (client
or server) for each and every packet, then auto/bridge mode will fail.
In these cases, it is best to use a different auto mode.

<P>

<H3><A NAME="SECTION00084200000000000000">
How does Auto/Router mode work? </A>
</H3>

<P>
Tcpprep does the same first pass as Auto/Bridge mode. It then trys
to convert the binary tree into a list of networks containing the
servers. Finally it uses the CIDR mode with the list of server networks
in a second pass of the libpcap file. Unlike auto/bridge mode, auto/router
mode can always successfully split IP addresses into clients and servers.

<P>

<H3><A NAME="SECTION00084300000000000000">
Determining Clients and Servers</A>
</H3>

<P>
Tcpprep uses the following methods in auto/router and auto/bridge
mode to determine if an IP address is a client or server:

<P>

<UL>
<LI>Client:

<P>

<UL>
<LI>TCP with Syn flag set
</LI>
<LI>UDP source/destination port 53 (DNS) without query flag set
</LI>
<LI>ICMP port unreachable (destination IP of packet)
</LI>
</UL>
</LI>
<LI>Server:

<P>

<UL>
<LI>TCP with Syn/Ack flag set
</LI>
<LI>UDP source/destination port 53 (DNS) with query flag set
</LI>
<LI>ICMP port unreachable (source IP of packet)
</LI>
</UL>
</LI>
</UL>

<P>

<H3><A NAME="SECTION00084400000000000000">
Client/Server ratio</A>
</H3>

<P>
Since a system may send traffic which would classify it as both a
client and server, it's necessary to be able to weigh the traffic.
This is done by specifying the client/server ratio (-R) which is by
default set to 2.0. The ratio is the modifier to the number of client
connections. Hence, by default, client connections are valued twice
as high as server connections.

<P>

<H2><A NAME="SECTION00085000000000000000">
Selectively sending/dropping packets</A>
</H2>

<P>
Tcpprep supports the same -include and -exclude
options to selectively send or drop packets.

<P>

<H2><A NAME="SECTION00086000000000000000">
Using tcpprep cache files with tcpreplay</A>
</H2>

<P>
Just run:

<P>

<DL COMPACT>
<DT>
<DD>tcpreplay&nbsp;-cachefile&nbsp;sample.cache&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
</DD>
</DL>
<P>

<H2><A NAME="SECTION00087000000000000000">
Commenting tcpprep cache files</A>
</H2>

<P>
In versions of tcpprep &gt;= 2.1.0, you can specify a comment to be embeded
in the tcpprep cache file. Comments are user specified and automatically
include the command line arguments passed to tcpprep. 

<P>

<DL COMPACT>
<DT>
<DD>tcpprep&nbsp;-comment&nbsp;``this&nbsp;is&nbsp;my&nbsp;comment''&nbsp;-pcap&nbsp;sample.pcap&nbsp;-cachefile&nbsp;sample.cache&nbsp;&lt;other&nbsp;args&gt;
</DD>
</DL>Or for no user comment, but still embed the command arguments:

<P>

<DL COMPACT>
<DT>
<DD>tcpprep&nbsp;-comment&nbsp;``''&nbsp;-pcap&nbsp;sample.pcap&nbsp;-cachefile&nbsp;sample.cache&nbsp;&lt;other&nbsp;args&gt;
</DD>
</DL>You can then later on print out the comments by running:

<P>

<DL COMPACT>
<DT>
<DD>tcpprep&nbsp;-print-comment&nbsp;sample.cache
</DD>
</DL>
<P>

<H1><A NAME="SECTION00090000000000000000">
Using Configuration Files</A>
</H1>

<P>
Each of the applications in the tcpreplay suite offers the choice
of specifying configuration options in a config file in addition to
the traditional command line. Each command line option has an equivalent
config file option which is listed in the man page. To specify the
configuration file you'd like to use, use the -load-opts=&lt;filename&gt;
option.

<P>
Configuration files have one option per line, and lines beginning
with the pound sign (#) are considered comments and ignored. An example
config file follows:

<P>
------BEGIN CONFIG FILE-------

<P>
<TT># send traffic out 'eth0'</TT>&nbsp;
<BR><TT>intf1 eth0</TT>&nbsp;
<BR>&nbsp;
<BR><TT># loop 5 times</TT>&nbsp;
<BR><TT>loop 5</TT>&nbsp;
<BR>&nbsp;
<BR><TT># send traffic 2x as fast</TT>&nbsp;
<BR><TT>multiplier 2</TT>
<BR>-------END CONFIG FILE--------

<P>
You would then execute:

<P>

<DL COMPACT>
<DT>
<DD>#&nbsp;tcpreplay&nbsp;-load-opts=myconfigfile&nbsp;sample.pcap
</DD>
</DL>You can also group configuration options for tcpprep, tcprewrite and
tcpreplay in a single config file by placing section markers in the
config file. An example:

<P>
------BEGIN CONFIG FILE-------

<P>
<TT>cachefile=example.tcpprep</TT>&nbsp;
<BR>&nbsp;
<BR><TT>[TCPREPLAY]</TT>&nbsp;
<BR><TT>intf1 eth0</TT>&nbsp;
<BR><TT>intf2 eth1</TT>&nbsp;
<BR><TT>topspeed </TT>&nbsp;
<BR>&nbsp;
<BR><TT>[TCPPREP]</TT>&nbsp;
<BR><TT>auto=bridge</TT>&nbsp;
<BR><TT>comment='This cache file was created with a config file'</TT>&nbsp;
<BR><TT>pcap=sample.pcap</TT>&nbsp;
<BR>&nbsp;
<BR><TT>[TCPREWRITE]</TT>&nbsp;
<BR><TT>infile=sample.pcap</TT>&nbsp;
<BR><TT>outfile=newsample.pcap</TT>&nbsp;
<BR><TT>vlan=add</TT>&nbsp;
<BR><TT>vlan-tag=44</TT>&nbsp;
<BR><TT>endpoints=10.0.0.1:10.0.1.1</TT>

<P>
------END CONFIG FILE-------

<P>

<H1><A NAME="SECTION000100000000000000000">
Flowreplay Usage</A>
</H1>

<P>
While tcpreplay is a great way to test NIDS and firewalls, it can't
be used to test servers or HIDS since tcpreplay can't connect to a
service running on a device. The solution to this problem is flowreplay
which instead of sending packets at Layer 2 (ethernet header and up),
it can actually connect via TCP or UDP to server and then sends and
receives data based upon a pcap capture file created with a tool like
Ethereal or tcpdump.

<P>
Please note that flowreplay is currently alpha quality and is missing
a number of key features.

<P>

<H2><A NAME="SECTION000101000000000000000">
How flowreplay works</A>
</H2>

<P>
Put simply, flowreplay opens a socket connection to a service on a
target system(s) and sends data over that socket based on the packet
capture. Flowreplay has no understanding of the application protocol
(like HTTP or FTP) so it is somewhat limited in how it can deal with
complicated exchanges between client and server. 

<P>
Some of these limitations are:

<P>

<UL>
<LI>Flowreplay only plays the client side<A NAME="tex2html10"
  HREF="#foot455"><SUP><SPAN CLASS="arabic">10</SPAN></SUP></A> of the connection.
</LI>
<LI>Flowreplay doesn't understand the application protocols. Hence it
can't always deal with the case when the server sends a different
response then what was originally captured in the pcap file.
</LI>
<LI>Flowreplay only sends TCP and UDP traffic.
</LI>
<LI>Flowreplay doesn't know about multi-flow protocols like FTP.
</LI>
<LI>Flowreplay can't listen on a port and wait for a client to connect
to it.
</LI>
</UL>

<P>

<H2><A NAME="SECTION000102000000000000000">
Running flowreplay</A>
</H2>

<P>
See the flowreplay(8) man page for details.

<P>

<H1><A NAME="SECTION000110000000000000000">
Tuning OS's for high performance</A>
</H1>

<P>
Regardless of the size of physical memory, UNIX kernels will only
allocate a static amount for network buffers. This includes packets
sent via the &#34;raw&#34; interface, like with tcpreplay.
Most kernels will allow you to tweak the size of these buffers, drastically
increasing performance and accuracy.

<P>
N<SMALL>OTE:</SMALL> The following information is provided based upon our
own experiences or the reported experiences of others. Depending on
your hardware and specific hardware, it may or may not work for you.
It may even make your system horribly unstable, corrupt your harddrive,
or worse.

<P>
N<SMALL>OTE</SMALL>: Different operating systems, network card drivers,
and even hardware can have an effect on the accuracy of packet timestamps
that tcpdump or other capture utilities generate. And as you know:
garbage in, garbage out.

<P>
N<SMALL>OTE:</SMALL> If you have information on tuning the kernel of an
operating system not listed here, please send it to me so I can include
it.

<P>

<H2><A NAME="SECTION000111000000000000000">
Linux 2.4.x</A>
</H2>

<P>
The following is known to apply to the 2.4.x series of kernels. If
anyone has any information regarding other kernel versions, please
let us know. By default Linux's tcpreplay performance isn't all that
stellar. However, with a simple tweak, relatively decent performance
can be had on the right hardware. By default, Linux specifies a 64K
buffer for sending packets. Increasing this buffer to about half a
megabyte does a good job:

<P>
<SPAN  CLASS="textit">echo 524287 &gt;/proc/sys/net/core/wmem_default </SPAN>
<BR><SPAN  CLASS="textit">echo 524287 &gt;/proc/sys/net/core/wmem_max </SPAN>
<BR><SPAN  CLASS="textit">echo 524287 &gt;/proc/sys/net/core/rmem_max </SPAN>
<BR><SPAN  CLASS="textit">echo 524287 &gt;/proc/sys/net/core/rmem_default </SPAN>

<P>
On one system, we've seen a jump from 23.02 megabits/sec (5560 packets/sec)
to 220.30 megabits/sec (53212 packets/sec) which is nearly a 10x increase
in performance. Depending on your system and capture file, different
numbers may provide different results.

<P>

<H2><A NAME="SECTION000112000000000000000">
*BSD</A>
</H2>

<P>
*BSD systems typically allow you to specify the size of network
buffers with the NMBCLUSTERS option in the kernel config file. Experiment
with different sizes to see which yields the best performance. See
the options(4) man page for more details.

<P>

<H1><A NAME="SECTION000120000000000000000">
Required Libraries and Tools</A>
</H1>

<P>

<H2><A NAME="SECTION000121000000000000000">
Libpcap</A>
</H2>

<P>
As of tcpreplay v1.4, you'll need to have libpcap installed on your
system. As of v2.0, you'll need at least version 0.6.0 or better,
but I only test our code with the latest version. Libpcap can be obtained
on the tcpdump homepage<A NAME="tex2html11"
  HREF="#foot518"><SUP><SPAN CLASS="arabic">11</SPAN></SUP></A>. 

<P>

<H2><A NAME="SECTION000122000000000000000">
Libnet</A>
</H2>

<P>
Tcpreplay v1.3 is the last version to support the old libnet API (everything
before 1.1.x). As of v1.4 you will need to use Libnet 1.1.0 or better
which can be obtained from the Libnet homepage<A NAME="tex2html12"
  HREF="#foot519"><SUP><SPAN CLASS="arabic">12</SPAN></SUP></A>. 

<P>

<H2><A NAME="SECTION000123000000000000000">
Tcpdump</A>
</H2>

<P>
As of 2.0, tcpreplay uses tcpdump (the binary, not code) to decode
packets to STDOUT in a human readable (with practice) format as it
sends them. If you would like this feature, tcpdump must be installed
on your system.

<P>
N<SMALL>OTE:</SMALL> The location of the tcpdump binary is hardcoded in
tcpreplay at compile time. If tcpdump gets renamed or moved, the feature
will become disabled.

<P>
<BR><HR><H4>Footnotes</H4>
<DL>
<DT><A NAME="foot56">... Libnet</A><A
 HREF="manual.html#tex2html1"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A></DT>
<DD>http://www.packetfactory.net/libnet/

</DD>
<DT><A NAME="foot57">... Libpcap</A><A
 HREF="manual.html#tex2html2"><SUP><SPAN CLASS="arabic">2</SPAN></SUP></A></DT>
<DD>http://www.tcpdump.org/

</DD>
<DT><A NAME="foot58">... tcpdump</A><A
 HREF="manual.html#tex2html3"><SUP><SPAN CLASS="arabic">3</SPAN></SUP></A></DT>
<DD>http://www.tcpdump.org/

</DD>
<DT><A NAME="foot507">...
captured</A><A
 HREF="manual.html#tex2html4"><SUP><SPAN CLASS="arabic">4</SPAN></SUP></A></DT>
<DD>Tcpreplay makes a &#34;best&#34; effort to replay traffic
at the given rate, but due to limitations in hardware or the pcap
file itself, it may not be possible. Capture files with only a few
packets in them are especially susceptible to inaccurately timing
packets.

</DD>
<DT><A NAME="foot118">... times</A><A
 HREF="manual.html#tex2html5"><SUP><SPAN CLASS="arabic">5</SPAN></SUP></A></DT>
<DD>Looping files resets internal counters which control the speed that
the file is replayed. Also because the file has to be closed and re-opened,
an added delay between the last and first packet may occur.

</DD>
<DT><A NAME="foot182">... interface</A><A
 HREF="manual.html#tex2html6"><SUP><SPAN CLASS="arabic">6</SPAN></SUP></A></DT>
<DD>Note that you can also use the following options to split traffic
into two files using -w and -W which are described later on in this
FAQ.

</DD>
<DT><A NAME="foot184">... cachefile</A><A
 HREF="manual.html#tex2html7"><SUP><SPAN CLASS="arabic">7</SPAN></SUP></A></DT>
<DD>For information on generating tcpprep cache files, see the section
on tcpprep.

</DD>
<DT><A NAME="foot208">... -x</A><A
 HREF="manual.html#tex2html8"><SUP><SPAN CLASS="arabic">8</SPAN></SUP></A></DT>
<DD>Note that if you want to send all the packets which do not match a
bpf filter, all you have to do is negate the bpf filter. See the tcpdump(1)
man page for more info.

</DD>
<DT><A NAME="foot277">... libpcap</A><A
 HREF="manual.html#tex2html9"><SUP><SPAN CLASS="arabic">9</SPAN></SUP></A></DT>
<DD>Note that some versions of tcpreplay prior to 1.4 also supported the
Solaris snoop format.

</DD>
<DT><A NAME="foot455">... side</A><A
 HREF="manual.html#tex2html10"><SUP><SPAN CLASS="arabic">10</SPAN></SUP></A></DT>
<DD>Flowreplay assumes the first UDP packet on a given 4-tuple is the
client

</DD>
<DT><A NAME="foot518">... homepage</A><A
 HREF="manual.html#tex2html11"><SUP><SPAN CLASS="arabic">11</SPAN></SUP></A></DT>
<DD>http://www.tcpdump.org/

</DD>
<DT><A NAME="foot519">... homepage</A><A
 HREF="manual.html#tex2html12"><SUP><SPAN CLASS="arabic">12</SPAN></SUP></A></DT>
<DD>http://www.packetfactory.net/Projects/Libnet/

</DD>
</DL>
<BR><HR>
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"></A>

<UL CLASS="ChildLinks">
<LI><UL>
<LI><UL>
<LI><A NAME="tex2html15"
  HREF="manual.html#SECTION00010000000000000000">Notice</A>
<LI><A NAME="tex2html16"
  HREF="manual.html#SECTION00020000000000000000">Overview</A>
<UL>
<LI><A NAME="tex2html17"
  HREF="manual.html#SECTION00021000000000000000">Using this manual</A>
<LI><A NAME="tex2html18"
  HREF="manual.html#SECTION00022000000000000000">Getting Help</A>
<LI><A NAME="tex2html19"
  HREF="manual.html#SECTION00023000000000000000">Corrections and additions to the manual</A>
</UL>
<LI><A NAME="tex2html20"
  HREF="manual.html#SECTION00030000000000000000">Getting Tcpreplay working on your system</A>
<UL>
<LI><A NAME="tex2html21"
  HREF="manual.html#SECTION00031000000000000000">Getting the source code</A>
<LI><A NAME="tex2html22"
  HREF="manual.html#SECTION00032000000000000000">Requirements</A>
<LI><A NAME="tex2html23"
  HREF="manual.html#SECTION00033000000000000000">Compiling Tcpreplay</A>
</UL>
<LI><A NAME="tex2html24"
  HREF="manual.html#SECTION00040000000000000000">Basic Tcpreplay Usage</A>
<UL>
<LI><A NAME="tex2html25"
  HREF="manual.html#SECTION00041000000000000000">Replaying the traffic</A>
<LI><A NAME="tex2html26"
  HREF="manual.html#SECTION00042000000000000000">Replaying at different speeds</A>
<LI><A NAME="tex2html27"
  HREF="manual.html#SECTION00043000000000000000">Replaying files multiple times</A>
</UL>
<LI><A NAME="tex2html28"
  HREF="manual.html#SECTION00050000000000000000">Editing Packets</A>
<LI><A NAME="tex2html29"
  HREF="manual.html#SECTION00060000000000000000">Splitting Traffic</A>
<UL>
<LI><A NAME="tex2html30"
  HREF="manual.html#SECTION00061000000000000000">Classifying client and servers with tcpprep</A>
<LI><A NAME="tex2html31"
  HREF="manual.html#SECTION00062000000000000000">Replaying on multiple interfaces</A>
<LI><A NAME="tex2html32"
  HREF="manual.html#SECTION00063000000000000000">Selectively sending or dropping packets</A>
<LI><A NAME="tex2html33"
  HREF="manual.html#SECTION00064000000000000000">Replaying only a few packets</A>
<LI><A NAME="tex2html34"
  HREF="manual.html#SECTION00065000000000000000">Skipping the first bytes in a pcap file</A>
<LI><A NAME="tex2html35"
  HREF="manual.html#SECTION00066000000000000000">Replaying packets which are bigger then the MTU</A>
<LI><A NAME="tex2html36"
  HREF="manual.html#SECTION00067000000000000000">Writing packets to a file</A>
<LI><A NAME="tex2html37"
  HREF="manual.html#SECTION00068000000000000000">Extracting Application Data (Layer 7)</A>
<LI><A NAME="tex2html38"
  HREF="manual.html#SECTION00069000000000000000">Replaying Live Traffic</A>
<LI><A NAME="tex2html39"
  HREF="manual.html#SECTION000610000000000000000">Replaying Packet Capture Formats Other Than Libpcap</A>
<LI><A NAME="tex2html40"
  HREF="manual.html#SECTION000611000000000000000">Replaying Client Traffic to a Server</A>
<LI><A NAME="tex2html41"
  HREF="manual.html#SECTION000612000000000000000">Decoding Packets</A>
</UL>
<LI><A NAME="tex2html42"
  HREF="manual.html#SECTION00070000000000000000">Packet Editing</A>
<UL>
<LI><A NAME="tex2html43"
  HREF="manual.html#SECTION00071000000000000000">Rewriting MAC addresses</A>
<LI><A NAME="tex2html44"
  HREF="manual.html#SECTION00072000000000000000">Randomizing IP addresses</A>
<LI><A NAME="tex2html45"
  HREF="manual.html#SECTION00073000000000000000">Replaying (de)truncated packets</A>
<LI><A NAME="tex2html46"
  HREF="manual.html#SECTION00074000000000000000">Rewriting Layer 2 with -2</A>
<LI><A NAME="tex2html47"
  HREF="manual.html#SECTION00075000000000000000">Rewriting DLT_LINUX_SLL (Linux Cooked Socket) captures</A>
<LI><A NAME="tex2html48"
  HREF="manual.html#SECTION00076000000000000000">Rewriting IP Addresses (pseudo-NAT)</A>
<LI><A NAME="tex2html49"
  HREF="manual.html#SECTION00077000000000000000">Advanced pseudo-NAT</A>
<LI><A NAME="tex2html50"
  HREF="manual.html#SECTION00078000000000000000">IP Endpoints</A>
<LI><A NAME="tex2html51"
  HREF="manual.html#SECTION00079000000000000000">Unifying Dual-Outputs</A>
</UL>
<LI><A NAME="tex2html52"
  HREF="manual.html#SECTION00080000000000000000">Tcpprep Usage</A>
<UL>
<LI><A NAME="tex2html53"
  HREF="manual.html#SECTION00081000000000000000">What is tcpprep?</A>
<LI><A NAME="tex2html54"
  HREF="manual.html#SECTION00082000000000000000">What are these 'modes' tcpprep has? </A>
<LI><A NAME="tex2html55"
  HREF="manual.html#SECTION00083000000000000000">Splitting traffic based upon IP address</A>
<LI><A NAME="tex2html56"
  HREF="manual.html#SECTION00084000000000000000">Auto Mode</A>
<LI><A NAME="tex2html57"
  HREF="manual.html#SECTION00085000000000000000">Selectively sending/dropping packets</A>
<LI><A NAME="tex2html58"
  HREF="manual.html#SECTION00086000000000000000">Using tcpprep cache files with tcpreplay</A>
<LI><A NAME="tex2html59"
  HREF="manual.html#SECTION00087000000000000000">Commenting tcpprep cache files</A>
</UL>
<LI><A NAME="tex2html60"
  HREF="manual.html#SECTION00090000000000000000">Using Configuration Files</A>
<LI><A NAME="tex2html61"
  HREF="manual.html#SECTION000100000000000000000">Flowreplay Usage</A>
<UL>
<LI><A NAME="tex2html62"
  HREF="manual.html#SECTION000101000000000000000">How flowreplay works</A>
<LI><A NAME="tex2html63"
  HREF="manual.html#SECTION000102000000000000000">Running flowreplay</A>
</UL>
<LI><A NAME="tex2html64"
  HREF="manual.html#SECTION000110000000000000000">Tuning OS's for high performance</A>
<UL>
<LI><A NAME="tex2html65"
  HREF="manual.html#SECTION000111000000000000000">Linux 2.4.x</A>
<LI><A NAME="tex2html66"
  HREF="manual.html#SECTION000112000000000000000">*BSD</A>
</UL>
<LI><A NAME="tex2html67"
  HREF="manual.html#SECTION000120000000000000000">Required Libraries and Tools</A>
<UL>
<LI><A NAME="tex2html68"
  HREF="manual.html#SECTION000121000000000000000">Libpcap</A>
<LI><A NAME="tex2html69"
  HREF="manual.html#SECTION000122000000000000000">Libnet</A>
<LI><A NAME="tex2html70"
  HREF="manual.html#SECTION000123000000000000000">Tcpdump</A>
</UL>
</UL>
</UL>
<BR>
<LI><A NAME="tex2html71"
  HREF="node1.html">Other Resources</A>
<UL>
<LI><A NAME="tex2html72"
  HREF="node1.html#SECTION01010000000000000000">Other pcap tools available</A>
<UL>
<LI><A NAME="tex2html73"
  HREF="node1.html#SECTION01011000000000000000">Tools to capture network traffic or decode pcap files</A>
<LI><A NAME="tex2html74"
  HREF="node1.html#SECTION01012000000000000000">Tools to edit pcap files</A>
<LI><A NAME="tex2html75"
  HREF="node1.html#SECTION01013000000000000000">Other useful tools</A>
</UL></UL></UL>
<!--End of Table of Child-Links-->

<DIV CLASS="navigation"><HR>
<!--Navigation Panel-->
<A NAME="tex2html13"
  HREF="node1.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A> 
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_g.png"> 
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev_g.png">   
<BR>
<B> Next:</B> <A NAME="tex2html14"
  HREF="node1.html">Other Resources</A></DIV>
<!--End of Navigation Panel-->
<ADDRESS>
Aaron Turner
2005-06-28
</ADDRESS>
</BODY>
</HTML>