Working With Network Monitor (Part 4)

by [Published on 25 Sept. 2007 / Last Updated on 25 Sept. 2007]

This article continues the Network Monitor series by examining various filtering techniques.

If you would like to read the previous articles in this series please go to:

If you would like to be notified when Brien Posey releases Working with Network Monitor (Part 5) please sign up to the WindowsNetworking.com Real Time Article update newsletter.

In the previous part of this article series, I showed you how to filter a Network Monitor capture so that only the communications between the desired hosts are shown. Filtering out conversations with hosts that you have no interest in goes a long way toward getting rid of “noise” in the capture file, but there may still be a lot of clutter that you have to sort through in order to locate the information that you are interested in. For example, in our sample capture we performed a ping against one of the other hosts on the network. A standard PING command typically produces twelve packets of data. If you look at Figure A you will see that even after filtering out conversations with other hosts, there are far more than twelve packets displayed.


Figure A: When you typically perform a capture there will be a lot of clutter to cut through

The scary part about this capture is that all of these packets were captured over a span of about five or six seconds. You can only imagine how many packets would be captured had the capture duration been longer, or had the hosts been busier, as would likely be the case in the real world.

Fortunately, there are a few other things that you can do to cut through the clutter. In this particular case, we are interested in seeing the packets that are related to a PING. Any time that you issue a PING command, Windows invokes the ICMP protocol. That being the case, we can filter the list so that only ICMP related packets are shown.

Remember that we have already filtered the list so that we are looking at the correct hosts. To further filter the list by protocol, click the Filter icon (the icon that looks like a funnel). When you do, you will see the Display Filter dialog box, shown in Figure B.


Figure B: The Display Filter dialog box allows you to filter by host and by protocol

To filter by protocol, select the Protocol==Any line, and click the Edit Expression button (This button will appear in place of the Change Operator button that is shown in the figure). Upon doing so, you will see a screen similar to the one that is shown in Figure C. As you can see in the figure, this window lists all of the protocols that Network Monitor is aware of, as well as a brief description of each protocol.


Figure C: The Expressions dialog box lists each protocol that Network Monitor is aware of

To create the filter, simply click the Disable All button. Doing so will move all of the protocols shown in the figure from the Enabled Protocols list to the Disabled Protocols list. Now, scroll through the Disabled Protocols list until you locate the ICMP protocol. Select the ICMP protocol and click the Enable button. After doing so, ICMP should be the only protocol that’s listed on the Enabled Protocols list. Click OK twice, and the capture will be filtered to show you only the packets that you are interested in, as shown in Figure D.


Figure D: You can filter by host and by protocol simultaneously

The technique that I just showed you works great if you know exactly which protocols you are interested in. Sometimes you might need to just get a general sense of what is going on in a conversation between two hosts, and may not know specifically which protocols will be involved in the conversation. Even in these types of situations there are techniques that you can use to cut through the clutter.

The technique that I am about to show you is nowhere near as efficient as the one that you just saw, but I have used it in real life. The idea behind this technique is to filter out the “noise” packets one at a time. Before I show you how this technique works, I just want to mention that the criteria for classifying a packet as noise will vary greatly from one situation to the next. The more thoroughly you want to investigate a capture file, the fewer packets you will want to filter out. On the other hand, if you just want to get a general idea of what is going on with a trace, then there will usually be quite a few packets that you can filter out.

As you have already seen, we used a computer named FUBAR to perform a PING against a server named TAZMANIA. Let’s pretend that we know that these two computers are the machines that we are interested in analyzing, but let’s also pretend that we do not know that ICMP is the protocol that is used by the PING command.

If that were the case, then the first thing that we would do is to filter the list of captured packets so as to eliminate conversations with hosts other than the ones that we are interested in. To do so, we will use the exact same technique used in Part 3, and the results should look like what you see in Figure A.

When we knew that we were only interested in seeing ICMP packets, we used the filter to eliminate every packet except for ICMP. In this technique, we are going to do the opposite. Rather than eliminating every protocol except for the one that we are interested in, we are going to leave all of the protocols enabled initially, and then filter out individual protocols as we realize that we are not interested in them.

As you look at Figure A, one of the protocols that you will see used the most often is the TCP protocol. The TCP/IP protocol tends to fragment data. Often when you see a TCP packet, it is a fragment of something that is left over from another frame. If I am trying to get a general understanding of what is happening in a trace, the very first thing that I will usually do is to filter out the TCP packets.

It would seem that you should be able to click the filter icon, to access the Display Filter dialog box. Click the Protocol==Any line and click the Edit Expression button. Select the TCP protocol, and click the Disable button.  Unfortunately, a bug in the current version of Network Monitor keeps this from working the way that it should. As a work around, I make a list of each protocol that was used in the capture. I then disable all of the protocol, but enable the protocols that were actually used by the capture. From there I can disable protocols as I find that they are irrelevant to what I am doing. For example, if you compare Figure E to Figure A, you can see just how much I was able to shorten the trace by filtering out the TCP protocol.


Figure E:
Filtering out protocols that are irrelevant to what you are looking for can greatly decrease the number of packets that you have to sort through

Conclusion

In this article, I have shown you two different techniques for isolating the packets that you need. In Part 5, I will continue the series by showing you how to extract data from an individual captured frame.

If you would like to read the previous articles in this series please go to:

If you would like to be notified when Brien Posey releases Working with Network Monitor (Part 5) please sign up to the WindowsNetworking.com Real Time Article update newsletter.

The Author — Brien M. Posey

Brien M. Posey avatar

Brien Posey is an MCSE and has won the Microsoft MVP award for the last few years. Brien has written well over 4,000 technical articles and written or contributed material to 27 books.

Latest Contributions

Advertisement

Featured Links