Debugging with EtherPeek
Volume Number: 13
Issue Number: 8
Column Tag: Tools Of The Trade
Debugging with EtherPeek
by Sam Gilligan, Open Systems Development
Use a Macintosh-based network analyzer to circumvent the
Heisenberg Uncertainty Principle and debug your network
code
Introduction
If you are developing network software and you're not using a network analyzer to help
you debug your product, you'll be amazed at how much time you can save. If you are
using EtherPeek or a similar product to debug your network code, you probably
wonder how you could do your job without it. After reading this article, you will have a
better understanding of the capabilities of EtherPeek and how you can use them to get
your job done faster. We'll start with an overview of network analyzers and then move
on to the basic features of EtherPeek. Next, we'll look at the methodology of debugging
with a network analyzer. Finally, we'll look at a simple HTTP client that contains a
trivial bug and then show how to use EtherPeek to help fix it. (This example is based
on a true story.)
What is a Network Analyzer Anyway?
In 1986, when I began developing network software on Ethernet at 3Com, our
Macintosh team was given an internal, DOS-based, utility program called "EtherSpy".
After reading the specifications for 3Com's DOS networking client, we used EtherSpy
to understand how the DOS client really connected to the server and to design, develop,
and debug the Macintosh version. I have used a variety of network analyzer programs
over the years and I can't imagine trying to develop any substantial networking
software without one.
A software-based network analyzer is a network utility program that runs on a
standard desktop or laptop computer using a standard Ethernet adapter. A
hardware-based network analyzer is sold as a complete package of a laptop or portable
computer, Ethernet adapter, and software. (Network analyzers are also available for
Token-Ring and other networks.) A network analyzer is able to receive all packets on
its network (LAN segment) by using a feature of Ethernet called promiscuous mode.
Normally an Ethernet adapter and its driver software are programmed to only receive
packets that are directed to that specific adapter or are broadcast to all adapters on
that network. (Packets destined for adapters on another network on an internet or on
the Internet must be directed to a router.) When an Ethernet adapter is operating in
promiscuous mode, it will receive all packets on its network.
Once triggered, the analyzer software captures all packets on the network using
promiscuous mode, discards packets not matching user-specified filters, and then
displays the captured packets in a human-readable format. This human readable
format is achieved through the use of protocol decoders. An IP protocol decoder will
know to display the 32-bit IP address in dotted decimal notation, based on the location
of the IP address within the packet (e.g., 17.254.3.21). Good decoders will take this a
step further and do a reverse-name lookup and display the machine name, such as
"www.apple.com," in addition to the dotted decimal notation.
For most developers, a software-based analyzer is the only affordable option. A small
company may be able to afford only a software-based analyzer, and getting access to a
hardware-based analyzer in a large company often requires waiting your turn. A
software-based analyzer can be installed on a machine in your office or in your
engineering test lab -- you can set it up and leave it monitoring your software for
extended periods of time. Hardware-based analyzers do offer a few advantages, such as
protocol decoders for some of the more obscure protocols, expert analysis capabilities
that can find and recommend a solution to a network problem, and the best
performance and hardware error reporting capabilities. In general, these features
tend to be more useful for network managers than for software developers. You should
verify that any protocols you need are supported before purchasing an analyzer.
There are several software-based network analyzers available for both the MacOS and
for Windows. In addition, there are hardware-based network analyzers such as the
Sniffer from Network General Corporation. EtherPeek, from the AG Group, Inc., with a
list price of $995 (developer discounts are available), is a fraction of the cost of the
Sniffer, easier to use, and equally capable for the vast majority of applications.
(Network General does offer optional modules to decode client/server messages for
Oracle, Sybase, and Microsoft SQL Server. This capability could be very valuable to
some developers.) EtherPeek is available for both Windows and the MacOS.
Basic EtherPeek Operation
Before using EtherPeek you must install it on a system with a supported Ethernet
adapter. Built-In Ethernet on PCI and NuBus-based PowerMacs is supported. Most
other common adapters are supported, but you should check the AG Group's web site
before assuming a particular adapter is supported. EtherPeek is drag-installable and
does not require any special files in the System Folder.
When you first run EtherPeek you'll be asked to select an Ethernet adapter, then the
main window will open. Click "Start Capture" to begin capturing packets in the capture
buffer. The "Start Capture" button will toggle to "Stop Capture". Click "Stop Capture
to end your trace. Figure 1 shows the main window with the results of a trace
displayed in it. Each line of text in the window displays summary information for a
single packet.
Figure 1. EtherPeek Main Window.
Double-click a packet summary line in the main window and you can view the details
of a packet (as shown below).
Figure 2. EtherPeek Packet Contents Window.
As you can see, capturing and viewing packets is very easy. By using filters you can
tell EtherPeek to capture only packets to or from certain addresses or capture packets
containing particular protocols. Triggers are used to tell EtherPeek when to begin or
end a trace. Filters are typically used to look at a dialog between two specific machines
and ignore the remaining traffic on your network. Later, in the HTTP client debugging
example, we will setup a filter to catch only the packets from the Macintosh on which
we are debugging. Triggers are useful if you don't know exactly when an error is going
to occur, but you know that the presence of a certain packet indicates the error has