print

Tip of the Month

WildPackets Tip of the Month – April, 2008

Finding Failed Conversations

By Jeff Trawick, WildPackets Professional Services

One thing the WildPackets instructor corps enjoys most about teaching is that we always learn at least as much as we teach. In one of our recent analysis classes, Brian Cantor from Nationwide Insurance provided us with a great tip that we want to share with you! During the class, we were building filters to find various types of TCP packets based on the TCP Flags field.

For example, suppose we need to locate all TCP RST (Reset) packets, which may be indicative of failed conversations. Building a filter to locate TCP Resets requires a binary value filter to focus only on those TCP packets that have the Reset bit set to 1. If you’re not sure how to build the binary value filter, refer to the Tip of the Month for January of 2005, which can be found at http://www.wildpackets.com/support/additional_resources/2005_01.

Once the filter is written, we can apply it by using the Display Filter drop-down list. As soon as we click on the filter, OmniPeek will immediately hide all of the packets that don’t match our criteria, leaving us with just the TCP Reset packets. We can also apply the filter using the Edit menu’s Select command (Ctrl-E), which is detailed in the December, 2006 Tip of the Month (http://www.wildpackets.com/support/additional_resources/2006_12). In this case, we would typically apply the filter and choose to hide the unselected (non-Reset) packets, or copy the selected packets to a new window for further examination. In either case, the result is the same: we are left with only the Reset packets. In some instances, this is OK, but in most cases, what we really need to see is what happened just before the Reset occurred. In other words, we need to look at the events that cause the Reset, and the cause is often evident in the packets just before the Reset packet is transmitted. So what we really need is a filter that finds not only the Reset packets, but also all of the packets for each of the conversations impacted by those Resets. Unfortunately, there really isn’t a way to write a filter that will find all of the Resets and then display all of the packets for all affected flows. However, as Brian pointed out, the key is not in writing the filter, but in the way the filter is applied. In fact, this technique combines our Reset filter with the Select Related feature to give us the desired result. Here’s how to do it…

First, use the Select command from the Edit menu (Ctrl-E) to apply the TCP Reset filter. Then, click Select Packets. When the Selection Results dialog appear, click Close. Then close the Select window also. In our example, 7 Resets were found.	Now we are back at the Packet List, and all of the TCP Reset packets are selected. In the example below, packet 918 is one of the Reset packets that has been located. BE VERY CAREFUL – if you click on anything, you will lose the selection. Now it’s time to right-click on one of the selected packets and perform a Select Related Packets By Flow. Then, just Hide Unselected Packets or Copy them to a new window to get the results we need.
This technique can be used for any filter that you can write. So, we can now locate conversations based on a specific type of packet, but then see the entire conversations! This is just another example of how WildPackets customers find powerful ways to use OmniPeek’s features! Thanks, Brian!