manual.html 60 KB

  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  2. <!--Converted with LaTeX2HTML 2002-2-1 (1.70)
  3. original version by: Nikos Drakos, CBLU, University of Leeds
  4. * revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
  5. * with significant contributions from:
  6. Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
  7. <HTML>
  8. <HEAD>
  9. <TITLE>Tcpreplay 3.x Manual (BETA)</TITLE>
  10. <META NAME="description" CONTENT="Tcpreplay 3.x Manual (BETA)">
  11. <META NAME="keywords" CONTENT="manual">
  12. <META NAME="resource-type" CONTENT="document">
  13. <META NAME="distribution" CONTENT="global">
  14. <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
  15. <META NAME="Generator" CONTENT="LaTeX2HTML v2002-2-1">
  16. <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
  17. <LINK REL="STYLESHEET" HREF="manual.css">
  18. <LINK REL="next" HREF="node1.html">
  19. </HEAD>
  20. <BODY >
  21. <DIV CLASS="navigation"><!--Navigation Panel-->
  22. <A NAME="tex2html13"
  23. HREF="node1.html">
  24. <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
  25. <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_g.png">
  26. <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev_g.png">
  27. <BR>
  28. <B> Next:</B> <A NAME="tex2html14"
  29. HREF="node1.html">Other Resources</A>
  30. <BR>
  31. <BR></DIV>
  32. <!--End of Navigation Panel-->
  33. <P>
  34. <P>
  35. <P>
  36. <H1 ALIGN="CENTER">Tcpreplay 3.x Manual (BETA)</H1>
  37. <DIV CLASS="author_info">
  38. <P ALIGN="CENTER"><STRONG>Aaron Turner</STRONG></P>
  39. <P ALIGN="CENTER"><I></I></P>
  40. </DIV>
  41. <P>
  42. <H1><A NAME="SECTION00010000000000000000">
  43. Notice</A>
  44. </H1>
  45. <P>
  46. This document is still in the process of being re-written due to the
  47. significant CLI and configuration file changes between versions 2.x
  48. and 3.x. For the definative source of configuration options, please
  49. see the tcpprep, tcprewrite, tcpreplay and tcpbridge man pages.
  50. <P>
  51. <H1><A NAME="SECTION00020000000000000000">
  52. Overview</A>
  53. </H1>
  54. <P>
  55. Tcpreplay is a suite of utilities for UNIX systems for editing and
  56. replaying network traffic which was previously captured by tools like
  57. tcpdump and ethereal. The goal of tcpreplay is to provide the means
  58. for providing reliable and repeatible means for testing a variety
  59. of network devices such as switches, router, firewalls, network intrusion
  60. detection and prevention systems (IDS and IPS).
  61. <P>
  62. Tcpreplay provides the ability to classify traffic as client or server,
  63. edit packets at layers 2-4 and replay the traffic at arbitrary speeds
  64. onto a network for sniffing or through a device.
  65. <P>
  66. Some of the advantages of using tcpreplay over using ``exploit
  67. code'' are:
  68. <P>
  69. <UL>
  70. <LI>Since tcpreplay emulates the victim and the attacker, you generally
  71. only need a tcpreplay box and the device under test (DUT)
  72. </LI>
  73. <LI>Tests can include background traffic of entire networks without the
  74. cost and effort of setting up dozens of hosts or costly emulators
  75. </LI>
  76. <LI>No need to have a ``victim'' host which needs to have the appropriate
  77. software installed, properly configured and rebuilt after compromise
  78. </LI>
  79. <LI>Less chance that a virus or trojan might escape your network and wreak
  80. havoc on your systems
  81. </LI>
  82. <LI>Uses the open standard pcap file format for which dozens of command
  83. line and GUI utilities exist
  84. </LI>
  85. <LI>Tests are fully repeatable without a complex test harnesses or network
  86. configuration
  87. </LI>
  88. <LI>Tests can be replayed at arbitrary speeds
  89. </LI>
  90. <LI>Single command-line interface to learn and integrate into test harness
  91. </LI>
  92. <LI>You only need to audit tcpreplay, rather then each and every exploit
  93. individually
  94. </LI>
  95. <LI>Actively developed and supported by it's author
  96. </LI>
  97. </UL>
  98. <P>
  99. <H2><A NAME="SECTION00021000000000000000">
  100. Using this manual</A>
  101. </H2>
  102. <P>
  103. The goal of this manual is to provide an idea of what tcpreplay and
  104. it's utilities can do. It is not however intended to be a complete
  105. document which covers every possible use case or situation. It is
  106. also very much a work in progress and is far from complete and has
  107. numerous errors since a lot of things have changed since tcpreplay
  108. 2.x. It is expected that most of these issues will be ironed out before
  109. the offical 3.0 release is made. You should keep in mind the following
  110. conventions when reading this document:
  111. <P>
  112. <UL>
  113. <LI>Commands you should run from the command line <TT>are in monotype</TT>.
  114. </LI>
  115. <LI>Commands that should be run as root will have a '#' in front of them.
  116. </LI>
  117. <LI>Commands that should be run as an unprivelged user will have a '$'
  118. in front of them.
  119. </LI>
  120. <LI>Text that should be placed in a file <TT>is in monospace.</TT>
  121. </LI>
  122. </UL>
  123. All of the applications shipped with tcpreplay support both short
  124. (a single dash followed by a single character) and long (two dashes
  125. followed by multiple characters) arguments. For consistancy, this
  126. document uses the long option format. Please review the man pages
  127. for the short argument equivalents.
  128. <P>
  129. <H2><A NAME="SECTION00022000000000000000">
  130. Getting Help</A>
  131. </H2>
  132. <P>
  133. If you still have a question after reading the Tcpreplay manual, man
  134. pages and FAQ, please contact the Tcpreplay-Users &lt;;
  135. mailing list. Note that if you ask a question which has clearly been
  136. covered in either the manual or FAQ, you will most likely be told
  137. to RTFM. Also, please try to explain your problem in detail. It is
  138. very difficult and fustrating to get requests from people seeking
  139. help who only provide vague and incomplete information.
  140. <P>
  141. <H2><A NAME="SECTION00023000000000000000">
  142. Corrections and additions to the manual</A>
  143. </H2>
  144. <P>
  145. I've tried to keep this document up to date with the changes in tcpreplay,
  146. but occasionally I get too busy, make a mistake or just forget something.
  147. If you find anything in this document which could be improved upon,
  148. please let me know.
  149. <P>
  150. <H1><A NAME="SECTION00030000000000000000">
  151. Getting Tcpreplay working on your system</A>
  152. </H1>
  153. <P>
  154. <H2><A NAME="SECTION00031000000000000000">
  155. Getting the source code</A>
  156. </H2>
  157. <P>
  158. The source code is available as a tarball on the tcpreplay homepage:
  159. I also encourage users familiar
  160. with Subversion to try checking out the latest code as it often has
  161. additional features and bugfixes not yet found in the offical releases.
  162. <P>
  163. <DL COMPACT>
  164. <DT>
  165. <DD>$&nbsp;svn&nbsp;checkout&nbsp;;tcpreplay
  166. </DD>
  167. </DL>
  168. <P>
  169. <H2><A NAME="SECTION00032000000000000000">
  170. Requirements</A>
  171. </H2>
  172. <P>
  173. <OL>
  174. <LI>Libnet<A NAME="tex2html1"
  175. 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)
  176. </LI>
  177. <LI>Libpcap<A NAME="tex2html2"
  178. HREF="#foot57"><SUP><SPAN CLASS="arabic">2</SPAN></SUP></A> 0.6.x or better (0.8.3 or better recommended)
  179. </LI>
  180. <LI>To support the packet decoding feature you'll need tcpdump<A NAME="tex2html3"
  181. HREF="#foot58"><SUP><SPAN CLASS="arabic">3</SPAN></SUP></A> binary installed.
  182. </LI>
  183. <LI>You'll also need a compatible operating system. Basically, any *NIX
  184. operating system should work. Linux, *BSD, Solaris, OS X and others
  185. should all work. If you find any compatibility issues with any *NIX
  186. OS, please let me know.
  187. </LI>
  188. </OL>
  189. <P>
  190. <H2><A NAME="SECTION00033000000000000000">
  191. Compiling Tcpreplay</A>
  192. </H2>
  193. <P>
  194. Two easy steps:
  195. <P>
  196. <DL COMPACT>
  197. <DT>
  198. <DD><SPAN CLASS="textit">$</SPAN>&nbsp;./configure&nbsp;&amp;&amp;&nbsp;make&nbsp;<SPAN CLASS="textit"></SPAN>
  199. <P>
  200. <SPAN CLASS="textit">#</SPAN>&nbsp;make&nbsp;install
  201. </DD>
  202. </DL>There are some optional arguments which can be passed to the 'configure'
  203. script which may help in cases where your libnet, libpcap or tcpdump
  204. installation is not standard or if it can't determine the correct
  205. network interface card to use for testing. I also recommend that for
  206. beta code you specify <SPAN CLASS="textbf">-enable-debug</SPAN>
  207. to the configure script in case you find any bugs. If you find that
  208. configure isn't completing correctly, run: <SPAN CLASS="textit">./configure -help</SPAN>
  209. for more information.
  210. <P>
  211. You may also choose to run:
  212. <P>
  213. <DL COMPACT>
  214. <DT>
  215. <DD>#&nbsp;<SPAN CLASS="textit">make&nbsp;test&nbsp;-i</SPAN>
  216. </DD>
  217. </DL>
  218. <UL>
  219. <LI>make test is just a series of sanity checks which try to find serious
  220. bugs (crashes) in tcpprep and tcpreplay.
  221. </LI>
  222. <LI>make test requires at least one properly configured network interface.
  223. If the configure script can't guess what a valid interface is you
  224. can specify it with the -with-testnic and -with-testnic2
  225. arguments.
  226. </LI>
  227. <LI>If make test fails, often you can find details in test/test.log.
  228. </LI>
  229. <LI>OpenBSD's make has a bug where it ignores the MAKEFLAGS variable in
  230. the Makefile, hence you'll probably want to run: <SPAN CLASS="textit">make -is test</SPAN>
  231. instead.
  232. </LI>
  233. </UL>
  234. <P>
  235. <H1><A NAME="SECTION00040000000000000000">
  236. Basic Tcpreplay Usage</A>
  237. </H1>
  238. <P>
  239. <H2><A NAME="SECTION00041000000000000000">
  240. Replaying the traffic</A>
  241. </H2>
  242. <P>
  243. To replay a given pcap as it was captured all you need to do is specify
  244. the pcap file and the interface to send the traffic out interface
  245. 'eth0':
  246. <P>
  247. <DL COMPACT>
  248. <DT>
  249. <DD>#&nbsp;tcpreplay&nbsp;-intf1=eth0&nbsp;sample.pcap
  250. </DD>
  251. </DL>
  252. <P>
  253. <H2><A NAME="SECTION00042000000000000000">
  254. Replaying at different speeds</A>
  255. </H2>
  256. <P>
  257. You can also replay the traffic at different speeds then it was originally
  258. captured<A NAME="tex2html4"
  259. HREF="#foot507"><SUP><SPAN CLASS="arabic">4</SPAN></SUP></A>.
  260. <P>
  261. Some examples:
  262. <P>
  263. <UL>
  264. <LI>To replay traffic as quickly as possible:
  265. </LI>
  266. </UL>
  267. <DL COMPACT>
  268. <DT>
  269. <DD>#&nbsp;tcpreplay&nbsp;-topspeed&nbsp;-intf1=eth0&nbsp;sample.pcap
  270. </DD>
  271. </DL>
  272. <UL>
  273. <LI>To replay traffic at a rate of 10Mbps:
  274. </LI>
  275. </UL>
  276. <DL COMPACT>
  277. <DT>
  278. <DD>#&nbsp;tcpreplay&nbsp;-mbps=10.0&nbsp;-intf1=eth0&nbsp;sample.pcap
  279. </DD>
  280. </DL>
  281. <UL>
  282. <LI>To replay traffic 7.3 times as fast as it was captured:
  283. </LI>
  284. </UL>
  285. <DL COMPACT>
  286. <DT>
  287. <DD>#&nbsp;tcpreplay&nbsp;-multiplier=7.3&nbsp;-intf1=eth0&nbsp;sample.pcap
  288. </DD>
  289. </DL>
  290. <UL>
  291. <LI>To replay traffic at half-speed:
  292. </LI>
  293. </UL>
  294. <DL COMPACT>
  295. <DT>
  296. <DD>#&nbsp;tcpreplay&nbsp;-multiplier=0.5&nbsp;-intf1=eth0&nbsp;sample.pcap
  297. </DD>
  298. </DL>
  299. <UL>
  300. <LI>To replay at 25 packets per second:
  301. </LI>
  302. </UL>
  303. <DL COMPACT>
  304. <DT>
  305. <DD>#&nbsp;tcpreplay&nbsp;-pps=25&nbsp;-intf1=eth0&nbsp;sample.pcap
  306. </DD>
  307. </DL>
  308. <P>
  309. <H2><A NAME="SECTION00043000000000000000">
  310. Replaying files multiple times</A>
  311. </H2>
  312. <P>
  313. Using the loop flag you can specify that a pcap file will be sent
  314. two or more times<A NAME="tex2html5"
  315. HREF="#foot118"><SUP><SPAN CLASS="arabic">5</SPAN></SUP></A>:
  316. <P>
  317. To replay the sample.pcap file 10 times:
  318. <P>
  319. <DL COMPACT>
  320. <DT>
  321. <DD>#&nbsp;tcpreplay&nbsp;-loop=10&nbsp;-intf1=eth0&nbsp;sample.pcap
  322. </DD>
  323. </DL>To replay the sample.pcap an infinitely or until CTRL-C is pressed:
  324. <P>
  325. <DL COMPACT>
  326. <DT>
  327. <DD>#&nbsp;tcpreplay&nbsp;-loop=0&nbsp;-intf1=eth0&nbsp;sample.pcap
  328. </DD>
  329. </DL>
  330. <P>
  331. <H1><A NAME="SECTION00050000000000000000">
  332. Editing Packets</A>
  333. </H1>
  334. <P>
  335. There are a number of ways you can edit packets stored in a pcap file:
  336. <P>
  337. <OL>
  338. <LI>Rewriting IP addresses so that they appear to be sent from and to
  339. different hosts
  340. </LI>
  341. <LI>Fixing corrupted packets which were truncated by tcpdump or had bad
  342. checksums
  343. </LI>
  344. <LI>Adding, removing or changing 802.1q VLAN tags on frames
  345. </LI>
  346. <LI>Rewriting traffic so that it no longer uses ``standard'' TCP or
  347. UDP ports for the given service
  348. </LI>
  349. <LI>Changing ethernet MAC addresses so that packets will be accepted by
  350. a router or firewall
  351. </LI>
  352. </OL>
  353. <P>
  354. <H1><A NAME="SECTION00060000000000000000">
  355. Splitting Traffic</A>
  356. </H1>
  357. <P>
  358. Anything other then just replaying packets at different speeds requires
  359. additional work and CPU cycles. While older versions of tcpreplay
  360. allowed you to do many of these calculations while replaying traffic,
  361. it had a negative effect on the overall throughput and performance
  362. of tcpreplay. Hence, these secondary features have been placed in
  363. two utilities:
  364. <P>
  365. <UL>
  366. <LI>tcpprep - Used to categorize packets as originating from clients or
  367. servers
  368. </LI>
  369. <LI>tcprewrite - Used to edit packets
  370. </LI>
  371. </UL>
  372. By using tcpprep and tcprewrite on a pcap file before sending it using
  373. tcpreplay, many possibilities open up. A few of these possibilities
  374. are:
  375. <P>
  376. <H2><A NAME="SECTION00061000000000000000">
  377. Classifying client and servers with tcpprep</A>
  378. </H2>
  379. <P>
  380. Both tcpreplay and tcprewrite process a single pcap file and generate
  381. output. Some features, such as rewriting IP or MAC addresses or sending
  382. traffic out two different interfaces, require tcpreplay and tcprewrite
  383. to have some basic knowledge about which packets were sent by ``clients''
  384. and ``servers''. Such classification is often rather arbitrary
  385. since for example a SMTP mail server both accepts inbound email (acts
  386. as a server) and forwards mail to other mail servers (acts as a client).
  387. A webserver might accept inbound HTTP requests, but make client connections
  388. to a SQL server.
  389. <P>
  390. To deal with this problem, tcpreplay comes with tcpprep which provides
  391. a number of manual and automatic classification methods which cover
  392. a variety of situations.
  393. <P>
  394. <H3><A NAME="SECTION00061100000000000000">
  395. Seperating clients and servers automatically</A>
  396. </H3>
  397. <P>
  398. The easiest way to split clients and servers is to let tcpprep do
  399. the classification for you. Tcpprep examines the pcap file for TCP
  400. three-way handshakes, DNS lookups and other types of traffic to figure
  401. out which IP's mostly act like clients and which mostly act like servers.
  402. There are four different automatic modes that you can choose between:
  403. <P>
  404. <OL>
  405. <LI>Bridge - This is the simplest mode. Each IP is individually tracked
  406. and ranked as a client or server. However, if any of the hosts do
  407. not generate enough ``client'' or ``server'' traffic then
  408. tcpprep will abort complaining that it was unable to determine its
  409. classification. This works best when clients and servers are intermixed
  410. on the same subnet.
  411. </LI>
  412. <LI>Client - This works just like bridge mode, except that unknown hosts
  413. will be marked a client.
  414. </LI>
  415. <LI>Server - This works just like bridge mode, except that unknown hosts
  416. will be marked a server.
  417. </LI>
  418. <LI>Router - Hosts are first ranked as client or server. Then each host
  419. is placed in a subnet which is expanded until either all the unknown
  420. hosts are included or the -maxmask is reached. This works best when
  421. clients and servers are on diffierent networks.
  422. </LI>
  423. </OL>
  427. <BR>
  428. S<SMALL>TEP 1:</SMALL> Categorize Clients, Servers and Unknowns</TD>
  429. </TR>
  430. </TABLE>
  431. </DIV>
  432. <P>
  433. &nbsp;&nbsp;&nbsp;
  434. <P>
  437. <TR><TD ALIGN="CENTER">S<SMALL>TEP 3:</SMALL> Unknowns Now Marked as Clients and Servers
  438. <BR></SMALL>
  439. <BR></TD>
  440. </TR>
  441. </TABLE>
  442. </DIV>
  443. <P>
  444. Classifying clients and servers in automatic mode is as easy as choosing
  445. a pcap file, an output ``tcpprep cache file'' and the mode to
  446. use:
  447. <P>
  448. <DL COMPACT>
  449. <DT>
  450. <DD><SPAN CLASS="textit">$</SPAN>&nbsp;tcpprep&nbsp;-auto=bridge&nbsp;-pcap=input.pcap&nbsp;-cachefile=input.cache
  451. </DD>
  452. </DL>The above example would split traffic in bridge mode. Other modes
  453. are ``router'', ``client'' and ``server''. If you wish,
  454. you can override the default 2:1 ratio of server vs. client traffic
  455. required to classify an IP as a server. If for example you wanted
  456. to require 3.5 times as much server to client traffic you would specify
  457. it like:
  458. <P>
  459. <DL COMPACT>
  460. <DT>
  461. <DD><SPAN CLASS="textit">$</SPAN>&nbsp;tcpprep&nbsp;-auto=bridge&nbsp;-ratio=3.5&nbsp;-pcap=input.pcap&nbsp;-cachefile=input.cache
  462. </DD>
  463. </DL>
  464. <P>
  465. <H3><A NAME="SECTION00061200000000000000">
  466. Seperating clients and servers manually by subnet</A>
  467. </H3>
  468. <P>
  469. Sometimes, you may not want to split traffic based on clients and
  470. servers. The alternative to using on of the automatic modes in this
  471. case, is to use one of the manual modes. One manual way of differentiating
  472. between clients and servers using tcpprep is by specifying a list
  473. of networks in CIDR notation which contain ``servers''. Of course
  474. the specified CIDR netblocks don't have to contain
  475. <P>
  476. <H2><A NAME="SECTION00062000000000000000">
  477. Replaying on multiple interfaces</A>
  478. </H2>
  479. <P>
  480. Tcpreplay can also split traffic so that each side of a connection
  481. is sent out a different interface<A NAME="tex2html6"
  482. HREF="#foot182"><SUP><SPAN CLASS="arabic">6</SPAN></SUP></A>. In order to do this, tcpreplay needs the name of the second interface
  483. (-j) and a way to split the traffic. Currently, there are two ways
  484. to split traffic:
  485. <P>
  486. <OL>
  487. <LI>-C = split traffic by source IP address which is specified in CIDR
  488. notation
  489. </LI>
  490. <LI>-c = split traffic according to a tcpprep cachefile<A NAME="tex2html7"
  491. HREF="#foot184"><SUP><SPAN CLASS="arabic">7</SPAN></SUP></A>
  492. </LI>
  493. </OL>
  494. When splitting traffic, it is important to remember that traffic that
  495. matches the filter is sent out the primary interface (-intf1). In
  496. this case, when splitting traffic by source IP address, you provide
  497. a list of networks in CIDR notation. For example:
  498. <P>
  499. <UL>
  500. <LI>To send traffic from out eth0 and everything else out eth1:
  501. </LI>
  502. </UL>
  503. <DL COMPACT>
  504. <DT>
  505. <DD>tcpreplay&nbsp;-C&nbsp;;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
  506. </DD>
  507. </DL>
  508. <UL>
  509. <LI>To send traffic from and out eth0 and everything
  510. else out eth1:
  511. </LI>
  512. </UL>
  513. <DL COMPACT>
  514. <DT>
  515. <DD>tcpreplay&nbsp;-C&nbsp;,;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
  516. </DD>
  517. </DL>
  518. <UL>
  519. <LI>After using tcpprep to generate a cache file, you can use it to split
  520. traffic between two interfaces like this:
  521. </LI>
  522. </UL>
  523. <DL COMPACT>
  524. <DT>
  525. <DD>tcpreplay&nbsp;-c&nbsp;sample.cache&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
  526. </DD>
  527. </DL>
  528. <P>
  529. <H2><A NAME="SECTION00063000000000000000">
  530. Selectively sending or dropping packets</A>
  531. </H2>
  532. <P>
  533. Sometimes, you want to do some post-capture filtering of packets.
  534. Tcpreplay let's you have some control over which packets get sent.
  535. <P>
  536. <OL>
  537. <LI>-M = disables sending of martian packets. By definition, martian packets
  538. have a source IP of 0.x.x.x, 127.x.x.x, or 255.x.x.x
  539. </LI>
  540. <LI>-x = send packets which match a specific pattern
  541. </LI>
  542. <LI>-X = send packets which do not match a specific pattern
  543. </LI>
  544. </OL>
  545. Both -x and -X support a variety of pattern matching types. These
  546. types are specified by a single character, followed by a colon, followed
  547. by the pattern. The following pattern matching types are available:
  548. <P>
  549. <OL>
  550. <LI>S - Source IP
  551. <BR>
  552. Pattern is a comma delimited CIDR notation
  553. </LI>
  554. <LI>D - Destination IP
  555. <BR>
  556. Pattern is a comma delimited CIDR notation
  557. </LI>
  558. <LI>B - Both source and destination IP must match
  559. <BR>
  560. Pattern is a comma delimited CIDR notation
  561. </LI>
  562. <LI>E - Either source or destination IP must match
  563. <BR>
  564. Pattern is a comma delimited CIDR notation
  565. </LI>
  566. <LI>P - A list of packet numbers from the pcap file.
  567. <BR>
  568. Pattern is a series of numbers, separated by commas or dashes.
  569. </LI>
  570. <LI>F - BPF syntax (same as used in tcpdump).
  571. <BR>
  572. Filter must be quoted and is only supported with -x<A NAME="tex2html8"
  573. HREF="#foot208"><SUP><SPAN CLASS="arabic">8</SPAN></SUP></A>.
  574. </LI>
  575. </OL>
  576. Examples:
  577. <P>
  578. <UL>
  579. <LI>To only send traffic that is too and from a host in
  580. </LI>
  581. </UL>
  582. <DL COMPACT>
  583. <DT>
  584. <DD>tcpreplay&nbsp;-x&nbsp;B:;-intf1&nbsp;eth0&nbsp;sample.pcap
  585. </DD>
  586. </DL>
  587. <UL>
  588. <LI>To not send traffic that is too or from a host in
  589. </LI>
  590. </UL>
  591. <DL COMPACT>
  592. <DT>
  593. <DD>tcpreplay&nbsp;-X&nbsp;E:;-intf1&nbsp;eth0&nbsp;sample.pcap
  594. </DD>
  595. </DL>
  596. <UL>
  597. <LI>To send every packet except the first 10 packets:
  598. </LI>
  599. </UL>
  600. <DL COMPACT>
  601. <DT>
  602. <DD>tcpreplay&nbsp;-X&nbsp;P:1-10&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap
  603. </DD>
  604. </DL>
  605. <UL>
  606. <LI>To only send the first 50 packets followed by packets: 100, 150, 200
  607. and 250:
  608. </LI>
  609. </UL>
  610. <DL COMPACT>
  611. <DT>
  612. <DD>tcpreplay&nbsp;-x&nbsp;P:1-50,100,150,200,250&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap
  613. </DD>
  614. </DL>
  615. <UL>
  616. <LI>To only send TCP packets from
  617. </LI>
  618. </UL>
  619. <DL COMPACT>
  620. <DT>
  621. <DD><SPAN CLASS="textit">tcpreplay&nbsp;-x&nbsp;F:'tcp&nbsp;and&nbsp;host&nbsp;'&nbsp;-intf1&nbsp;eth0&nbsp;sample.pcap</SPAN>
  622. </DD>
  623. </DL>
  624. <P>
  625. <H2><A NAME="SECTION00064000000000000000">
  626. Replaying only a few packets</A>
  627. </H2>
  628. <P>
  629. Using the limit packets flag (-L) you can specify that tcpreplay will
  630. only send at most a specified number of packets.
  631. <P>
  632. <UL>
  633. <LI>To send at most 100 packets:
  634. </LI>
  635. </UL>
  636. <DL COMPACT>
  637. <DT>
  638. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-L&nbsp;100&nbsp;sample.pcap
  639. </DD>
  640. </DL>
  641. <P>
  642. <H2><A NAME="SECTION00065000000000000000">
  643. Skipping the first bytes in a pcap file</A>
  644. </H2>
  645. <P>
  646. If you want to skip the beginning of a pcap file, you can use the
  647. offset flag (-o) to skip a specified number of bytes and start sending
  648. on the next packet.
  649. <P>
  650. <UL>
  651. <LI>To skip 15Kb into the pcap file and start sending packets from there:
  652. </LI>
  653. </UL>
  654. <DL COMPACT>
  655. <DT>
  656. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-o&nbsp;15000&nbsp;sample.pcap
  657. </DD>
  658. </DL>
  659. <P>
  660. <H2><A NAME="SECTION00066000000000000000">
  661. Replaying packets which are bigger then the MTU</A>
  662. </H2>
  663. <P>
  664. Occasionally, you might find yourself trying to replay a pcap file
  665. which contains packets which are larger then the MTU for the sending
  666. interface. This might be due to the packets being captured on the
  667. loopback interface or on a 1000Mbps ethernet interface supporting
  668. ``jumbo frames''. I've even seen packets which are 1500 bytes
  669. but contain both an ethernet header and trailer which bumps the total
  670. frame size to 1518 which is 4 bytes too large.
  671. <P>
  672. By default, tcpreplay will skip these packets and not send them. Alternatively,
  673. you can specify the -T flag to truncate these packets to the MTU and
  674. then send them. Of course this may invalidate your testing, but it
  675. has proven useful in certain situations. Also, when this feature is
  676. enabled, tcpreplay will automatically recalculate the IP and TCP,
  677. UDP or ICMP checksums as needed. Example:
  678. <P>
  679. <DL COMPACT>
  680. <DT>
  681. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-T&nbsp;sample.pcap
  682. </DD>
  683. </DL>
  684. <P>
  685. <H2><A NAME="SECTION00067000000000000000">
  686. Writing packets to a file</A>
  687. </H2>
  688. <P>
  689. It's not always necessary to write packets to the network. Since tcpreplay
  690. has so many features which modify and select which packets are sent,
  691. it is occasionally useful to save these changes to another pcap file
  692. for comparison. Rather then running a separate tcpdump process to
  693. capture the packets, tcpreplay now supports output directly to a file.
  694. Example:
  695. <P>
  696. <DL COMPACT>
  697. <DT>
  698. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-w&nbsp;output.pcap&nbsp;-F&nbsp;-u&nbsp;pad&nbsp;-x&nbsp;E:;input1.pcap&nbsp;input2.pcap&nbsp;input3.pcap
  699. </DD>
  700. </DL>Notice that specifying an interface is still required (required for
  701. various internal functions), but all the packets will be written to
  702. <SPAN CLASS="textit">output.pcap</SPAN>.
  703. <P>
  704. You can also split traffic into two files by using -W &lt;2nd output
  705. file&gt;.
  706. <P>
  707. <H2><A NAME="SECTION00068000000000000000">
  708. Extracting Application Data (Layer 7)</A>
  709. </H2>
  710. <P>
  711. New to version 2.0 is the ability to extract the application layer
  712. data from the packets and write them to a file. In the man page, we
  713. call this ``data dump mode'' which is enabled with -D. It's important
  714. to specify -D before -w (and -W if you're splitting data into two
  715. files). Example:
  716. <P>
  717. <DL COMPACT>
  718. <DT>
  719. <DD>tcpreplay&nbsp;-D&nbsp;-intf1&nbsp;eth0&nbsp;-j&nbsp;eth0&nbsp;-w&nbsp;clientdata&nbsp;-W&nbsp;serverdata&nbsp;-C&nbsp;;sample.pcap
  720. </DD>
  721. </DL>
  722. <P>
  723. <H2><A NAME="SECTION00069000000000000000">
  724. Replaying Live Traffic</A>
  725. </H2>
  726. <P>
  727. You can now replay live traffic sniffed on one network interface and
  728. replay it on another interface using the -S flag to indicate sniff
  729. mode and the appropriate snaplen in bytes (0 denotes the entire packet).
  730. You can also enabling bi-directional traffic using the bridge mode
  731. flag: -b.
  732. <P>
  733. N<SMALL>OTE:</SMALL> It is critical for your sanity (and to prevent your
  734. murder by your network administrators) that the input interface and
  735. the output interface be on separate networks and additionally that
  736. no other network devices (such as bridges, switches, routers, etc)
  737. be connecting the two networks, else you will surely get a networkstorm
  738. the likes that have not been seen for years.
  739. <P>
  740. <UL>
  741. <LI>Send packets sniffed on eth0 out eth1:
  742. </LI>
  743. </UL>
  744. <DL COMPACT>
  745. <DT>
  746. <DD>tcpreplay&nbsp;-intf1&nbsp;eth1&nbsp;-S&nbsp;0&nbsp;eth0
  747. </DD>
  748. </DL>
  749. <UL>
  750. <LI>Bridge two subnets connected to eth0 and eth1:
  751. </LI>
  752. </UL>
  753. <DL COMPACT>
  754. <DT>
  755. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-intf2=eth1&nbsp;-b&nbsp;-S&nbsp;0
  756. </DD>
  757. </DL>By default, tcpreplay listens in promiscuous mode on the specified
  758. interface, however if you only want to send unicasts directed for
  759. the local system and broadcasts, you can specify the ``not_nosy''
  760. option in the configuration file or -n on the command line. Note that
  761. if another program has already placed the interface in promiscuous
  762. mode, the -n flag will have no effect, so you may want to use the
  763. -x or -X argument to limit packets.
  764. <P>
  765. <H2><A NAME="SECTION000610000000000000000">
  766. Replaying Packet Capture Formats Other Than Libpcap</A>
  767. </H2>
  768. <P>
  769. There are about as many different capture file formats as there are
  770. sniffers. In the interest of simplicity, tcpreplay only supports libpcap<A NAME="tex2html9"
  771. HREF="#foot277"><SUP><SPAN CLASS="arabic">9</SPAN></SUP></A>. If you would like to replay a file in one of these multitude of
  772. formats, the excellent open source tool Ethereal easily allows you
  773. to convert it to libpcap. For instance, to convert a file in Sun's
  774. snoop format to libpcap, issue the command:
  775. <P>
  776. <DL COMPACT>
  777. <DT>
  778. <DD>tethereal&nbsp;-r&nbsp;blah.snoop&nbsp;-w&nbsp;blah.pcap
  779. </DD>
  780. </DL>and replay the resulting file.
  781. <P>
  782. <H2><A NAME="SECTION000611000000000000000">
  783. Replaying Client Traffic to a Server</A>
  784. </H2>
  785. <P>
  786. A common question on the tcpreplay-users list is how does one replay
  787. the client side of a connection back to a server. Unfortunately, tcpreplay
  788. doesn't support this right now. The major problem concerns syncing
  789. up TCP Seq/Ack numbers which will be different. ICMP also often contains
  790. IP header information which would need to be adjusted. About the only
  791. thing that could be easy to do is UDP, which isn't usually requested.
  792. <P>
  793. This is however a feature that we're looking into implementing in
  794. the flowreplay utility. If you're interested in helping work on this
  795. feature, please contact us and we'd be more then happy to work with
  796. you. At this time however, we don't have an ETA when this will be
  797. implemented, so don't bother asking.
  798. <P>
  799. <H2><A NAME="SECTION000612000000000000000">
  800. Decoding Packets</A>
  801. </H2>
  802. <P>
  803. If the tcpdump binary is installed on your system when tcpreplay is
  804. compiled, it will allow you to decode packets as they are sent without
  805. running tcpdump in a separate window or worrying about it capturing
  806. packets which weren't sent by tcpreplay.
  807. <P>
  808. <UL>
  809. <LI>Decode packets as they are sent:
  810. </LI>
  811. </UL>
  812. <DL COMPACT>
  813. <DT>
  814. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-v&nbsp;sample.pcap
  815. </DD>
  816. </DL>
  817. <UL>
  818. <LI>Decode packets with the link level header:
  819. </LI>
  820. </UL>
  821. <DL COMPACT>
  822. <DT>
  823. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-v&nbsp;-A&nbsp;``-e''&nbsp;sample.pcap
  824. </DD>
  825. </DL>
  826. <UL>
  827. <LI>Fully decode and send one packet at a time:
  828. </LI>
  829. </UL>
  830. <DL COMPACT>
  831. <DT>
  832. <DD>tcpreplay&nbsp;-intf1&nbsp;eth0&nbsp;-v&nbsp;-1&nbsp;-A&nbsp;``-s0&nbsp;-evvvxX''&nbsp;sample.pcap
  833. </DD>
  834. </DL>Note that tcpreplay automatically applies the -n flag to disable DNS
  835. lookups which would slow down tcpdump too much to make it effective.
  836. <P>
  837. <H1><A NAME="SECTION00070000000000000000">
  838. Packet Editing</A>
  839. </H1>
  840. <P>
  841. <H2><A NAME="SECTION00071000000000000000">
  842. Rewriting MAC addresses</A>
  843. </H2>
  844. <P>
  845. If you ever want to send traffic to another device on a switched LAN,
  846. you may need to change the destination MAC address of the packets.
  847. Tcpreplay allows you to set the destination MAC for each interface
  848. independently using the -I and -J switches. As of version 2.1.0, you
  849. can also specify the source MAC via -k and -K. Example:
  850. <P>
  851. <UL>
  852. <LI>To send traffic out eth0 with a destination MAC of your router (00:00:01:02:03:04)
  853. and the source MAC of the server (00:20:30:40:50:60):
  854. </LI>
  855. </UL>
  856. <DL COMPACT>
  857. <DT>
  858. <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
  859. </DD>
  860. </DL>
  861. <UL>
  862. <LI>To split traffic between internal ( and external addresses
  863. and to send that traffic to the two interfaces of a firewall:
  864. </LI>
  865. </UL>
  866. <DL COMPACT>
  867. <DT>
  868. <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;;sample.pcap
  869. </DD>
  870. </DL>
  871. <P>
  872. <H2><A NAME="SECTION00072000000000000000">
  873. Randomizing IP addresses</A>
  874. </H2>
  875. <P>
  876. Occasionally, it is necessary to have tcpreplay rewrite the source
  877. and destination IP addresses, yet maintain the client/server relationship.
  878. Such a case might be having multiple copies of tcpreplay running at
  879. the same time using the same pcap file while trying to stress test
  880. firewall, IDS or other stateful device. If you didn't change the source
  881. and destination IP addresses, the device under test would get confused
  882. since it would see multiple copies of the same connection occurring
  883. at the same time. In order to accomplish this, tcpreplay accepts a
  884. user specified seed which is used to generate pseudo-random IP addresses.
  885. Also, when this feature is enabled, tcpreplay will automatically recalculate
  886. the IP and TCP, UDP or ICMP checksums as needed. Example:
  887. <P>
  888. <DL COMPACT>
  889. <DT>
  890. <DD><SPAN CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;-s&nbsp;1239&nbsp;sample.pcap&nbsp;&amp;</SPAN>&nbsp;
  891. <BR><SPAN CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;-s&nbsp;76&nbsp;sample.pcap&nbsp;&amp;</SPAN>&nbsp;
  892. <BR><SPAN CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;-s&nbsp;239&nbsp;sample.pcap&nbsp;&amp;</SPAN>&nbsp;
  893. <BR><SPAN CLASS="textit">tcpreplay&nbsp;-intf1=eth0&nbsp;sample.pcap</SPAN>
  894. </DD>
  895. </DL>
  896. <P>
  897. <H2><A NAME="SECTION00073000000000000000">
  898. Replaying (de)truncated packets</A>
  899. </H2>
  900. <P>
  901. Occasionally, it is necessary to replay traffic which has been truncated
  902. by tcpdump. This occurs when the tcpdump snaplen is smaller then the
  903. actual packet size. Since this will create problems for devices which
  904. are expecting a full-sized packet or attempting checksum calculations,
  905. tcpreplay allows you to either pad the packet with zeros or reset
  906. the packet length in the headers to the actual packet size. In either
  907. case, the IP and TCP, UDP or ICMP checksums are recalculated. Examples:
  908. <P>
  909. <UL>
  910. <LI>Pad truncated packets:
  911. </LI>
  912. </UL>
  913. <DL COMPACT>
  914. <DT>
  915. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-u&nbsp;pad&nbsp;sample.pcap
  916. </DD>
  917. </DL>
  918. <UL>
  919. <LI>Rewrite packet header lengths to the actual packet size:
  920. </LI>
  921. </UL>
  922. <DL COMPACT>
  923. <DT>
  924. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-u&nbsp;trunc&nbsp;sample.pcap
  925. </DD>
  926. </DL>
  927. <P>
  928. <H2><A NAME="SECTION00074000000000000000">
  929. Rewriting Layer 2 with -2</A>
  930. </H2>
  931. <P>
  932. Starting in the 2.0.x branch, tcpreplay can replace the existing layer
  933. 2 header with one of your choosing. This is useful for when you want
  934. to change the layer 2 header type or add a header for pcap files without
  935. one. Each pcap file tells the type of frame. Currently tcpreplay knows
  936. how to deal with the following pcap(3) frame types:
  937. <P>
  938. <UL>
  939. <LI>DLT_EN10MB
  940. <BR>
  941. Replace existing 802.3/Ethernet II header
  942. </LI>
  943. <LI>DLT_RAW
  944. <BR>
  945. Frame has no Layer 2 header, so we can add one.
  946. </LI>
  948. <BR>
  949. Frame uses the Linux Cooked Socket header which is most commonly created
  950. with <SPAN CLASS="textit">tcpdump -i any</SPAN> on a Linux system.
  951. </LI>
  952. </UL>
  953. Tcpreplay accepts the new Layer 2 header as a string of comma separated
  954. hex values such as: 0xff,0xac,0x00,0x01,0xc0,0x64. Note that the leading
  955. '0x' is <SPAN CLASS="textit">not</SPAN> required.
  956. <P>
  957. Potential uses for this are to add a layer 2 header for DLT_RAW captures
  958. or add/remove ethernet tags or QoS features.
  959. <P>
  960. <H2><A NAME="SECTION00075000000000000000">
  961. Rewriting DLT_LINUX_SLL (Linux Cooked Socket) captures</A>
  962. </H2>
  963. <P>
  964. Tcpdump uses a special frame type to store captures created with the
  965. ``-i any'' argument. This frame type uses a custom 16 byte layer
  966. 2 header which tracks which interface captured the packet and often
  967. the source MAC address of the original ethernet frame. Unfortunately,
  968. it never stores the destination MAC address and it doesn't store a
  969. source MAC when the packet is captured on the loopback interface.
  970. Normally, tcpreplay can't replay these pcap files because there isn't
  971. enough information in the LINUX_SLL header to do so; however two
  972. options do exist:
  973. <P>
  974. <OL>
  975. <LI>You can send these packets with -2 which will replace the LINUX_SLL
  976. header with an ethernet header of your choosing.
  977. </LI>
  978. <LI>You can specify a destination MAC via -I and -J in which case tcpreplay
  979. will use the stored source MAC and create a new 802.3 Ethernet header.
  980. Note that if the pcap contains loopback packets, you will also need
  981. to specify -k and/or -K to specify the source MAC as well or they
  982. will be skipped.
  983. </LI>
  984. </OL>
  985. <P>
  986. <H2><A NAME="SECTION00076000000000000000">
  987. Rewriting IP Addresses (pseudo-NAT)</A>
  988. </H2>
  989. <P>
  990. Pseudo-NAT allows the mapping of IP addresses in IPv4 and ARP packets
  991. from one subnet to another subnet of the same or different size. This
  992. allows some or all the traffic sent to appear to come from a different
  993. IP subnet then it actually was captured on.
  994. <P>
  995. The mapping is done through a user specified translation table comprised
  996. of one or more source and destination network(s) in the format of
  997. &lt;srcnet&gt;/&lt;masklen&gt;:&lt;dstnet&gt;/&lt;masklen&gt; deliminated by a comma. Mapping
  998. is done by matching IP addresses to the source subnet and rewriting
  999. the most significant bits with the destination subnet. For example:
  1000. <P>
  1001. <SPAN CLASS="textit">tcpreplay -intf1=eth0 -N sample.pcap</SPAN>
  1002. <P>
  1003. would match any IP in the subnet and rewrite it as if
  1004. it came from or sent to the subnet. Ie:
  1005. would become and would become
  1006. But would not be rewritten.
  1007. <P>
  1008. For any given IP address, the translation table is applied in order
  1009. (so if there are multiple mappings, earlier maps take precedence)
  1010. and occurs only once per IP (no risk of an address getting rewritten
  1011. a second time).
  1012. <P>
  1013. <H2><A NAME="SECTION00077000000000000000">
  1014. Advanced pseudo-NAT</A>
  1015. </H2>
  1016. <P>
  1017. Pseudo-NAT also works with traffic splitting (using two interfaces
  1018. or output files) but with a few important differences. First you have
  1019. the option of specifying one or two pseudo-NAT tables. Using a single
  1020. pseudo-NAT table means that the source and destination IP addresses
  1021. of both interfaces are rewritten using the same rules. Using two pseudo-NAT
  1022. tables (specifying -N &lt;Table1&gt; -N &lt;Table2&gt;) will cause the source
  1023. and destination IP addresses to be rewritten differently for each
  1024. interface using the following matrix:
  1025. <P>
  1026. <DIV ALIGN="CENTER">
  1028. <TR><TD ALIGN="CENTER">&nbsp;</TD>
  1029. <TD ALIGN="CENTER">Out Primary Interface</TD>
  1030. <TD ALIGN="CENTER">Out Secondary Interface
  1031. <BR>
  1032. Src IP</TD>
  1033. </TR>
  1034. </TABLE>
  1035. </DIV>
  1036. <P>
  1037. While seemingly a bit confusing, this feature provides a number of
  1038. interesting possibilities such as the ability to rewrite the IP headers
  1039. of packets in the case where traffic is captured on the loopback interface
  1040. (and the source and destination address is always so that
  1041. tcpreplay can make it look like two different systems are talking
  1042. to each other (you'll probably also need to specify the source and
  1043. destination MAC addresses via -I, -J, -k and -K).
  1044. <P>
  1045. <H2><A NAME="SECTION00078000000000000000">
  1046. IP Endpoints</A>
  1047. </H2>
  1048. <P>
  1049. While pseudo-NAT provides a great deal of flexibility, it is often
  1050. more complicated then is necessary for testing of inline devices.
  1051. As a simplier alternative, tcpreplay supports the concept of rewriting
  1052. all traffic to so that it appears to be between two IP addresses:
  1053. <P>
  1054. <DL COMPACT>
  1055. <DT>
  1056. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;-c&nbsp;sample.cache&nbsp;-e&nbsp;;sample.pcap
  1057. </DD>
  1058. </DL>Will rewrite all the traffic so that it is between and
  1059. The equivalent command using -N would be:
  1060. <P>
  1061. <DL COMPACT>
  1062. <DT>
  1063. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;-c&nbsp;sample.cache&nbsp;-N&nbsp;;-N&nbsp;;sample.pcap
  1064. </DD>
  1065. </DL>
  1066. <P>
  1067. <H2><A NAME="SECTION00079000000000000000">
  1068. Unifying Dual-Outputs</A>
  1069. </H2>
  1070. <P>
  1071. Since a number of tcpreplay's packet editing functions require splitting
  1072. traffic between client and servers, one problem that may arrise is
  1073. needing to edit packets but still output to a single interface or
  1074. file. The solution to this is to use the one output option -O which
  1075. causes packets to be processed as if they will be split between the
  1076. interfaces/files, but then always go out the primary interface or
  1077. file. Note that even though only one interface/file will be written
  1078. to, both -i and -j must be specified; although they can be the same
  1079. physical interface.
  1080. <P>
  1081. <DL COMPACT>
  1082. <DT>
  1083. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-j&nbsp;eth0&nbsp;-O&nbsp;-c&nbsp;sample.cache&nbsp;-e&nbsp;;sample.pcap
  1084. </DD>
  1085. </DL>Merging the output to a single file:
  1086. <P>
  1087. <DL COMPACT>
  1088. <DT>
  1089. <DD>tcpreplay&nbsp;-intf1=eth0&nbsp;-j&nbsp;eth0&nbsp;-w&nbsp;rewrite.pcap&nbsp;-c&nbsp;sample.cache&nbsp;-e&nbsp;;sample.pcap
  1090. </DD>
  1091. </DL>
  1092. <P>
  1093. <H1><A NAME="SECTION00080000000000000000">
  1094. Tcpprep Usage</A>
  1095. </H1>
  1096. <P>
  1097. <H2><A NAME="SECTION00081000000000000000">
  1098. What is tcpprep?</A>
  1099. </H2>
  1100. <P>
  1101. Tcpreplay can send traffic out two network cards, however it requires
  1102. the calculations be done in real-time. These calculations can be expensive
  1103. and can significantly reduce the throughput of tcpreplay.
  1104. <P>
  1105. Tcpprep is a libpcap pre-processor for tcpreplay which enables using
  1106. two network cards to send traffic without the performance hit of doing
  1107. the calculations in real-time.
  1108. <P>
  1109. <H2><A NAME="SECTION00082000000000000000">
  1110. What are these 'modes' tcpprep has? </A>
  1111. </H2>
  1112. <P>
  1113. Tcpprep has three basic modes which require the user to specify how
  1114. to split traffic.
  1115. <P>
  1116. <UL>
  1117. <LI>CIDR (-cidr) mode requires the user to provide
  1118. a list of networks. Any packet with a source IP in one of these networks
  1119. gets sent out the primary interface.
  1120. </LI>
  1121. <LI>Regex (-regex) mode requires the user to provide
  1122. a regular expression. Any packet with a source IP matching the regex
  1123. gets sent out the primary interface.
  1124. </LI>
  1125. <LI>Port (-port) mode splits TCP/UDP traffic based
  1126. on the destination port in the header. Normally, ports 0-1023 are
  1127. considered ``server'' ports and everything else a client port.
  1128. You can create your own custom mapping file in the same format as
  1129. /etc/services (see the services(5) man page for details) by specifying
  1130. -services &lt;file&gt;.
  1131. </LI>
  1132. </UL>
  1133. And four auto modes in which tcpprep decides how to split traffic.
  1134. Auto modes are useful for when you don't know much about the contents
  1135. of the dump file in question and you want to split traffic up based
  1136. upon servers and clients.
  1137. <P>
  1138. <UL>
  1139. <LI>Auto/Router (-auto router) mode trys to find
  1140. the largest network(s) that contain all the servers and no clients.
  1141. Any unknown system is automatically re-classified as servers if it's
  1142. inside the server network(s), otherwise it is classified as a client.
  1143. </LI>
  1144. <LI>Auto/Bridge (-auto bridge) mode makes the assumption
  1145. that the clients and servers are horribly intermixed on the network
  1146. and there's no way to subnet them. While this takes less processing
  1147. time to create the cache file it is unable to deal with unknown systems.
  1148. </LI>
  1149. <LI>Auto/Client (-auto client) mode which works just
  1150. like Auto/Bridge mode, except that any system it can't figure out
  1151. is treated like a client.
  1152. </LI>
  1153. <LI>Auto/Server (-auto server) mode which works just
  1154. like Auto/Bridge mode, except that any system it can't figure out
  1155. is treated like a server.
  1156. </LI>
  1157. </UL>
  1158. <P>
  1159. <H2><A NAME="SECTION00083000000000000000">
  1160. Splitting traffic based upon IP address</A>
  1161. </H2>
  1162. <P>
  1163. Tcpprep supports the same CIDR mode that tcpreplay supports using
  1164. the -cidr flag. Additionally, tcpprep also supports
  1165. regex(7) regular expressions to match source IP addresses using the
  1166. -regex flag.
  1167. <P>
  1168. <H2><A NAME="SECTION00084000000000000000">
  1169. Auto Mode</A>
  1170. </H2>
  1171. <P>
  1172. <H3><A NAME="SECTION00084100000000000000">
  1173. How does Auto/Bridge mode work? </A>
  1174. </H3>
  1175. <P>
  1176. Tcpprep does an initial pass over the libpcap file to build a binary
  1177. tree (one node per IP). For each IP, it keeps track of how many times
  1178. it was a client or server. It then does a second pass of the file
  1179. using the data in the tree and the ratio to determine if an IP is
  1180. a client or server. If tcpprep is unable to determine the type (client
  1181. or server) for each and every packet, then auto/bridge mode will fail.
  1182. In these cases, it is best to use a different auto mode.
  1183. <P>
  1184. <H3><A NAME="SECTION00084200000000000000">
  1185. How does Auto/Router mode work? </A>
  1186. </H3>
  1187. <P>
  1188. Tcpprep does the same first pass as Auto/Bridge mode. It then trys
  1189. to convert the binary tree into a list of networks containing the
  1190. servers. Finally it uses the CIDR mode with the list of server networks
  1191. in a second pass of the libpcap file. Unlike auto/bridge mode, auto/router
  1192. mode can always successfully split IP addresses into clients and servers.
  1193. <P>
  1194. <H3><A NAME="SECTION00084300000000000000">
  1195. Determining Clients and Servers</A>
  1196. </H3>
  1197. <P>
  1198. Tcpprep uses the following methods in auto/router and auto/bridge
  1199. mode to determine if an IP address is a client or server:
  1200. <P>
  1201. <UL>
  1202. <LI>Client:
  1203. <P>
  1204. <UL>
  1205. <LI>TCP with Syn flag set
  1206. </LI>
  1207. <LI>UDP source/destination port 53 (DNS) without query flag set
  1208. </LI>
  1209. <LI>ICMP port unreachable (destination IP of packet)
  1210. </LI>
  1211. </UL>
  1212. </LI>
  1213. <LI>Server:
  1214. <P>
  1215. <UL>
  1216. <LI>TCP with Syn/Ack flag set
  1217. </LI>
  1218. <LI>UDP source/destination port 53 (DNS) with query flag set
  1219. </LI>
  1220. <LI>ICMP port unreachable (source IP of packet)
  1221. </LI>
  1222. </UL>
  1223. </LI>
  1224. </UL>
  1225. <P>
  1226. <H3><A NAME="SECTION00084400000000000000">
  1227. Client/Server ratio</A>
  1228. </H3>
  1229. <P>
  1230. Since a system may send traffic which would classify it as both a
  1231. client and server, it's necessary to be able to weigh the traffic.
  1232. This is done by specifying the client/server ratio (-R) which is by
  1233. default set to 2.0. The ratio is the modifier to the number of client
  1234. connections. Hence, by default, client connections are valued twice
  1235. as high as server connections.
  1236. <P>
  1237. <H2><A NAME="SECTION00085000000000000000">
  1238. Selectively sending/dropping packets</A>
  1239. </H2>
  1240. <P>
  1241. Tcpprep supports the same -include and -exclude
  1242. options to selectively send or drop packets.
  1243. <P>
  1244. <H2><A NAME="SECTION00086000000000000000">
  1245. Using tcpprep cache files with tcpreplay</A>
  1246. </H2>
  1247. <P>
  1248. Just run:
  1249. <P>
  1250. <DL COMPACT>
  1251. <DT>
  1252. <DD>tcpreplay&nbsp;-cachefile&nbsp;sample.cache&nbsp;-intf1=eth0&nbsp;-intf2=eth1&nbsp;sample.pcap
  1253. </DD>
  1254. </DL>
  1255. <P>
  1256. <H2><A NAME="SECTION00087000000000000000">
  1257. Commenting tcpprep cache files</A>
  1258. </H2>
  1259. <P>
  1260. In versions of tcpprep &gt;= 2.1.0, you can specify a comment to be embeded
  1261. in the tcpprep cache file. Comments are user specified and automatically
  1262. include the command line arguments passed to tcpprep.
  1263. <P>
  1264. <DL COMPACT>
  1265. <DT>
  1266. <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;
  1267. </DD>
  1268. </DL>Or for no user comment, but still embed the command arguments:
  1269. <P>
  1270. <DL COMPACT>
  1271. <DT>
  1272. <DD>tcpprep&nbsp;-comment&nbsp;``''&nbsp;-pcap&nbsp;sample.pcap&nbsp;-cachefile&nbsp;sample.cache&nbsp;&lt;other&nbsp;args&gt;
  1273. </DD>
  1274. </DL>You can then later on print out the comments by running:
  1275. <P>
  1276. <DL COMPACT>
  1277. <DT>
  1278. <DD>tcpprep&nbsp;-print-comment&nbsp;sample.cache
  1279. </DD>
  1280. </DL>
  1281. <P>
  1282. <H1><A NAME="SECTION00090000000000000000">
  1283. Using Configuration Files</A>
  1284. </H1>
  1285. <P>
  1286. Each of the applications in the tcpreplay suite offers the choice
  1287. of specifying configuration options in a config file in addition to
  1288. the traditional command line. Each command line option has an equivalent
  1289. config file option which is listed in the man page. To specify the
  1290. configuration file you'd like to use, use the -load-opts=&lt;filename&gt;
  1291. option.
  1292. <P>
  1293. Configuration files have one option per line, and lines beginning
  1294. with the pound sign (#) are considered comments and ignored. An example
  1295. config file follows:
  1296. <P>
  1297. ------BEGIN CONFIG FILE-------
  1298. <P>
  1299. <TT># send traffic out 'eth0'</TT>&nbsp;
  1300. <BR><TT>intf1 eth0</TT>&nbsp;
  1301. <BR>&nbsp;
  1302. <BR><TT># loop 5 times</TT>&nbsp;
  1303. <BR><TT>loop 5</TT>&nbsp;
  1304. <BR>&nbsp;
  1305. <BR><TT># send traffic 2x as fast</TT>&nbsp;
  1306. <BR><TT>multiplier 2</TT>
  1307. <BR>-------END CONFIG FILE--------
  1308. <P>
  1309. You would then execute:
  1310. <P>
  1311. <DL COMPACT>
  1312. <DT>
  1313. <DD>#&nbsp;tcpreplay&nbsp;-load-opts=myconfigfile&nbsp;sample.pcap
  1314. </DD>
  1315. </DL>You can also group configuration options for tcpprep, tcprewrite and
  1316. tcpreplay in a single config file by placing section markers in the
  1317. config file. An example:
  1318. <P>
  1319. ------BEGIN CONFIG FILE-------
  1320. <P>
  1321. <TT>cachefile=example.tcpprep</TT>&nbsp;
  1322. <BR>&nbsp;
  1323. <BR><TT>[TCPREPLAY]</TT>&nbsp;
  1324. <BR><TT>intf1 eth0</TT>&nbsp;
  1325. <BR><TT>intf2 eth1</TT>&nbsp;
  1326. <BR><TT>topspeed </TT>&nbsp;
  1327. <BR>&nbsp;
  1328. <BR><TT>[TCPPREP]</TT>&nbsp;
  1329. <BR><TT>auto=bridge</TT>&nbsp;
  1330. <BR><TT>comment='This cache file was created with a config file'</TT>&nbsp;
  1331. <BR><TT>pcap=sample.pcap</TT>&nbsp;
  1332. <BR>&nbsp;
  1333. <BR><TT>[TCPREWRITE]</TT>&nbsp;
  1334. <BR><TT>infile=sample.pcap</TT>&nbsp;
  1335. <BR><TT>outfile=newsample.pcap</TT>&nbsp;
  1336. <BR><TT>vlan=add</TT>&nbsp;
  1337. <BR><TT>vlan-tag=44</TT>&nbsp;
  1338. <BR><TT>endpoints=</TT>
  1339. <P>
  1340. ------END CONFIG FILE-------
  1341. <P>
  1342. <H1><A NAME="SECTION000100000000000000000">
  1343. Flowreplay Usage</A>
  1344. </H1>
  1345. <P>
  1346. While tcpreplay is a great way to test NIDS and firewalls, it can't
  1347. be used to test servers or HIDS since tcpreplay can't connect to a
  1348. service running on a device. The solution to this problem is flowreplay
  1349. which instead of sending packets at Layer 2 (ethernet header and up),
  1350. it can actually connect via TCP or UDP to server and then sends and
  1351. receives data based upon a pcap capture file created with a tool like
  1352. Ethereal or tcpdump.
  1353. <P>
  1354. Please note that flowreplay is currently alpha quality and is missing
  1355. a number of key features.
  1356. <P>
  1357. <H2><A NAME="SECTION000101000000000000000">
  1358. How flowreplay works</A>
  1359. </H2>
  1360. <P>
  1361. Put simply, flowreplay opens a socket connection to a service on a
  1362. target system(s) and sends data over that socket based on the packet
  1363. capture. Flowreplay has no understanding of the application protocol
  1364. (like HTTP or FTP) so it is somewhat limited in how it can deal with
  1365. complicated exchanges between client and server.
  1366. <P>
  1367. Some of these limitations are:
  1368. <P>
  1369. <UL>
  1370. <LI>Flowreplay only plays the client side<A NAME="tex2html10"
  1371. HREF="#foot455"><SUP><SPAN CLASS="arabic">10</SPAN></SUP></A> of the connection.
  1372. </LI>
  1373. <LI>Flowreplay doesn't understand the application protocols. Hence it
  1374. can't always deal with the case when the server sends a different
  1375. response then what was originally captured in the pcap file.
  1376. </LI>
  1377. <LI>Flowreplay only sends TCP and UDP traffic.
  1378. </LI>
  1379. <LI>Flowreplay doesn't know about multi-flow protocols like FTP.
  1380. </LI>
  1381. <LI>Flowreplay can't listen on a port and wait for a client to connect
  1382. to it.
  1383. </LI>
  1384. </UL>
  1385. <P>
  1386. <H2><A NAME="SECTION000102000000000000000">
  1387. Running flowreplay</A>
  1388. </H2>
  1389. <P>
  1390. See the flowreplay(8) man page for details.
  1391. <P>
  1392. <H1><A NAME="SECTION000110000000000000000">
  1393. Tuning OS's for high performance</A>
  1394. </H1>
  1395. <P>
  1396. Regardless of the size of physical memory, UNIX kernels will only
  1397. allocate a static amount for network buffers. This includes packets
  1398. sent via the &#34;raw&#34; interface, like with tcpreplay.
  1399. Most kernels will allow you to tweak the size of these buffers, drastically
  1400. increasing performance and accuracy.
  1401. <P>
  1402. N<SMALL>OTE:</SMALL> The following information is provided based upon our
  1403. own experiences or the reported experiences of others. Depending on
  1404. your hardware and specific hardware, it may or may not work for you.
  1405. It may even make your system horribly unstable, corrupt your harddrive,
  1406. or worse.
  1407. <P>
  1408. N<SMALL>OTE</SMALL>: Different operating systems, network card drivers,
  1409. and even hardware can have an effect on the accuracy of packet timestamps
  1410. that tcpdump or other capture utilities generate. And as you know:
  1411. garbage in, garbage out.
  1412. <P>
  1413. N<SMALL>OTE:</SMALL> If you have information on tuning the kernel of an
  1414. operating system not listed here, please send it to me so I can include
  1415. it.
  1416. <P>
  1417. <H2><A NAME="SECTION000111000000000000000">
  1418. Linux 2.4.x</A>
  1419. </H2>
  1420. <P>
  1421. The following is known to apply to the 2.4.x series of kernels. If
  1422. anyone has any information regarding other kernel versions, please
  1423. let us know. By default Linux's tcpreplay performance isn't all that
  1424. stellar. However, with a simple tweak, relatively decent performance
  1425. can be had on the right hardware. By default, Linux specifies a 64K
  1426. buffer for sending packets. Increasing this buffer to about half a
  1427. megabyte does a good job:
  1428. <P>
  1429. <SPAN CLASS="textit">echo 524287 &gt;/proc/sys/net/core/wmem_default </SPAN>
  1430. <BR><SPAN CLASS="textit">echo 524287 &gt;/proc/sys/net/core/wmem_max </SPAN>
  1431. <BR><SPAN CLASS="textit">echo 524287 &gt;/proc/sys/net/core/rmem_max </SPAN>
  1432. <BR><SPAN CLASS="textit">echo 524287 &gt;/proc/sys/net/core/rmem_default </SPAN>
  1433. <P>
  1434. On one system, we've seen a jump from 23.02 megabits/sec (5560 packets/sec)
  1435. to 220.30 megabits/sec (53212 packets/sec) which is nearly a 10x increase
  1436. in performance. Depending on your system and capture file, different
  1437. numbers may provide different results.
  1438. <P>
  1439. <H2><A NAME="SECTION000112000000000000000">
  1440. *BSD</A>
  1441. </H2>
  1442. <P>
  1443. *BSD systems typically allow you to specify the size of network
  1444. buffers with the NMBCLUSTERS option in the kernel config file. Experiment
  1445. with different sizes to see which yields the best performance. See
  1446. the options(4) man page for more details.
  1447. <P>
  1448. <H1><A NAME="SECTION000120000000000000000">
  1449. Required Libraries and Tools</A>
  1450. </H1>
  1451. <P>
  1452. <H2><A NAME="SECTION000121000000000000000">
  1453. Libpcap</A>
  1454. </H2>
  1455. <P>
  1456. As of tcpreplay v1.4, you'll need to have libpcap installed on your
  1457. system. As of v2.0, you'll need at least version 0.6.0 or better,
  1458. but I only test our code with the latest version. Libpcap can be obtained
  1459. on the tcpdump homepage<A NAME="tex2html11"
  1460. HREF="#foot518"><SUP><SPAN CLASS="arabic">11</SPAN></SUP></A>.
  1461. <P>
  1462. <H2><A NAME="SECTION000122000000000000000">
  1463. Libnet</A>
  1464. </H2>
  1465. <P>
  1466. Tcpreplay v1.3 is the last version to support the old libnet API (everything
  1467. before 1.1.x). As of v1.4 you will need to use Libnet 1.1.0 or better
  1468. which can be obtained from the Libnet homepage<A NAME="tex2html12"
  1469. HREF="#foot519"><SUP><SPAN CLASS="arabic">12</SPAN></SUP></A>.
  1470. <P>
  1471. <H2><A NAME="SECTION000123000000000000000">
  1472. Tcpdump</A>
  1473. </H2>
  1474. <P>
  1475. As of 2.0, tcpreplay uses tcpdump (the binary, not code) to decode
  1476. packets to STDOUT in a human readable (with practice) format as it
  1477. sends them. If you would like this feature, tcpdump must be installed
  1478. on your system.
  1479. <P>
  1480. N<SMALL>OTE:</SMALL> The location of the tcpdump binary is hardcoded in
  1481. tcpreplay at compile time. If tcpdump gets renamed or moved, the feature
  1482. will become disabled.
  1483. <P>
  1484. <BR><HR><H4>Footnotes</H4>
  1485. <DL>
  1486. <DT><A NAME="foot56">... Libnet</A><A
  1487. HREF="manual.html#tex2html1"><SUP><SPAN CLASS="arabic">1</SPAN></SUP></A></DT>
  1488. <DD>
  1489. </DD>
  1490. <DT><A NAME="foot57">... Libpcap</A><A
  1491. HREF="manual.html#tex2html2"><SUP><SPAN CLASS="arabic">2</SPAN></SUP></A></DT>
  1492. <DD>
  1493. </DD>
  1494. <DT><A NAME="foot58">... tcpdump</A><A
  1495. HREF="manual.html#tex2html3"><SUP><SPAN CLASS="arabic">3</SPAN></SUP></A></DT>
  1496. <DD>
  1497. </DD>
  1498. <DT><A NAME="foot507">...
  1499. captured</A><A
  1500. HREF="manual.html#tex2html4"><SUP><SPAN CLASS="arabic">4</SPAN></SUP></A></DT>
  1501. <DD>Tcpreplay makes a &#34;best&#34; effort to replay traffic
  1502. at the given rate, but due to limitations in hardware or the pcap
  1503. file itself, it may not be possible. Capture files with only a few
  1504. packets in them are especially susceptible to inaccurately timing
  1505. packets.
  1506. </DD>
  1507. <DT><A NAME="foot118">... times</A><A
  1508. HREF="manual.html#tex2html5"><SUP><SPAN CLASS="arabic">5</SPAN></SUP></A></DT>
  1509. <DD>Looping files resets internal counters which control the speed that
  1510. the file is replayed. Also because the file has to be closed and re-opened,
  1511. an added delay between the last and first packet may occur.
  1512. </DD>
  1513. <DT><A NAME="foot182">... interface</A><A
  1514. HREF="manual.html#tex2html6"><SUP><SPAN CLASS="arabic">6</SPAN></SUP></A></DT>
  1515. <DD>Note that you can also use the following options to split traffic
  1516. into two files using -w and -W which are described later on in this
  1517. FAQ.
  1518. </DD>
  1519. <DT><A NAME="foot184">... cachefile</A><A
  1520. HREF="manual.html#tex2html7"><SUP><SPAN CLASS="arabic">7</SPAN></SUP></A></DT>
  1521. <DD>For information on generating tcpprep cache files, see the section
  1522. on tcpprep.
  1523. </DD>
  1524. <DT><A NAME="foot208">... -x</A><A
  1525. HREF="manual.html#tex2html8"><SUP><SPAN CLASS="arabic">8</SPAN></SUP></A></DT>
  1526. <DD>Note that if you want to send all the packets which do not match a
  1527. bpf filter, all you have to do is negate the bpf filter. See the tcpdump(1)
  1528. man page for more info.
  1529. </DD>
  1530. <DT><A NAME="foot277">... libpcap</A><A
  1531. HREF="manual.html#tex2html9"><SUP><SPAN CLASS="arabic">9</SPAN></SUP></A></DT>
  1532. <DD>Note that some versions of tcpreplay prior to 1.4 also supported the
  1533. Solaris snoop format.
  1534. </DD>
  1535. <DT><A NAME="foot455">... side</A><A
  1536. HREF="manual.html#tex2html10"><SUP><SPAN CLASS="arabic">10</SPAN></SUP></A></DT>
  1537. <DD>Flowreplay assumes the first UDP packet on a given 4-tuple is the
  1538. client
  1539. </DD>
  1540. <DT><A NAME="foot518">... homepage</A><A
  1541. HREF="manual.html#tex2html11"><SUP><SPAN CLASS="arabic">11</SPAN></SUP></A></DT>
  1542. <DD>
  1543. </DD>
  1544. <DT><A NAME="foot519">... homepage</A><A
  1545. HREF="manual.html#tex2html12"><SUP><SPAN CLASS="arabic">12</SPAN></SUP></A></DT>
  1546. <DD>
  1547. </DD>
  1548. </DL>
  1549. <BR><HR>
  1550. <!--Table of Child-Links-->
  1551. <A NAME="CHILD_LINKS"></A>
  1552. <UL CLASS="ChildLinks">
  1553. <LI><UL>
  1554. <LI><UL>
  1555. <LI><A NAME="tex2html15"
  1556. HREF="manual.html#SECTION00010000000000000000">Notice</A>
  1557. <LI><A NAME="tex2html16"
  1558. HREF="manual.html#SECTION00020000000000000000">Overview</A>
  1559. <UL>
  1560. <LI><A NAME="tex2html17"
  1561. HREF="manual.html#SECTION00021000000000000000">Using this manual</A>
  1562. <LI><A NAME="tex2html18"
  1563. HREF="manual.html#SECTION00022000000000000000">Getting Help</A>
  1564. <LI><A NAME="tex2html19"
  1565. HREF="manual.html#SECTION00023000000000000000">Corrections and additions to the manual</A>
  1566. </UL>
  1567. <LI><A NAME="tex2html20"
  1568. HREF="manual.html#SECTION00030000000000000000">Getting Tcpreplay working on your system</A>
  1569. <UL>
  1570. <LI><A NAME="tex2html21"
  1571. HREF="manual.html#SECTION00031000000000000000">Getting the source code</A>
  1572. <LI><A NAME="tex2html22"
  1573. HREF="manual.html#SECTION00032000000000000000">Requirements</A>
  1574. <LI><A NAME="tex2html23"
  1575. HREF="manual.html#SECTION00033000000000000000">Compiling Tcpreplay</A>
  1576. </UL>
  1577. <LI><A NAME="tex2html24"
  1578. HREF="manual.html#SECTION00040000000000000000">Basic Tcpreplay Usage</A>
  1579. <UL>
  1580. <LI><A NAME="tex2html25"
  1581. HREF="manual.html#SECTION00041000000000000000">Replaying the traffic</A>
  1582. <LI><A NAME="tex2html26"
  1583. HREF="manual.html#SECTION00042000000000000000">Replaying at different speeds</A>
  1584. <LI><A NAME="tex2html27"
  1585. HREF="manual.html#SECTION00043000000000000000">Replaying files multiple times</A>
  1586. </UL>
  1587. <LI><A NAME="tex2html28"
  1588. HREF="manual.html#SECTION00050000000000000000">Editing Packets</A>
  1589. <LI><A NAME="tex2html29"
  1590. HREF="manual.html#SECTION00060000000000000000">Splitting Traffic</A>
  1591. <UL>
  1592. <LI><A NAME="tex2html30"
  1593. HREF="manual.html#SECTION00061000000000000000">Classifying client and servers with tcpprep</A>
  1594. <LI><A NAME="tex2html31"
  1595. HREF="manual.html#SECTION00062000000000000000">Replaying on multiple interfaces</A>
  1596. <LI><A NAME="tex2html32"
  1597. HREF="manual.html#SECTION00063000000000000000">Selectively sending or dropping packets</A>
  1598. <LI><A NAME="tex2html33"
  1599. HREF="manual.html#SECTION00064000000000000000">Replaying only a few packets</A>
  1600. <LI><A NAME="tex2html34"
  1601. HREF="manual.html#SECTION00065000000000000000">Skipping the first bytes in a pcap file</A>
  1602. <LI><A NAME="tex2html35"
  1603. HREF="manual.html#SECTION00066000000000000000">Replaying packets which are bigger then the MTU</A>
  1604. <LI><A NAME="tex2html36"
  1605. HREF="manual.html#SECTION00067000000000000000">Writing packets to a file</A>
  1606. <LI><A NAME="tex2html37"
  1607. HREF="manual.html#SECTION00068000000000000000">Extracting Application Data (Layer 7)</A>
  1608. <LI><A NAME="tex2html38"
  1609. HREF="manual.html#SECTION00069000000000000000">Replaying Live Traffic</A>
  1610. <LI><A NAME="tex2html39"
  1611. HREF="manual.html#SECTION000610000000000000000">Replaying Packet Capture Formats Other Than Libpcap</A>
  1612. <LI><A NAME="tex2html40"
  1613. HREF="manual.html#SECTION000611000000000000000">Replaying Client Traffic to a Server</A>
  1614. <LI><A NAME="tex2html41"
  1615. HREF="manual.html#SECTION000612000000000000000">Decoding Packets</A>
  1616. </UL>
  1617. <LI><A NAME="tex2html42"
  1618. HREF="manual.html#SECTION00070000000000000000">Packet Editing</A>
  1619. <UL>
  1620. <LI><A NAME="tex2html43"
  1621. HREF="manual.html#SECTION00071000000000000000">Rewriting MAC addresses</A>
  1622. <LI><A NAME="tex2html44"
  1623. HREF="manual.html#SECTION00072000000000000000">Randomizing IP addresses</A>
  1624. <LI><A NAME="tex2html45"
  1625. HREF="manual.html#SECTION00073000000000000000">Replaying (de)truncated packets</A>
  1626. <LI><A NAME="tex2html46"
  1627. HREF="manual.html#SECTION00074000000000000000">Rewriting Layer 2 with -2</A>
  1628. <LI><A NAME="tex2html47"
  1629. HREF="manual.html#SECTION00075000000000000000">Rewriting DLT_LINUX_SLL (Linux Cooked Socket) captures</A>
  1630. <LI><A NAME="tex2html48"
  1631. HREF="manual.html#SECTION00076000000000000000">Rewriting IP Addresses (pseudo-NAT)</A>
  1632. <LI><A NAME="tex2html49"
  1633. HREF="manual.html#SECTION00077000000000000000">Advanced pseudo-NAT</A>
  1634. <LI><A NAME="tex2html50"
  1635. HREF="manual.html#SECTION00078000000000000000">IP Endpoints</A>
  1636. <LI><A NAME="tex2html51"
  1637. HREF="manual.html#SECTION00079000000000000000">Unifying Dual-Outputs</A>
  1638. </UL>
  1639. <LI><A NAME="tex2html52"
  1640. HREF="manual.html#SECTION00080000000000000000">Tcpprep Usage</A>
  1641. <UL>
  1642. <LI><A NAME="tex2html53"
  1643. HREF="manual.html#SECTION00081000000000000000">What is tcpprep?</A>
  1644. <LI><A NAME="tex2html54"
  1645. HREF="manual.html#SECTION00082000000000000000">What are these 'modes' tcpprep has? </A>
  1646. <LI><A NAME="tex2html55"
  1647. HREF="manual.html#SECTION00083000000000000000">Splitting traffic based upon IP address</A>
  1648. <LI><A NAME="tex2html56"
  1649. HREF="manual.html#SECTION00084000000000000000">Auto Mode</A>
  1650. <LI><A NAME="tex2html57"
  1651. HREF="manual.html#SECTION00085000000000000000">Selectively sending/dropping packets</A>
  1652. <LI><A NAME="tex2html58"
  1653. HREF="manual.html#SECTION00086000000000000000">Using tcpprep cache files with tcpreplay</A>
  1654. <LI><A NAME="tex2html59"
  1655. HREF="manual.html#SECTION00087000000000000000">Commenting tcpprep cache files</A>
  1656. </UL>
  1657. <LI><A NAME="tex2html60"
  1658. HREF="manual.html#SECTION00090000000000000000">Using Configuration Files</A>
  1659. <LI><A NAME="tex2html61"
  1660. HREF="manual.html#SECTION000100000000000000000">Flowreplay Usage</A>
  1661. <UL>
  1662. <LI><A NAME="tex2html62"
  1663. HREF="manual.html#SECTION000101000000000000000">How flowreplay works</A>
  1664. <LI><A NAME="tex2html63"
  1665. HREF="manual.html#SECTION000102000000000000000">Running flowreplay</A>
  1666. </UL>
  1667. <LI><A NAME="tex2html64"
  1668. HREF="manual.html#SECTION000110000000000000000">Tuning OS's for high performance</A>
  1669. <UL>
  1670. <LI><A NAME="tex2html65"
  1671. HREF="manual.html#SECTION000111000000000000000">Linux 2.4.x</A>
  1672. <LI><A NAME="tex2html66"
  1673. HREF="manual.html#SECTION000112000000000000000">*BSD</A>
  1674. </UL>
  1675. <LI><A NAME="tex2html67"
  1676. HREF="manual.html#SECTION000120000000000000000">Required Libraries and Tools</A>
  1677. <UL>
  1678. <LI><A NAME="tex2html68"
  1679. HREF="manual.html#SECTION000121000000000000000">Libpcap</A>
  1680. <LI><A NAME="tex2html69"
  1681. HREF="manual.html#SECTION000122000000000000000">Libnet</A>
  1682. <LI><A NAME="tex2html70"
  1683. HREF="manual.html#SECTION000123000000000000000">Tcpdump</A>
  1684. </UL>
  1685. </UL>
  1686. </UL>
  1687. <BR>
  1688. <LI><A NAME="tex2html71"
  1689. HREF="node1.html">Other Resources</A>
  1690. <UL>
  1691. <LI><A NAME="tex2html72"
  1692. HREF="node1.html#SECTION01010000000000000000">Other pcap tools available</A>
  1693. <UL>
  1694. <LI><A NAME="tex2html73"
  1695. HREF="node1.html#SECTION01011000000000000000">Tools to capture network traffic or decode pcap files</A>
  1696. <LI><A NAME="tex2html74"
  1697. HREF="node1.html#SECTION01012000000000000000">Tools to edit pcap files</A>
  1698. <LI><A NAME="tex2html75"
  1699. HREF="node1.html#SECTION01013000000000000000">Other useful tools</A>
  1700. </UL></UL></UL>
  1701. <!--End of Table of Child-Links-->
  1702. <DIV CLASS="navigation"><HR>
  1703. <!--Navigation Panel-->
  1704. <A NAME="tex2html13"
  1705. HREF="node1.html">
  1706. <IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
  1707. <IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up_g.png">
  1708. <IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev_g.png">
  1709. <BR>
  1710. <B> Next:</B> <A NAME="tex2html14"
  1711. HREF="node1.html">Other Resources</A></DIV>
  1712. <!--End of Navigation Panel-->
  1713. <ADDRESS>
  1714. Aaron Turner
  1715. 2005-08-07
  1716. </ADDRESS>
  1717. </BODY>
  1718. </HTML>