TCPdump is the UNIX version of a packet decoder, and
Lawrence Berkeley Labs
is the place to look for it.
Originally written by Van Jacobsen to analyze TCP performance
problems, it is still a decent tool for that task, but
many features have been added since then.
Getting TCPdump to work on a UNIX system can be a chore.
TCPdump must be able to put the interface (typically an Ethernet)
into promiscuous mode to read all the network traffic.
Currently supported systems include SunOS, Ultrix, and most BSDs.
Linux is not supported, though there have been reports of a port.
Using TCPdump
The simplest way to use TCPdump is to run it with just
an `-i' switch to specify which network interface should be used.
This will dump summary information for every Internet packet
received or transmitted on the interface.
However, TCPdump provides several important options, as well
as the ability to specify an expression
to restrict the range of packets you wish to study.
Rather than rehash here what is better documented elsewhere,
I suggest you read TCPdump's exceptionally well written
manual page, particularly
if you intend to use TCPdump for analyzing TCP, DNS, NFS, SLIP,
or Appletalk.
Problems You Might Encounter
No output
Check to make sure you're specifying the correct network interface
with the -i option, which I suggest you always use explicitly.
If you're having DNS problems, TCPdump might hang trying to lookup
DNS names for IP addresses, try the -f or -n options
to disable this feature. If you still see nothing,
check the kernel interface - TCPdump might be mis-configured for
your system.
Dropped packets
At the end of its run, TCPdump will inform you if any packets were
dropped in the kernel. If this becomes a problem, it's likely
that your host can't keep up with the network traffic and
decode it at the same time. Try using TCPdump's -w option
to bypass the decoding and write the raw packets to a file,
then come back later and decode the file with the -r switch.
You can also try using -s to reduce the capture snapshot size.
Messages that end like[|rip]and[|domain]
Messages ending with [|proto] indicate that the packet
couldn't be completely decoded because
the capture snapshot size (the so-called "snarf length") was too small.
Increase it with the -s switch.
Decoding RIP traces
TCPdump assumes that UDP packets sourced from or targeted at
port 520 conform to the
Routing Information Protocol (RIP),
the distance-vector interior IP routing protocol, of which several
versions are in use.
RIP packets can be explicitly requested from traceroute
by specifying the clause udp port route.
For each RIP packet, TCPdump prints the RIP command.
If the RIP command is rip-resp, the routing information
in the packet is printed.
If the RIP decode ends with [|rip], the packet was
truncated and though it contained additional routing entries,
they could not be decoded. Use the -s
switch to enlarge the capture snapshot size.
According to RFC 1058, the maximum size of a RIP packet is
512 bytes, excluding the IP header (usually 20 bytes) and the
UDP header (usually 8 bytes). Using -s540 should
capture even the largest RIP packets.
