A Guided Tour of Ethereal
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.
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.
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.
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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- A Topic for Discussion - Open Source Feature-Richness?
- Why Python?
- Tech Tip: Really Simple HTTP Server with Python
- Not free anymore
1 hour 39 min ago
5 hours 27 min ago
- Reply to comment | Linux Journal
5 hours 35 min ago
- Understanding the Linux Kernel
7 hours 49 min ago
10 hours 19 min ago
- Kernel Problem
20 hours 22 min ago
- BASH script to log IPs on public web server
1 day 49 min ago
1 day 4 hours ago
- Reply to comment | Linux Journal
1 day 4 hours ago
- All the articles you talked
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?