One of my favorite utilities in the ports collection is the network analyzer, Ethereal. I've used NT's Network Monitor and Novell's Lanalyzer, but I've found that neither matches the functionality of Ethereal.
If you've never used a network analyzer before, you may wonder why you'd want to use such a utility. If a network administrator is experiencing slow network performance, a network analyzer can help him pinpoint which NICs, cable segments, and protocols are generating the most traffic. The results can be used to determine if he needs to upgrade his cabling, change a faulty NIC, install a bridge, reorder his network bindings, consider using less chatty protocols, etc.
A security engineer can use the results to determine if his firewall system is responding to requests according to his security policy.
And finally, the results of a network analyzer provide the best learning environment to gain a practical understanding of the OSI model and how protocols actually interact with each other.
One word of caution before firing up any network analyzer: These utilities are designed to capture and show the contents of every frame that passes through a cable segment. Don't monitor a cable segment that is not part of your LAN unless you have explicit permission to do so.
Before you can use Ethereal, you'll need to configure your X Server and Window Manager. Once you have these, the easiest way to build Ethereal is from the ports collection. As root, and while connected to the Internet:
cd /usr/ports/net/ethereal make && make install
Once this is finished:
Running a network analyzer is an administrative task. If you want to add
Ethereal to a menu in your favorite Window Manager, you'll have to start
your X Windows session as root. Alternately, you can start your X Window
session as a regular user, open up an xterm,
su to root, and start
Ethereal from the xterm. If you start Ethereal as a regular user, the
utility will launch but it won't display any interfaces to monitor.
Ethereal has the ability to use display and capture filters; creating these is beyond the scope of this article, but you can get more information on using filters by doing a:
and by checking out the main website for Ethereal. The FAQ will get you started and the useful links page is outstanding, especially if you wish to do more research on protocols and network analysis. Don't forget to order your free protocol posters when you visit the protocols.com site.
Let's do some example captures. We'll start with a simple ping. I have a computer named alpha with an IP address of 10.0.0.1 and another computer named gamma at 10.0.0.3. I've fired up Ethereal on gamma, clicked on the capture menu, and pressed start. Because I'm root, I'm presented with the list of interfaces on gamma; I choose the one attached to my LAN cable segment and click OK. To make things a little more interesting, I'll forget to power on the computer named alpha.
Don't be afraid to try this exercise yourself; just ping a host that is either down or non-existent. I open up an xterm and type:
and wait; not surprisingly, nothing happens. I press Ctrl-C to end the
ping and my xterm now reads:
PING 10.0.0.1 (10.0.0.1): 56 data bytes ping: sendto: Host is down ^C --- 10.0.0.1 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss
Going back to Ethereal, I stop the capture and look at the results. I do have 7 packets listed, but they are all ARP (address resolution protocol) packets, not the ICMP echo/reply packets you would expect with ping.
For those of you who never had the opportunity to yawn your way through a lecture on the OSI model, I've just demonstrated the first rule of transmission on a TCP/IP network. No unicast packets can enter the wire until the MAC address of the NIC who will receive the packets is known; this is the job of ARP, the address resolution protocol.
As you can see from your capture, ARP isn't that complicated a protocol. It sends out a broadcast (the destination of ff:ff:ff:ff:ff:ff) onto the cable segment that asks who has 10.0.0.1? tell 10.0.0.3. This is the equivalent of your four-year-old yelling into a crowded room, "Where is my Mommy?" It's not the most elegant way of accomplishing a task, but it's usually quite effective.
Because 10.0.0.1 wasn't available to answer, there was no MAC address to
send packets to, and
ping was unable to send out its ICMP packets.
Let's fire up alpha, start another capture, and try pinging 10.0.0.1 again.
PING 10.0.0.1 (10.0.0.1): 56 data bytes 64 bytes from 10.0.0.1: icmp_seq=0 ttl=255 time=0.675 ms 64 bytes from 10.0.0.1: icmp_seq=1 ttl=255 time=0.522 ms 64 bytes from 10.0.0.1: icmp_seq=2 ttl=255 time=0.508 ms 64 bytes from 10.0.0.1: icmp_seq=3 ttl=255 time=0.498 ms 64 bytes from 10.0.0.1: icmp_seq=4 ttl=255 time=0.509 ms 64 bytes from 10.0.0.1: icmp_seq=5 ttl=255 time=0.524 ms ^C --- 10.1.0.2 ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.498/0.539/0.675/0.061 ms
If I end the capture, I'll see that 14 packets were captured. Two of these
will be ARP packets; the first of these asks who has 10.0.0.1? Tell
10.0.0.3. The second is the reply from 10.0.0.1 with its MAC address. The
other 12 packets are ICMP packets; half of these are Echo (
the other half are Echo (
If you repeat this capture again and transmit 6 packets, the capture will only show the 12 ICMP packets. What happened to the 2 ARP packets? To find out, from your xterm type:
alpha (10.0.0.1) at 0:0:b4:3c:56:40 [ethernet]
ARP utilizes a cache (area of memory) where it keeps a list of which MAC addresses it has recently resolved; this cuts down on the number of broadcasts. Since ARP already knew alpha's MAC address, it didn't have to issue another request for it.
If you type:
arp -d -a
you will remove all the entries in your ARP cache. And an
will just return you back to your prompt.
If you now repeat the capture and ping, you'll notice the 2 extra ARP entries will reappear. And
will show alpha's MAC address again.
Now let's look at some FTP traffic. At gamma, I've started a capture. At alpha, I've typed:
Connected to 10.0.0.3 220 gamma FTP server (Version 6.00LS) ready. Name (10.0.0.0:genisis):
anonymous530 User anonymous unknown. ftp: Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp>
I haven't set up an anonymous FTP login account at gamma, so the login failed. When I stop the capture, I have a total of 10 packets.
The first three packets used the TCP protocol and represent TCP's three-way handshake as the flags were set at [SYN] (step 1 of handshake), [SYN, ACK] (step 2 of handshake), and [ACK] (step 3 of handshake). No FTP packets were sent until the handshake process finished successfully.
The first FTP packet was sent to alpha, and contained the information that first appeared on alpha's screen:
220 gamma FTP server (Version 6.00LS) ready.
This is actually the first packet we've captured that had a data payload attached to it. Highlight it in Ethereal and look at the second section of your Ethereal screen where it says:
+ Frame4 + Ethernet II + Internet Protocol + Transmission Control Protocol + File Transfer Protocol
This section allows you to view the various encapsulations that each layer of the OSI model added to the original data packet, from the physical layer up to the application layer. If you click on the + next to a layer, you will expand all the gory details that that layer added to the IP header. If you highlight something interesting, note that a portion of the data in the third section of Ethereal will become darker. This section of Ethereal shows the actual 1s and 0s (written in hex) that were sent to the NIC. Keep in mind that your NIC is actually raising and lowering the voltages on the cable segment to transmit all these 1s and 0s. Isn't networking amazing?
The next 2 FTP packets are alpha's login information and gamma's response:
530 User anonymous unknown. ftp: Login failed.
The last 2 FTP packets are alpha's request for system information, and gamma's response:
Remote system type is UNIX. Using binary mode to transfer files.
Note that the FTP utility on alpha modified gamma's actual response slightly when it displayed it on alpha's screen.
The rest of the TCP packets are acknowledgements, as TCP is responsible for ensuring reliable delivery of data.
I've kept the FTP prompt at alpha, so let's start another capture:
ftp 10.0.0.3Connected to 10.0.0.3. 220 gamma FTP server (Version 6.00LS) ready. Name (10.0.0.3:genisis):
genisis331 Password required for genisis. Password: 230 User genisis logged in. Remote system type is UNIX. Using binary mode to transfer files. ftp>
If I end the capture and analyze the packets, the first 2 packets are the TCP packets that ended the failed FTP session. Note that alpha sent a [FIN, ACK] to request the connection be closed, and gamma responded with a [RST] to reset the connection to make it available to other potential TCP sessions.
This was followed by another three-way handshake involving 3 TCP packets. Take a close look at the FTP response/reply pairs. When the user genisis typed in the password at alpha, the FTP client did not display the password at the terminal. However, this information was sent in the clear to gamma and wasn't hidden from the packet analyzer -- one of many reasons why you don't analyze the traffic on other people's networks.
These exercises should provide you with a starting point for using Ethereal. If you are interested in how various operating systems send and receive network traffic, here are some interesting exercises to try on your own:
Start a capture on a cable segment with an NT Server and an NT workstation; power on the NT workstation and end your capture once it has successfully logged into the network.
Start a capture on a cable segment with a Novell server and a Novell client. From the Novell client, attach to the server and map a network drive.
Start a capture on a cable segment with an NFS server. Have an NFS client mount a filesystem being exported by the NFS server and copy data to and from the mountpoint.
Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.
Read more FreeBSD Basics columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.
Copyright © 2017 O'Reilly Media, Inc.