ONLamp.com: Using Ethereal
1 of 5
http://www.onlamp.com/lpt/a/323
Published on ONLamp.com (http://www.onlamp.com/)
http://www.onlamp.com/pub/a/bsd/2000/08/16/FreeBSD_Basics.html
See this if you're having trouble printing code examples
Using Ethereal
08/16/2000
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:
whereis ethereal
/usr/X11R6/bin/ethereal
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:
4/6/2005 1:25 AM
ONLamp.com: Using Ethereal
2 of 5
http://www.onlamp.com/lpt/a/323
man ethereal
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:
ping 10.0.0.1
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
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
4/6/2005 1:25 AM
ONLamp.com: Using Ethereal
3 of 5
http://www.onlamp.com/lpt/a/323
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 (ping) requests, the other half are Echo (ping)
replies.
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:
arp -a
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
arp -a
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
arp -a
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:
ftp 10.0.0.3
Connected to 10.0.0.3
220 gamma FTP server (Version 6.00LS) ready.
Name (10.0.0.0:genisis): anonymous
530 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:
4/6/2005 1:25 AM
ONLamp.com: Using Ethereal
4 of 5
+
+
+
+
+
http://www.onlamp.com/lpt/a/323
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> quit
ftp 10.0.0.3
Connected to 10.0.0.3.
220 gamma FTP server (Version 6.00LS) ready.
Name (10.0.0.3:genisis): genisis
331 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
4/6/2005 1:25 AM
ONLamp.com: Using Ethereal
5 of 5
http://www.onlamp.com/lpt/a/323
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 an instructor at Marketbridge Technologies in Ottawa and the maintainer of the Open
Protocol Resource.
Read more FreeBSD Basics columns.
Discuss this article in the Operating Systems Forum.
Return to the BSD DevCenter.
Copyright © 2004 O'Reilly Media, Inc.
4/6/2005 1:25 AM