| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971197219731974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025202620272028202920302031203220332034203520362037203820392040204120422043204420452046204720482049205020512052205320542055205620572058205920602061 | 
							- <!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 <tcpreplay-users@lists.sourceforge.net>
 
- 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>$ svn checkout https://www.synfin.net:444/svn/tcpreplay/trunk 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> ./configure && make <SPAN  CLASS="textit"></SPAN>
 
- <P>
 
- <SPAN  CLASS="textit">#</SPAN> make 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># <SPAN  CLASS="textit">make test -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># tcpreplay -intf1=eth0 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># tcpreplay -topspeed -intf1=eth0 sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>To replay traffic at a rate of 10Mbps:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD># tcpreplay -mbps=10.0 -intf1=eth0 sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>To replay traffic 7.3 times as fast as it was captured:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD># tcpreplay -multiplier=7.3 -intf1=eth0 sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>To replay traffic at half-speed:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD># tcpreplay -multiplier=0.5 -intf1=eth0 sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>To replay at 25 packets per second:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD># tcpreplay -pps=25 -intf1=eth0 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># tcpreplay -loop=10 -intf1=eth0 sample.pcap
 
- </DD>
 
- </DL>To replay the sample.pcap an infinitely or until CTRL-C is pressed:
 
- <P>
 
- <DL COMPACT>
 
- <DT>
 
- <DD># tcpreplay -loop=0 -intf1=eth0 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>
 
-    
 
- <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> tcpprep -auto=bridge -pcap=input.pcap -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> tcpprep -auto=bridge -ratio=3.5 -pcap=input.pcap -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 -C 10.0.0.0/8 -intf1=eth0 -intf2=eth1 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 -C 10.1.0.0/24,10.2.0.0/20 -intf1=eth0 -intf2=eth1 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 -c sample.cache -intf1=eth0 -intf2=eth1 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 -x B:10.0.0.0/8 -intf1 eth0 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 -X E:10.0.0.0/8 -intf1 eth0 sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>To send every packet except the first 10 packets:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpreplay -X P:1-10 -intf1 eth0 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 -x P:1-50,100,150,200,250 -intf1 eth0 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 -x F:'tcp and host 10.0.0.1' -intf1 eth0 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 -intf1 eth0 -L 100 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 -intf1=eth0 -o 15000 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 -intf1 eth0 -T 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 -intf1 eth0 -w output.pcap -F -u pad -x E:10.0.0.0/8 input1.pcap input2.pcap 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 <2nd output
 
- file>.
 
- <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 -D -intf1 eth0 -j eth0 -w clientdata -W serverdata -C 10.0.0.0/24 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 -intf1 eth1 -S 0 eth0
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>Bridge two subnets connected to eth0 and eth1:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpreplay -intf1 eth0 -intf2=eth1 -b -S 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 -r blah.snoop -w 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 -intf1 eth0 -v sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>Decode packets with the link level header:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpreplay -intf1 eth0 -v -A ``-e'' sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>Fully decode and send one packet at a time:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpreplay -intf1 eth0 -v -1 -A ``-s0 -evvvxX'' 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 -intf1=eth0 -I 00:00:01:02:03:04 -k 00:20:30:40:50:60 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 -intf1=eth0 -intf2=eth1 -I 00:01:00:00:AA:01 -J 00:01:00:00:AA:02 -C 10.0.0.0/24 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 -intf1=eth0 -s 1239 sample.pcap &</SPAN> 
 
- <BR><SPAN  CLASS="textit">tcpreplay -intf1=eth0 -s 76 sample.pcap &</SPAN> 
 
- <BR><SPAN  CLASS="textit">tcpreplay -intf1=eth0 -s 239 sample.pcap &</SPAN> 
 
- <BR><SPAN  CLASS="textit">tcpreplay -intf1=eth0 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 -intf1=eth0 -u pad sample.pcap
 
- </DD>
 
- </DL>
 
- <UL>
 
- <LI>Rewrite packet header lengths to the actual packet size:
 
- </LI>
 
- </UL>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpreplay -intf1=eth0 -u trunc 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
 
- <srcnet>/<masklen>:<dstnet>/<masklen> 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 <Table1> -N <Table2>) 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"> </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 -intf1=eth0 -intf2=eth1 -c sample.cache -e 10.0.0.1:10.1.1.1 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 -intf1=eth0 -intf2=eth1 -c sample.cache -N 0.0.0.0/0:10.0.0.1 -N 0.0.0.0/0:10.1.1.1 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 -intf1=eth0 -j eth0 -O -c sample.cache -e 10.0.0.1:10.1.1.1 sample.pcap
 
- </DD>
 
- </DL>Merging the output to a single file:
 
- <P>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpreplay -intf1=eth0 -j eth0 -w rewrite.pcap -c sample.cache -e 10.0.0.1:10.1.1.1 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 <file>.
 
- </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 -cachefile sample.cache -intf1=eth0 -intf2=eth1 sample.pcap
 
- </DD>
 
- </DL>
 
- <P>
 
- <H2><A NAME="SECTION00087000000000000000">
 
- Commenting tcpprep cache files</A>
 
- </H2>
 
- <P>
 
- In versions of tcpprep >= 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 -comment ``this is my comment'' -pcap sample.pcap -cachefile sample.cache <other args>
 
- </DD>
 
- </DL>Or for no user comment, but still embed the command arguments:
 
- <P>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpprep -comment ``'' -pcap sample.pcap -cachefile sample.cache <other args>
 
- </DD>
 
- </DL>You can then later on print out the comments by running:
 
- <P>
 
- <DL COMPACT>
 
- <DT>
 
- <DD>tcpprep -print-comment 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=<filename>
 
- 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> 
 
- <BR><TT>intf1 eth0</TT> 
 
- <BR> 
 
- <BR><TT># loop 5 times</TT> 
 
- <BR><TT>loop 5</TT> 
 
- <BR> 
 
- <BR><TT># send traffic 2x as fast</TT> 
 
- <BR><TT>multiplier 2</TT>
 
- <BR>-------END CONFIG FILE--------
 
- <P>
 
- You would then execute:
 
- <P>
 
- <DL COMPACT>
 
- <DT>
 
- <DD># tcpreplay -load-opts=myconfigfile 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> 
 
- <BR> 
 
- <BR><TT>[TCPREPLAY]</TT> 
 
- <BR><TT>intf1 eth0</TT> 
 
- <BR><TT>intf2 eth1</TT> 
 
- <BR><TT>topspeed </TT> 
 
- <BR> 
 
- <BR><TT>[TCPPREP]</TT> 
 
- <BR><TT>auto=bridge</TT> 
 
- <BR><TT>comment='This cache file was created with a config file'</TT> 
 
- <BR><TT>pcap=sample.pcap</TT> 
 
- <BR> 
 
- <BR><TT>[TCPREWRITE]</TT> 
 
- <BR><TT>infile=sample.pcap</TT> 
 
- <BR><TT>outfile=newsample.pcap</TT> 
 
- <BR><TT>vlan=add</TT> 
 
- <BR><TT>vlan-tag=44</TT> 
 
- <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 "raw" 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 >/proc/sys/net/core/wmem_default </SPAN>
 
- <BR><SPAN  CLASS="textit">echo 524287 >/proc/sys/net/core/wmem_max </SPAN>
 
- <BR><SPAN  CLASS="textit">echo 524287 >/proc/sys/net/core/rmem_max </SPAN>
 
- <BR><SPAN  CLASS="textit">echo 524287 >/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 "best" 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>
 
 
  |