A Guided Tour of Ethereal

Learn exactly what's in all those packets flying by on your network with this essential development and administration tool.
Key Features

From my point of view, the key features of Ethereal are its ability to capture and analyze network traffic within a single application and the sophistication of its display and filtering code.

Although we looked earlier in this article at how capturing network traffic is done, Ethereal can capture more than Ethernet traffic. Ethereal typically can (at least on Linux) capture data from Ethernet, Token-Ring, FDDI, serial (PPP and SLIP), 802.11 wireless LAN, ATM connections and all networking devices at the same time. Called the “any” device in the Ethereal capture dialog, this feature only works in Linux. Of course, suitable networking hardware and kernel drivers need to be enabled to get the packets.

On a busy network, you may have thousands of packets in a capture file and be interested in only some of them. To make it easier to interpret the Ethereal display, which can get pretty busy, you can use colors. From the Display→Colorize Display... option, you can select display packets in various colors; Figure 7 shows how the filter is specified. In this case, I'm filtering on only a single field (the version number for Service Location Protocol), but you can build sophisticated filters with Boolean logic. Figure 8 shows a typical example with a few filters, and Figure 9 shows the working display (with Service Location Protocol Version 2 in red, DNS in green and ARP in blue). You can use a wide range of text colors as well as background coloring to separate out the various protocols.

Figure 7. Specifying an Ethereal Color Filter

Figure 8. Ethereal Supports Multiple Color Filters

Figure 9. A Typical Colorized Capture Session

After coloring the display, the next step is to remove packets of no interest, a task Ethereal handles through display filtering. A simple example is shown in Figure 10, where adding a srvloc filter (in the bottom left of the window) has removed all the other protocols, leaving only the Service Location Protocol. If this still is too complex, you could choose to change the coloring again, this time showing packets from particular hosts in separate colors or packets containing particular types of client requests or server responses in particular colors.

Figure 10. Display Filtering on Same Session as Shown in Figure 9

Another option is to not capture the unwanted packets in the first place. To do this, Ethereal supports the same capture filter syntax that tcpdump uses. An example of this syntax is shown in Figure 11, where the dialog captures only the packets going to or from the machine with IP Unfortunately, the syntax used in capture filters is different from that used in the display filters, a fact that makes capture filtering much less accessible to occasional users.

Figure 11. Capture Filtering Dialog

Another feature that some people find useful is the Follow TCP Stream... tool, which presents a text representation of the conversation. I personally don't use this feature often, but it is a powerful tool for looking at text-based protocols such as IMAP (Figure 12).

Figure 12. Following a TCP Stream—IMAP

Misfeatures and Omissions

Apart from the different syntaxes required for capturing and displaying filters, I've come across a few other issues in the time I've been using Ethereal. Some of these have to do with personal preferences, and others have been gleaned from monitoring the Ethereal mailing lists.

At the time of this writing, my biggest issue is with the quality of the support documentation, especially the User's Guide, which is incomplete and outdated. Also, a significant amount of the User's Guide, about the last 80%, is generated automatically and is not user-friendly. In addition, the version on the Web site has not been regenerated in some time. I personally found the GUI a little difficult to get used to, although as I became more familiar with the various menus, I became more productive with Ethereal. Perhaps some better documentation would have helped with this. There is also limited developer documentation, although I see this as a less important issue, given the large number of examples from which you can work.

Various users occasionally ask “when will such and such a protocol be supported?” Where I have found a few protocols not supported by Ethereal (rsync, distcc and ACAP), I've generally needed to code support myself. This is fairly easy to do with Ethereal. If you need support for a particular protocol, however, and it is not supported by Ethereal at the moment, you should allow for some development effort (either as an in-house development or on a contract basis) before committing to Ethereal. If you do develop additional dissectors or enhance an existing one, I strongly recommend that you have it incorporated into the Ethereal source tree to ensure it remains up to date.

Another feature supported by other packet analysis tools is the ability to capture data on a remote host and display it locally. If you can run Ethereal on the remote host, this scenario is possible, but often you want to capture data on a machine acting as a router or a server, where a full-blown X environment is undesirable. This lack may be overcome in a future version or it may not be particularly important, depending on your environment.

The only other issue worth mentioning is that a substantial number of the queries on the user-support mailing list seem to be from Windows users experiencing a wide range of problems. I personally haven't run the Windows version, so I don't know if the difficulties are associated with the underlying tools (especially WinPcap), Windows itself or the skill levels of the users.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

application would

software free's picture

That application would be the ethereal GUI.

This way:
-no need for X on router
-no need to install ethereal on client
-no need to transmit all the packets over the wire, minimal network impact (packet processing would be server-side)

Re: A Guided Tour of Ethereal

bsilva's picture

Regarding the ability to capture packets remotely:
While it's true that Ethereal cannot do this dynamically, i.e.; with an agent on the remote end, Ethereal can read packet captures from command line tools such as tcpdump and snoop.

I use both of these tools to capture packets from Firewalls, Routers, servers, etc. I also use a beat-up Pentium-90 laptop as a network monitor that I can leave at a customer site. Once the data is collected I can analyse it with Ethereal. Ethereal will also read packet captures from commercial tools such as NAI's Sniffer tools.

Ethereal is a tool that just keeps getting a little better each year. I've used it to solve a variety of problems, but I've also used it to teach networking protocols. It's the best tool I know of to show students exactly how protocols are encapsulated in each other and to demonstrate exactly how data gets across the network.

On a slightly different note, it's interesting that I'm posting this comment on January 10th 2004, but the article claims to have been posted on Feburary 1st, 2004.

Thanks for the Article,
Brad Silva


Anonymous's picture

I use SSH + tethereal from the command line to do remote captures

Sure that's what i do but it'

Anonymous's picture

Sure that's what i do but it's so much nicer to see live rolling capture in the ethereal GUI.

Re: A Guided Tour of Ethereal

Anonymous's picture

I think the date reflects the publishing date for the magazine, not for the article.

I agree with the remote capture comments, and some work on remote capture has been done, but when you are working with the Ethereal GUI, it would sometimes be nice to do "now show me what that remote machine is seeing, in real time". That needs more work.

Brad Hards

Re: A Guided Tour of Ethereal

Anonymous's picture

Isn't that was remote (secure) X display is for? Which is tremendously less overhead, potentially, than sending the entire packet contents across the wire to the "local" monitoring app?

Well ideally you would naviga

Anonymous's picture

Well ideally you would navigate to a webpage that would contain a java application.
That application would be the ethereal GUI.

This way:
-no need for X on router
-no need to install ethereal on client
-no need to transmit all the packets over the wire, minimal network impact (packet processing would be server-side)

Negative aspects:
-More CPU usage on router
-We need is someone to implement this!

An X display on a router is a

Anonymous's picture

An X display on a router is a waste of resources, especially since you'll probably end up doing all your work in shell windows inside X!

Re: A Guided Tour of Ethereal

Anonymous's picture

Actually, the RMON (and RMON2) protocol is substantially thinner than remote X. Ethereal just needs an RMON/RMON2 interface.