tcpreplay-2-faq.html 71 KB

  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//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 2.x FAQ</TITLE>
  10. <META NAME="description" CONTENT="Tcpreplay 2.x FAQ">
  11. <META NAME="keywords" CONTENT="FAQ">
  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="tcpreplay-2-faq.css">
  18. </HEAD>
  19. <BODY >
  20. <P>
  21. <P>
  22. <P>
  23. <P>
  24. <H1 ALIGN="CENTER">Tcpreplay 2.x FAQ</H1>
  25. <DIV>
  26. <P ALIGN="CENTER"><STRONG>Aaron Turner</STRONG></P>
  27. <P ALIGN="CENTER"><I></I></P>
  28. <P ALIGN="CENTER"><STRONG>Last Edited:
  29. <BR>
  30. Sept 6, 2004</STRONG></P>
  31. </DIV>
  32. <BR>
  33. <H2><A NAME="SECTION01000000000000000000">
  34. Contents</A>
  35. </H2>
  36. <!--Table of Contents-->
  37. <UL>
  38. <LI><A NAME="tex2html109"
  39. HREF="tcpreplay-2-faq.html#SECTION02000000000000000000">1 Before You Start</A>
  40. <UL>
  41. <LI><A NAME="tex2html110"
  42. HREF="tcpreplay-2-faq.html#SECTION02010000000000000000">1 General Info</A>
  43. <UL>
  44. <LI><A NAME="tex2html111"
  45. HREF="tcpreplay-2-faq.html#SECTION02011000000000000000">1.1 What is this FAQ for?</A>
  46. <LI><A NAME="tex2html112"
  47. HREF="tcpreplay-2-faq.html#SECTION02012000000000000000">1.2 What tools come with tcpreplay?</A>
  48. <LI><A NAME="tex2html113"
  49. HREF="tcpreplay-2-faq.html#SECTION02013000000000000000">1.3 How can I get tcpreplay's source?</A>
  50. <LI><A NAME="tex2html114"
  51. HREF="tcpreplay-2-faq.html#SECTION02014000000000000000">1.4 What requirements does tcpreplay have?</A>
  52. <LI><A NAME="tex2html115"
  53. HREF="tcpreplay-2-faq.html#SECTION02015000000000000000">1.5 How do I compile tcpreplay?</A>
  54. <LI><A NAME="tex2html116"
  55. HREF="tcpreplay-2-faq.html#SECTION02016000000000000000">1.6 Are there binaries available?</A>
  56. <LI><A NAME="tex2html117"
  57. HREF="tcpreplay-2-faq.html#SECTION02017000000000000000">1.7 Is there a Microsoft Windows port?</A>
  58. <LI><A NAME="tex2html118"
  59. HREF="tcpreplay-2-faq.html#SECTION02018000000000000000">1.8 How is tcpreplay licensed?</A>
  60. <LI><A NAME="tex2html119"
  61. HREF="tcpreplay-2-faq.html#SECTION02019000000000000000">1.9 What is tcpreplay?</A>
  62. <LI><A NAME="tex2html120"
  63. HREF="tcpreplay-2-faq.html#SECTION020110000000000000000">1.10 What isn't tcpreplay?</A>
  64. <LI><A NAME="tex2html121"
  65. HREF="tcpreplay-2-faq.html#SECTION020111000000000000000">1.11 What are some uses for tcpreplay?</A>
  66. <LI><A NAME="tex2html122"
  67. HREF="tcpreplay-2-faq.html#SECTION020112000000000000000">1.12 What are some uses for flowreplay?</A>
  68. <LI><A NAME="tex2html123"
  69. HREF="tcpreplay-2-faq.html#SECTION020113000000000000000">1.13 What happened to version 1.5?</A>
  70. <LI><A NAME="tex2html124"
  71. HREF="tcpreplay-2-faq.html#SECTION020114000000000000000">1.14 What is the history of tcpreplay?</A>
  72. </UL>
  73. <LI><A NAME="tex2html125"
  74. HREF="tcpreplay-2-faq.html#SECTION02020000000000000000">2 Bugs, Feature Requests, and Patches</A>
  75. <UL>
  76. <LI><A NAME="tex2html126"
  77. HREF="tcpreplay-2-faq.html#SECTION02021000000000000000">2.1 Where can I get help, report bugs or contact the developers?</A>
  78. <LI><A NAME="tex2html127"
  79. HREF="tcpreplay-2-faq.html#SECTION02022000000000000000">2.2 What information should I provide when I report a bug?</A>
  80. <LI><A NAME="tex2html128"
  81. HREF="tcpreplay-2-faq.html#SECTION02023000000000000000">2.3 I have a feature request, what should I do?</A>
  82. <LI><A NAME="tex2html129"
  83. HREF="tcpreplay-2-faq.html#SECTION02024000000000000000">2.4 I've written a patch for tcpreplay, how can I submit it?</A>
  84. <LI><A NAME="tex2html130"
  85. HREF="tcpreplay-2-faq.html#SECTION02025000000000000000">2.5 Patch requirements</A>
  86. </UL>
  87. </UL>
  88. <BR>
  89. <LI><A NAME="tex2html131"
  90. HREF="tcpreplay-2-faq.html#SECTION03000000000000000000">2 Basics</A>
  91. <UL>
  92. <LI><A NAME="tex2html132"
  93. HREF="tcpreplay-2-faq.html#SECTION03010000000000000000">3 Basic Tcpreplay Usage</A>
  94. <UL>
  95. <LI><A NAME="tex2html133"
  96. HREF="tcpreplay-2-faq.html#SECTION03011000000000000000">3.1 Replaying the traffic</A>
  97. <LI><A NAME="tex2html134"
  98. HREF="tcpreplay-2-faq.html#SECTION03012000000000000000">3.2 Replaying at different speeds</A>
  99. <LI><A NAME="tex2html135"
  100. HREF="tcpreplay-2-faq.html#SECTION03013000000000000000">3.3 Replaying the same file over and over again</A>
  101. <LI><A NAME="tex2html136"
  102. HREF="tcpreplay-2-faq.html#SECTION03014000000000000000">3.4 Using Configuration Files</A>
  103. </UL>
  104. </UL>
  105. <BR>
  106. <LI><A NAME="tex2html137"
  107. HREF="tcpreplay-2-faq.html#SECTION04000000000000000000">3 Advanced Usage</A>
  108. <UL>
  109. <LI><A NAME="tex2html138"
  110. HREF="tcpreplay-2-faq.html#SECTION04010000000000000000">4 Output: Interfaces, Packets &amp; Files</A>
  111. <UL>
  112. <LI><A NAME="tex2html139"
  113. HREF="tcpreplay-2-faq.html#SECTION04011000000000000000">4.1 Replaying on multiple interfaces</A>
  114. <LI><A NAME="tex2html140"
  115. HREF="tcpreplay-2-faq.html#SECTION04012000000000000000">4.2 Selectively sending or dropping packets</A>
  116. <LI><A NAME="tex2html141"
  117. HREF="tcpreplay-2-faq.html#SECTION04013000000000000000">4.3 Replaying only a few packets</A>
  118. <LI><A NAME="tex2html142"
  119. HREF="tcpreplay-2-faq.html#SECTION04014000000000000000">4.4 Skipping the first bytes in a pcap file</A>
  120. <LI><A NAME="tex2html143"
  121. HREF="tcpreplay-2-faq.html#SECTION04015000000000000000">4.5 Replaying packets which are bigger then the MTU</A>
  122. <LI><A NAME="tex2html144"
  123. HREF="tcpreplay-2-faq.html#SECTION04016000000000000000">4.6 Writing packets to a file</A>
  124. <LI><A NAME="tex2html145"
  125. HREF="tcpreplay-2-faq.html#SECTION04017000000000000000">4.7 Extracting Application Data (Layer 7)</A>
  126. <LI><A NAME="tex2html146"
  127. HREF="tcpreplay-2-faq.html#SECTION04018000000000000000">4.8 Replaying Live Traffic</A>
  128. <LI><A NAME="tex2html147"
  129. HREF="tcpreplay-2-faq.html#SECTION04019000000000000000">4.9 Replaying Packet Capture Formats Other Than Libpcap</A>
  130. <LI><A NAME="tex2html148"
  131. HREF="tcpreplay-2-faq.html#SECTION040110000000000000000">4.10 Replaying Client Traffic to a Server</A>
  132. <LI><A NAME="tex2html149"
  133. HREF="tcpreplay-2-faq.html#SECTION040111000000000000000">4.11 Decoding Packets</A>
  134. </UL>
  135. <LI><A NAME="tex2html150"
  136. HREF="tcpreplay-2-faq.html#SECTION04020000000000000000">5 Packet Editing</A>
  137. <UL>
  138. <LI><A NAME="tex2html151"
  139. HREF="tcpreplay-2-faq.html#SECTION04021000000000000000">5.1 Rewriting MAC addresses</A>
  140. <LI><A NAME="tex2html152"
  141. HREF="tcpreplay-2-faq.html#SECTION04022000000000000000">5.2 Randomizing IP addresses</A>
  142. <LI><A NAME="tex2html153"
  143. HREF="tcpreplay-2-faq.html#SECTION04023000000000000000">5.3 Replaying (de)truncated packets</A>
  144. <LI><A NAME="tex2html154"
  145. HREF="tcpreplay-2-faq.html#SECTION04024000000000000000">5.4 Rewriting Layer 2 with -2</A>
  146. <LI><A NAME="tex2html155"
  147. HREF="tcpreplay-2-faq.html#SECTION04025000000000000000">5.5 Rewriting DLT_LINUX_SLL (Linux Cooked Socket) captures</A>
  148. <LI><A NAME="tex2html156"
  149. HREF="tcpreplay-2-faq.html#SECTION04026000000000000000">5.6 Rewriting IP Addresses (pseudo-NAT)</A>
  150. <LI><A NAME="tex2html157"
  151. HREF="tcpreplay-2-faq.html#SECTION04027000000000000000">5.7 Advanced pseudo-NAT</A>
  152. <LI><A NAME="tex2html158"
  153. HREF="tcpreplay-2-faq.html#SECTION04028000000000000000">5.8 IP Endpoints</A>
  154. <LI><A NAME="tex2html159"
  155. HREF="tcpreplay-2-faq.html#SECTION04029000000000000000">5.9 Unifying Dual-Outputs</A>
  156. </UL>
  157. <LI><A NAME="tex2html160"
  158. HREF="tcpreplay-2-faq.html#SECTION04030000000000000000">6 Tcpprep Usage</A>
  159. <UL>
  160. <LI><A NAME="tex2html161"
  161. HREF="tcpreplay-2-faq.html#SECTION04031000000000000000">6.1 What is tcpprep?</A>
  162. <LI><A NAME="tex2html162"
  163. HREF="tcpreplay-2-faq.html#SECTION04032000000000000000">6.2 How does tcpprep work? </A>
  164. <LI><A NAME="tex2html163"
  165. HREF="tcpreplay-2-faq.html#SECTION04033000000000000000">6.3 Does tcpprep modify my libpcap file?</A>
  166. <LI><A NAME="tex2html164"
  167. HREF="tcpreplay-2-faq.html#SECTION04034000000000000000">6.4 Why use tcpprep?</A>
  168. <LI><A NAME="tex2html165"
  169. HREF="tcpreplay-2-faq.html#SECTION04035000000000000000">6.5 Can a cache file be used for multiple (different) libpcap files? </A>
  170. <LI><A NAME="tex2html166"
  171. HREF="tcpreplay-2-faq.html#SECTION04036000000000000000">6.6 Why would I want to use tcpreplay with two network cards? </A>
  172. <LI><A NAME="tex2html167"
  173. HREF="tcpreplay-2-faq.html#SECTION04037000000000000000">6.7 How big are the cache files?</A>
  174. <LI><A NAME="tex2html168"
  175. HREF="tcpreplay-2-faq.html#SECTION04038000000000000000">6.8 What are these 'modes' tcpprep has? </A>
  176. <LI><A NAME="tex2html169"
  177. HREF="tcpreplay-2-faq.html#SECTION04039000000000000000">6.9 Splitting traffic based upon IP address</A>
  178. <LI><A NAME="tex2html170"
  179. HREF="tcpreplay-2-faq.html#SECTION040310000000000000000">6.10 Auto Mode</A>
  180. <LI><A NAME="tex2html171"
  181. HREF="tcpreplay-2-faq.html#SECTION040311000000000000000">6.11 Selectively sending/dropping packets</A>
  182. <LI><A NAME="tex2html172"
  183. HREF="tcpreplay-2-faq.html#SECTION040312000000000000000">6.12 Using tcpprep cache files with tcpreplay</A>
  184. <LI><A NAME="tex2html173"
  185. HREF="tcpreplay-2-faq.html#SECTION040313000000000000000">6.13 Commenting tcpprep cache files</A>
  186. </UL>
  187. <LI><A NAME="tex2html174"
  188. HREF="tcpreplay-2-faq.html#SECTION04040000000000000000">7 Flowreplay Usage</A>
  189. <UL>
  190. <LI><A NAME="tex2html175"
  191. HREF="tcpreplay-2-faq.html#SECTION04041000000000000000">7.1 How flowreplay works</A>
  192. <LI><A NAME="tex2html176"
  193. HREF="tcpreplay-2-faq.html#SECTION04042000000000000000">7.2 Running flowreplay</A>
  194. </UL>
  195. <LI><A NAME="tex2html177"
  196. HREF="tcpreplay-2-faq.html#SECTION04050000000000000000">8 Tuning OS's for high performance</A>
  197. <UL>
  198. <LI><A NAME="tex2html178"
  199. HREF="tcpreplay-2-faq.html#SECTION04051000000000000000">8.1 Linux 2.4.x</A>
  200. <LI><A NAME="tex2html179"
  201. HREF="tcpreplay-2-faq.html#SECTION04052000000000000000">8.2 *BSD</A>
  202. </UL>
  203. <LI><A NAME="tex2html180"
  204. HREF="tcpreplay-2-faq.html#SECTION04060000000000000000">9 Understanding Common Error and Warning Messages</A>
  205. <UL>
  206. <LI><A NAME="tex2html181"
  207. HREF="tcpreplay-2-faq.html#SECTION04061000000000000000">9.1 Can't open eth0: libnet_select_device(): Can't find interface eth0</A>
  208. <LI><A NAME="tex2html182"
  209. HREF="tcpreplay-2-faq.html#SECTION04062000000000000000">9.2 Can't open lo: libnet_select_device(): Can't find interface lo</A>
  210. <LI><A NAME="tex2html183"
  211. HREF="tcpreplay-2-faq.html#SECTION04063000000000000000">9.3 Can't open eth0: UID != 0</A>
  212. <LI><A NAME="tex2html184"
  213. HREF="tcpreplay-2-faq.html#SECTION04064000000000000000">9.4 100000 write attempts failed from full buffers and were repeated</A>
  214. <LI><A NAME="tex2html185"
  215. HREF="tcpreplay-2-faq.html#SECTION04065000000000000000">9.5 Invalid mac address: 00:00:00:00:00:00</A>
  216. <LI><A NAME="tex2html186"
  217. HREF="tcpreplay-2-faq.html#SECTION04066000000000000000">9.6 Unable to process test.cache: cache file version missmatch</A>
  218. <LI><A NAME="tex2html187"
  219. HREF="tcpreplay-2-faq.html#SECTION04067000000000000000">9.7 Skipping SLL loopback packet.</A>
  220. <LI><A NAME="tex2html188"
  221. HREF="tcpreplay-2-faq.html#SECTION04068000000000000000">9.8 Packet length (8892) is greater then MTU; skipping packet.</A>
  222. <LI><A NAME="tex2html189"
  223. HREF="tcpreplay-2-faq.html#SECTION04069000000000000000">9.9 Why is tcpreplay not sending all the packets?</A>
  224. </UL>
  225. <LI><A NAME="tex2html190"
  226. HREF="tcpreplay-2-faq.html#SECTION04070000000000000000">10 Required Libraries and Tools</A>
  227. <UL>
  228. <LI><A NAME="tex2html191"
  229. HREF="tcpreplay-2-faq.html#SECTION04071000000000000000">10.1 Libpcap</A>
  230. <LI><A NAME="tex2html192"
  231. HREF="tcpreplay-2-faq.html#SECTION04072000000000000000">10.2 Libnet</A>
  232. <LI><A NAME="tex2html193"
  233. HREF="tcpreplay-2-faq.html#SECTION04073000000000000000">10.3 Libpcapnav</A>
  234. <LI><A NAME="tex2html194"
  235. HREF="tcpreplay-2-faq.html#SECTION04074000000000000000">10.4 Tcpdump</A>
  236. </UL>
  237. </UL>
  238. <BR>
  239. <LI><A NAME="tex2html195"
  240. HREF="tcpreplay-2-faq.html#SECTION05000000000000000000">4 Other Resources</A>
  241. <UL>
  242. <LI><A NAME="tex2html196"
  243. HREF="tcpreplay-2-faq.html#SECTION05010000000000000000">11 Other pcap tools available</A>
  244. <UL>
  245. <LI><A NAME="tex2html197"
  246. HREF="tcpreplay-2-faq.html#SECTION05011000000000000000">11.1 Tools to capture network traffic or decode pcap files</A>
  247. <LI><A NAME="tex2html198"
  248. HREF="tcpreplay-2-faq.html#SECTION05012000000000000000">11.2 Tools to edit pcap files</A>
  249. <LI><A NAME="tex2html199"
  250. HREF="tcpreplay-2-faq.html#SECTION05013000000000000000">11.3 Other useful tools</A>
  251. </UL>
  252. <LI><A NAME="tex2html200"
  253. HREF="tcpreplay-2-faq.html#SECTION06010000000000000000">1 BSD License</A>
  254. </UL></UL>
  255. <!--End of Table of Contents-->
  256. <P>
  257. <H1><A NAME="SECTION02000000000000000000">
  258. 1 Before You Start</A>
  259. </H1>
  260. <P>
  261. <H1><A NAME="SECTION02010000000000000000">
  262. 1 General Info</A>
  263. </H1>
  264. <P>
  265. <H2><A NAME="SECTION02011000000000000000">
  266. 1.1 What is this FAQ for?</A>
  267. </H2>
  268. <P>
  269. Tcpreplay is a suite of powerful tools, but with that power comes
  270. complexity. While I have done my best to write good man pages for
  271. tcpreplay and it's associated utilities, I understand that many people
  272. may want more information then I can provide in the man pages. Additionally,
  273. this FAQ attempts to cover material which I feel will be of use to
  274. people using tcpreplay, as well as common questions that occur on
  275. the Tcpreplay-Users &lt;; mailing
  276. list.
  277. <P>
  278. <H2><A NAME="SECTION02012000000000000000">
  279. 1.2 What tools come with tcpreplay?</A>
  280. </H2>
  281. <P>
  282. <UL>
  283. <LI>tcpreplay - replay ethernet packets stored in a pcap file as they
  284. were captured
  285. </LI>
  286. <LI>tcpprep - a pcap pre-processor for tcpreplay
  287. </LI>
  288. <LI>flowreplay<A NAME="tex2html1"
  289. HREF="#foot310"><SUP>1</SUP></A> - connects to a server(s) and replays the client side of the connection
  290. stored in a pcap file
  291. </LI>
  292. <LI>pcapmerge - merges two or more pcap files into one
  293. </LI>
  294. <LI>capinfo - displays basic information about a pcap file
  295. </LI>
  296. </UL>
  297. <P>
  298. <H2><A NAME="SECTION02013000000000000000">
  299. 1.3 How can I get tcpreplay's source?</A>
  300. </H2>
  301. <P>
  302. The source code is available in tarball format on the tcpreplay homepage:
  303. I also encourage users familiar
  304. with CVS to try checking out the latest code as it often has additional
  305. features and bugfixes not found in the tarballs.
  306. <P>
  307. cvs login
  308. <BR>
  309. Pass: <I>&lt;Enter&gt;</I>
  310. <BR>
  311. cvs -z3 co tcpreplay
  312. <P>
  313. <H2><A NAME="SECTION02014000000000000000">
  314. 1.4 What requirements does tcpreplay have?</A>
  315. </H2>
  316. <P>
  317. <OL>
  318. <LI>You'll need the libnet and libpcap libraries.
  319. </LI>
  320. <LI>To support the jump to offset feature, you'll need the libpcapnav<A NAME="tex2html2"
  321. HREF="#foot38"><SUP>2</SUP></A> library.
  322. </LI>
  323. <LI>To support the packet decoding feature you'll need tcpdump<A NAME="tex2html3"
  324. HREF="#foot39"><SUP>3</SUP></A> installed.
  325. </LI>
  326. <LI>You'll also need a compatible operating system. Basically, any UNIX-like
  327. or UNIX-based operating system should work. Linux, *BSD, Solaris,
  328. OS X and others should all work. If you find any compatibility issues
  329. with any UNIX-like/based OS, please let me know.
  330. </LI>
  331. </OL>
  332. <P>
  333. <H2><A NAME="SECTION02015000000000000000">
  334. 1.5 How do I compile tcpreplay?</A>
  335. </H2>
  336. <P>
  337. Two easy steps:
  338. <P>
  339. <OL>
  340. <LI>As a normal user: <I>./configure &amp;&amp; make</I>
  341. </LI>
  342. <LI>As root: <I>make test -i &amp;&amp; make install</I>
  343. </LI>
  344. </OL>
  345. There are some optional arguments which can be passed to the configure
  346. script which may help in cases where your libnet, libpcap, libpcapnav
  347. or tcpdump installation is not standard or if it can't determine the
  348. correct network interface card to use for testing. If you find that
  349. configure isn't completing correctly, run: <I>./configure -help</I>
  350. for more information.
  351. <P>
  352. A few comments about 'make test':
  353. <P>
  354. <UL>
  355. <LI>make test is just a series of sanity checks which try to find serious
  356. bugs (crashes) in tcpprep and tcpreplay.
  357. </LI>
  358. <LI>make test requires at least one properly configured network interface.
  359. If the configure script can't guess what a valid interface is you
  360. can specify it with the -with-testnic and -with-testnic2 arguments.
  361. </LI>
  362. <LI>If make test fails, often you can find details in test/test.log.
  363. </LI>
  364. <LI>OpenBSD's make has a bug where it ignores the MAKEFLAGS variable in
  365. the Makefile, hence you'll probably want to run: <I>make -is test</I>
  366. instead.
  367. </LI>
  368. </UL>
  369. <P>
  370. <H2><A NAME="SECTION02016000000000000000">
  371. 1.6 Are there binaries available?</A>
  372. </H2>
  373. <P>
  374. Occasionally. And even when we do, generally only for one or two operating
  375. systems. Generally speaking, we assume people who want to use a tool
  376. like this can figure out how to compile it.
  377. <P>
  378. <H2><A NAME="SECTION02017000000000000000">
  379. 1.7 Is there a Microsoft Windows port?</A>
  380. </H2>
  381. <P>
  382. Not really. We had one user port the code over for a slightly old
  383. version of tcpreplay to Windows. Now we're looking for someone to
  384. help merge and maintain the code in to the main development tree.
  385. If you're interested in helping with this please contact Aaron Turner
  386. or the tcpreplay-users list.
  387. <P>
  388. <H2><A NAME="SECTION02018000000000000000">
  389. 1.8 How is tcpreplay licensed?</A>
  390. </H2>
  391. <P>
  392. Tcpreplay is licensed under a BSD-style license. For details, see
  393. Appendix A.
  394. <P>
  395. <H2><A NAME="SECTION02019000000000000000">
  396. 1.9 What is tcpreplay?</A>
  397. </H2>
  398. <P>
  399. In the simplest terms, tcpreplay is a tool to send network traffic
  400. stored in pcap format back onto the network; basically the exact opposite
  401. of tcpdump. Tcpreplay also has the ability to edit various packet
  402. headers as the packets are sent. Tcpreplay is also a suite of tools:
  403. tcpreplay, tcpprep, pcapmerge, capinfo and flowreplay.
  404. <P>
  405. <H2><A NAME="SECTION020110000000000000000">
  406. 1.10 What isn't tcpreplay?</A>
  407. </H2>
  408. <P>
  409. Tcpreplay is <I>not</I> a tool to replay captured traffic to a server
  410. or client. Specifically, tcpreplay does not have the ability to rewrite
  411. IP addresses to a user-specified value or synchronize TCP sequence
  412. and acknowledgment numbers. In other words, tcpreplay can't ``connect''
  413. to a server or be used to emulate a server and have clients connect
  414. to it. If you're looking for that, check out flowreplay.
  415. <P>
  416. <H2><A NAME="SECTION020111000000000000000">
  417. 1.11 What are some uses for tcpreplay?</A>
  418. </H2>
  419. <P>
  420. Originally, tcpreplay was written to test network intrusion detection
  421. systems (NIDS), however tcpreplay has been used to test firewalls,
  422. routers, and other network devices.
  423. <P>
  424. <H2><A NAME="SECTION020112000000000000000">
  425. 1.12 What are some uses for flowreplay?</A>
  426. </H2>
  427. <P>
  428. A lot of people wanted a tool like tcpreplay, but wanted to be able
  429. to replay traffic <I>to</I> a server. Since tcpreplay was unable to
  430. do this, I developed flowreplay which replays the data portion of
  431. the flow, but recreates the connection to the specified server(s).
  432. This makes flowreplay an ideal tool to test host intrusion detection
  433. systems (HIDS) as well as captured exploits and security patches when
  434. the actual exploit code is not available. Please note that flowreplay
  435. is still alpha quality code and is currently missing some important
  436. features.
  437. <P>
  438. <H2><A NAME="SECTION020113000000000000000">
  439. 1.13 What happened to version 1.5?</A>
  440. </H2>
  441. <P>
  442. After looking at all the changes that have happened over the last
  443. year or so, I decided that it was finally time to graduate tcpreplay
  444. to 2.0 status. Hence the 1.5 branch was renamed 2.0.
  445. <P>
  446. <H2><A NAME="SECTION020114000000000000000">
  447. 1.14 What is the history of tcpreplay?</A>
  448. </H2>
  449. <P>
  450. Tcpreplay has had quite a few authors over the past five or so years.
  451. One of the advantages of the BSD and GPL licenses is that if someone
  452. becomes unable or unwilling to continue development, anyone else can
  453. take over.
  454. <P>
  455. Originally, Matt Undy of Anzen Computing wrote tcpreplay. Matt released
  456. version 1.0.1 sometime in 1999. Sometime after that, Anzen Computing
  457. was (at least partially) purchased by NFR and development ceased.
  458. <P>
  459. Then in 2001, two people independently started work on tcpreplay:
  460. Matt Bing of NFR and Aaron Turner. After developing a series of patches
  461. (the -adt branch), Aaron attempted to send the patches in to be included
  462. in the main development tree.
  463. <P>
  464. After some discussion between Aaron and Matt Bing, they decided to
  465. continue development together. Since then, over a dozen stable releases
  466. have been made and more then twenty new features have been added,
  467. including the addition of a number of accessory tools.
  468. <P>
  469. Today, Aaron continues active development of the code.
  470. <P>
  471. <H1><A NAME="SECTION02020000000000000000">
  472. 2 Bugs, Feature Requests, and Patches</A>
  473. </H1>
  474. <P>
  475. <H2><A NAME="SECTION02021000000000000000">
  476. 2.1 Where can I get help, report bugs or contact the developers?</A>
  477. </H2>
  478. <P>
  479. The best place to get help or report a bug is the Tcpreplay-Users
  480. mailing list:
  481. <BR>
  483. <P>
  484. <H2><A NAME="SECTION02022000000000000000">
  485. 2.2 What information should I provide when I report a bug?</A>
  486. </H2>
  487. <P>
  488. One of the most frustrating things for any developer trying to help
  489. a user with a problem is not enough information. Please be sure to
  490. include <I>at minimum</I> the following information, however any additional
  491. information you feel may be helpful will be appreciated.
  492. <P>
  493. <UL>
  494. <LI>Version information (output of -V)
  495. </LI>
  496. <LI>Command line used (options and arguments)
  497. </LI>
  498. <LI>Platform (Red Hat Linux 9 on Intel, Solaris 7 on SPARC, etc)
  499. </LI>
  500. <LI>Error message (if available) and/or description of problem
  501. </LI>
  502. <LI>If possible, attach the pcap file used (compressed with bzip2 or gzip
  503. preferred)
  504. </LI>
  505. </UL>
  506. <P>
  507. <H2><A NAME="SECTION02023000000000000000">
  508. 2.3 I have a feature request, what should I do?</A>
  509. </H2>
  510. <P>
  511. Let us know! Many of the features exist today because users like you
  512. asked for them. To make a feature request, you can either email the
  513. tcpreplay-users mailing list (see above) or fill out the feature request
  514. form on the tcpreplay SourceForge website.
  515. <P>
  516. <H2><A NAME="SECTION02024000000000000000">
  517. 2.4 I've written a patch for tcpreplay, how can I submit it?</A>
  518. </H2>
  519. <P>
  520. I'm always willing to include new features or bug fixes submitted
  521. by users. You may email me directly or the tcpreplay-users mailing
  522. list. Please <I>do not</I> use the Patch Tracker on the tcpreplay
  523. SourceForge web site.
  524. <P>
  525. <H2><A NAME="SECTION02025000000000000000">
  526. 2.5 Patch requirements</A>
  527. </H2>
  528. <P>
  529. <UL>
  530. <LI>Be aware that submitting a patch, <I>you are licensing it under
  531. the BSD License</I> as written in Appendix A. If this is not acceptable
  532. to you, then <I>do not</I> send me the patch!
  533. </LI>
  534. <LI>If you wish to maintain the copyright over your code, be sure that
  535. your patch contains the appropriate information.
  536. </LI>
  537. <LI>Please provide a description of what your patch does!
  538. </LI>
  539. <LI>Comment your code! I won't use code I can't understand.
  540. </LI>
  541. <LI>Make sure you are patching a branch that is still being maintained.
  542. Generally that means that most recent stable and development branches
  543. (1.4 and 2.0 at the time of this writing).
  544. </LI>
  545. <LI>Make sure you are patching against the most recent release for that
  546. branch.
  547. </LI>
  548. <LI>Please submit your patch in the unified diff format so I can better
  549. understand what you're changing.
  550. </LI>
  551. <LI>Please provide any relevant personal information you'd like listed
  552. in the CREDITS file.
  553. </LI>
  554. </UL>
  555. Please note that while I'm always interested in patches, I may rewrite
  556. some or all of your submission to maintain a consistent coding style.
  557. <P>
  558. <H1><A NAME="SECTION03000000000000000000">
  559. 2 Basics</A>
  560. </H1>
  561. <P>
  562. <H1><A NAME="SECTION03010000000000000000">
  563. 3 Basic Tcpreplay Usage</A>
  564. </H1>
  565. <P>
  566. <H2><A NAME="SECTION03011000000000000000">
  567. 3.1 Replaying the traffic</A>
  568. </H2>
  569. <P>
  570. To replay a given pcap as it was captured all you need to do is specify
  571. the pcap file and the interface to send the traffic out of:
  572. <P>
  573. <I>tcpreplay -i eth0 sample.pcap</I>
  574. <P>
  575. <H2><A NAME="SECTION03012000000000000000">
  576. 3.2 Replaying at different speeds</A>
  577. </H2>
  578. <P>
  579. You can also replay the traffic at different speeds then it was originally
  580. captured<A NAME="tex2html4"
  581. HREF="#foot311"><SUP>4</SUP></A>. To support this, tcpreplay supports four different flags: -R, -r,
  582. -m, and -p
  583. <P>
  584. Some examples:
  585. <P>
  586. <UL>
  587. <LI>To replay traffic as fast as possible:
  588. <BR><I>tcpreplay -R -i eth0 sample.pcap</I>
  589. </LI>
  590. <LI>To replay traffic at 10Mbps:
  591. <BR><I>tcpreplay -r 10.0 -i eth0 sample.pcap</I>
  592. </LI>
  593. <LI>To replay traffic 7.3 times as fast as it was captured:
  594. <BR><I>tcpreplay -m 7.3 -i eth0 sample.pcap</I>
  595. </LI>
  596. <LI>To replay traffic at half-speed:
  597. <BR><I>tcpreplay -m 0.5 -i eth0 sample.pcap</I>
  598. </LI>
  599. <LI>To replay at 25.5 packets per second:
  600. <BR><I>tcpreplay -p 25.5 -i eth0 sample.pcap</I>
  601. </LI>
  602. </UL>
  603. <P>
  604. <H2><A NAME="SECTION03013000000000000000">
  605. 3.3 Replaying the same file over and over again</A>
  606. </H2>
  607. <P>
  608. Using the loop flag (-l) you can specify that a pcap file will be
  609. sent two or more times<A NAME="tex2html5"
  610. HREF="#foot93"><SUP>5</SUP></A>:
  611. <P>
  612. <UL>
  613. <LI>To replay the sample.pcap file 10 times:
  614. <BR><I>tcpreplay -l 10 -i eth0 sample.pcap</I>
  615. </LI>
  616. <LI>To replay the sample.pcap an infinitely or until CTRL-C is pressed:
  617. <BR><I>tcpreplay -l 0 -i eth0 sample.pcap</I>
  618. </LI>
  619. </UL>
  620. <P>
  621. <H2><A NAME="SECTION03014000000000000000">
  622. 3.4 Using Configuration Files</A>
  623. </H2>
  624. <P>
  625. Tcpreplay offers the options of specifying configuration options in
  626. a config file in addition to the traditional command line. Each configuration
  627. option has an equivalent config file option which is listed in the
  628. tcpreplay man page. To specify the configuration file you'd like to
  629. use, use the -f &lt;filename&gt; option.
  630. <P>
  631. Configuration files have one option per line, and lines beginning
  632. with the pound sign (#) are considered comments and ignored. An example
  633. config file follows:
  634. <P>
  635. # send traffic out 'eth0'
  636. <BR>
  637. intf eth0
  638. <BR>
  639. <BR># loop 5 times
  640. <BR>
  641. loop 5
  642. <BR>
  643. <BR># send traffic 2x as fast
  644. <BR>
  645. multiplier 2
  646. <BR>
  647. <BR># pad any packets out to their original size if they were truncated
  648. during capture
  649. <BR>
  650. untruncate pad
  651. <BR>
  652. <BR>
  653. <BR>
  654. <P>
  655. You would then execute:
  656. <BR><I>tcpreplay -f myconfigfile sample.pcap</I>
  657. <P>
  658. <H1><A NAME="SECTION04000000000000000000">
  659. 3 Advanced Usage</A>
  660. </H1>
  661. <P>
  662. <H1><A NAME="SECTION04010000000000000000">
  663. 4 Output: Interfaces, Packets &amp; Files</A>
  664. </H1>
  665. <P>
  666. <H2><A NAME="SECTION04011000000000000000">
  667. 4.1 Replaying on multiple interfaces</A>
  668. </H2>
  669. <P>
  670. Tcpreplay can also split traffic so that each side of a connection
  671. is sent out a different interface<A NAME="tex2html6"
  672. HREF="#foot103"><SUP>6</SUP></A>. In order to do this, tcpreplay needs the name of the second interface
  673. (-j) and a way to split the traffic. Currently, there are two ways
  674. to split traffic:
  675. <P>
  676. <OL>
  677. <LI>-C = split traffic by source IP address which is specified in CIDR
  678. notation
  679. </LI>
  680. <LI>-c = split traffic according to a tcpprep cachefile<A NAME="tex2html7"
  681. HREF="#foot105"><SUP>7</SUP></A>
  682. </LI>
  683. </OL>
  684. When splitting traffic, it is important to remember that traffic that
  685. matches the filter is sent out the primary interface (-i). In this
  686. case, when splitting traffic by source IP address, you provide a list
  687. of networks in CIDR notation. For example:
  688. <P>
  689. <UL>
  690. <LI>To send traffic from out eth0 and everything else out eth1:
  691. <BR><I>tcpreplay -C -i eth0 -j eth1 sample.pcap</I>
  692. </LI>
  693. <LI>To send traffic from and out eth0 and everything
  694. else out eth1:
  695. <BR><I>tcpreplay -C, -i eth0 -j eth1 sample.pcap</I>
  696. </LI>
  697. <LI>After using tcpprep to generate a cache file, you can use it to split
  698. traffic between two interfaces like this:
  699. <BR><I>tcpreplay -c sample.cache -i eth0 -j eth1 sample.pcap</I>
  700. </LI>
  701. </UL>
  702. <P>
  703. <H2><A NAME="SECTION04012000000000000000">
  704. 4.2 Selectively sending or dropping packets</A>
  705. </H2>
  706. <P>
  707. Sometimes, you want to do some post-capture filtering of packets.
  708. Tcpreplay let's you have some control over which packets get sent.
  709. <P>
  710. <OL>
  711. <LI>-M = disables sending of martian packets. By definition, martian packets
  712. have a source IP of 0.x.x.x, 127.x.x.x, or 255.x.x.x
  713. </LI>
  714. <LI>-x = send packets which match a specific pattern
  715. </LI>
  716. <LI>-X = send packets which do not match a specific pattern
  717. </LI>
  718. </OL>
  719. Both -x and -X support a variety of pattern matching types. These
  720. types are specified by a single character, followed by a colon, followed
  721. by the pattern. The following pattern matching types are available:
  722. <P>
  723. <OL>
  724. <LI>S - Source IP
  725. <BR>
  726. Pattern is a comma delimited CIDR notation
  727. </LI>
  728. <LI>D - Destination IP
  729. <BR>
  730. Pattern is a comma delimited CIDR notation
  731. </LI>
  732. <LI>B - Both source and destination IP must match
  733. <BR>
  734. Pattern is a comma delimited CIDR notation
  735. </LI>
  736. <LI>E - Either source or destination IP must match
  737. <BR>
  738. Pattern is a comma delimited CIDR notation
  739. </LI>
  740. <LI>P - A list of packet numbers from the pcap file.
  741. <BR>
  742. Pattern is a series of numbers, separated by commas or dashes.
  743. </LI>
  744. <LI>F - BPF syntax (same as used in tcpdump).
  745. <BR>
  746. Filter must be quoted and is only supported with -x<A NAME="tex2html8"
  747. HREF="#foot116"><SUP>8</SUP></A>.
  748. </LI>
  749. </OL>
  750. Examples:
  751. <P>
  752. <UL>
  753. <LI>To only send traffic that is too and from a host in
  754. <BR><I>tcpreplay -x B: -i eth0 sample.pcap</I>
  755. </LI>
  756. <LI>To not send traffic that is too or from a host in
  757. <BR><I>tcpreplay -X E: -i eth0 sample.pcap</I>
  758. </LI>
  759. <LI>To send every packet except the first 10 packets:
  760. <BR><I>tcpreplay -X P:1-10 -i eth0 sample.pcap</I>
  761. </LI>
  762. <LI>To only send the first 50 packets followed by packets: 100, 150, 200
  763. and 250:
  764. <BR><I>tcpreplay -x P:1-50,100,150,200,250 -i eth0 sample.pcap</I>
  765. </LI>
  766. <LI>To only send TCP packets from
  767. <BR>
  768. tcpreplay -x F:'tcp and host' -i eth0 sample.pcap
  769. </LI>
  770. </UL>
  771. <P>
  772. <H2><A NAME="SECTION04013000000000000000">
  773. 4.3 Replaying only a few packets</A>
  774. </H2>
  775. <P>
  776. Using the limit packets flag (-L) you can specify that tcpreplay will
  777. only send at most a specified number of packets.
  778. <P>
  779. <UL>
  780. <LI>To send at most 100 packets:
  781. <BR><I>tcpreplay -i eth0 -L 100 sample.pcap</I>
  782. </LI>
  783. </UL>
  784. <P>
  785. <H2><A NAME="SECTION04014000000000000000">
  786. 4.4 Skipping the first bytes in a pcap file</A>
  787. </H2>
  788. <P>
  789. If you want to skip the beginning of a pcap file, you can use the
  790. offset flag (-o) to skip a specified number of bytes and start sending
  791. on the next packet.
  792. <P>
  793. <UL>
  794. <LI>To skip 15Kb into the pcap file and start sending packets from there:
  795. <BR><I>tcpreplay -i eth0 -o 15000 sample.pcap</I>
  796. </LI>
  797. </UL>
  798. <P>
  799. <H2><A NAME="SECTION04015000000000000000">
  800. 4.5 Replaying packets which are bigger then the MTU</A>
  801. </H2>
  802. <P>
  803. Occasionally, you might find yourself trying to replay a pcap file
  804. which contains packets which are larger then the MTU for the sending
  805. interface. This might be due to the packets being captured on the
  806. loopback interface or on a 1000Mbps ethernet interface supporting
  807. ``jumbo frames''. I've even seen packets which are 1500 bytes
  808. but contain both an ethernet header and trailer which bumps the total
  809. frame size to 1518 which is 4 bytes too large.
  810. <P>
  811. By default, tcpreplay will skip these packets and not send them. Alternatively,
  812. you can specify the -T flag to truncate these packets to the MTU and
  813. then send them. Of course this may invalidate your testing, but it
  814. has proven useful in certain situations. Also, when this feature is
  815. enabled, tcpreplay will automatically recalculate the IP and TCP,
  816. UDP or ICMP checksums as needed. Example:
  817. <P>
  818. <I>tcpreplay -i eth0 -T sample.pcap</I>
  819. <P>
  820. <H2><A NAME="SECTION04016000000000000000">
  821. 4.6 Writing packets to a file</A>
  822. </H2>
  823. <P>
  824. It's not always necessary to write packets to the network. Since tcpreplay
  825. has so many features which modify and select which packets are sent,
  826. it is occasionally useful to save these changes to another pcap file
  827. for comparison. Rather then running a separate tcpdump process to
  828. capture the packets, tcpreplay now supports output directly to a file.
  829. Example:
  830. <P>
  831. <I>tcpreplay -i eth0 -w output.pcap -F -u pad -x E: input1.pcap
  832. input2.pcap input3.pcap</I>
  833. <P>
  834. Notice that specifying an interface is still required (required for
  835. various internal functions), but all the packets will be written to
  836. <I>output.pcap</I>.
  837. <P>
  838. You can also split traffic into two files by using -W &lt;2nd output
  839. file&gt;.
  840. <P>
  841. <H2><A NAME="SECTION04017000000000000000">
  842. 4.7 Extracting Application Data (Layer 7)</A>
  843. </H2>
  844. <P>
  845. New to version 2.0 is the ability to extract the application layer
  846. data from the packets and write them to a file. In the man page, we
  847. call this ``data dump mode'' which is enabled with -D. It's important
  848. to specify -D before -w (and -W if you're splitting data into two
  849. files). Example:
  850. <P>
  851. <I>tcpreplay -D -i eth0 -j eth0 -w clientdata -W serverdata -C
  852. sample.pcap</I>
  853. <P>
  854. <H2><A NAME="SECTION04018000000000000000">
  855. 4.8 Replaying Live Traffic</A>
  856. </H2>
  857. <P>
  858. You can now replay live traffic sniffed on one network interface and
  859. replay it on another interface using the -S flag to indicate sniff
  860. mode and the appropriate snaplen in bytes (0 denotes the entire packet).
  861. You can also enabling bi-directional traffic using the bridge mode
  862. flag: -b.
  863. <P>
  864. N<SMALL>OTE:</SMALL> It is critical for your sanity (and to prevent your
  865. murder by your network administrators) that the input interface and
  866. the output interface be on separate networks and additionally that
  867. no other network devices (such as bridges, switches, routers, etc)
  868. be connecting the two networks, else you will surely get a networkstorm
  869. the likes that have not been seen for years.
  870. <P>
  871. <UL>
  872. <LI>Send packets sniffed on eth0 out eth1:
  873. <BR><I>tcpreplay -i eth1 -S 0 eth0</I>
  874. </LI>
  875. <LI>Bridge two subnets connected to eth0 and eth1:
  876. <BR><I>tcpreplay -i eth0 -j eth1 -b -S 0</I>
  877. </LI>
  878. </UL>
  879. By default, tcpreplay listens in promiscuous mode on the specified
  880. interface, however if you only want to send unicasts directed for
  881. the local system and broadcasts, you can specify the ``not_nosy''
  882. option in the configuration file or -n on the command line. Note that
  883. if another program has already placed the interface in promiscuous
  884. mode, the -n flag will have no effect, so you may want to use the
  885. -x or -X argument to limit packets.
  886. <P>
  887. <H2><A NAME="SECTION04019000000000000000">
  888. 4.9 Replaying Packet Capture Formats Other Than Libpcap</A>
  889. </H2>
  890. <P>
  891. There are about as many different capture file formats as there are
  892. sniffers. In the interest of simplicity, tcpreplay only supports libpcap<A NAME="tex2html9"
  893. HREF="#foot149"><SUP>9</SUP></A>. If you would like to replay a file in one of these multitude of
  894. formats, the excellent open source tool Ethereal easily allows you
  895. to convert it to libpcap. For instance, to convert a file in Sun's
  896. snoop format to libpcap, issue the command:
  897. <P>
  898. <I>tethereal -r blah.snoop -w blah.pcap</I>
  899. <P>
  900. and replay the resulting file.
  901. <P>
  902. <H2><A NAME="SECTION040110000000000000000">
  903. 4.10 Replaying Client Traffic to a Server</A>
  904. </H2>
  905. <P>
  906. A common question on the tcpreplay-users list is how does one replay
  907. the client side of a connection back to a server. Unfortunately, tcpreplay
  908. doesn't support this right now. The major problem concerns syncing
  909. up TCP Seq/Ack numbers which will be different. ICMP also often contains
  910. IP header information which would need to be adjusted. About the only
  911. thing that could be easy to do is UDP, which isn't usually requested.
  912. <P>
  913. This is however a feature that we're looking into implementing in
  914. the flowreplay utility. If you're interested in helping work on this
  915. feature, please contact us and we'd be more then happy to work with
  916. you. At this time however, we don't have an ETA when this will be
  917. implemented, so don't bother asking.
  918. <P>
  919. <H2><A NAME="SECTION040111000000000000000">
  920. 4.11 Decoding Packets</A>
  921. </H2>
  922. <P>
  923. If the tcpdump binary is installed on your system when tcpreplay is
  924. compiled, it will allow you to decode packets as they are sent without
  925. running tcpdump in a separate window or worrying about it capturing
  926. packets which weren't sent by tcpreplay.
  927. <P>
  928. <UL>
  929. <LI>Decode packets as they are sent:
  930. <BR><I>tcpreplay -i eth0 -v sample.pcap</I>
  931. </LI>
  932. <LI>Decode packets with the link level header:
  933. <BR><I>tcpreplay -i eth0 -v -A ``-e'' sample.pcap</I>
  934. </LI>
  935. <LI>Fully decode and send one packet at a time:
  936. <BR><I>tcpreplay -i eth0 -v -1 -A ``-s0 -evvvxX'' sample.pcap</I>
  937. </LI>
  938. </UL>
  939. Note that tcpreplay automatically applies the -n flag to disable DNS
  940. lookups which would slow down tcpdump too much to make it effective.
  941. <P>
  942. <H1><A NAME="SECTION04020000000000000000">
  943. 5 Packet Editing</A>
  944. </H1>
  945. <P>
  946. <H2><A NAME="SECTION04021000000000000000">
  947. 5.1 Rewriting MAC addresses</A>
  948. </H2>
  949. <P>
  950. If you ever want to send traffic to another device on a switched LAN,
  951. you may need to change the destination MAC address of the packets.
  952. Tcpreplay allows you to set the destination MAC for each interface
  953. independently using the -I and -J switches. As of version 2.1.0, you
  954. can also specify the source MAC via -k and -K. Example:
  955. <P>
  956. <UL>
  957. <LI>To send traffic out eth0 with a destination MAC of your router (00:00:01:02:03:04)
  958. and the source MAC of the server (00:20:30:40:50:60):
  959. <BR><I>tcpreplay -i eth0 -I 00:00:01:02:03:04 -k 00:20:30:40:50:60
  960. sample.pcap</I>
  961. </LI>
  962. <LI>To split traffic between internal ( and external addresses
  963. and to send that traffic to the two interfaces of a firewall:
  964. <BR><I>tcpreplay -i eth0 -j eth1 -I 00:01:00:00:AA:01 -J 00:01:00:00:AA:02
  965. -C sample.pcap</I>
  966. </LI>
  967. </UL>
  968. <P>
  969. <H2><A NAME="SECTION04022000000000000000">
  970. 5.2 Randomizing IP addresses</A>
  971. </H2>
  972. <P>
  973. Occasionally, it is necessary to have tcpreplay rewrite the source
  974. and destination IP addresses, yet maintain the client/server relationship.
  975. Such a case might be having multiple copies of tcpreplay running at
  976. the same time using the same pcap file while trying to stress test
  977. firewall, IDS or other stateful device. If you didn't change the source
  978. and destination IP addresses, the device under test would get confused
  979. since it would see multiple copies of the same connection occurring
  980. at the same time. In order to accomplish this, tcpreplay accepts a
  981. user specified seed which is used to generate pseudo-random IP addresses.
  982. Also, when this feature is enabled, tcpreplay will automatically recalculate
  983. the IP and TCP, UDP or ICMP checksums as needed. Example:
  984. <P>
  985. <I>tcpreplay -i eth0 -s 1239 sample.pcap &amp;</I>
  986. <BR><I>tcpreplay -i eth0 -s 76 sample.pcap &amp;</I>
  987. <BR><I>tcpreplay -i eth0 -s 239 sample.pcap &amp;</I>
  988. <BR><I>tcpreplay -i eth0 sample.pcap</I>
  989. <P>
  990. <H2><A NAME="SECTION04023000000000000000">
  991. 5.3 Replaying (de)truncated packets</A>
  992. </H2>
  993. <P>
  994. Occasionally, it is necessary to replay traffic which has been truncated
  995. by tcpdump. This occurs when the tcpdump snaplen is smaller then the
  996. actual packet size. Since this will create problems for devices which
  997. are expecting a full-sized packet or attempting checksum calculations,
  998. tcpreplay allows you to either pad the packet with zeros or reset
  999. the packet length in the headers to the actual packet size. In either
  1000. case, the IP and TCP, UDP or ICMP checksums are recalculated. Examples:
  1001. <P>
  1002. <UL>
  1003. <LI>Pad truncated packets:
  1004. <BR><I>tcpreplay -i eth0 -u pad sample.pcap</I>
  1005. </LI>
  1006. <LI>Rewrite packet header lengths to the actual packet size:
  1007. <BR><I>tcpreplay -i eth0 -u trunc sample.pcap</I>
  1008. </LI>
  1009. </UL>
  1010. <P>
  1011. <H2><A NAME="SECTION04024000000000000000">
  1012. 5.4 Rewriting Layer 2 with -2</A>
  1013. </H2>
  1014. <P>
  1015. Starting in the 2.0.x branch, tcpreplay can replace the existing layer
  1016. 2 header with one of your choosing. This is useful for when you want
  1017. to change the layer 2 header type or add a header for pcap files without
  1018. one. Each pcap file tells the type of frame. Currently tcpreplay knows
  1019. how to deal with the following pcap(3) frame types:
  1020. <P>
  1021. <UL>
  1022. <LI>DLT_EN10MB
  1023. <BR>
  1024. Replace existing 802.3/Ethernet II header
  1025. </LI>
  1026. <LI>DLT_RAW
  1027. <BR>
  1028. Frame has no Layer 2 header, so we can add one.
  1029. </LI>
  1031. <BR>
  1032. Frame uses the Linux Cooked Socket header which is most commonly created
  1033. with <I>tcpdump -i any</I> on a Linux system.
  1034. </LI>
  1035. </UL>
  1036. Tcpreplay accepts the new Layer 2 header as a string of comma separated
  1037. hex values such as: 0xff,0xac,0x00,0x01,0xc0,0x64. Note that the leading
  1038. '0x' is <I>not</I> required.
  1039. <P>
  1040. Potential uses for this are to add a layer 2 header for DLT_RAW captures
  1041. or add/remove ethernet tags or QoS features.
  1042. <P>
  1043. <H2><A NAME="SECTION04025000000000000000">
  1044. 5.5 Rewriting DLT_LINUX_SLL (Linux Cooked Socket) captures</A>
  1045. </H2>
  1046. <P>
  1047. Tcpdump uses a special frame type to store captures created with the
  1048. ``-i any'' argument. This frame type uses a custom 16 byte layer
  1049. 2 header which tracks which interface captured the packet and often
  1050. the source MAC address of the original ethernet frame. Unfortunately,
  1051. it never stores the destination MAC address and it doesn't store a
  1052. source MAC when the packet is captured on the loopback interface.
  1053. Normally, tcpreplay can't replay these pcap files because there isn't
  1054. enough information in the LINUX_SLL header to do so; however two
  1055. options do exist:
  1056. <P>
  1057. <OL>
  1058. <LI>You can send these packets with -2 which will replace the LINUX_SLL
  1059. header with an ethernet header of your choosing.
  1060. </LI>
  1061. <LI>You can specify a destination MAC via -I and -J in which case tcpreplay
  1062. will use the stored source MAC and create a new 802.3 Ethernet header.
  1063. Note that if the pcap contains loopback packets, you will also need
  1064. to specify -k and/or -K to specify the source MAC as well or they
  1065. will be skipped.
  1066. </LI>
  1067. </OL>
  1068. <P>
  1069. <H2><A NAME="SECTION04026000000000000000">
  1070. 5.6 Rewriting IP Addresses (pseudo-NAT)</A>
  1071. </H2>
  1072. <P>
  1073. Pseudo-NAT allows the mapping of IP addresses in IPv4 and ARP packets
  1074. from one subnet to another subnet of the same or different size. This
  1075. allows some or all the traffic sent to appear to come from a different
  1076. IP subnet then it actually was captured on.
  1077. <P>
  1078. The mapping is done through a user specified translation table comprised
  1079. of one or more source and destination network(s) in the format of
  1080. &lt;srcnet&gt;/&lt;masklen&gt;:&lt;dstnet&gt;/&lt;masklen&gt; deliminated by a comma. Mapping
  1081. is done by matching IP addresses to the source subnet and rewriting
  1082. the most significant bits with the destination subnet. For example:
  1083. <P>
  1084. <I>tcpreplay -i eth0 -N sample.pcap</I>
  1085. <P>
  1086. would match any IP in the subnet and rewrite it as if
  1087. it came from or sent to the subnet. Ie:
  1088. would become and would become
  1089. But would not be rewritten.
  1090. <P>
  1091. For any given IP address, the translation table is applied in order
  1092. (so if there are multiple mappings, earlier maps take precedence)
  1093. and occurs only once per IP (no risk of an address getting rewritten
  1094. a second time).
  1095. <P>
  1096. <H2><A NAME="SECTION04027000000000000000">
  1097. 5.7 Advanced pseudo-NAT</A>
  1098. </H2>
  1099. <P>
  1100. Pseudo-NAT also works with traffic splitting (using two interfaces
  1101. or output files) but with a few important differences. First you have
  1102. the option of specifying one or two pseudo-NAT tables. Using a single
  1103. pseudo-NAT table means that the source and destination IP addresses
  1104. of both interfaces are rewritten using the same rules. Using two pseudo-NAT
  1105. tables (specifying -N &lt;Table1&gt; -N &lt;Table2&gt;) will cause the source
  1106. and destination IP addresses to be rewritten differently for each
  1107. interface using the following matrix:
  1108. <P>
  1109. <DIV ALIGN="CENTER">
  1111. <TR><TD ALIGN="CENTER">&nbsp;</TD>
  1112. <TD ALIGN="CENTER">Out Primary Interface</TD>
  1113. <TD ALIGN="CENTER">Out Secondary Interface
  1114. <BR>
  1115. Src IP</TD>
  1116. </TR>
  1117. </TABLE>
  1118. </DIV>
  1119. <P>
  1120. While seemingly a bit confusing, this feature provides a number of
  1121. interesting possibilities such as the ability to rewrite the IP headers
  1122. of packets in the case where traffic is captured on the loopback interface
  1123. (and the source and destination address is always so that
  1124. tcpreplay can make it look like two different systems are talking
  1125. to each other (you'll probably also need to specify the source and
  1126. destination MAC addresses via -I, -J, -k and -K).
  1127. <P>
  1128. <H2><A NAME="SECTION04028000000000000000">
  1129. 5.8 IP Endpoints</A>
  1130. </H2>
  1131. <P>
  1132. While pseudo-NAT provides a great deal of flexibility, it is often
  1133. more complicated then is necessary for testing of inline devices.
  1134. As a simplier alternative, tcpreplay supports the concept of rewriting
  1135. all traffic to so that it appears to be between two IP addresses:
  1136. <P>
  1137. <I>tcpreplay -i eth0 -j eth1 -c sample.cache -e
  1138. sample.pcap</I>
  1139. <P>
  1140. Will rewrite all the traffic so that it is between and
  1141. The equivalent command using -N would be:
  1142. <P>
  1143. <I>tcpreplay -i eth0 -j eth1 -c sample.cache -N
  1144. -N sample.pcap</I>
  1145. <P>
  1146. <H2><A NAME="SECTION04029000000000000000">
  1147. 5.9 Unifying Dual-Outputs</A>
  1148. </H2>
  1149. <P>
  1150. Since a number of tcpreplay's packet editing functions require splitting
  1151. traffic between client and servers, one problem that may arrise is
  1152. needing to edit packets but still output to a single interface or
  1153. file. The solution to this is to use the one output option -O which
  1154. causes packets to be processed as if they will be split between the
  1155. interfaces/files, but then always go out the primary interface or
  1156. file. Note that even though only one interface/file will be written
  1157. to, both -i and -j must be specified; although they can be the same
  1158. physical interface.
  1159. <P>
  1160. <I>tcpreplay -i eth0 -j eth0 -O -c sample.cache -e
  1161. sample.pcap</I>
  1162. <P>
  1163. Merging the output to a single file:
  1164. <P>
  1165. <I>tcpreplay -i eth0 -j eth0 -w rewrite.pcap -c sample.cache -e
  1166. sample.pcap</I>
  1167. <P>
  1168. <H1><A NAME="SECTION04030000000000000000">
  1169. 6 Tcpprep Usage</A>
  1170. </H1>
  1171. <P>
  1172. <H2><A NAME="SECTION04031000000000000000">
  1173. 6.1 What is tcpprep?</A>
  1174. </H2>
  1175. <P>
  1176. Tcpreplay can send traffic out two network cards, however it requires
  1177. the calculations be done in real-time. These calculations can be expensive
  1178. and can significantly reduce the throughput of tcpreplay.
  1179. <P>
  1180. Tcpprep is a libpcap pre-processor for tcpreplay which enables using
  1181. two network cards to send traffic without the performance hit of doing
  1182. the calculations in real-time.
  1183. <P>
  1184. <H2><A NAME="SECTION04032000000000000000">
  1185. 6.2 How does tcpprep work? </A>
  1186. </H2>
  1187. <P>
  1188. Tcpprep reads in a libpcap (tcpdump) formatted capture file and does
  1189. some processing to generate a tcpreplay cache file. This cache file
  1190. tells tcpreplay which interface a given packet should be sent out
  1191. of.
  1192. <P>
  1193. <H2><A NAME="SECTION04033000000000000000">
  1194. 6.3 Does tcpprep modify my libpcap file?</A>
  1195. </H2>
  1196. <P>
  1197. No.
  1198. <P>
  1199. <H2><A NAME="SECTION04034000000000000000">
  1200. 6.4 Why use tcpprep?</A>
  1201. </H2>
  1202. <P>
  1203. There are three major reasons to use tcpprep:
  1204. <P>
  1205. <OL>
  1206. <LI>Tcpprep can split traffic based upon more methods and criteria then
  1207. tcpreplay.
  1208. </LI>
  1209. <LI>By pre-processing the pcap, tcpreplay has a higher theoretical maximum
  1210. throughput.
  1211. </LI>
  1212. <LI>By pre-processing the pcap, tcpreplay can be more accurate in timing
  1213. when replaying traffic at normal speed.
  1214. </LI>
  1215. </OL>
  1216. <P>
  1217. <H2><A NAME="SECTION04035000000000000000">
  1218. 6.5 Can a cache file be used for multiple (different) libpcap files? </A>
  1219. </H2>
  1220. <P>
  1221. Cache files have nothing linking them to a given libpcap file, so
  1222. there is nothing to stop you from doing this. However running tcpreplay
  1223. with a cache file from a different libpcap source file is likely to
  1224. cause a lot of problems and is not supported.
  1225. <P>
  1226. <H2><A NAME="SECTION04036000000000000000">
  1227. 6.6 Why would I want to use tcpreplay with two network cards? </A>
  1228. </H2>
  1229. <P>
  1230. Tcpreplay traditionally is good for putting traffic on a given network,
  1231. often used to test a network intrusion detection system (NIDS). However,
  1232. there are cases where putting traffic onto a subnet in this manner
  1233. is not good enough- you have to be able to send traffic *through*
  1234. a device such as a router, firewall, or bridge.
  1235. <P>
  1236. In these cases, being able to use a single source file (libpcap) for
  1237. both ends of the connection solves this problem.
  1238. <P>
  1239. <H2><A NAME="SECTION04037000000000000000">
  1240. 6.7 How big are the cache files?</A>
  1241. </H2>
  1242. <P>
  1243. Very small. Actual size depends on the number of packets in the dump
  1244. file. Two bits of data is stored for each packet. On a test using
  1245. a 900MB dump file containing over 500,000 packets, the cache file
  1246. was only 150K.
  1247. <P>
  1248. <H2><A NAME="SECTION04038000000000000000">
  1249. 6.8 What are these 'modes' tcpprep has? </A>
  1250. </H2>
  1251. <P>
  1252. Tcpprep has three basic modes which require the user to specify how
  1253. to split traffic.
  1254. <P>
  1255. <UL>
  1256. <LI>CIDR (-c) mode requires the user to provide a list of networks. Any
  1257. packet with a source IP in one of these networks gets sent out the
  1258. primary interface.
  1259. </LI>
  1260. <LI>Regex (-r) mode requires the user to provide a regular expression.
  1261. Any packet with a source IP matching the regex gets sent out the primary
  1262. interface.
  1263. </LI>
  1264. <LI>Port (-p) mode splits TCP/UDP traffic based on the destination port
  1265. in the header. Normally, ports 0-1023 are considered ``server''
  1266. ports and everything else a client port. You can create your own custom
  1267. mapping file in the same format as /etc/services (see the services(5)
  1268. man page for details) by specifying -s &lt;file&gt;.
  1269. </LI>
  1270. </UL>
  1271. And four auto modes in which tcpprep decides how to split traffic.
  1272. Auto modes are useful for when you don't know much about the contents
  1273. of the dump file in question and you want to split traffic up based
  1274. upon servers and clients.
  1275. <P>
  1276. <UL>
  1277. <LI>Auto/Router (-a -n router) mode trys to find the largest network(s)
  1278. that contain all the servers and no clients. Any unknown system is
  1279. automatically re-classified as servers if it's inside the server network(s),
  1280. otherwise it is classified as a client.
  1281. </LI>
  1282. <LI>Auto/Bridge (-a -n bridge) mode makes the assumption that the clients
  1283. and servers are horribly intermixed on the network and there's no
  1284. way to subnet them. While this takes less processing time to create
  1285. the cache file it is unable to deal with unknown systems.
  1286. </LI>
  1287. <LI>Auto/Client (-a -n client) mode which works just like Auto/Bridge
  1288. mode, except that any system it can't figure out is treated like a
  1289. client.
  1290. </LI>
  1291. <LI>Auto/Server (-a -n server) mode which works just like Auto/Bridge
  1292. mode, except that any system it can't figure out is treated like a
  1293. server.
  1294. </LI>
  1295. </UL>
  1296. <P>
  1297. <H2><A NAME="SECTION04039000000000000000">
  1298. 6.9 Splitting traffic based upon IP address</A>
  1299. </H2>
  1300. <P>
  1301. Tcpprep supports the same CIDR mode that tcpreplay supports using
  1302. the -c flag (tcpreplay uses -C). Additionally, tcpprep also supports
  1303. regex(7) regular expressions to match source IP addresses using the
  1304. -r flag.
  1305. <P>
  1306. <H2><A NAME="SECTION040310000000000000000">
  1307. 6.10 Auto Mode</A>
  1308. </H2>
  1309. <P>
  1310. <H3><A NAME="SECTION040310100000000000000">
  1311. 6.10.1 How does Auto/Bridge mode work? </A>
  1312. </H3>
  1313. <P>
  1314. Tcpprep does an initial pass over the libpcap file to build a binary
  1315. tree (one node per IP). For each IP, it keeps track of how many times
  1316. it was a client or server. It then does a second pass of the file
  1317. using the data in the tree and the ratio to determine if an IP is
  1318. a client or server. If tcpprep is unable to determine the type (client
  1319. or server) for each and every packet, then auto/bridge mode will fail.
  1320. In these cases, it is best to use a different auto mode.
  1321. <P>
  1322. <H3><A NAME="SECTION040310200000000000000">
  1323. 6.10.2 How does Auto/Router mode work? </A>
  1324. </H3>
  1325. <P>
  1326. Tcpprep does the same first pass as Auto/Bridge mode. It then trys
  1327. to convert the binary tree into a list of networks containing the
  1328. servers. Finally it uses the CIDR mode with the list of server networks
  1329. in a second pass of the libpcap file. Unlike auto/bridge mode, auto/router
  1330. mode can always successfully split IP addresses into clients and servers.
  1331. <P>
  1332. <H3><A NAME="SECTION040310300000000000000">
  1333. 6.10.3 Determining Clients and Servers</A>
  1334. </H3>
  1335. <P>
  1336. Tcpprep uses the following methods in auto/router and auto/bridge
  1337. mode to determine if an IP address is a client or server:
  1338. <P>
  1339. <UL>
  1340. <LI>Client:
  1341. <P>
  1342. <UL>
  1343. <LI>TCP with Syn flag set
  1344. </LI>
  1345. <LI>UDP source/destination port 53 (DNS) without query flag set
  1346. </LI>
  1347. <LI>ICMP port unreachable (destination IP of packet)
  1348. </LI>
  1349. </UL>
  1350. </LI>
  1351. <LI>Server:
  1352. <P>
  1353. <UL>
  1354. <LI>TCP with Syn/Ack flag set
  1355. </LI>
  1356. <LI>UDP source/destination port 53 (DNS) with query flag set
  1357. </LI>
  1358. <LI>ICMP port unreachable (source IP of packet)
  1359. </LI>
  1360. </UL>
  1361. </LI>
  1362. </UL>
  1363. <P>
  1364. <H3><A NAME="SECTION040310400000000000000">
  1365. 6.10.4 Client/Server ratio</A>
  1366. </H3>
  1367. <P>
  1368. Since a system may send traffic which would classify it as both a
  1369. client and server, it's necessary to be able to weigh the traffic.
  1370. This is done by specifying the client/server ratio (-R) which is by
  1371. default set to 2.0. The ratio is the modifier to the number of client
  1372. connections. Hence, by default, client connections are valued twice
  1373. as high as server connections.
  1374. <P>
  1375. <H2><A NAME="SECTION040311000000000000000">
  1376. 6.11 Selectively sending/dropping packets</A>
  1377. </H2>
  1378. <P>
  1379. Tcpprep supports the same -x and -X options to selectively send or
  1380. drop packets.
  1381. <P>
  1382. <H2><A NAME="SECTION040312000000000000000">
  1383. 6.12 Using tcpprep cache files with tcpreplay</A>
  1384. </H2>
  1385. <P>
  1386. Just run:
  1387. <P>
  1388. <I>tcpreplay -c sample.cache -i eth0 -j eth1 sample.pcap</I>
  1389. <P>
  1390. <H2><A NAME="SECTION040313000000000000000">
  1391. 6.13 Commenting tcpprep cache files</A>
  1392. </H2>
  1393. <P>
  1394. In versions of tcpprep &gt;= 2.1.0, you can specify a comment to be embeded
  1395. in the tcpprep cache file. Comments are user specified and automatically
  1396. include the command line arguments passed to tcpprep.
  1397. <P>
  1398. <I>tcpprep -C ``this is my comment'' -i sample.pcap -o sample.cache
  1399. &lt;other args&gt;</I>
  1400. <P>
  1401. Or for no user comment, but still embed the command arguments:
  1402. <P>
  1403. <I>tcpprep -C ``'' -i sample.pcap -o sample.cache &lt;other args&gt;</I>
  1404. <P>
  1405. You can then later on print out the comments by running:
  1406. <P>
  1407. <I>tcpprep -P sample.cache</I>
  1408. <P>
  1409. <H1><A NAME="SECTION04040000000000000000">
  1410. 7 Flowreplay Usage</A>
  1411. </H1>
  1412. <P>
  1413. While tcpreplay is a great way to test NIDS and firewalls, it can't
  1414. be used to test servers or HIDS since tcpreplay can't connect to a
  1415. service running on a device. The solution to this problem is flowreplay
  1416. which instead of sending packets at Layer 2 (ethernet header and up),
  1417. it can actually connect via TCP or UDP to server and then sends and
  1418. receives data based upon a pcap capture file created with a tool like
  1419. Ethereal or tcpdump.
  1420. <P>
  1421. Please note that flowreplay is currently alpha quality and is missing
  1422. a number of key features.
  1423. <P>
  1424. <H2><A NAME="SECTION04041000000000000000">
  1425. 7.1 How flowreplay works</A>
  1426. </H2>
  1427. <P>
  1428. Put simply, flowreplay opens a socket connection to a service on a
  1429. target system(s) and sends data over that socket based on the packet
  1430. capture. Flowreplay has no understanding of the application protocol
  1431. (like HTTP or FTP) so it is somewhat limited in how it can deal with
  1432. complicated exchanges between client and server.
  1433. <P>
  1434. Some of these limitations are:
  1435. <P>
  1436. <UL>
  1437. <LI>Flowreplay only plays the client side<A NAME="tex2html10"
  1438. HREF="#foot237"><SUP>10</SUP></A> of the connection.
  1439. </LI>
  1440. <LI>Flowreplay doesn't understand the application protocols. Hence it
  1441. can't always deal with the case when the server sends a different
  1442. response then what was originally captured in the pcap file.
  1443. </LI>
  1444. <LI>Flowreplay only sends TCP and UDP traffic.
  1445. </LI>
  1446. <LI>Flowreplay doesn't know about multi-flow protocols like FTP.
  1447. </LI>
  1448. <LI>Flowreplay can't listen on a port and wait for a client to connect
  1449. to it.
  1450. </LI>
  1451. </UL>
  1452. <P>
  1453. <H2><A NAME="SECTION04042000000000000000">
  1454. 7.2 Running flowreplay</A>
  1455. </H2>
  1456. <P>
  1457. See the flowreplay(8) man page for details.
  1458. <P>
  1459. <H1><A NAME="SECTION04050000000000000000">
  1460. 8 Tuning OS's for high performance</A>
  1461. </H1>
  1462. <P>
  1463. Regardless of the size of physical memory, UNIX kernels will only
  1464. allocate a static amount for network buffers. This includes packets
  1465. sent via the &#34;raw&#34; interface, like with tcpreplay.
  1466. Most kernels will allow you to tweak the size of these buffers, drastically
  1467. increasing performance and accuracy.
  1468. <P>
  1469. N<SMALL>OTE:</SMALL> The following information is provided based upon our
  1470. own experiences or the reported experiences of others. Depending on
  1471. your hardware and specific hardware, it may or may not work for you.
  1472. It may even make your system horribly unstable, corrupt your harddrive,
  1473. or worse.
  1474. <P>
  1475. N<SMALL>OTE</SMALL>: Different operating systems, network card drivers,
  1476. and even hardware can have an effect on the accuracy of packet timestamps
  1477. that tcpdump or other capture utilities generate. And as you know:
  1478. garbage in, garbage out.
  1479. <P>
  1480. N<SMALL>OTE:</SMALL> If you have information on tuning the kernel of an
  1481. operating system not listed here, please send it to me so I can include
  1482. it.
  1483. <P>
  1484. <H2><A NAME="SECTION04051000000000000000">
  1485. 8.1 Linux 2.4.x</A>
  1486. </H2>
  1487. <P>
  1488. The following is known to apply to the 2.4.x series of kernels. If
  1489. anyone has any information regarding other kernel versions, please
  1490. let us know. By default Linux's tcpreplay performance isn't all that
  1491. stellar. However, with a simple tweak, relatively decent performance
  1492. can be had on the right hardware. By default, Linux specifies a 64K
  1493. buffer for sending packets. Increasing this buffer to about half a
  1494. megabyte does a good job:
  1495. <P>
  1496. <I>echo 524287 &gt;/proc/sys/net/core/wmem_default </I>
  1497. <BR><I>echo 524287 &gt;/proc/sys/net/core/wmem_max </I>
  1498. <BR><I>echo 524287 &gt;/proc/sys/net/core/rmem_max </I>
  1499. <BR><I>echo 524287 &gt;/proc/sys/net/core/rmem_default </I>
  1500. <P>
  1501. On one system, we've seen a jump from 23.02 megabits/sec (5560 packets/sec)
  1502. to 220.30 megabits/sec (53212 packets/sec) which is nearly a 10x increase
  1503. in performance. Depending on your system and capture file, different
  1504. numbers may provide different results.
  1505. <P>
  1506. <H2><A NAME="SECTION04052000000000000000">
  1507. 8.2 *BSD</A>
  1508. </H2>
  1509. <P>
  1510. *BSD systems typically allow you to specify the size of network
  1511. buffers with the NMBCLUSTERS option in the kernel config file. Experiment
  1512. with different sizes to see which yields the best performance. See
  1513. the options(4) man page for more details.
  1514. <P>
  1515. <H1><A NAME="SECTION04060000000000000000">
  1516. 9 Understanding Common Error and Warning Messages</A>
  1517. </H1>
  1518. <P>
  1519. <H2><A NAME="SECTION04061000000000000000">
  1520. 9.1 Can't open eth0: libnet_select_device(): Can't find interface eth0</A>
  1521. </H2>
  1522. <P>
  1523. Generally this occurs when the interface (eth0 in this example) is
  1524. not up or doesn't have an IP address assigned to it.
  1525. <P>
  1526. <H2><A NAME="SECTION04062000000000000000">
  1527. 9.2 Can't open lo: libnet_select_device(): Can't find interface lo</A>
  1528. </H2>
  1529. <P>
  1530. Version 1.1.0 of Libnet is unable to send traffic on the loopback
  1531. device. Upgrade to a later release of the Libnet library to solve
  1532. this problem.
  1533. <P>
  1534. <H2><A NAME="SECTION04063000000000000000">
  1535. 9.3 Can't open eth0: UID != 0</A>
  1536. </H2>
  1537. <P>
  1538. Tcpreplay requires that you run it as root.
  1539. <P>
  1540. <H2><A NAME="SECTION04064000000000000000">
  1541. 9.4 100000 write attempts failed from full buffers and were repeated</A>
  1542. </H2>
  1543. <P>
  1544. When tcpreplay displays a message like &#34;100000 write attempts
  1545. failed from full buffers and were repeated&#34;, this usually
  1546. means the kernel buffers were full and it had to wait until memory
  1547. was available. This is quite common when replaying files as fast as
  1548. possible with the &#34;-R&#34; option. See the tuning OS
  1549. section in this document for suggestions on solving this problem.
  1550. <P>
  1551. <H2><A NAME="SECTION04065000000000000000">
  1552. 9.5 Invalid mac address: 00:00:00:00:00:00</A>
  1553. </H2>
  1554. <P>
  1555. Currently tcpreplay reserves the MAC address of 00:00:00:00:00:00
  1556. as reserved for internal use. Hence you can't rewrite the MAC address
  1557. of packets to be all zeros. While we intend to fix this someday it's
  1558. not currently high on our priority list, so let us know if we should
  1559. re-prioritize things.
  1560. <P>
  1561. <H2><A NAME="SECTION04066000000000000000">
  1562. 9.6 Unable to process test.cache: cache file version missmatch</A>
  1563. </H2>
  1564. <P>
  1565. Cache files generated by tcpprep and read by tcpreplay are versioned
  1566. to allow enhancements to the cache file format. Anytime the cache
  1567. file format changes, the version is incremented. Since this occurs
  1568. on a very rare basis, this is generally not an issue; however anytime
  1569. there is a change, it breaks compatibility with previously created
  1570. cache files. The solution for this problem is to use the same version
  1571. of tcpreplay and tcpprep to read/write the cache files. Cache file
  1572. versions match the following versions of tcpprep/tcpreplay:
  1573. <P>
  1574. <UL>
  1575. <LI>Version 1:
  1576. <BR>
  1577. Prior to 1.3.beta1
  1578. </LI>
  1579. <LI>Version 2:
  1580. <BR>
  1581. 1.3.beta2 to 1.3.1/1.4.beta1
  1582. </LI>
  1583. <LI>Version 3:
  1584. <BR>
  1585. 1.3.2/1.4.beta2 to 2.0.3
  1586. </LI>
  1587. <LI>Version 4:
  1588. <BR>
  1589. 2.1.0 and above. Note that prior to version 2.3.0, tcpprep had a bug
  1590. which broke cache file compatibility between big and little endian
  1591. systems.
  1592. </LI>
  1593. </UL>
  1594. <P>
  1595. <H2><A NAME="SECTION04067000000000000000">
  1596. 9.7 Skipping SLL loopback packet.</A>
  1597. </H2>
  1598. <P>
  1599. Your capture file was created on Linux with the 'any' parameter which
  1600. then captured a packet on the loopback interface. However, tcpreplay
  1601. doesn't have enough information to actual send the packet, so it skips
  1602. it. Specifying a source and destination MAC address (-I, -k, -J, -K)
  1603. will allow tcpreplay to send these packets.
  1604. <P>
  1605. <H2><A NAME="SECTION04068000000000000000">
  1606. 9.8 Packet length (8892) is greater then MTU; skipping packet.</A>
  1607. </H2>
  1608. <P>
  1609. The packet length (in this case 8892 bytes) is greater then the maximum
  1610. transmition unit (MTU) on the outgoing interface. Tcpreplay must skip
  1611. the packet. Alternatively, you can specify the -T option and tcpreplay
  1612. will truncate the packet to the MTU size, fix the checksums and send
  1613. it.
  1614. <P>
  1615. <H2><A NAME="SECTION04069000000000000000">
  1616. 9.9 Why is tcpreplay not sending all the packets?</A>
  1617. </H2>
  1618. <P>
  1619. Every now and then, someone emails the tcpreplay-users list, asking
  1620. if there is a bug in tcpreplay which causes it not to send all the
  1621. packets. This usually happens when the user uses the -R flag or is
  1622. replaying a high-speed pcap file (&gt; 50Mbps, although this number is
  1623. dependant on the hardware in use).
  1624. <P>
  1625. The short version of the answer is: no, we are not aware of any bugs
  1626. which might cause a few packets to not be sent.
  1627. <P>
  1628. The longer version goes something like this:
  1629. <P>
  1630. If you are running tcpreplay multiple times and are using tcpdump
  1631. or other packet sniffer to count the number packets sent and are getting
  1632. different numbers, it's not tcpreplay's fault. The problem lies in
  1633. one of two places:
  1634. <P>
  1635. <OL>
  1636. <LI>It is well known that tcpdump and other sniffers have a problem keeping
  1637. up with high-speed traffic. Furthermore, the OS in many cases <I>lies</I>
  1638. about how many packets were dropped. Tcpdump will repeat this lie
  1639. to you. In other words, tcpdump isn't seeing all the packets. Usually
  1640. this is a problem with the network card or driver which may or may
  1641. not be fixable. Try another network card/driver.
  1642. </LI>
  1643. <LI>When tcpreplay sends a packet, it actually gets copied to a send buffer
  1644. in the kernel. If this buffer is full, the kernel is supposed to tell
  1645. tcpreplay that it didn't copy the packet to this buffer. If the kernel
  1646. has a bug which squelches this error, tcpreplay will not keep trying
  1647. to send the packet and will move on to the next one. Currently I am
  1648. not aware of any OS kernels with this bug, but it is possible that
  1649. it exists. If you find out that your OS has this problem, please let
  1650. me know so I can list it here.
  1651. </LI>
  1652. </OL>
  1653. If for some reason, you still think its a bug in tcpreplay, by all
  1654. means read the code and tell me how stupid I am. The do_packets()
  1655. function in do_packets.c is where tcpreplay processes the pcap file
  1656. and sends all of the packets.
  1657. <P>
  1658. <H1><A NAME="SECTION04070000000000000000">
  1659. 10 Required Libraries and Tools</A>
  1660. </H1>
  1661. <P>
  1662. <H2><A NAME="SECTION04071000000000000000">
  1663. 10.1 Libpcap</A>
  1664. </H2>
  1665. <P>
  1666. As of tcpreplay v1.4, you'll need to have libpcap installed on your
  1667. system. As of v2.0, you'll need at least version 0.6.0 or better,
  1668. but I only test our code with the latest version. Libpcap can be obtained
  1669. on the tcpdump homepage<A NAME="tex2html11"
  1670. HREF="#foot317"><SUP>11</SUP></A>.
  1671. <P>
  1672. <H2><A NAME="SECTION04072000000000000000">
  1673. 10.2 Libnet</A>
  1674. </H2>
  1675. <P>
  1676. Tcpreplay v1.3 is the last version to support the old libnet API (everything
  1677. before 1.1.x). As of v1.4 you will need to use Libnet 1.1.0 or better
  1678. which can be obtained from the Libnet homepage<A NAME="tex2html12"
  1679. HREF="#foot318"><SUP>12</SUP></A>.
  1680. <P>
  1681. <H2><A NAME="SECTION04073000000000000000">
  1682. 10.3 Libpcapnav</A>
  1683. </H2>
  1684. <P>
  1685. Starting with v2.0, tcpreplay can use libpcapnav to support the jump
  1686. offset feature. If libpcapnav is not found on the system, that feature
  1687. will be disabled. Libpcapnav can be found on the NetDude homepage<A NAME="tex2html13"
  1688. HREF="#foot319"><SUP>13</SUP></A>.
  1689. <P>
  1690. <H2><A NAME="SECTION04074000000000000000">
  1691. 10.4 Tcpdump</A>
  1692. </H2>
  1693. <P>
  1694. As of 2.0, tcpreplay uses tcpdump (the binary, not code) to decode
  1695. packets to STDOUT in a human readable (with practice) format as it
  1696. sends them. If you would like this feature, tcpdump must be installed
  1697. on your system.
  1698. <P>
  1699. N<SMALL>OTE:</SMALL> The location of the tcpdump binary is hardcoded in
  1700. tcpreplay at compile time. If tcpdump gets renamed or moved, the feature
  1701. will become disabled.
  1702. <P>
  1703. <H1><A NAME="SECTION05000000000000000000">
  1704. 4 Other Resources</A>
  1705. </H1>
  1706. <P>
  1707. <H1><A NAME="SECTION05010000000000000000">
  1708. 11 Other pcap tools available</A>
  1709. </H1>
  1710. <P>
  1711. <H2><A NAME="SECTION05011000000000000000">
  1712. 11.1 Tools to capture network traffic or decode pcap files</A>
  1713. </H2>
  1714. <P>
  1715. <UL>
  1716. <LI>tcpdump
  1717. <BR>
  1719. </LI>
  1720. <LI>ethereal
  1721. <BR>
  1723. </LI>
  1724. <LI>ettercap
  1725. <BR>
  1727. </LI>
  1728. </UL>
  1729. <P>
  1730. <H2><A NAME="SECTION05012000000000000000">
  1731. 11.2 Tools to edit pcap files</A>
  1732. </H2>
  1733. <P>
  1734. <UL>
  1735. <LI>tcpslice
  1736. <BR>
  1737. Splits pcap files into smaller files
  1738. <BR>
  1740. </LI>
  1741. <LI>mergecap
  1742. <BR>
  1743. Merges two pcap capture files into one
  1744. <BR>
  1746. </LI>
  1747. <LI>pcapmerge
  1748. <BR>
  1749. Merges two or more pcap capture files into one
  1750. <BR>
  1752. </LI>
  1753. <LI>editcap
  1754. <BR>
  1755. Converts capture file formats (pcap, snoop, etc)
  1756. <BR>
  1758. </LI>
  1759. <LI>netdude
  1760. <BR>
  1761. GTK based pcap capture file editor. Allows editing most anything in
  1762. the packet.
  1763. <BR>
  1765. </LI>
  1766. </UL>
  1767. <P>
  1768. <H2><A NAME="SECTION05013000000000000000">
  1769. 11.3 Other useful tools</A>
  1770. </H2>
  1771. <P>
  1772. <UL>
  1773. <LI>capinfo
  1774. <BR>
  1775. Prints statistics and basic information about a pcap file
  1776. <BR>
  1778. </LI>
  1779. <LI>text2pcap
  1780. <BR>
  1781. Generates a pcap capture file from a hex dump
  1782. <BR>
  1784. </LI>
  1785. <LI>tcpflow
  1786. <BR>
  1787. Extracts and reassembles the data portion on a per-flow basis on live
  1788. traffic or pcap capture files
  1789. <BR>
  1791. </LI>
  1792. </UL>
  1793. <P>
  1794. <H1><A NAME="SECTION06000000000000000000">
  1795. Appendix</A>
  1796. </H1>
  1797. <P>
  1798. <H1><A NAME="SECTION06010000000000000000">
  1799. 1 BSD License</A>
  1800. </H1>
  1801. <P>
  1802. <BR>
  1803. <PRE>Copyright (c) 2001-2004 Aaron Turner, Matt Bing. All rights reserved.
  1804. Some portions of code are:
  1805. Copyright(c) 1999 Anzen Computing. All rights reserved.
  1806. Redistribution and use in source and binary forms, with or without
  1807. modification, are permitted provided that the following conditions
  1808. are met:
  1809. 1. Redistributions of source code must retain the above copyright
  1810. notice, this list of conditions and the following disclaimer.
  1811. 2. Redistributions in binary form must reproduce the above copyright
  1812. notice, this list of conditions and the following disclaimer in the
  1813. documentation and/or other materials provided with the distribution.
  1814. 3. Neither the names of the copyright owners nor the names of its
  1815. contributors may be used to endorse or promote products derived from
  1816. this software without specific prior written permission.
  1817. 4. All advertising materials mentioning features or use of this software
  1818. must display the following acknowledgement:
  1819. This product includes software developed by Anzen Computing, Inc.
  1831. </PRE>
  1832. <H1><A NAME="SECTION07000000000000000000">
  1833. About this document ...</A>
  1834. </H1>
  1835. <STRONG>Tcpreplay 2.x FAQ</STRONG><P>
  1836. This document was generated using the
  1837. <A HREF=""><STRONG>LaTeX</STRONG>2<tt>HTML</tt></A> translator Version 2002-2-1 (1.70)
  1838. <P>
  1839. Copyright &#169; 1993, 1994, 1995, 1996,
  1840. <A HREF="">Nikos Drakos</A>,
  1841. Computer Based Learning Unit, University of Leeds.
  1842. <BR>
  1843. Copyright &#169; 1997, 1998, 1999,
  1844. <A HREF="">Ross Moore</A>,
  1845. Mathematics Department, Macquarie University, Sydney.
  1846. <P>
  1847. The command line arguments were: <BR>
  1848. <STRONG>latex2html</STRONG> <TT>-nonavigation -no_subdir -split 0 -show_section_numbers FAQ.tex</TT>
  1849. <P>
  1850. The translation was initiated by Aaron Turner on 2005-02-24
  1851. <BR><HR><H4>Footnotes</H4>
  1852. <DL>
  1853. <DT><A NAME="foot310">... flowreplay</A><A
  1854. HREF="tcpreplay-2-faq.html#tex2html1"><SUP>1</SUP></A></DT>
  1855. <DD>Flowreplay is still ``alpha'' quality and is not usable for most
  1856. situations. Anyone interested in helping me develop flowreplay is
  1857. encouraged to contact me.
  1858. </DD>
  1859. <DT><A NAME="foot38">... libpcapnav</A><A
  1860. HREF="tcpreplay-2-faq.html#tex2html2"><SUP>2</SUP></A></DT>
  1861. <DD>
  1862. </DD>
  1863. <DT><A NAME="foot39">... tcpdump</A><A
  1864. HREF="tcpreplay-2-faq.html#tex2html3"><SUP>3</SUP></A></DT>
  1865. <DD>
  1866. </DD>
  1867. <DT><A NAME="foot311">...
  1868. captured</A><A
  1869. HREF="tcpreplay-2-faq.html#tex2html4"><SUP>4</SUP></A></DT>
  1870. <DD>Tcpreplay makes a &#34;best&#34; effort to replay traffic
  1871. at the given rate, but due to limitations in hardware or the pcap
  1872. file itself, it may not be possible. Capture files with only a few
  1873. packets in them are especially susceptible to this.
  1874. </DD>
  1875. <DT><A NAME="foot93">... times</A><A
  1876. HREF="tcpreplay-2-faq.html#tex2html5"><SUP>5</SUP></A></DT>
  1877. <DD>Looping files resets internal counters which control the speed that
  1878. the file is replayed. Also because the file has to be closed and re-opened,
  1879. an added delay between the last and first packet may occur.
  1880. </DD>
  1881. <DT><A NAME="foot103">... interface</A><A
  1882. HREF="tcpreplay-2-faq.html#tex2html6"><SUP>6</SUP></A></DT>
  1883. <DD>Note that you can also use the following options to split traffic
  1884. into two files using -w and -W which are described later on in this
  1885. FAQ.
  1886. </DD>
  1887. <DT><A NAME="foot105">... cachefile</A><A
  1888. HREF="tcpreplay-2-faq.html#tex2html7"><SUP>7</SUP></A></DT>
  1889. <DD>For information on generating tcpprep cache files, see the section
  1890. on tcpprep.
  1891. </DD>
  1892. <DT><A NAME="foot116">... -x</A><A
  1893. HREF="tcpreplay-2-faq.html#tex2html8"><SUP>8</SUP></A></DT>
  1894. <DD>Note that if you want to send all the packets which do not match a
  1895. bpf filter, all you have to do is negate the bpf filter. See the tcpdump(1)
  1896. man page for more info.
  1897. </DD>
  1898. <DT><A NAME="foot149">... libpcap</A><A
  1899. HREF="tcpreplay-2-faq.html#tex2html9"><SUP>9</SUP></A></DT>
  1900. <DD>Note that some versions of tcpreplay prior to 1.4 also supported the
  1901. Solaris snoop format.
  1902. </DD>
  1903. <DT><A NAME="foot237">... side</A><A
  1904. HREF="tcpreplay-2-faq.html#tex2html10"><SUP>10</SUP></A></DT>
  1905. <DD>Flowreplay assumes the first UDP packet on a given 4-tuple is the
  1906. client
  1907. </DD>
  1908. <DT><A NAME="foot317">... homepage</A><A
  1909. HREF="tcpreplay-2-faq.html#tex2html11"><SUP>11</SUP></A></DT>
  1910. <DD>
  1911. </DD>
  1912. <DT><A NAME="foot318">... homepage</A><A
  1913. HREF="tcpreplay-2-faq.html#tex2html12"><SUP>12</SUP></A></DT>
  1914. <DD>
  1915. </DD>
  1916. <DT><A NAME="foot319">... homepage</A><A
  1917. HREF="tcpreplay-2-faq.html#tex2html13"><SUP>13</SUP></A></DT>
  1918. <DD>
  1919. </DD>
  1920. </DL>
  1921. <BR><HR>
  1922. <ADDRESS>
  1923. Aaron Turner
  1924. 2005-02-24
  1925. </ADDRESS>
  1926. </BODY>
  1927. </HTML>