I gave EtherPeek 4 for Macintosh, which has been completely revised, a full workout over the course of a few weeks. The most noteworthy improvements are in the tool's interface and filters. A few interface issues bothered me (more about that later), but I took the plunge and deleted EtherPeek 3.5.4 from my laptop in favor of 4.0. I suggest that all EtherPeek users do the same.

Performance can be an issue with any software-based solution, so I inserted a Farallon 10/100 CardBus card and attached the PowerBook G3 to our Hewlett-Packard Co. switch. I enabled port-mirroring and began capturing NFS traffic from our Novell NetWare server to a few Sun Microsystems Ultra 10 workstations. When network utilization peaked somewhere around 70 Mbps to 80 Mbps, my laptop performance didn't feel sluggish. And I didn't notice any dropped packets, either.

Getting To Know You
For the first few days working with the new version of EtherPeek, I was a bit clumsy with my troubleshooting. The new interface is quite different from that of previous versions and it took a while to get used to it. However, once I got the hang of it, I was able to surpass my previous troubleshooting effectiveness.

Simplifying the main interface of any tool is very important, and AG Group got the job done by hiding the detail configuration options behind tabs in the main window. EtherPeek 4 offers multiple capture buffers at the same time. So instead of just starting a capture, you must open a capture buffer and specify the amount of memory to store packets. By default, EtherPeek allocates 2 MB. That is easy to change temporarily in the open dialog, but to speed up starting a capture, it would be nice to be able to change the default to 5 MB (doing so would make it unnecessary to have to edit the parameter every time you open a new capture buffer).

The main capture window is clean and shows only the packets as they are being captured. The window is tabbed across the top so you can quickly access other representations of the captured data in real time. By clicking on the Filters tab, I was able to apply a filter without stopping the current capture.

As with previous versions of EtherPeek, double-clicking on any packet in the capture window reveals one of the best decodes in the protocol-analyzer business--without stopping the capture process. The individual packet window is split, with the decode on the top and the raw data on the bottom. Highlighting any section in the decode area automatically highlights the corresponding hex in the raw data area. The earlier versions allowed you to look at decode or raw data, but not both.

I found the Conversations tab extremely useful. On busy segments, I simply looked at this screen to see which stations were talking to one another. With a quick click on the bytes or packets column, I could sort and discover which traffic is chewing up the bandwidth.

On a busy network segment, a protocol analyzer's buffer can fill up quickly. Not only that, but weeding through all that hay to find the needle can be an arduous task. If you know what you're looking for, adding filters can winnow out the information you don't need. Version 4.0 improves on EtherPeek's filter capability, which was already impressive.

During my EtherPeek 4 tests, I was troubleshooting DHCP problems on our network and I wanted to capture traffic from our DHCP server. Making a filter using an IP address and a port number was quick and easy using EtherPeek's advanced filters. With the advanced filter in place, I needed only to look at DHCP packets from our server. Although this is a very simplistic advanced filter, I could have used any number of identifiers and Boolean strings to winnow the data.

While performing some other protocol tracing, I noticed a few POP and SMTP connections from IP addresses I didn't recognize. I quickly selected one of the packets and hit CMD-R (quick key for resolve name). The resolved host name wasn't any more familiar to me. So I selected Make Filter and continued capturing with the filter in place. The probing continued with possible malicious intent, so I sent an e-mail to the upstream provider of the mischievous Internet user.

Minimal Remote Analysis
For analysis of remote problems, I configured a workstation to output basic information to HTML format. By installing a personal Web server, I was able to access the information remotely using a browser. This configuration can only gather minimal statistics, but they can be valuable. I found it useful to look at the protocol conversation tables to see what was happening on the remote network.

EtherPeek continues to be an essential component of my troubleshooting suite. After upgrading to version 4.0, I find that regular protocol decoding is easier and more intuitive.

Send your comments on this article to Robert J. Kohlhepp at rkohlhepp@nwc.com.