TCP/IP Packet Headers
This section describes the contents of a TCP/IP packet header so you can understand what you see in the Tcpdump display. The layout of the TCP/IP packet is specified in RFC 793 for the TCP portion and RFC 791 for the IP portion. You can find the full text of these RFCs online at www.rfc-editor.org. Figure 6.1 is a graphical representation of TCP and IP headers. Both header types are at least 20 bytes long and are usually shown in 32-bit (4-byte) sections with the addresses, options, and other settings for the session.
Figure 6.1. TCP/IP Header
Let's look at the IP portion first, since this is the lowest layer of the network model. The IP protocol header contains the delivery address for the packet and its sender. Since each address is 32 bits (4 octets of 8 bits each), the source and destination IP address takes up 8 bytes. The first part of the header contains various switches and options for the packet. The first line contains several switches that identify the IP version. Most networks uses IP version 4 (IPv4), but a newer 128-bit IP system called IP version 6 (IPv6) has been circulating for several years and has been gradually gaining acceptance. IPv6 is supposed to solve the IP address space problem by allowing up to 128 bits for the address portion.
This should create enough addresses to solve any foreseeable address space needs. IPv6 also resolves the security and verification issues with IPv4. But for now, you will mostly see IPv4 packets. Then there are the Header Length and the Type Of Service settings (TOS), which allow for differentiating in the priority of packets. The last part of this line is the total length of the header, which is normally the same from packet to packet (20 bytes), but can vary for newer protocols like IPv6.
The next two lines deal with identification of the packet and a checksum to make sure that it is valid. Finally, there are the source and destination IP addresses, and an options field that can be variable length or padded with zeros and any data.
The TCP header takes care of establishing a TCP session and higher-level functions. It is usually 20 bytes long and starts with a source port number of 16 bits and a destination port number of 16 bits. This is why the port numbers can only go up to 65,535—because the port number field in TCP/IP is a 16-bit binary number and 216 power equals 65,536, or 0–65,565. (It is interesting how all these seemingly arbitrary numbers always have a basis in something.)
The port numbers, as mentioned earlier, identify which program the packets need to be directed to on the remote machine and identify the session on the local machine. The next line contains a sequence number. This is used to reassemble the packets in the right order at the other end, even if they arrive in a different order. This is one of the fault-tolerant aspects of TCP sessions. After that, there is an acknowledgment number, also 32 bits long, which allows for verification that it is coming from the right machine. The next line contains a 4-bit section called the data offset, which gives how many 32-bit lines or "words" are in this header (typically 4) and 6 bits that are reserved for future use. After that there is a 6-bit section called the TCP Flags; the last half of that line is used to confer the window size, which tells the recipient how many bits the sender is willing to accept. The Flags are pretty important, as this is where different TCP control bits are set that control how the packet is handled. Each type of TCP communication is designated by one bit, with one being on, or set, and zero being off. Table 6.1 lists the six fields of the TCP Flag section and describes their use. Note: Each "field" is one bit wide, simply a one or zero, on or off.
Table 6.1. TCP Flag Fields
Indicates the TCP priority of the packets.
Designates this packet as an acknowledgment of receipt.
Flushes queued data from buffers.
Resets a TCP connection on completion or being aborted.
Synchronizes a connection.
Finishes a transmission.
Normally only one or two of these fields are on (the bits set to one), but as you saw in Chapter 4, there is nothing to stop you from sending a packet with all these bits flipped on (XMAS scan) or flipped off (NULL scan) to try to confuse a remote system.
Next are the TCP checksum and an urgent pointer. Then there is a line with any TCP options for the packet. These might include additional checksums, timestamps, or other optional information. This line is padded out to 32 bits with zeros if the options don't fill all the space. Finally the actual payload, the data of the packet, follows. This may seem like a lot of administrative overhead for sending one packet (approximately 48 bytes for every packet), but it does ensure a relatively stable connection on networks that are not always reliable end to end (like the Internet). And indeed, because of the TCP overhead, some protocols that are not connection-sensitive use UDP, which is a connectionless protocol that lowers the amount of overhead.
On a standard Tcpdump session with normal verbosity, you will see a timestamp followed by the TCP sequence number. Then it shows parts of the IP stack, including the source and destination with a > (greater than sign) between them, meaning this packet is going from here to there. At the end is the info field, which tells what the packet is doing. You can use the -v or -vv option to get more detail from Tcpdump about the header (see the next section).
Usually, you will want to run Tcpdump with some of the options or filters set to narrow down and focus the output. The general form of the Tcpdump statement is:
tcpdump options expressions
Replace options or expressions with one or more of the valid variables. Table 6.2 lists the Tcpdump options.
Table 6.2. Tcpdump Options
Attempts to convert addresses to names. This puts a higher load on the system and may cause packet loss.
Stops Tcpdump after count number of packets are processed.
Limits the output files to filesize number of bytes.
Dumps the packet-matching code in a human-readable form and then stops.
Dumps the packet-matching code as a C program fragment.
Dumps the packet-matching code as decimal numbers.
Prints the link-level header on each dump line. This is the MAC address on an Ethernet network.
Uses Tcpdump's built-in ability to decrypt packets encrypted with IPsec ESP on the fly. Of course, you must have the shared secret to use this option. The algo options include des-cbc, 3des-cdc, blowfish-cbc, r3c-cbc, cast 128-cbc, and none. The default is des-cbc. The value of secret should be the ESP secret key in ASCII text form. For more information on IPsec, see Chapter 9.
Uses the filename file as input rather than taking input live from the wire. This is useful for analyzing events after the fact.
Reads from interface when there are multiple network interfaces on the sniffer machine. By default, Tcpdump uses the lowest numbered valid interface. On Linux boxes, you can also use the parameter any to capture packets on all network interfaces.
Doesn't convert addresses to names.
Doesn't print the upper-level domain name element of host names. This is useful if you need to provide a sanitized version of the output and don't want to reveal whose network it is on.
Doesn't put the interface into promiscuous mode. Only used when you are troubleshooting traffic to your sniffer box.
Prints quick output. Less protocol information is printed so the lines are shorter.
Forces packets selected by the filter in the expression to be interpreted by type.
Doesn't print a timestamp on each line.
Prints an unformatted timestamp on each line.
Prints the delta time between packets.
Prints a timestamp in a default format preceded by the date on each line.
Uses slightly more verbose output. Includes the time-to-live, identification, total length, and options fields of each packet.
Provides more verbose output. NFS and SMB packets are fully decoded.
Provides even more verbose output. This may seriously slow down your sniffer.
Writes the packets to the file filename rather than displaying them on the screen. This way, unattended sniffing can be saved and analyzed later. For example, if you had some strange things happening on your network, you could leave Tcpdump running overnight to capture any odd traffic. Just make sure you write a good filter, or you could have a very large file when you come back in the morning.
Displays each packet (minus the link-level header) in hex.
Displays packet contents in both hex and ASCII.
The Tcpdump expressions select which packets from the datastream are displayed. This is where the work of Tcpdump is really done. Only items that match the expression are dumped; if no expression is given, then all packets will be displayed. A Tcpdump expression consists of one more directives, called primitives. These consist of an ID followed by a qualifier. Table 6.3 lists the three different kinds of qualifiers, and Table 6.4 lists the allowable primitive combinations.
Table 6.3. Tcpdump Qualifiers
Specifies what the ID name or number refers to. Possible types are host, net, and port. For example, host foo, net 128.3, or port 20.
Specifies the direction of traffic from a particular ID. Possible directions are src; dst; src or dst; and src and dst (src stands for source address and dst stands for destination address).
Lets you specify the protocol to filter out. Possible protos are ether, fddi, tr, ip, ipv6, arp, rarp, decnet, tcp, and udp. If no proto is specified, then all protocols consistent with the rest of the expression are allowed. You can use this to find out which machine is doing excessive arps or to filter out udp requests, which can be extensive on many networks since DNS requests use udp.
Table 6.4. Allowable Primitive Combinations
dst host host
Shows only traffic addressed to host, which may be either an IP address or hostname.
src host host
Shows only traffic coming from host.
Shows traffic either originating or destined for host.
ether dst ehost
Shows traffic destined for a specific Ethernet name, ehost, which can be either a name or a number (MAC address).
ether src ehost
Shows traffic originating from ehost.
ether host ehost
Shows traffic either originating from or destined for ehost.
Shows any traffic that used host as a gateway. In other words, it was forwarded from host. This happens when the IP source or destination address doesn't match the Ethernet address of host. You can use this when you want to track all traffic going through your Internet gateway or some specific router.
dst net net
Filters traffic that is destined for a specific network, net, specified in 0.0.0.0 notation. Similar to ether dst ehost, except it can be much broader than a single host.
src net net
Filters for a source network, net.
Same as the previous two statements except it allows traffic either from or to the net network.
net net mask netmask
Matches traffic from or to net network with a netmask of netmask. Used for specifying the exact size of a network in increments smaller than a class C. You can also use src or dst with this statement to specify the direction of the traffic.
Matches traffic with network addresses of net and len bits in the netmask. Similar to the last statement.
dst port port
Filters TCP and UDP traffic with a destination port value of port. You can also specify either TCP or UDP here to only catch traffic of that type. Otherwise, both types are shown.
src port port
Same as the last statement, except this captures traffic with a source port of port.
Shows packets with a length of less than length. This can also be stated as len <= length.
Same as the statement above except it captures only traffic of length greater than the length value.
ip proto protocol
Captures traffic that is of a specific protocol type. Allowable names are icmp, icmpv6, igmp, igrp, pim, ah, esp, vrrp, udp, and tcp. The names tcp, udp, and icmp must be put between backslashes in order to keep them from being read as keywords. For example: ip proto protocol /tcp/.
ip6 proto protocol
Similar to the above statement but for IPv6 packets and types.
ip6 protochain protocol
Finds IPv6 packets that have a protocol header of protocol.
ip protochain protocol
Same as above but for IPv4 packets.
Identifies only traffic that is broadcast, that is, has all zeros or all ones in the destination fields.
Registers true (displays) if the packet is an Ethernet multicast packet.
Registers true if the packet is an IP multicast packet.
Registers true if the packet is an IPv6 multicast packet.
ether proto protocol
Displays any traffic that is of Ethernet type procotol. Allowable protocol names are ip, ipv6, arp, rarp, atalk, aarp, decnet, sca, lat, mopdl, moprc, iso, stp, ipx, or netbeui. These names are also identifiers, so they must be escaped by using backslashes.
decnet src host
Captures DECnet traffic with a source address of host.
decnet dst host
Same as the above statement but filters on destination address of host.
Filters for DECnet addresses with either the source or destination equal to host.
A shorter version of the ether proto statement described earlier. Traps traffic matching the Ethernet protocol of IP.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of IPv6.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of arp.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of rarp.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of AppleTalk.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of aarp.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of DECnet.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of iso.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of stp.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of ipx.
Shorter version of the ether proto statement for trapping traffic matching the Ethernet protocol of netbeui.
Captures packets based on the 802.1Q VLAN standard. It can be used by itself or by specifying vlan_id.
An abbreviated form of the statement ip proto tcp.
An abbreviated form of the statement ip proto udp.
An abbreviated form of the statement ip proto icmp.
iso proto protocol
Captures OSI packets with a protocol type of procotol. Allowable OSI protocol types are clnp, esis, and isis.
An abbreviated form of the above statement using clnp for protocol.
An abbreviated form of the iso proto protocol statement using esis for protocol.
An abbreviated form of the iso proto protocol statement using isis for protocol.
There are also more complex expressions that can be constructed using Boolean arithmetic operators such as and, or, not, greater than, and less than. See the Tcpdump man page for examples and usage.
The following are several practical examples of ways to use Tcpdump.
View All Traffic to and from a Particular Host
If you want to monitor only traffic to and from a specific host, you can filter everything else out with the simple "host" expression. For example, to monitor a host with the IP address 192.168.1.1, the statement would look like this:
tcpdump –n host 192.168.1.1
Watch Only Traffic Coming in or out on a Certain Port
If you want to track usage of a certain application, you can use Tcpdump to trap all traffic for a particular TCP/UDP port. If the application you are trying to monitor is Telnet (port 23), you could do this with the following Tcpdump expression:
tcpdump –n port 23
View All Traffic to and from a Particular Host but Eliminate Some Kinds of Traffic
Say you want to monitor a single host as in the first example but want to filter out SSH traffic (if you were ssh'd into that host, unfiltered Tcpdump output would show your own connection traffic). You can do this by adding the port expression with a Boolean operator "not" statement. Here is the command:
tcpdump –n host 192.168.1.1 and not port 22
Find a Rogue Workstation
If you are having network problems and suspect a rogue computer is swamping your network, you can use Tcpdump to quickly track down the culprit. Whether it's a bad network card or a trojanized PC causing a denial of service attack, Tcpdump will help shed some light on your problem. First try just running it wide open to see what is generating the most traffic. Use the -a and -e options to generate names and MAC addresses.
Notice that you can concatenate the two letters with one dash. If this causes the output to scroll off the screen too fast, use the -c 1000 option to only count 1,000 packets and then stop.
Monitor a Specific Workstation
If you want to log the traffic from a specific workstation to analyze later, you can do this easily with Tcpdump (just make sure that you have the legal right to do so). Use the Tcpdump statement from the first example with a –w switch to write to a file. If you use DHCP on your network, you may be better off using SMB (Windows) names. For example:
tcpdump –w logfile host 192.168.1.1
where logfile is the file it will log to. You may also want to use the -c or -C options to limit your output file size.
Look for Suspicious Network Traffic
If you are worried about what is happening on your network after hours, you can leave Tcpdump running to flag traffic you might deem questionable. You could run it with the gateway 192.168.0.1 flag set, where you replace the IP address with that of your own Internet gateway. Assuming your home network was in the IP Range of 192.168.0.0 through 192.168.0.254, this would flag any traffic coming or going from your Internet gateway. If you have an internal mail server and don't want to log that traffic since that would be valid traffic, you could add the statement:
and host != 192.168.0.2
where the IP address is the address of your mail server. The exclamation point also acts as the Boolean "not" statement. This would flag any incoming traffic not bound for your mail server. The expression would look like this:
tcpdump –w logfile gateway 192.168.0.1 and host!=192.168.1.2
If you are looking for users using a particular application, such as a streaming video or an audio program, you can further specify that as long as you know its port number. If you know it uses the TCP port 1000, you can use the proto primitive to trap traffic using that protocol. For example:
tcpdump –w logfile gateway 192.168.0.1 and host!=192.168.1.2
dst port 1000
For more complicated intrusion detection scenarios, you will be better off using one of the intrusion detection systems described in Chapter 7, but for a quick and dirty analysis, Tcpdump can be a very handy tool.
Finally, there is a Tcpdump program for Windows. In fact, this is the actual UNIX Tcpdump ported over to the Windows platform, so all the functions and expressions work exactly the same.
Loris Degioanni was kind enough to do the porting work and made it a breeze to install—even easier than its UNIX counterpart.
Just like the UNIX Tcpdump, you first need to have the packet capture libraries installed before you can run WinDump. There is a special version for Windows called WinPcap. This is included on the CD-ROM in the Misc Folder. The latest version is also available at the program's Web site.
Install the WinPcap libraries by clicking on the file.
Download the WinDump executable and place it in the directory you want to run it from.
No additional installation is necessary.
Using WinDump is exactly the same as using Tcpdump from the command line. Just go to a command prompt in Windows and issue the command from the directory that the WinDump executable is in. All the commands and expressions work the same, but Table 6.5 lists a few commands specific to the Windows version.
Table 6.5. WinDump-Specific Commands
Sets the driver buffer size in kilobytes for your capture session. If you are experiencing high rates of packet loss, you can try increasing this value a little. The default is 1MB
Prints a list of available network interfaces on your system. It shows the interface name, number, and description, if any. You can use these parameters to specify an interface to capture from using the Tcpdump -i switch.
The source code is also available on the Web site for those wishing to contribute or to make modifications of their own. A word of warning, though: this kind of Windows coding is only for the hard core and those truly knowledgeable about network protocols.
This is all you need to get going in either Windows or UNIX. If you want more than just a command line interface though, the next tool described offers a graphical interface for your sniffing activities.
Ethereal offers all the benefits of a command line tool like Tcpdump with a number of advantages. It has a user-friendly graphical interface, so you don't have to deal with learning all the command line parameters. It also offers many more analytical and statistical options. Some of the other benefits of Ethereal are:
Cleaner output format. The output is much easier to read and understand than the raw packet captures of Tcpdump.
Many more protocol formats are supported. Ethereal can interpret over 300 different network protocols, which covers just about every network type ever invented.
More physical network formats are supported. This includes newer protocols such as IP over ATM and FDDI.
Captured network data can be interactively browsed and sorted.
Output can be saved as plain text or in PostScript format.
A rich display filter mode. This includes the ability to highlight certain packets in color. There is a filter creation GUI to walk you through the process of creating filters easily.
The ability to follow a TCP stream and view the content in ASCII. This can be invaluable when you need to read inter-server messages to track down e-mail or Web problems. You can follow the conversation between communicating nodes in order using this feature.
The ability to work with a number of capture programs and libraries. Ethereal also works with dedicated hardware beyond libpcap. Some of the programs supported include Network Associate's Sniffer and Sniffer Pro; Novell's LANalyser; some Cisco, Lucent, and Toshiba devices; and some wireless sniffing gear such as NetStumbler and Kismet Wireless. Ethereal now works as a plug-in module for many of these programs and devices.
The ability to save sessions in multiple formats. This is useful if you want to do additional analysis with different tools, including libcap (the default), Sun Snoop, Microsoft Network Monitor, and Network Associates' Sniffer.
A command-line terminal mode. This is for those not graphically inclined, although a huge part of Ethereal's usefulness comes from its GUI tools.
Ethereal is so useful as a networking tool that it has been rated as number two among the most popular network security tools available by the security Web site Insecure.org. Ethereal has many uses beyond just security; in fact, you can also use it as a general network analysis tool.
Installing Ethereal for Linux
You need two prerequisites before loading Ethereal: the libpcap libraries and the GTK development libraries. If you have loaded the port scanners or vulnerability scanners from earlier chapters, you should be all set. If not, you will need to download the GTK libraries or install them off of your OS installation disks. You can get libpcap on the CD-ROM or at www.tcpdump.org
. GTK is available at www.gtk.org
Now, you have to decide whether to use an RPM or compile from the source code. There are many RPM packages for different versions of Linux. If one exists for your distribution, you can use that and skip the compile process. If there isn't an RPM version for your operating system, you need to compile it.
To compile Ethereal, first download and unpack the latest distribution. The default installation should work fine for most uses. Look at the INSTALL file if you want to set additional compile-time parameters.
Change to the install directory and type the usual:
You can now run Ethereal by typing ./ethereal at the command prompt or by clicking on the executable from X-Windows. You need to be the root user to run Ethereal in the X-windows environment. To run Ethereal in command-line mode, you can type ./tethereal.
Installing Ethereal for Windows
You need to have the WinPcap libraries installed before running Ethereal. If you have already installed the port or vulnerability scanners from the previous chapters on your Windows system, then you already have these loaded and you can go to Step 2. Make sure your version of WinPcap is at least 2.3 or later. If you are running a machine with a multiprocessor or one of the newer Pentium processors with hyper-threading technology, you need to have WinPcap 3.0 or higher, and your results may be unpredictable as Ethereal doesn't work well with multiple processors.
The GTK tools for the graphical interface are included in the Ethereal installation package. Go to the Ethereal Web site and download a self-extracting install file. (I recommend you install the binary rather than messing with compilation on a Windows machine. This is much easier and doesn't require a Windows compiler.)
After you download the file, double-click on it. The installation program walks you through the install process. When it is done, it will put an icon on your desktop and you are ready to start using Ethereal.
Whether you are using the Windows or Linux version, almost all of the operations are the same and the interfaces look the same. When you bring up Ethereal, you will see a screen with three sections in it. These windows display the capture data and other information about your session. Figure 6.2 shows an example of this main window with a session in progress.
Figure 6.2. Ethereal Main Screen
The top third of the screen is where the packet stream is displayed in order of receipt, although you can sort this in just about any way by clicking on the headings. Table 6.6 lists the items displayed for each packet or frame.
Table 6.6. Packet Stream Data
Assigned by Ethereal.
The time the packet was received, set from the elapsed time from the start of the capture session. Alternately, this can be configured to show the clock time, the clock time and date, or even the time between packets (this is helpful for network performance analysis).
Where the packet came from. This is an IP address on IP networks.
Where the packet is going to, also usually an IP address.
The level 4 protocol that the packet is using.
Some summary information about the packet, usually a type field.
The next section of the screen goes into more detail on each packet that is highlighted. It is arranged in an order that basically conforms to the OSI model, so the first item listed is detail on the data link layer, and so on. The little pluses can be expanded to show even more information on each level. It is amazing how much detail you can see on each packet. Ethereal is like an electron microscope for network packets!
The final section contains the actual packet contents, in both hexadecimal and translated into ASCII where possible. Binary files will still look like garbage, as will encrypted traffic, but anything in clear text will appear. This highlights the power (and danger) of having a sniffer on your network.
Starting a Capture Session
There are a lot of options and filters you can set. Begin by running a wide open capture session. Choose Start from the Capture menu, and the Capture Options window displays (see Figure 6.3).
Figure 6.3. Ethereal Capture Options
Table 6.7 describes the options you can set before starting your session.
Table 6.7. Ethereal Capture Options
Picks the interface to capture from the pull-down menu. Ethereal automatically senses all the available interfaces and lists them. You can also choose to capture from all interfaces at once, just like Tcpdump.
Limit each packet to x bytes
Sets a maximum size for the packets captured. You can use this if you fear some of the packets may be very large and you don't want to overload your machine.
Capture packets in promiscuous mode
This is on by default. Turn this off if you want to capture traffic only to your sniffer machine.
Click the Filter button to create a filter using Tcpdump-style expressions. It will ask you to name the filter (which you can then use in future sessions) and enter the expression.
Click the File button if you want to read from a file rather than capture live data.
These are disabled by default, but enable them if you want to watch the packets scroll by in real time. If you are capturing on a busy network or your machine is slow, this is not recommended because it will cause the session to bog down and possibly drop packets. However, it is very useful if you want to "eyeball" the traffic to get a general idea of the nature of flow on the network as it goes by.
You have several more options here on when to end your session. Besides manually stopping it, you can have Ethereal stop after x number of packets or kilobytes of data have been captured, or after x number of seconds have elapsed.
You can specify whether you want Ethereal to resolve names at various levels of the network model. You can selectively resolve MAC address names, network names (SMB or hostnames), and/or transport layer names. Enabling all of these, especially DNS, can slow down your capture significantly.
Once you have set your options, click OK and your session will start. A window will appear that tracks the session statistics in real time (see Figure 6.4). If you set your session to show packets in real time, you will see them as they come across the wire in the window (see Figure 6.2).
Figure 6.4. Ethereal Session Statistics Window
You can stop your session at any time by clicking Stop in the statistic window or choosing Stop from the Capture menu. If you set a limit in the options, it will automatically stop when it reaches it. You can now analyze and manipulate your session results.
By clicking on the headings at the top of the window, you can resort the results by that heading, so you can sort the output by source address, destination, protocol, or the info fields. This helps to organize things if you are looking for a specific kind of traffic, for example, all the DNS queries or all the mail-related traffic. Of course, you could also write a filter to capture only this kind of traffic in the first place.
Table 6.8 lists the commands on the Display menu that you can use to affect how the packets are displayed on the screen.
Table 6.8. Ethereal Display Menu Options
This where you can set some global settings, such as how the time field is calculated. You can also set automatic scrolling of traffic and name resolution to on since they are turned off by default.
You can select certain kinds of packet to shade different colors. This makes the display easier to read and pick out the items you are looking for.
Shows either full detail on every item or just the top level.
There are several built-in analytical tools included with Ethereal. It is also built with a plug-in architecture so that other programs can interact with Ethereal or you can write your own. You can access these options under the Tools menu (see Table 6.9).
Table 6.9. Ethereal Tools Menu Options
Shows a listing of the top-level data on your captures session, such as time elapsed, packet count, average packet size, total bytes captured, and average Mps on the wire during the capture.
Protocol hierarchy statistics
Gives a statistical view of the traffic on your network. It shows what percentage of the capture session each type of packet makes up. You can collapse or expand the view to see major levels or minor protocols within a level.
Contains a number of reports that are specific to certain kinds of protocols. Refer to the Ethereal documentation for more details on these tests.
Shows the protocol analyzer plug-ins that you have loaded. These are decoders for newer protocols that can be added to Ethereal without a major version upgrade. And because it's a plug-in architecture, you can write your own.
Saving Your Ethereal Output
Once you have finished capturing and analyzing your Ethereal data, you may want to save it, either for analysis with additional tools or for presentation to other parties. Using the Save As option from the File menu, you can choose from a number of formats, including libpcap (the default), Sun Snoop, LANalyser, Sniffer, Microsoft Network Monitor, and Visual Networks traffic capture.
Now that you understand the basics of Ethereal, here are some practical applications you can use it for.
By running a wide-open network capture and then using the statistical reports, you can see how saturated your LAN is and what kinds of packets are making up most of the traffic. By looking at this, you may decide that it is time to move to a 100Mps switched network, or to segregate two departments into routed LANs versus one big network. You can also tell if you need to install a WINS server (too many SMB name requests being broadcast across the LAN) or if a particular server should be moved to a DMZ or a separate router port to take that traffic off the network.
Application Server Troubleshooting
Do you have a mail server that doesn't seem to be connecting? Having DNS problems? These application-level problems can be fiendishly difficult to troubleshoot. But if you have Ethereal, you can tap into the network and watch the inter-server communications. You can see the actual server messages for protocols like SMTP or HTTP and figure out where the problem is happening by watching the TCP stream.