van@LBL-CSAM.ARPA.UUCP (01/09/87)
An incredible number of people have requested my tcp monitor.
It's available via anonymous ftp from host lbl-rtsg.arpa
(128.3.254.68 or 128.3.255.68), file tcpdump.tar. This is
a binary file in Unix tar format (remember to set binary
mode before you ftp it). It contains the program executable,
manual entry, README file and a couple of data analysis awk
scripts. The file is about 100KB. A copy of the README
file, describing the program and giving examples of some
of the things you can do with it, is appended to this
message (and I apologize for the length of this message).
The program runs on a Sun-3 under version 3.2 or later of
the Sun OS. It may run under earlier versions of the system.
It won't run on a Sun-2.
The source isn't available (don't even ask). The program was,
unfortunately, originally based on Sun's etherfind so I won't
distribute it without permission from Sun. It doesn't matter
if you have a Sun source license, we are not an authorized
re-distributor of Sun source. If anyone from Sun is reading
this, it would be nice if you could
- send me a letter saying it's ok to distribute the source, or
- send me a letter saying it's ok to submit the source for the
upcoming Sun user group tape.
If neither of the above is acceptable, maybe I'll just give you
the source and you can figure out what to do with it.
I would appreciate it if someone would post the tar to mod.sources
or any other appropriate redistribution points. I'll be traveling
most of the next month. Please don't send me mail asking if I'll
mail the program to you.
Best of luck using the program. Hope it helps dispel some of the
tcp mis-information and folklore that's been floating around.
- Van
------------------------
Fri Jan 9 05:40:50 PST 1987
This directory contains the binary and manual entry for an
ethernet monitor program, tcpdump. The program runs on a Sun-3
under Sun OS version 3.2 or later (kernel bugs in earlier
versions of the system make it inadvisable to run this program).
The program is loosely based on SMI's "etherfind" although very
little of the etherfind code remains. It was written by Van
Jacobson, Lawrence Berkeley Laboratory, as part of an ongoing
research project to investigate and improve tcp and internet
gateway performance.
The current versions of these files are available via anonymous
ftp from host lbl-rtsg.arpa (128.3.254.68 or 128.3.255.68), file
tcpdump.tar (a Unix tar file). The source to the program is not
currently available (pending distribution permission from Sun).
The author would welcome comments, bug reports, etc. I can be
reached via electronic mail to van@lbl-csam.arpa or van@lbl-rtsg.arpa.
As of this writing, I have a backlog of 6 months of unread mail
(2500 msgs) so don't expect a prompt reply. It is, for all
practical purposes, impossible to reach me by telephone.
The program is copyright (C) 1987 by Van Jacobson, Lawrence
Berkeley Laboratory. You are free to copy and redistribute
it as long as you don't charge for it. If you try to sell
tcpdump or claim that it's yours, I'll sic our overpaid,
underworked lawyers on you.
This directory also contains two short awk programs intended as
examples of ways to reduce tcpdump data when you're tracking
particular network problems. 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 between local remote 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 tranfer is finished, stop tcpdump. Make a copy of the
tracefile and delete the initial SYN packets and final FIN
packets from the copy (using the editor). While doing this,
make note of the average packet size.
- Use awk to make up the two files of summary data:
awk -f send-ack.awk packetsize=avgsize tracecopy >sa
awk -f packetdat.awk packetsize=avgsize tracecopy >pd
- 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 raw and reduced 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".
In both the awk programs we assume that all packets are about
the same size, the tcp max segment size (a size variation of
about 40% is handled ok). Given this, we can regard the
sequence space as consecutive mss-size "chunks" and can label
each packet by the "chunk" it transports rather than the bytes
it transports. I.e., the packet numbers will be 1, 2, 3, ...
instead of 1, 513, 1025, .... (This simply makes it easier
to spot holes and duplicates, plot different views of the data,
etc.) Keeping this chunking in mind, the awk programs are:
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". Sequence
numbers are converted to "chunk numbers" by assuming all
packets are about the same size and dividing the start sequence
number by that size.
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)). Field 4 has the packet flags
(same format as raw trace). Field 5 is the "chunk
number", essentially the start sequence number divided by
the max segment size (rounded down to the nearest mss).
Send and ack numbers correspond, e.g., "ack 7" is the ack
for "send 7". 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 . 7
3.20 0.20 ack . 7 (0.20)
3.20 0.00 send P 8
3.40 0.20 ack . 8 (0.20)
3.80 0.40 * send . 1 (3.80) [2]
3.82 0.02 * ack . 8 (0.62) [2]
Three seconds into the conversation, chunk 7 was sent. 200ms
later it was acked. Shortly thereafter chunk 8 was sent and,
again, it was acked after 200ms. Then, for no apparent reason,
chunk 1 is retransmitted, 3.8 seconds after its initial
send (the round trip time for this ftp was 1sec, +-500ms).
Since the receiver is expecting chunk 9, chunk 8 is re-acked
when chunk 1 arrives.
packetdat.awk
Computes chunk summary data for an ftp (or similar
unidirectional tcp transfer).
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 transfered (about 70KB
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.
(The data for this and the preceding example were
taken from a Stanford-to-LBL ftp. As of this
writing, Stanford provides several fine sources of
"interesting" tcp behavior.)