210 lines
8.7 KiB
Plaintext
210 lines
8.7 KiB
Plaintext
$NetBSD: README,v 1.3 1995/03/07 23:18:35 mycroft Exp $
|
|
@(#) Header: README,v 1.39 94/06/20 20:15:16 leres Exp (LBL)
|
|
|
|
TCPDUMP 3.0
|
|
Lawrence Berkeley Laboratory
|
|
Network Research Group
|
|
tcpdump@ee.lbl.gov
|
|
ftp://ftp.ee.lbl.gov/tcpdump-*.tar.Z
|
|
|
|
This directory contains source code for tcpdump, a tool for network
|
|
monitoring and data acquisition. The original distribution is
|
|
available via anonymous ftp to ftp.ee.lbl.gov, in tcpdump-*.tar.Z.
|
|
|
|
Tcpdump now uses libcap, a system-independent interface for
|
|
user-level packet capture. Before building tcpdump, you must
|
|
first retrieve and build libpcap, also from LBL, in:
|
|
|
|
ftp://ftp.ee.lbl.gov/libpcap-*.tar.Z.
|
|
|
|
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.
|
|
|
|
Tcpdump and libpcap have been built and tested under SGI Irix 4.x & 5.2,
|
|
SunOS 4.x, Solaris 2.3, BSD/386 v1.1, DEC/OSF v1.3 v2.0, and Ultrix 4.x.
|
|
SunOS 3.5, 4.3BSD Reno/Tahoe and 4.4BSD are supported as well, but we
|
|
currently do not have the resources to carry out testing in these
|
|
environments (we suspect you'll run into problems building the most
|
|
recent version under these systems -- please send us the patches if
|
|
you fix any porting problems).
|
|
|
|
Tcpdump has reportedly been ported to Mach 3.0 and Linux, but we have
|
|
not received patches to integrate back into the master source tree.
|
|
|
|
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
|
|
it's output, pick up this book.
|
|
|
|
Problems, bugs, questions, desirable enhancements, etc., should be
|
|
sent to the email address "tcpdump@ee.lbl.gov".
|
|
|
|
- Steve McCanne (mccanne@ee.lbl.gov)
|
|
Craig Leres (leres@ee.lbl.gov)
|
|
Van Jacobson (van@ee.lbl.gov)
|
|
-------------------------------------
|
|
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".
|
|
|