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.

I recently started using a network tool called Ethereal. For those familiar with tcpdump, think of Ethereal as a GUI form of tcpdump that shows you the whole packet and can break down the packet to show individual fields. For those who haven't used tcpdump or similar packet sniffers, it might be best to show the capabilities of Ethereal through a few examples.

When you start Ethereal, it looks like the graphic shown in Figure 1. Typically, you want to capture some data from the network attached to your workstation; do this by selecting Capture→Start..., which brings up the dialog shown in Figure 2. When you've captured the data you need, stop the capture and examine it. Figure 3 shows a capture of some IPv6 traffic, where I've selected an ICMPv6 packet (in the top frame) and expanded the IPv6 and ICMPv6 contents to select the IPv6 source address (in the middle frame). Ethereal automatically highlights the raw bytes corresponding to the selected field—in this case, source address—within the packet in the bottom frame. This type of functionality makes Ethereal useful for understanding various network protocols, and I definitely recommend its use as a teaching or self-education aid in conjunction with networking RFCs. Ethereal also is useful for educating users and management about the dangers of using protocols that send data in clear text, as shown for File Transfer Protocol in Figure 4.

Figure 1. The Ethereal Main Window

Figure 2. Capture Dialog

Figure 3. ICMPv6 Capture and Dissection

Figure 4. FTP Capture and Dissection, Showing Password

Ethereal also is useful for investigating proprietary protocols or other networking protocols that are not well documented. Figure 5 shows a somewhat contrived example—rsync. This protocol is in widespread use because of its ability to save significant bandwidth but is essentially defined by the source code to the application. I used Ethereal to capture a number of rsync transactions and figured out how the protocol works—at least enough to write an rsync protocol dissector for Ethereal. I understand the Samba team uses Ethereal and a number of other tools to develop clients and servers that interoperate with the Microsoft CIFS implementations, because the Microsoft documentation for these protocols is incomplete or incorrect.

Figure 5. Ethereal Capturing rsync (Now Supported)

I also have used Ethereal as a part of network application testing (on zcip and Service Location Protocol) to assess correctness and response times. Ethereal time-tags each transaction, so you easily can see the relationship between packets.

How Ethereal Works

Ethereal works by capturing packets through a reasonably portable library called libpcap, which on Linux accesses the packets on the network through using a kernel mechanism called packet socket. It is possible to disable this option under Linux, although probably all vendor kernels have it enabled, and it is enabled in the default kernel configuration for most architectures on Linux kernels. Other operating systems have different interfaces, but libpcap abstracts this away and provides a common API.

Having received a copy of the network packets, Ethereal builds an internal linked list and saves the packets to a file. It then determines what protocol the packet is carrying based on the port numbers, type fields in the supporting protocols or a heuristic that guesses the protocol based on the contents of the field. It is worth noting that this approach essentially is informed guesswork and is by no means infallible. For example, traffic to port 53 probably is DNS, but there is no reason why a network administrator could not choose to run another service on that port. In addition, Ethereal supports an option to interpret a particular packet as a different protocol, using Tools→Decode As.

Based on the guessed protocol, Ethereal decodes (dissects, in Ethereal nomenclature) the packet. Each protocol supported by Ethereal is handled through a bit of code known as a dissector. At the time of this writing, 333 dissectors are built in to Ethereal, some of which handle more than one protocol. Protocols also can be provided as plugins, which are loaded dynamically. Depending on the protocol and the level of sophistication provided by the dissector code, the packets can be broken down for analysis of individual bits or they can be presented at a very high level. Both options are depicted in Figure 6, where the TCP dissector shows the individual bits set in the flags, but the IMAP dissector breaks out only two fields. It is worth noting that IMAP is a text-based protocol, so a simple ASCII dump of the packet contents is an appropriate way to show them.

Figure 6. Two Variations on Dissection—TCP and IMAP



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.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot