Sign In Sign-Up

Welcome!

Close

Would you like to make this site your homepage? It's fast and easy...

Yes, Please make this my home page!

No Thanks

  Don't show this to me again.

Close

TCPdump

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.

• TCPdump(1)