A Guided Tour of Ethereal
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.
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.
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 192.168.0.1. 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.
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).
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.
- Nasdaq Selects Drupal 8
- Non-Linux FOSS: Screenshotting for Fun and Profit!
- Ubuntu MATE, Not Just a Whim
- An Introduction to Tabled Logic Programming with Picat
- Build Your Own Raspberry Pi Camera
- Secure Desktops with Qubes: Compartmentalization
- Canonical Ltd.'s Ubuntu Core
- The Peculiar Case of Email in the Cloud
- A New Mental Model for Computers and Networks
- Linux Journal October 2016