Packet sniffers
tcpdump, snoop, and nettl belong to a class of tools known as packet sniffers. They listen to the traffic on a network and record or print packets that meet certain criteria specified by the user. For example, all packets sent to or from a particular host or TCP packets related to one particular network connection could be inspected.
Packet sniffers are useful both for solving problems you know about and for discovering entirely new problems. It's a good idea to take an occasional sniff of your net work to make sure the traffic is in order.
Since packet sniffers need to be able to intercept traffic that the local machine would not normally receive (or at least, pay attention to), the underlying network hardware must allow access to every packet. Broadcast technologies such as Ethernet work fine, as do some types of token ring network on which the sender of a packet removes it from the ring after it has made a complete circuit.
Since packet sniffers need to see as much of the raw network traffic as possible, they can be thwarted by network switches, which by design try to limit the propagation of -unnecessary" packets. However, it can still be informative to try out a sniffer on a switched network. You may discover problems related to broadcast or multicast packets. Depending on your switch vendor, you may be surprised at how much traffic you can see.
In addition to having potential access to all network packets, the interface hardware must provide a way to actually transport those packets up to the software layer. Packet addresses are normally checked in hardware, and only broadcast/multicast packets and those addressed to the local host are relayed to the kernel.
In -promiscuous mode," an interface lets the kernel read all packets on the network, even the ones intended for other hosts. Packet sniffers understand many of the packet formats used by standard UNIX daemons, and they can often print out packets in a human-readable form. This capability makes it easier to track the flow of a conversation between two programs. Some sniffers print the ASCII contents of a packet in addition to the packet header, which can be useful for investigating high-layer protocols. Since some of these protocols send information (and even passwords) across the network as cleartext, you must exercise caution to avoid invading the privacy of your users.
Each of our example operating systems comes with a packet sniffer. The sniffer must read data from a raw network device, so it must run as root. Although the root limitation serves to decrease the chance that normal users will listen in on your network traffic, it is really not much of a barrier. Some sites choose to remove the sniffers from most hosts to reduce the chance of abuse. If nothing else, you should check your systems' interfaces to be sure they are not running in promiscuous mode without your knowledge or consent. snoop: Solaris's packet sniffer
Solaris includes a packet sniffer called snoop. It takes arguments on the command line that specify how to behave and what packets to collect. snoop can filter packets based on host, protocol, packet type, and port number, among other things.
With no arguments, snoop collects packets from the first interface it finds, which is usually also the first interface listed by netstat -i (excluding the loopback). To specify a particular interface, use the -d device flag, where device is the name of the interface as reported by netstat -i (often hme0 for the first Ethernet interface). Using the -V flag gives you a little more information, and the -v flag gives you several lines of detail on each packet.
snoop's command-line language is quite sophisticated, and it is well documented in the snoop man page. Expressions can be created with primitives such as host, port, tcp, udp, and ip. Simple expressions can be combined with primitives such as and, or, and not. Let's look at a couple of examples.
Below is the output of a snoop session that might be useful for debugging mail between the hosts evolve and xor.com. We overspecified the filters to snoop to give a better example:
# snoop host chimchim and host evolve and tcp port 25
evolve.xor.com -> xor.com SMTP C
xor.com -> evolve.xor.com SMTP R 220 xor.com ESMTP Se
evolve.xor.com -> xor.com SMTP C
evolve.xor.com -> xor.com SMTP C EHLO evolve.xor.com\r
xor.com -> evolve.xor.com R 250- xor.com Hello ev
evolve.xor.com -> xor.com SMTP C MAIL FROM: <root@evol
xor.com -> evolve.xor.com SMTP R
xor.com -> evolve.xor.com SMTP R 250 <root@evolve.xor
evolve.xor.com -> xor.com SMTP C RCPT TO:<ned@xor.com>
xor.com -> evolve.xor.com SMTP R 250 <ned@xor.com>...
evolve.xor.com -> xor.com SMTP C DATA\r\n
xor.com -> evolve.xor.com SMTP R 354 Enter mail, end
You should read the command and arguments above like this: -Capture all packets between the hosts chimchim and evolve which involve TCP port 25."
This example shows one line for each packet that was collected. The packet's source is written first, and the destination appears in the second column. The remainder of the line contains information from the highest layer of the packet, such as protocol, port, and the first few bytes of the packet's data (we cut out a few columns from this example to save space).
If you telnet to a host and run snoop there, you must filter out the traffic from your telnet session. Otherwise, output to your terminal will get caught in loop as it is displayed on the virtual terminal, sent across the telnet session, and captured again. To ignore all traffic to or from the host evolve, you would use a command such as:
# snoop not host evolve
If we were investigating a failing DNS server named mrhat, we might use the following command line:
# snoop host mrhat | grep DNS
This command incorporates a grep to further limit the packets that are displayed.
nettl: HP-UX's packet sniffer
HP-UX is bundled with a sick joke of a packet sniffer called nettl. (Note: Score one for truth in command naming: -nettle, vt.: to irritate; vex," American Heritage Dictionary of the English Language, Third Edition.) nettl is actually very powerful and can keep up with a fast network, but configuring it is such a hassle that it is rarely useful for short-term network debugging. If you plan on doing network debugging from an HP-UX host, we recommend that you install tcpdump.
nettl is part of HP-UX's Network Tracing and Logging package. By default, nettl logging is started at boot time. Unless you want to use nettl to collect data indefinitely, it is wise to disable it until you need it. Edit the /etc/rc.config.d/nettl file and set the NETTL variable to 0.
nettl reads its configuration information from /etc/nettlgen.conf.
tcpdump: king of sniffers
tcpdump, yet another amazing network tool by Van Jacobson, is distributed with Red Hat Linux and FreeBSD. It is also available in source form for HP-UX, Solaris, and most other operating systems. tcpdump behaves much like snoop and has long been the industry-standard sniffer.
By default, tcpdump tunes in on the first network interface that it comes across. If it chooses the wrong interface, you can force an interface with the -i flag. If DNS is broken or you just don't want tcpdump doing name lookups, use the -n option. This option is important because slow DNS service can cause the filter to start dropping packets before they can be dealt with by tcpdump. The -v flag increases the information you see about packets, and -vv gives you even more data. Finally, tcpdump can store packets to a file with the -w flag and can read them back in with the -r flag.
For example, the following output comes from the machine jaguar.xor.com. The filter specification host jaguar limits the display of packets to those that directly involve the machine jaguar, either as source or as destination.
# tcpdump host jaguar
13:40:23 jaguar.xor.com.1697 > xor.com.domain: A? cs.colorado.edu.
13:40:23 xor.com.domain > jaguar.xor.com.1697: A mroe.cs.colorado.edu
13:40:23 jaguar.xor.com.1698 > xor.com.domain: PTR? 5.96.138.128.in-addr.arpa.
13:40:23 xor.com.domain > jaguar.xor.com.1698: PTR mroe.cs.colorado.edu.
The first packet shows jaguar sending a DNS lookup request about cs.colourado.edu to xor.com. The response is the actual name of the machine for which that name is an alias, which is mroe.cs.colourado.edu. The third packet is a reverse lookup of mroe's IP address, and the fourth packet contains the expected response.
The tcpdump man page contains several good examples of advanced filtering along with a complete listing of primitives.
1%
8%
