BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Using Ethereal
Pages: 1, 2

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

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:

+ 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 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.

 





Sponsored by: