print

Tip of the Month

April 2001

The Wonderful Thing About Triggers Is That Triggers Are Wonderful Things!

As you become more experienced with the features of your protocol analyzer, you will appreciate the benefits of applying Triggers from time to time.

Triggers are set up like filters; but, instead of accepting only certain frames into the capture buffer, Triggers start or stop the capture. You may want to set up a Trigger that will continue capturing packets after a trigger event so that you capture packets that led up to as well as follow the event. EtherPeek, TokenPeek and AiroPeek allow you to have simultaneous captures from one adapter. The first capture can be set to stop on the Trigger while a second can be set to start on the Trigger. That way, you can look at a buffer of packets that led up to the event and a second buffer of packets after the event.

If you know the precise event that you are waiting for, such as an ICMP packet containing a "host unreachable" message or a packet from your server containing an SMB return code of "invalid password," setting up a Trigger is very straight forward. Simply start with a trace containing the event you are looking for and look inside the packet of interest for the appropriate patterns and offsets to set up your Trigger. Don't have such a trace? Then force the event yourself while capturing with your analyzer.

Now for the challenging part. What if you have no clue what the event will be? For example, what if there are random times that your server locks up for no apparent reason? This is where a couple of handy analysis tricks come into play.

Trick #1: Detecting a failed server.

This technique is for Windows-based servers but can be generalized for other servers and services as well. Set up the following batch file on a workstation:

:TOP
NET VIEW \\A_SERVER
If errorlevel 1 GOTO FAIL
GOTO TOP
:FAIL
PING 215.16.173.4