diff options
Diffstat (limited to 'contrib/tcpdump/README')
| -rw-r--r-- | contrib/tcpdump/README | 235 |
1 files changed, 0 insertions, 235 deletions
diff --git a/contrib/tcpdump/README b/contrib/tcpdump/README deleted file mode 100644 index cb51d30..0000000 --- a/contrib/tcpdump/README +++ /dev/null @@ -1,235 +0,0 @@ -@(#) $Header: /tcpdump/master/tcpdump/README,v 1.65.2.1 2007/09/14 01:03:12 guy Exp $ (LBL) - -TCPDUMP 3.9 -Now maintained by "The Tcpdump Group" -See www.tcpdump.org - -Please send inquiries/comments/reports to tcpdump-workers@tcpdump.org - -Anonymous CVS is available via: - cvs -d :pserver:cvs.tcpdump.org:/tcpdump/master login - (password "anoncvs") - cvs -d :pserver:cvs.tcpdump.org:/tcpdump/master checkout tcpdump - -Version 3.9 of TCPDUMP can be retrieved with the CVS tag "tcpdump_3_9rel1": - cvs -d :pserver:cvs.tcpdump.org:/tcpdump/master checkout -r tcpdump_3_9rel1 tcpdump - -Please submit patches against the master copy to the tcpdump project on -sourceforge.net. - -formerly from Lawrence Berkeley National Laboratory - Network Research Group <tcpdump@ee.lbl.gov> - ftp://ftp.ee.lbl.gov/tcpdump.tar.Z (3.4) - -This directory contains source code for tcpdump, a tool for network -monitoring and data acquisition. This software was originally -developed by the Network Research Group at the Lawrence Berkeley -National Laboratory. The original distribution is available via -anonymous ftp to ftp.ee.lbl.gov, in tcpdump.tar.Z. More recent -development is performed at tcpdump.org, http://www.tcpdump.org/ - -Tcpdump uses libpcap, a system-independent interface for user-level -packet capture. Before building tcpdump, you must first retrieve and -build libpcap, also originally from LBL and now being maintained by -tcpdump.org; see http://www.tcpdump.org/ . - -Once libpcap is built (either install it or make sure it's in -../libpcap), you can build tcpdump using the procedure in the INSTALL -file. - -The program is loosely based on SMI's "etherfind" although none of the -etherfind code remains. It was originally written by Van Jacobson as -part of an ongoing research project to investigate and improve tcp and -internet gateway performance. The parts of the program originally -taken from Sun's etherfind were later re-written by Steven McCanne of -LBL. To insure that there would be no vestige of proprietary code in -tcpdump, Steve wrote these pieces from the specification given by the -manual entry, with no access to the source of tcpdump or etherfind. - -Over the past few years, tcpdump has been steadily improved by the -excellent contributions from the Internet community (just browse -through the CHANGES file). We are grateful for all the input. - -Richard Stevens gives an excellent treatment of the Internet protocols -in his book ``TCP/IP Illustrated, Volume 1''. If you want to learn more -about tcpdump and how to interpret its output, pick up this book. - -Some tools for viewing and analyzing tcpdump trace files are available -from the Internet Traffic Archive: - - http://www.acm.org/sigcomm/ITA/ - -Another tool that tcpdump users might find useful is tcpslice: - - ftp://ftp.ee.lbl.gov/tcpslice.tar.Z - -It is a program that can be used to extract portions of tcpdump binary -trace files. See the above distribution for further details and -documentation. - -Problems, bugs, questions, desirable enhancements, etc. should be sent -to the address "tcpdump-workers@tcpdump.org". Bugs, support requests, -and feature requests may also be submitted on the SourceForge site for -tcpdump at - - http://sourceforge.net/projects/tcpdump/ - -Source code contributions, etc. should be sent to the email address -"patches@tcpdump.org", or submitted as patches on the SourceForge site -for tcpdump. - -Current versions can be found at www.tcpdump.org, or the SourceForge -site for tcpdump. - - - The TCPdump team - -original text by: Steve McCanne, Craig Leres, Van Jacobson - -------------------------------------- -This directory also contains some short awk programs intended as -examples of ways to reduce tcpdump data when you're tracking -particular network problems: - -send-ack.awk - Simplifies the tcpdump trace for an ftp (or other unidirectional - tcp transfer). Since we assume that one host only sends and - the other only acks, all address information is left off and - we just note if the packet is a "send" or an "ack". - - There is one output line per line of the original trace. - Field 1 is the packet time in decimal seconds, relative - to the start of the conversation. Field 2 is delta-time - from last packet. Field 3 is packet type/direction. - "Send" means data going from sender to receiver, "ack" - means an ack going from the receiver to the sender. A - preceding "*" indicates that the data is a retransmission. - A preceding "-" indicates a hole in the sequence space - (i.e., missing packet(s)), a "#" means an odd-size (not max - seg size) packet. Field 4 has the packet flags - (same format as raw trace). Field 5 is the sequence - number (start seq. num for sender, next expected seq number - for acks). The number in parens following an ack is - the delta-time from the first send of the packet to the - ack. A number in parens following a send is the - delta-time from the first send of the packet to the - current send (on duplicate packets only). Duplicate - sends or acks have a number in square brackets showing - the number of duplicates so far. - - Here is a short sample from near the start of an ftp: - 3.00 0.20 send . 512 - 3.20 0.20 ack . 1024 (0.20) - 3.20 0.00 send P 1024 - 3.40 0.20 ack . 1536 (0.20) - 3.80 0.40 * send . 0 (3.80) [2] - 3.82 0.02 * ack . 1536 (0.62) [2] - Three seconds into the conversation, bytes 512 through 1023 - were sent. 200ms later they were acked. Shortly thereafter - bytes 1024-1535 were sent and again acked after 200ms. - Then, for no apparent reason, 0-511 is retransmitted, 3.8 - seconds after its initial send (the round trip time for this - ftp was 1sec, +-500ms). Since the receiver is expecting - 1536, 1536 is re-acked when 0 arrives. - -packetdat.awk - Computes chunk summary data for an ftp (or similar - unidirectional tcp transfer). [A "chunk" refers to - a chunk of the sequence space -- essentially the packet - sequence number divided by the max segment size.] - - A summary line is printed showing the number of chunks, - the number of packets it took to send that many chunks - (if there are no lost or duplicated packets, the number - of packets should equal the number of chunks) and the - number of acks. - - Following the summary line is one line of information - per chunk. The line contains eight fields: - 1 - the chunk number - 2 - the start sequence number for this chunk - 3 - time of first send - 4 - time of last send - 5 - time of first ack - 6 - time of last ack - 7 - number of times chunk was sent - 8 - number of times chunk was acked - (all times are in decimal seconds, relative to the start - of the conversation.) - - As an example, here is the first part of the output for - an ftp trace: - - # 134 chunks. 536 packets sent. 508 acks. - 1 1 0.00 5.80 0.20 0.20 4 1 - 2 513 0.28 6.20 0.40 0.40 4 1 - 3 1025 1.16 6.32 1.20 1.20 4 1 - 4 1561 1.86 15.00 2.00 2.00 6 1 - 5 2049 2.16 15.44 2.20 2.20 5 1 - 6 2585 2.64 16.44 2.80 2.80 5 1 - 7 3073 3.00 16.66 3.20 3.20 4 1 - 8 3609 3.20 17.24 3.40 5.82 4 11 - 9 4097 6.02 6.58 6.20 6.80 2 5 - - This says that 134 chunks were transferred (about 70K - since the average packet size was 512 bytes). It took - 536 packets to transfer the data (i.e., on the average - each chunk was transmitted four times). Looking at, - say, chunk 4, we see it represents the 512 bytes of - sequence space from 1561 to 2048. It was first sent - 1.86 seconds into the conversation. It was last - sent 15 seconds into the conversation and was sent - a total of 6 times (i.e., it was retransmitted every - 2 seconds on the average). It was acked once, 140ms - after it first arrived. - -stime.awk -atime.awk - Output one line per send or ack, respectively, in the form - <time> <seq. number> - where <time> is the time in seconds since the start of the - transfer and <seq. number> is the sequence number being sent - or acked. I typically plot this data looking for suspicious - patterns. - - -The problem I was looking at was the bulk-data-transfer -throughput of medium delay network paths (1-6 sec. round trip -time) under typical DARPA Internet conditions. The trace of the -ftp transfer of a large file was used as the raw data source. -The method was: - - - On a local host (but not the Sun running tcpdump), connect to - the remote ftp. - - - On the monitor Sun, start the trace going. E.g., - tcpdump host local-host and remote-host and port ftp-data >tracefile - - - On local, do either a get or put of a large file (~500KB), - preferably to the null device (to minimize effects like - closing the receive window while waiting for a disk write). - - - When transfer is finished, stop tcpdump. Use awk to make up - two files of summary data (maxsize is the maximum packet size, - tracedata is the file of tcpdump tracedata): - awk -f send-ack.awk packetsize=avgsize tracedata >sa - awk -f packetdat.awk packetsize=avgsize tracedata >pd - - - While the summary data files are printing, take a look at - how the transfer behaved: - awk -f stime.awk tracedata | xgraph - (90% of what you learn seems to happen in this step). - - - Do all of the above steps several times, both directions, - at different times of day, with different protocol - implementations on the other end. - - - Using one of the Unix data analysis packages (in my case, - S and Gary Perlman's Unix|Stat), spend a few months staring - at the data. - - - Change something in the local protocol implementation and - redo the steps above. - - - Once a week, tell your funding agent that you're discovering - wonderful things and you'll write up that research report - "real soon now". |
