README revision 251158
1@(#) $Header: /tcpdump/master/tcpdump/README,v 1.68 2008-12-15 00:05:27 guy Exp $ (LBL) 2 3TCPDUMP 4.x.y 4Now maintained by "The Tcpdump Group" 5See www.tcpdump.org 6 7Please send inquiries/comments/reports to: 8 tcpdump-workers@lists.tcpdump.org 9 10Anonymous Git is available via: 11 git clone git://bpf.tcpdump.org/tcpdump 12 13Version 4.x.y of TCPDUMP can be retrieved with the CVS tag "tcpdump_4_xrely": 14 cvs -d :pserver:cvs.tcpdump.org:/tcpdump/master checkout -r tcpdump_4_xrely tcpdump 15 16Please submit patches by forking the branch on GitHub at 17 18 http://github.com/mcr/tcpdump/tree/master 19 20and issuing a pull request. 21 22formerly from Lawrence Berkeley National Laboratory 23 Network Research Group <tcpdump@ee.lbl.gov> 24 ftp://ftp.ee.lbl.gov/tcpdump.tar.Z (3.4) 25 26This directory contains source code for tcpdump, a tool for network 27monitoring and data acquisition. This software was originally 28developed by the Network Research Group at the Lawrence Berkeley 29National Laboratory. The original distribution is available via 30anonymous ftp to ftp.ee.lbl.gov, in tcpdump.tar.Z. More recent 31development is performed at tcpdump.org, http://www.tcpdump.org/ 32 33Tcpdump uses libpcap, a system-independent interface for user-level 34packet capture. Before building tcpdump, you must first retrieve and 35build libpcap, also originally from LBL and now being maintained by 36tcpdump.org; see http://www.tcpdump.org/ . 37 38Once libpcap is built (either install it or make sure it's in 39../libpcap), you can build tcpdump using the procedure in the INSTALL 40file. 41 42The program is loosely based on SMI's "etherfind" although none of the 43etherfind code remains. It was originally written by Van Jacobson as 44part of an ongoing research project to investigate and improve tcp and 45internet gateway performance. The parts of the program originally 46taken from Sun's etherfind were later re-written by Steven McCanne of 47LBL. To insure that there would be no vestige of proprietary code in 48tcpdump, Steve wrote these pieces from the specification given by the 49manual entry, with no access to the source of tcpdump or etherfind. 50 51Over the past few years, tcpdump has been steadily improved by the 52excellent contributions from the Internet community (just browse 53through the CHANGES file). We are grateful for all the input. 54 55Richard Stevens gives an excellent treatment of the Internet protocols 56in his book ``TCP/IP Illustrated, Volume 1''. If you want to learn more 57about tcpdump and how to interpret its output, pick up this book. 58 59Some tools for viewing and analyzing tcpdump trace files are available 60from the Internet Traffic Archive: 61 62 http://www.acm.org/sigcomm/ITA/ 63 64Another tool that tcpdump users might find useful is tcpslice: 65 66 ftp://ftp.ee.lbl.gov/tcpslice.tar.Z 67 68It is a program that can be used to extract portions of tcpdump binary 69trace files. See the above distribution for further details and 70documentation. 71 72Problems, bugs, questions, desirable enhancements, etc. should be sent 73to the address "tcpdump-workers@lists.tcpdump.org". Bugs, support 74requests, and feature requests may also be submitted on the GitHub issue 75tracker for tcpdump at 76 77 https://github.com/mcr/tcpdump/issues 78 79Source code contributions, etc. should be sent to the email address 80above or submitted by forking the branch on GitHub at 81 82 http://github.com/mcr/tcpdump/tree/master 83 84and issuing a pull request. 85 86Current versions can be found at www.tcpdump.org. 87 88 - The TCPdump team 89 90original text by: Steve McCanne, Craig Leres, Van Jacobson 91 92------------------------------------- 93This directory also contains some short awk programs intended as 94examples of ways to reduce tcpdump data when you're tracking 95particular network problems: 96 97send-ack.awk 98 Simplifies the tcpdump trace for an ftp (or other unidirectional 99 tcp transfer). Since we assume that one host only sends and 100 the other only acks, all address information is left off and 101 we just note if the packet is a "send" or an "ack". 102 103 There is one output line per line of the original trace. 104 Field 1 is the packet time in decimal seconds, relative 105 to the start of the conversation. Field 2 is delta-time 106 from last packet. Field 3 is packet type/direction. 107 "Send" means data going from sender to receiver, "ack" 108 means an ack going from the receiver to the sender. A 109 preceding "*" indicates that the data is a retransmission. 110 A preceding "-" indicates a hole in the sequence space 111 (i.e., missing packet(s)), a "#" means an odd-size (not max 112 seg size) packet. Field 4 has the packet flags 113 (same format as raw trace). Field 5 is the sequence 114 number (start seq. num for sender, next expected seq number 115 for acks). The number in parens following an ack is 116 the delta-time from the first send of the packet to the 117 ack. A number in parens following a send is the 118 delta-time from the first send of the packet to the 119 current send (on duplicate packets only). Duplicate 120 sends or acks have a number in square brackets showing 121 the number of duplicates so far. 122 123 Here is a short sample from near the start of an ftp: 124 3.00 0.20 send . 512 125 3.20 0.20 ack . 1024 (0.20) 126 3.20 0.00 send P 1024 127 3.40 0.20 ack . 1536 (0.20) 128 3.80 0.40 * send . 0 (3.80) [2] 129 3.82 0.02 * ack . 1536 (0.62) [2] 130 Three seconds into the conversation, bytes 512 through 1023 131 were sent. 200ms later they were acked. Shortly thereafter 132 bytes 1024-1535 were sent and again acked after 200ms. 133 Then, for no apparent reason, 0-511 is retransmitted, 3.8 134 seconds after its initial send (the round trip time for this 135 ftp was 1sec, +-500ms). Since the receiver is expecting 136 1536, 1536 is re-acked when 0 arrives. 137 138packetdat.awk 139 Computes chunk summary data for an ftp (or similar 140 unidirectional tcp transfer). [A "chunk" refers to 141 a chunk of the sequence space -- essentially the packet 142 sequence number divided by the max segment size.] 143 144 A summary line is printed showing the number of chunks, 145 the number of packets it took to send that many chunks 146 (if there are no lost or duplicated packets, the number 147 of packets should equal the number of chunks) and the 148 number of acks. 149 150 Following the summary line is one line of information 151 per chunk. The line contains eight fields: 152 1 - the chunk number 153 2 - the start sequence number for this chunk 154 3 - time of first send 155 4 - time of last send 156 5 - time of first ack 157 6 - time of last ack 158 7 - number of times chunk was sent 159 8 - number of times chunk was acked 160 (all times are in decimal seconds, relative to the start 161 of the conversation.) 162 163 As an example, here is the first part of the output for 164 an ftp trace: 165 166 # 134 chunks. 536 packets sent. 508 acks. 167 1 1 0.00 5.80 0.20 0.20 4 1 168 2 513 0.28 6.20 0.40 0.40 4 1 169 3 1025 1.16 6.32 1.20 1.20 4 1 170 4 1561 1.86 15.00 2.00 2.00 6 1 171 5 2049 2.16 15.44 2.20 2.20 5 1 172 6 2585 2.64 16.44 2.80 2.80 5 1 173 7 3073 3.00 16.66 3.20 3.20 4 1 174 8 3609 3.20 17.24 3.40 5.82 4 11 175 9 4097 6.02 6.58 6.20 6.80 2 5 176 177 This says that 134 chunks were transferred (about 70K 178 since the average packet size was 512 bytes). It took 179 536 packets to transfer the data (i.e., on the average 180 each chunk was transmitted four times). Looking at, 181 say, chunk 4, we see it represents the 512 bytes of 182 sequence space from 1561 to 2048. It was first sent 183 1.86 seconds into the conversation. It was last 184 sent 15 seconds into the conversation and was sent 185 a total of 6 times (i.e., it was retransmitted every 186 2 seconds on the average). It was acked once, 140ms 187 after it first arrived. 188 189stime.awk 190atime.awk 191 Output one line per send or ack, respectively, in the form 192 <time> <seq. number> 193 where <time> is the time in seconds since the start of the 194 transfer and <seq. number> is the sequence number being sent 195 or acked. I typically plot this data looking for suspicious 196 patterns. 197 198 199The problem I was looking at was the bulk-data-transfer 200throughput of medium delay network paths (1-6 sec. round trip 201time) under typical DARPA Internet conditions. The trace of the 202ftp transfer of a large file was used as the raw data source. 203The method was: 204 205 - On a local host (but not the Sun running tcpdump), connect to 206 the remote ftp. 207 208 - On the monitor Sun, start the trace going. E.g., 209 tcpdump host local-host and remote-host and port ftp-data >tracefile 210 211 - On local, do either a get or put of a large file (~500KB), 212 preferably to the null device (to minimize effects like 213 closing the receive window while waiting for a disk write). 214 215 - When transfer is finished, stop tcpdump. Use awk to make up 216 two files of summary data (maxsize is the maximum packet size, 217 tracedata is the file of tcpdump tracedata): 218 awk -f send-ack.awk packetsize=avgsize tracedata >sa 219 awk -f packetdat.awk packetsize=avgsize tracedata >pd 220 221 - While the summary data files are printing, take a look at 222 how the transfer behaved: 223 awk -f stime.awk tracedata | xgraph 224 (90% of what you learn seems to happen in this step). 225 226 - Do all of the above steps several times, both directions, 227 at different times of day, with different protocol 228 implementations on the other end. 229 230 - Using one of the Unix data analysis packages (in my case, 231 S and Gary Perlman's Unix|Stat), spend a few months staring 232 at the data. 233 234 - Change something in the local protocol implementation and 235 redo the steps above. 236 237 - Once a week, tell your funding agent that you're discovering 238 wonderful things and you'll write up that research report 239 "real soon now". 240