Network Monitor : tshoot

Top Users Expert for Network Monitor 3.3

PaulELong — Fri, 01 May 2009 00:48:00 GMT

One of the major new features in Network Monitor 3.3 is the ability to run experts directly from the UI. And now NMTopUsers is available from our Experts Portal. Plus as it's a CodePlex project, we have opened the source code as well. It's a fairly simple C# project which uses the NMAPI to access data from a trace. You can view and download the source code if you are interested in more details.

What Does NMTopUsers Do?

The problem we are trying to solve is a way to quickly identify the heaviest users of network traffic. For instance you might want to understand if there's a computer on your network that is hogging all the bandwidth. You might also want to identify a chatty machine which could be an indication that it has been infected with a virus or adware.

There are actually two experts in one here. The Endpoint version shows traffic for each machine address, IPv4, or IPv6 address on your network. The Conversation version, on the other hand, shows traffic based on a pair of machines, IPv4, or IPv6 addresses so you can understand the traffic involved between machines.

How Does NMTopUsers Work?

Once you've installed the expert by running the MSI, "Top Users by Endpoint" and/or "Top Users by Conversation" will appear in the experts menu. Once you run the expert a new window will show up and display a data grid. The data will depend on any display filters applied or conversation tree nodes you might have selected. The data grid contains a list of nodes or conversations and then statics on the frames and bytes that have been sent and/or received.

By default the data is sorted by Total Bytes. But you can click on any column header to sort by that column.

The Address Type drop-down lets you select which types of addresses you want to see. By default we only show IPv4 addresses, but you can add Machine addresses and IPv6 addresses as well.

The Tree View allows you to see the IPv4 and IPv6 address as they relate to the Machine addresses that they belong too. But as you can imagine this option is only available if you've enabled the Machine address type. Also if you've re-sorted on a different column in the Tree View, you can reset to the original order by using the Reset Tree button.

Finally you can create a Pie or Bar chart of the information. While sometimes this can be cluttered due to the number of addresses, it can give you a high level overview of the usage. Keep in mind that the Bar chart can't display if you have Machine Addresses selected and multiple IPv4 or IPv6 addresses for a single machine address. This is because the bar chart attempts to line up each IPv4/IPv6 address with its matching Machine address and this doesn't make sense with multiple IP addresses.

Give it a Run

Please go to the Experts Portal and download both Top Users for Conversations and Endpoint. Try it out!

Broadcasts

PaulELong — Wed, 20 Aug 2008 17:31:00 GMT

We can categorize traffic into two general types; directed and broadcast traffic. In the most general sense, a broadcast is sent to anybody that wants to listen. What I’d like to talk about is how broadcasts work and what they are used for.

How broadcasts work

In general a broadcast is a special address. Different layers, in particular the hardware and network layers have specific addresses defined as broadcasts. So let’s look at each layer specifically.

Hardware Layer:

This layer is normally controlled completely by hardware. It defines how the electrical signals go across the wire and how to decide what traffic you network adapter should listen to. In reality network traffic is always broadcasted to everybody on the same segment. Switches and Routers will further determine how segments are defined and may block or allow this type of traffic.

Your network adapter is setup to “listen” for a hardware address that is assigned to it. This 6 byte address is usually hard coded by the network card manufacturer. A manufacturer is assigned a group of addresses and they make sure they are all unique when shipped. When your network adapter sees an electrical signal, it decodes the Ethernet header information and checks if it’s one of the addresses it’s listening for. If it matches, then it sends the packet to the OS for more processing.

Here’s an example of the Ethernet portion of a packet.

    - Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-06-5B-61-2E-7A]
     + MacAddress DestinationAddress: *BROADCAST [FF-FF-FF-FF-FF-FF]
     + MacAddress SourceAddress: Dell Computer Corp. 612E7A [00-06-5B-61-2E-7A]
       UINT16 EthernetType: Internet IP (IPv4), 2048(0x800)

You can see that the Source Address is comprised of 6 bytes, 00-06-5B-61-2E-7A. The first 3 bytes, 00-06-5B, indentify it as the Dell Computer Corp. The final 3 bytes are unique and set by the manufacturer.

In wireless, all traffic is inherently broadcast based. The air is the medium, ok not really air, but the idea is that everybody sees that traffic. But again once your wireless adapter sees the traffic; it will inspect the address and if it matches, it knows to send to the OS.

Broadcasts at this layer are special addresses that are industry defined. Each NIC is configured to listen to its personal address and any broadcast related traffic. For Ethernet, the broadcast is simply an Ethernet address of FF-FF-FF-FF-FF-FF.

So for instance, if we look at an ARP packet with NM3.2, you can see that the destination address is FF-FF-FF-FF-FF-FF, and there for while be listened to by any machine that receives the packet.

    Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-07-B3-29-F8-00]

Network Layer:

The network layer in the case of IPv4 and IPv6 also does the same thing. The only difference here is that it may also include information on how to route traffic. For instance an IP address will determine if traffic is local or not for outgoing traffic.

[See http://blogs.technet.com/netmon/archive/2007/07/20/intro-to-name-resolution.aspx for more info about routing.]

When incoming traffic arrives at the IP layer, it again checks the address to see if it’s something it should be listening for. IP addresses however are not hardcoded. They are assigned and a NIC can listen on multiple IP addresses if it wants.

At this layer the broadcast again is defined as a specific IP address. For IPv4, this could be 255.255.255.255. This can also be restricted to the current sub net, so for instance 192.168.1.255 for a class C network. (For more info on IPv4 classes see http://en.wikipedia.org/wiki/Classful_network).

Why have Broadcasts?

You may have already figured this out but broadcasts are used to send information that every machine on the same segment. For instance, when IPv4 needs to see if an address is already taken it will broadcast an ARP packet and ask if an address is available. In fact, you may have already seen that ARPs tend to always be broadcasts.

    Frame: Number = 41, Captured Frame Length = 60, MediaType = ETHERNET 
    + Ethernet: Etype = ARP,DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-07-B3-29-F8-00]
    + Arp: Request, 192.168.100.253 asks for 192.168.100.13

Broadcasts are also used to announce general things like their names to everybody. When NETBIOS starts up, it sends out an announcement to anybody who’s listening to see if this name has been used before. When the name is heard machines called browse masters listen to these names and record them. This allows you to see all the machines on your local network. Your machine may ask the browser for a complete list.

    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-1D-09-AB-5D-0A]
    + Ipv4: Src = 192.168.1.5, Dest = 192.168.1.255, Next Protocol = UDP, Packet ID = 3092, Total IP Length = 78
    + Udp: SrcPort = NETBIOS Name Service(137), DstPort = NETBIOS Name Service(137), Length = 58
    + Nbtns: Query Request for MachineX <0x00> Workstation Service

When a computer boots, often broadcasts are used to ask the DCHP server for an address. In fact each time you boot a machine without an IP address, it must use a broadcast to find and communicate with the DHCP server. The message below is discover request that is sent when a machine is looking to find its first IP address.

    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[FF-FF-FF-FF-FF-FF],SourceAddress:[00-60-08-01-D3-03]
    + Ipv4: Src = 0.0.0.0, Dest = 255.255.255.255, Next Protocol = UDP, Packet ID = 288, Total IP Length = 328
    + Udp: SrcPort = BOOTP client(68), DstPort = BOOTP server(67), Length = 308
    + Dhcp: Request, MsgType = DISCOVER, TransactionID = 0x83484743

Another application, and perhaps the first thing you had in mind when you heard the word broadcast, is sending audio or video data to minimize the network utilization. Rather than sending a separate feed to everybody, you can broadcast to a general address, and NICs can then be told to listen to these special broadcast addresses. This form of broadcast is also called multicasts.

What is P-Mode?

Your NIC has a special mode called Promiscuous. This mode allows your NIC to see all traffic regardless if it’s meant for your machine or not. However, P-Mode is not necessary to see broadcast traffic as your NIC is already listening for these. By default this mode is disabled for each NIC. Even if you don’t enable P-Mode you will still see traffic where your IP or Ethernet address is not involved. This is because of the broadcast traffic. So this is why to see traffic when you click on the “Other Traffic” node in the conversation tree.

Conclusion

Now hopefully you’ll be able to identify broadcast traffic and understand some reasons why this kind of traffic exist. There are many other reasons broadcasts are used and IPv6 uses something similar to IPv4. Perhaps with this knowledge you can inspect traffic and make sure broadcasts are going to the intended network segments as sometimes ill configured routers/switches can make for a noisier than necessary network.

Reassembly with NM3

PaulELong — Wed, 09 Apr 2008 16:59:00 GMT

Ever wonder how a network works? Maybe it just seemed so easy, and in your mind sending a file was just putting each byte on the wire to the receiving machine. That’s not too far from the truth but you’d be very selfish to think that the network was there for your bidding only. Since a network has to be shared between many users, strategies have been created to chop your file up and send it in chunks.

Like Packing for a Move

We’ve all done it before. We take all of the bits and pieces of junk we’ve collected over the years and are tasked with moving them from one location to another. We invite friends and relatives, and like ants, they arduously move each piece from house A to house B. If your house=file, and boxes=packets, then we’ve created an analogy for reassembly. If you are organized, you’ll label each box, 1 of 20, 2 of 20, and so on. When you get to the new location, you can put all your things back together using the labels you created and verify you received everything.

The architects of our Internet are not any cleverer. They’ve borrowed these same techniques to determine how a chopped up file can reach its destination and be reconstituted. As long as the data is sequenced, the other side should be able to put the pieces back together.

The Transport Layer

In networking we like to talk about layers. You may have heard terms like “Layer 3 switch” or the “Network Layer”. Well, the architects of our Internet are just like everybody else. They get easily confused if too much is going on. Transferring network data from one place to another is a difficult problem. And a common strategy used to solve difficult problems is to divide and concur. Each layer is responsible for different things, and the transport layer is the one we use to define how files get chopped up and rebuilt.

We’ll narrow our focus down to TCP for a bit. This is the workhorse transporter for most networking applications. There are others, such as SPX/IPX, but TCP is by far the most popular. And it turns out RCP, SMB and HTTP can also fragment data. SMB might chop your file up into 4K chunks, and then each of these chunks could be further fragmented by TCP.

Labeling Your Boxes

So in our analogy, labeling=sequencing. We could label each packet 1 of 20 and so on, and some protocols do use this strategy. But for TCP, we go a bit further and describe the number of bytes that are sent. We’ll say, for instance, that this packet contains Sequence 1000-2000. What we actually send is the first sequence number and the size, but this range can be derived from that data. When the other side gets the data, even if it’s out of order, it knows how to put the puzzle back together. Also, the receiving TCP will keep the sender up to date by acknowledging what it’s received so far. In the simplest scenario, the receiver ACKs the latest segment it received. If the sender gets an acknowledgment for sequence 2000, then that confirms the receiver has seen all data up to that point.

Using NM3 to Reassemble the Data

When we capture data from the network, we are capturing it before the data has been put back together. But this can make it difficult to read, as you might imagine. With NM3 we’ve created a way to reassemble the data, so that you can see the data as it is seen by the application layer (there’s one of those darn layers again, see http://en.wikipedia.org/wiki/OSI_model). So when you click on a web page and get a trace, you can see the entire packet as sent by the browser, rather than a bunch of fragments after TCP has gotten to them.

Data Before You Reassemble

So if you start a network trace and view a web page you’ll notice that the traffic that gets created shows HTTP and TCP. The HTTP packets are the headers sent/received by your web browser. But the TCP that is in between is also your browser traffic. The original HTTP packet was larger than would fit in single packet, so TCP has chopped it up for you.

In this example, you can see that the server has responded with a page. Frame 6 is a continuation of frame 5 and is where TCP has chunked up the data. Frame 7 is an acknowledgment so the server knows we are receiving data. And frame 8 is the final frame in the fragmented data.

Frame	Source	Destination	Description
5	Srv	Client	HTTP:Response, HTTP/1.1, Status Code = 502, URL: http://239.255.255.250/
6	Srv	Client	TCP:[Continuation to #5]Flags=...A...., SrcPort=HTTP(80), DstPort=49382, PayloadLen=1460, Seq=3331697971 - 3331699431, Ack=1190309335, Win=65217 (scale factor 0) = 65217
7	Client	Srv	TCP:Flags=...A...., SrcPort=49382, DstPort=HTTP(80), PayloadLen=0, Seq=1190309335, Ack=3331699431, Win=255 (scale factor 8) = 65280
8	Srv	Client	TCP:[Continuation to #5]Flags=...AP..., SrcPort=HTTP(80), DstPort=49382, PayloadLen=1392, Seq=3331699431 - 3331700823, Ack=1190309335, Win=65217 (scale factor 0) = 65217

Data After You reassemble

To reassemble with NM3.1, you go to the Frames menu and select “Reassemble All Frames”. In NM3.2 we’ve created a more prominent button on the tool bar so this should be easier to find. Once the reassembly is complete a new window opens and contains all the original frames PLUS new frames for each reassembled piece.

Frames	Source	Destination	Description
5	Srv	Client	HTTP:Response, HTTP/1.1, Status Code = 502, URL: http://239.255.255.250/
6	Srv	Client	TCP:[Continuation to #5]Flags=...A...., SrcPort=HTTP(80), DstPort=49382, PayloadLen=1460, Seq=3331697971 - 3331699431, Ack=1190309335, Win=65217 (scale factor 0) = 65217
7	Client	Srv	TCP:Flags=...A...., SrcPort=49382, DstPort=HTTP(80), PayloadLen=0, Seq=1190309335, Ack=3331699431, Win=255 (scale factor 8) = 65280
8	Srv	Client	TCP:[Continuation to #5]Flags=...AP..., SrcPort=HTTP(80), DstPort=49382, PayloadLen=1392, Seq=3331699431 - 3331700823, Ack=1190309335, Win=65217 (scale factor 0) = 65217
9	Srv	Client	HTTP:Response, HTTP/1.1, Status Code = 502, URL: http://239.255.255.250/

So frame 9 is the new frame we inserted. While the Description doesn’t look much different, the devil’s in the details. Quite literally we have to look at the frame details to see the difference.

Frame: Number: 9, Captured Frame Length = 4449, MediaType= PayloadHeader
+ PayloadHeader: Re-assembled Payload
+ Http: Response, HTTP/1.1, Status Code = 502, URL: http://239.255.255.250/

The major difference is that we don’t see Ethernet, IP, or TCP anymore. We’ve replaced the original network header with our own called PayloadHeader. This header contains info about the protocols that have been reassembled, as well as information we might need from those layers. We don’t show the original frame numbers, but you can enable some debug NPL to get this information if you need. Just look at Payload.NPL for more info.

If you were to open up HTTP Response in the details, you would also see that all the HTML and header information is in this one packet. This reassembling of the data makes is very easy to understand that data from the HTTP level.

Also realize that in cases where both HTTP and TCP are fragmenting data, there can be multiple levels of reassembly. In those cases you may see a PayloadHeader for each TCP fragmentation, and then another for the HTTP fragmentation.

Reassembly FAQ

Reassembly doesn’t seem to be working for me, why?

The reassembly feature does depend on two things. One, conversations have to be enabled. Make sure this option is enabled when you open a trace. Currently the option can be found on the start page. Two, you can only reassemble a saved trace. If you just started a trace, you’ll need to save and reopen it.

Why do all the original frames show up?

When NM3 does reassembly, new frames are added in. Rather than remove the original frames, we’ve decided to leave them in as they still provide information about the original TCP data. Also, if there’s a problem with reassembly, perhaps due to missing packets, you could use the data to figure out why it didn’t reassemble correctly.

Can I only see reassembled frames?

Well yes, you can filter on only those things that have been reassembled. As we mentioned above, we add a PayloadHeader, which is just a protocol we’ve devised. So you can filter out all reassembled data, but applying a filter of “PayloadHeader”. I actually create a color filter for this so they stick out.

What you can’t do, however, is see only data that has been reassembled and the data that was never originally fragmented. While we realized this would be useful, we haven’t exposed a way to make this possible. However, with the API and NM32, it would be possible to do this programmatically.

Why doesn’t the Reassembly window have a conversation tree?

When we originally designed reassembly, the conversation window wasn’t really integral to the product yet. The simple work around is to save the capture file and reopen.

Putting it All Together

Networks have devised ways to break apart data and rebuild them. But with protocol analyzers that capture this raw data, it’s sometimes difficult to follow. With the reassembly option in NM3 your network traffic is put back together making it easier to read. Add this ability with the new Process Tracking feature in the upcoming NM3.2 and finding the only the data you need will be easier than ever.

Understanding HTTP Flow with Netmon 3 - By Yuri Diogenes

PaulELong — Fri, 21 Dec 2007 18:37:00 GMT

1. Introduction

One of the most common protocols that we need to deal with these days is the HTTP Protocol. This is not only a privilege of Internet users, there are a lot of Intranet users that also use this protocol for internal transactions.

This post will show how to use Network Monitor 3 to better understand HTTP traffic and also to help you troubleshooting HTTP traffic.

2. HTTP Components

On HTTP we pretty much have two messages: HTTP Request and HTTP Response. The picture below shows an example of these messages:

Figure 1 – HTTP Messages

Here is a brief explanation of the main components of a message:

HTTP Version: the http version in use by the message (ex.: HTTP 1.0 or HTTP 1.1).
Method: this is about the action that the client is requesting to the server (ex.: GET and POST).
Status Code: this code describes what happened on that transaction (ex.: 200, 301 and 407).
Reason: complement to the status code (ex.: OK, NOT OK).
Headers: the content of the header will depend on the version of the HTTP. For instance, HTTP/1.1. has some headers that needs to be present for the method in use (request or response).
Body: some messages will contain the body, which is the data itself. Some other messages will have a blank line.

Based on this brief explanation about the main components of a message, let’s see how NetMon 3 can help us tracking down a HTTP conversation.

3. Understanding HTTP Messages using Netmon3

On this example the server is trying to access the website www.sysinternals.com. This server (Windows Server 2003) is behind a Proxy (ISA Server 2004) and using Integrated Authentication. All the traffic was captured from this server while was accessing this web site.

To help understand the HTTP conversations add the columns “HTTP is Request” and “HTTP is Response”. Those columns will have a number 1 in the column if this sentence is TRUE. This will help to identify what HTTP message was in use at that time.

Figure 2 – Choosing Columns.

For this example is quiet easy to identify the traffic, however on a real world scenario it might be difficult to locate the packet that has the URL request that you want. You might say, “Well, let’s create a filter for this request.” The thing is, if you create a filter for this request you will see only one packet requesting for this URL and this is not what we want here.

There is one cool feature on Netmon3 that allows you to use a filter to find a packet. To use this feature you need to click on the menu Frames than click in Find (or click Ctrl+F). The following window will appear:

Figure 3 – Find Packet based on a filter.

In this case I want to find a packet that matches with the following criteria:

Contains(http.request.URI,”sysinternals.com”)

After typing this and clicking Find the packet that matches with this request is selected as the current frame.

To make even easier to read the trace we can also change the color for the HTTP packets. This will allow you to quickly identify the HTTP traffic. For this example we will set the HTTP Request in Red and the HTTP Response in blue. Follow the steps below to configure that:

Click in Filter.
Click in Color Filters.
Click in Add and type the query specified on the figure below:

Figure 4 – Color Filter feature.

After type this query click, the color (red) and the Bold style click OK.
Click in Add again and now type the following query: protocol.HTTP.response
Choose the color blue and leave it bold
Click OK again.

Here an example of how it will look after you apply the color filter:

Figure 5 – Frame summary after applies the filter.

Now we can close the Find Dialog window and look at the packet. Here is the HTTP part of the packet:

- Http: Request, GET http://www.sysinternals.com/ 
- Request: 
  Command: GET
  - URI: http://www.sysinternals.com/
    + Uri: 
    ProtocolVersion: HTTP/1.0
    Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
    Accept-Language: en-us
    UA-CPU: x86
    Proxy-Connection: Keep-Alive
    UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
    Host: www.sysinternals.com
    HeaderEnd: CRLF

As you can see, this is a HTTP Request message and some of the components of the messages previously explained appear on this packet. Let’s check the answer for this packet:

- Http: Response, HTTP/1.1, Status Code = 301
  - Response: 
    ProtocolVersion: HTTP/1.1
    StatusCode: 301, Moved permanently
    Reason: Moved Permanently
    Via: 1.1 SRVISA
    Connection: Keep-Alive
    Proxy-Connection: Keep-Alive
    ContentLength: 31
    Date: Sun, 26 Aug 2007 15:05:10 GMT
    Location: http://www.microsoft.com/technet/sysinternals
    ContentType: text/html
    Server: Microsoft-IIS/6.0
    XPoweredBy: ASP.NET
    Set-Cookie: ASPSESSIONIDCCRASDTB=OKKIMCCDOMFAEPIPJCLNPEBN; path=/
    Cache-control: private
    HeaderEnd: CRLF
    + payload: HttpContentType = text/html

Note: it is important to mention that in my lab there were no multiple streams involved. Which make it easier to track it down the answer, since it is the next packet in the sequence.

This HTTP Response message is really important to emphasize one particular point, which is the Status Code.

The status code on this answer is 301. This number itself already says what is going on in this answer. It is important to know at least the meaning of status code based on the number range. The ranges are:

Status Code	Means
200 – 299	Success
300 – 399	Redirection
400 – 499	Error on the client side
500 – 599	Error on the server side

The netmon3 parser for HTTP has the main codes already defined. If you click on the Parser Tab, click on Protocols and HTTP, you will see on the right panel those definitions.

Figure 6 – Netmon3 HTTP Parser.

You also can view this code on the Table object on the Parser tab, as showed below:

Figure 7 – Table View.

Since this is a redirection answer, the field “location” has the place where the page is now located. This is presented to the client (requester) that based on that will send another HTTP Request for this URL.

4. HTTP with Netmon3 Conversation

The conversation feature on netmon3 allows you to view the frames aggregated on the same conversation. For this next example, let’s see the frames aggregated for the HTTP request for the URL www.microsoft.com:

Figure 8 – Filtering by conversation.

Clicking on the conversation tree filters out packets based on the HTTP traffic automatically. This can help to understand the whole conversation that client and server are having during this access. Another way to customize this filter is right clicking on the conversation and chooses the option Copy Conversation Filter to Clipboard” as showed in figure 8. Remember that all filters are applied in combination with the current node that is selected in the Conversation Tree. Be sure to click on the root of the tree if you don’t want the frames to be qualified further by the conversation tree.

Looking at this conversation we can see another status code that means there was an error on the client side:

- Http: Response, HTTP/1.1, Status Code = 407
- Response: 
  ProtocolVersion: HTTP/1.1
  StatusCode: 407, Proxy authentication required
  Reason: Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )
  Via: 1.1 SRVISA
  - ProxyAuthenticate: Negotiate
  WhiteSpace:
  AuthenticateData: Negotiate
  - ProxyAuthenticate: Kerberos
    WhiteSpace:
    AuthenticateData: Kerberos
  - ProxyAuthenticate: NTLM
    WhiteSpace:
    AuthenticateData: NTLM
  Connection: Keep-Alive
  Proxy-Connection: Keep-Alive
  Pragma: no-cache
  Cache-Control: no-cache
  ContentType: text/html
  ContentLength: 4106
  HeaderEnd: CRLF
  + payload: HttpContentType = text/html

The reason why this request was considered an error on a client side is because the ISA requires authentication and the Internet Explorer on the first attempt to access the web site did not send the user credentials. After the response from the server, and depending on the browser and on the configuration, the client will use either NTLM or Kerberos to send another packet with the credentials.

5. General Information

There are many commands that you can use to obtain more information about your HTTP traffic using netmon 3. Let’s see some of them:

Filter	Explanation
contains(Http.Response.StatusCode,"301")	Show all HTTP packets where the Status Code is 301
Property.HttpIsRequest	Show all HTTP Request packets
Property.HttpPragma	Show all HTTP messages that cannot be cached. More information about the Pragma Field, see the HTTP Field definition.

Yuri Diogenes

Security Support Engineer – ISA Server Team

NM3 One Click Capture Tool - BETA

PaulELong — Tue, 06 Nov 2007 17:56:10 GMT

Wish you could get a network capture from a computer with no capture software installed? Wish you could have a network traffic "flight recorder" on a USB key? Here's your answer!"

The motivation behind creating this tool was to provide an extremely simple way to get a trace from an end user. And the name says it all, though maybe a small bit of false advertisement as it may take a bit more than just one click :). Once you have it downloaded to your machine, you can launch the executable and it will lead you through some simple dialogs that install the tool and start a trace. Once the trace is complete, which means it was manually stopped by the user or the default time of 2 hours have passed, a window will be opened to the location for the capture, called OneClick.cap.

Two Versions for Two Scenarios

One Click Autorun: The main scenario is a customer who has network access and can simply click on the EXE from a share or get the tool locally using the internet. Running this version will install NM 3.1 on your machine (if you do not already have a previous version of NM 3) and begin capturing. The capture will terminate after 2 hours, or if you press the 'x' key on your keyboard. If you did not have NM3 on your machine previously, NM 3.1 will subsequently be uninstalled.

Extract Only: For this scenario, the user doesn’t have network access at all. This version is tailor made for use with a USB drive to be inserted into a problem machine. If you place the files on the root of a flash drive, One Click will run automatically when you insert the drive. You can also run One Click by double clicking the file "OneClick.cmd" in the destination folder. The resulting capture will be copied back onto the USB device.

Detailed Tour of a One Click Capture

First thing I should mention is if you are running on Vista and don’t have NM3.1 previously installed or you are not a member of the Netmon User’s group, then you will need to run the EXE with elevated rights. Just right click the EXE and select “Run as Administrator”.

When you launch the One Click tool, it will prompt you with a EULA dialog. Assuming you accept the terms, then click YES. Remember that we do install a driver for Vista in cases where NM3 is not already installed. Also one caveat here is that if NM3.0 is installed, we use that driver rather than installing a new one. The disadvantage here is that NM3.0 can’t do wireless monitor mode or RAS capturing.

Once you accept the EULA, a CMD prompt dialog with a red background and white text shows up. We leverage NMCap for this job which is a command line utility, hence the CMD window. The window contains instructions as to where the capture file will be put by default. If you want to change this location, you can type a new one now.

If you choose the default be pressing enter, the capture will be started. At this point typing X on the keyboard will stop the capture once you are done. If you don’t press the X key, the capture will complete after 2 hours.

When the capture completes, an explorer window will open to the location where the capture file was stored. This allows the user to simply send the file to you in email or upload it to a location where it can be accessed by the original requestor.

If multiple captures are taken with the tool, the current OneClick.cap file will be renamed and appended with an incrementing number on the end.

Obtaining the Tool

At this point we are beta testing the tool. So the only means of getting it is on the Network Monitor project on http://connect.microsoft.com. When you join the project, you will see both the Auto-run and Extract Only packages in the download section. Once we release the tool, we will make it available on the Microsoft Download site as this is more convenient, which is our goal for this tool.

Trouble Shooting Name Resolution with NM3

PaulELong — Thu, 16 Aug 2007 16:41:00 GMT

Using the previous blog on “Intro to Name Resolution” we should have a basic idea of what is supposed to happen when a name needs to be resolved. Now let’s discuss how you’d use Network Monitor to determine where the problem is when connecting to your network resource. But let’s first list out some general breaking scenarios and the suggested course of action.

1. DNS address not found – This could be due to the fact the machine you are trying to reach hasn’t registered itself properly or the machine name you are using is incorrect. Resolution: verify the resource name; you should check to make sure it’s properly registered in DNS. It may also be possible that the name hasn’t properly propagated to your DNS server.

2. Machine not responding to NBTSS – Either the machine is not responding at all, or the NBTSS service is not started. Resolution: check with owner of the machine to make sure NBTSS is running properly. This may be indication of a larger problem.

3. Machine not responding to ARP – In this case perhaps the machine is hung or not accepting network requests. Resolution: find the owner of that machine. It may require a reboot and this could be an indication of a larger problem as to why it’s getting in this state to begin with.

4. Machine not responding to connect request – The machines name can be resolved, but the particular service you are trying to reach is not running properly. The machine may also be in a hung or unavailable state or you may not have rights to connect in this fashion. This could also indicate the IP Address you are receiving is old and inaccurate. Resolution: Check with the owner of that machine to make sure the IP address is correct. If it is correct, then check DNS to make sure that address is properly registered. This might also indicate the machine is blocking traffic, perhaps due to a firewall.

So the first step in t-shooting any network problem is getting a trace. So start an NM3.1 capture, attempt to connect to the resource in question, and then stop the trace.

The next thing we’ll want to do is filter out everything but name resolution type traffic for the resource we are connecting to.

nbtns.NbtNsQuestionSectionData.QuestionName.Name.contains("ResourceName")

dns.QRecord.QuestionName.contains("ResourceName")

Checking DNS

Once you apply this filter you’ll see any name resolution traffic, either DNS or NBTNS that involves the machine you are trying to reach. Depending on how your machine is setup, you may see both DNS and NBTNS or just one of the two. If you see DNS traffic show up, then you can just look at the corresponding response to see if it was successful. If it was not, then you have situation #1 described above. Here’s an example of the successful summary info provided for DNS.

DNS: QueryId = 0xDF19, QUERY (Standard query), Query for ResourceName of type Host Addr on class Internet

DNS: QueryId = 0xDF19, QUERY (Standard query), Response - Success

And here’s an example of a failed DNS request.

QueryId = 0xA92E, QUERY (Standard query), Query for asdfg.northamerica.corp.microsoft.com of type Host Addr on class Internet

QueryId = 0xA92E, QUERY (Standard query), Response - Name Error

Checking NBTNS

If instead you see NBTNS traffic, then you’ll see the same kind of things, but only NBTNS will be the protocol. So for instance you might see this for NBTNS.

NbtNs: Query Request for RESOURCENAME <0x00> Workstation Service

NbtNs: Query Response, Success for RESOURCENAME <0x00> Workstation Service, 192.168.1.100

If in your case the response does not come back at all OR it comes back negative for NBTNS and there is no successful DNS traffic to resolve your name, then the resource you are looking for is not registered properly. If the machine that responded to the NbtNS request is not the owner of the Name then you may also have a WINS problem. In that case you may have to check the WINS server to make sure it’s data is replicating properly. This is situation #2 above.

Checking ARP

Once you’ve resolved the name to an IP address, you may have to further find the hardware address. This only occurs if the traffic is local to your subnet. We haven’t talked about IP Subnets, but the basic idea is you can determine if the address is local or not by using your subnet mask. You could actually apply the following tricky filter to determine this. This is similar to what your computer does when determining if traffic is local or not.

(ipconfig.LocalIpv4Address & 255.255.252.0) == (192.168.1.100 & 255.255.252.0)

In this example the subnet mask is 255.255.252.0. You can determine this from the NetworkInfoEx frame if you started the capture in NM3. This is also available from the command line when you run IPCONFIG. The 192.168.1.100 is the destination address that is returned from DNS or NBTNS.

If applying the filter returns no frames, then the machine in question IS NOT on the same subnet. If it returns all frames, then it IS on the same subnet. The filter simply returns 0 or 1, which when applied as a filter shows all frames or none.

If the IP address is remote, then your machine sends the packet to your preferred gateway and lets your router determine where to route the packet. In this case you’ll never know the hardware address, so you can continue to the next section.

If it is a local address, then you should see an ARP request for the packet, assuming it’s hasn’t been resolved already. To avoid extra calls, ARP requests are cached. In fact you can see this cache by typing “ARP –a” from a command prompt. You can also clear the cache of the entry, “ARP –d 192.168.1.100”.

So assuming that is has not been resolved already, you should see ARP traffic. At this point I would recommend a filter to just show the ARP traffic for that IP address. So if the machine you were looking for is 192.168.1.100, your filter would be as follows.

Arp.TargetIp4Address == 192.168.1.100

Arp.SendersIp4Address == 192.168.1.100

We choose the same address for the target and sender so we can see both the request and response. You should see at least one of each, again assuming it hasn’t been cached. If you see only ARP requests, then the machine may not be responding. This is situation #3 above.

ARP Successful Response:

ARP: Request, 65.53.5.59 asks for 65.53.4.240

ARP: Response, 65.53.4.240 at 00-11-43-03-E5-A4

A failure is indicated by the lack of a Response. While the lack of a response doesn’t always indicate a problem, it could mean the machine is not responsive.

Name Resolves but No Response

At this point the name resolution portion seems to be working. But the resource in question may be there and not responding. The next step is to take a look at the traffic going to that machine. You can do this with the following filter.

IPv4.Address == 192.168.1.100

This will show only traffic where this machine is involved. Since you took the trace with traffic only leaving your machine, this should show you traffic to and frame your machine to the destination resource, 192.168.1.100.

At this point you’ll usually see one of two things occurring. You might see an attempt to connect to the machine from TCP. When you look at the summary for TCP it looks like this.

TCP: Flags=.S......, SrcPort=2932, DstPort=HTTPS(443), Len=0, Seq=2697306090, Ack=0, Win=65535 (scale factor not found)

The S (synchronize) in the Flags indicates that TCP is attempting to connect to the port, in this case 443. If you don’t see a response from this machine going back to your IP, then the service or machine you are connecting to is in some kind of hung state. It’s also possible in this case that the port is being blocked by a firewall somewhere in your network. The next thing I’d recommend is trying to PING the machine by the IP Address you obtained above. If this succeeds, the problem is specific to the server or a firewall. If it doesn’t respond then again it might be the machine, though it’s possible a firewall may again be blocking PINGS as well.

If you narrow it down to just one port and PINGs work fine, this indicates that the program or service you are talking to may be hung or not working properly. Or it still may be a firewall that is just blocking that one port.

Wrapping Things Up

Unfortunately there are other things that could go wrong. And while IPv6 has a different scheme for resolving names, it’s still an important step in the process of making a connection. The aim of this blog was just to help you understand one major component of getting connected, Name Resolution. Perhaps next time you run into a situation where you can’t reach a resource, you’ll fire up Network Monitor and see if Name Resolution is at the root of the problem.

Intro to Name Resolution

PaulELong — Sat, 21 Jul 2007 00:47:00 GMT

You sit down at your computer and attempt to connect to your network resource Du Jour (website/ server/application) and it just doesn’t want to work this morning. I’m sure this has happen to you more than a few times. And if you are a support or help desk professional, multiply that by a 10. What’s interesting is from a network perspective there’s just a few things that break. And one of the key factors in making a connection is resolving a name. Today, we are going to talk about trouble shooting that type of problem. So let’s start with a simple analogy.

Can I ask you for your phone number?

When you meet anybody these days there are two pertinent pieces of information you need; their name and phone number. Of course, if you lose the number or the number changes, 411 or the phonebook might help you find, (think resolve), your friend’s phone number. For a computer something similar happens.

Phone Number = Address

Whenever your computer needs to make a connection to a network resource, at some point it has to locate the address of the machine it wants to talk to. So it performs something we call “Name Resolution” in the most general terms. There are different levels o f Name Resolution, as we’ll see later. But in general, the idea is the same; I’ve got a name and I need to know your phone number to contact you.

I promise, the layers make it easier.

You might have heard of the mighty OSI Network Model. We have different layers in networking because it lets us divide the big problem of communicating into smaller problems that are easier to manage. Name resolution is one of those problems, but it can occur on more than one layer. So we’ll discuss name resolution with regards to two different network layers.

It all starts with a name of the resource you are trying to attach. Of course, if computers ruled the world the plain numbers would be good enough. But they don’t, yet, so for now we’ll stick to our anthropomorphic habit of using friendly names so us humans can remember them easily. GSB-OFL5060-4 is what you’re company might use for instance, though I think I prefer PaulsOffice J

ARP – Address Resolution Protocol

In this case we are talking about machines that are physically connected together. When you send a broadcast packet out, all the other machines on your local network segment see it. If this is your house we are talking about, it’s probably all the machines you own. At work it may be those machines on your floor, building, or some other delineation as defined by your network configuration. But the idea is that there are usually a group of computers that are in shouting distance for a stream of electrons.

And while you could just broadcast everything, this is inefficient. A broadcast has to be handled by every computer that hears that traffic. So in the end we want to send our packets to just the machine we are intending to contact.

For ARP, we are talking about resolving IP addresses into machine addresses. Every Ethernet network card has an Ethernet machine address burned into it. They are all unique (unless we are talking about more archaic hardware like ARCNET, ugh). And in order for one of the higher layers to properly route network packets, we must use an IP address. So let’s look at a hardware address in NM3.1.

Here are the frame details of the Ethernet portion. The first two things in an Ethernet packet are the hardware destination address and source address. The destination is where this packet is going. The Source is who sent it. The source is normally your machine, unless you are doing promiscuous mode tracing. [Note: Promiscuous mode lets you see traffic from other machines. It tells your NIC to listen to more than just broadcasts and traffic directed to your NICs hardware address. This is disabled by default in NM3.1, but can be enabled by selecting the adapter, and pressing the P-Mode button.]

Now you can see that we’ve prettified the address for you in NM3.1. Remember I said all addresses are unique? Well there’s an organization (IEEE) that provides the first 3 bytes of the address to each network card manufacturing company. In many cases they may get multiple sets of numbers. The company part of these addresses is well known. So NM3 will display that friendly name instead (this can be changed in NPL if you wish). The last three bytes are shown following the manufacturer name, 0x03E5A4.

Shout it Out

So it’s quite simple really. You yell out the address you are looking for and presto, a response comes back with the hardware address (often call MAC address). So here’s an ARP Request.

You can see that the Destination says BROADCAST. This is a special address. Any NIC which is connected to your network will listen to for its own address and the BROADCAST address. When the machine responds, it will send back an ARP response.

With this ARP response we know the hardware address. Any future traffic to this machine can use this address to communicate directly to the machine in question without having to broadcast to the world.

Finding an IP address for Name

At the next level, you need to find the IP address for a name so you can ARP that to get physical address. Perhaps this sounds a little fishy. Why not just get the physical address and skip the middle man? Well IP can do something in its layer that ARP cannot. IP can span connected networks.

Yelling is all fine and good in your own house, but imagine if all houses were connected by intercom systems and a shout in one house would automatically be blasted out to all the others. Networks don’t like noise either. Too much traffic on the wire slows things down. One of the simple rules of the physical wired Ethernet medium is that it’s limited to just one machine talking at a time. If two machines speak at the same time, the message is garbled, and nobody understands what is said. In this situation one machine has to politely wait for the other to finish before its takes its turn. [This is called Collision Detection or CSMA/CD]

There happens to be more than one way to resolve an IP address. If it is a local machine, then we might use a resolution protocol known as NBTNS or NETBIOS Name Service. This uses the same strategy as ARP. We broadcast a request out and wait for a response.

In NM3.1 the summary looks like this:

Nbtns: Query Request for PAULYSSTUDIO <0x00> Workstation Service

It sends out the name and includes an identifier on the end of the type of name we are looking for. In NETBIOS you can also find the address information for domains, users and other things. The response carries a resource record which in this case contains the IP address.

Nbtns: Query Response, Success for PAULYSSTUDIO <0x00> Workstation Service, 192.168.1.7

But for traffic that is not local, we don’t want to broadcast a NBT Name Request to the world. Furthermore routers and such are programmed to block that kind of traffic. So the network gods have provided another protocol to solve this problem.

It’s also important to note that for NbtNS traffic we also have something called WINS which serves as a way to replicate NbtNS addresses across routers. This way if you have a local WINS server, it may respond on behalf of the machine you are looking for. This is similar to how DNS works, but it’s being phased out. These days, DNS has taken over this roll but there are legacy systems which still use WINS, like Windows 2000.

DNS - Domain Name Service

The third protocol we’ll talk about is DNS or Domain Name Service. This uses a distributed database, like 411 or a phone book for each city, to store addresses. Furthermore, if you’re local DNS doesn’t have the answer it can query or forward your request to other DNS servers. So DNS servers have a way of using its partners to resolve addresses.

When your machine receives an IP address, it will often also receive the IP address of your DNS server. This lets us contact the DNS Server. This potentially may also require an ARP, but sometimes this server is not local. We’ll talk about this a little further on in the blog.

The difference with DNS traffic is that it’s directed to the DNS server. There’s no need for broadcasts in this case. We send the server the name we want to look for, and it returns with the IP address of that machine. Here’s an example of a NM31 DNS query summary line.

Dns: QueryId = 0x2847, QUERY (Standard query), Query for MysteryMachine of type Host Addr on class Internet

You’ll note we send the name of the machine “MysteryMachine” and a query ID. Since this is UDP traffic the query ID is used to track which response is related to our request. You can also tell the server that you want it to do a recursive search for you. This means that if it doesn’t have the record local, it can query other DNS servers to resolve the name.

The DNS response contains one or more Answer Records with the IP address of the machine you are looking for. You may get multiple records if for instance there is a web farm for the address you are looking for and any one of multiple machines can accept your connection.

- Dns: QueryId = 0x2847, QUERY (Standard query), Response - Success 
    UINT16 QueryIdentifier: 10311 (0x2847)
  + UINT16 Flags:  Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success
    UINT16 QuestionCount: 1 (0x1)
    UINT16 AnswerCount: 1 (0x1)
    UINT16 NameServerCount: 0 (0x0)
    UINT16 AdditionalCount: 0 (0x0)
  + DNSQuestionRecord QRecord:  MysteryMachine of type Host Addr on class Internet
  - DNSResourceRecord ARecord:  MysteryMachine of type Host Addr on class Internet
     DnsString ResourceName: MysteryMachine
     UINT16 ResourceType: A, IPv4 address, 1(0x1)
     UINT16 ResourceClass: Internet, 1(0x1)
     UINT32 TimeToLive: 1200 (0x4B0)
     UINT16 ResourceDataLength: 4 (0x4)
     IPv4Address IPAddress: 192.168.1.100

Conclusion

Name resolution problems are one of the more important pieces in networking and when it breaks, it can appear your network is down. The described protocols and processes give you a background of what is happening behind the scenes. In the next blog we’ll discuss how to trouble shoot those problems with Network Monitor 3.1.

Color Filtering Error Messages

PaulELong — Thu, 28 Jun 2007 23:32:00 GMT

Color Filters in Network Monitor are a simple way to make frames stick out in a trace. Dealing with large traces often makes it difficult to see important information. The sea of data represented by network traffic becomes a difficult backdrop to catch errors that occur. This blog will focus on creating color filters to make these types of errors stick out.

The Protocols

For this blog, I concentrate on the protocols above the transport layer: Kerberos, LDAP, SMB and HTTP. I could have dove into TCP or ICMP as well, but those types of errors are in a different class. For instance TCP resets, don’t always indicate a problem. But this should give you a good background to understand how to create color filters to flag errors for other protocols you work with.

Kerberos

We’ll start with the simplest filter. When we flag an error in Kerberos, we use a structure called “KrbError”. So we’ll simply filter on any frame which has this structure created. We can do this by using the name of the structure as our filter.

KrbError

LDAP

For LDAP, we need to look at frames where the LDAPResult is not zero. But due to an engine quirk, we can’t just search for frames where the Result code is not zero. Instead we’ll search for frames that have a ResultCode, and where the description string does not have success in it.

(!LDAPResult.ToString.contains("Success") && LDAPResult.ResultCode)

I also want to flag Abandon Request for LDAP, since these may also be an indication that something went awry. The following filter catches these.

(LDAPAbandonRequest)

HTTP

HTTP return’s a status code that’s 400 or larger when an error occurs. But one problem is this value is a string. For this filter, we will use the StringToNumber plug-in and convert to a number first so we can use our mathematical operators.

http.Response.StatusCode.StringToNumber >= 400

SMB

SMB has an NTStatus code that is set when an error occurs. The only modification we are going to do here is ignore one specific error. This is because SMB will return an error STATUS_MORE_PROCESSING_REQUIRED (22) when SMB expects more frames with the rest of the data. This isn’t exactly an error, so my filter ignores that specific value.

smb.NTStatus.Code != 0 AND smb.NTStatus.Code != 22

Creating the Color Filter

Now that we’ve determined the various things we want to flag, now it’s time to create the color filter. Just go to the Filter menu and open the Color Filter dialog. Simply click on Add and paste the following.

(KrbError )

(smb.NTStatus.Code != 0 AND smb.NTStatus.Code != 22)

(!LDAPResult.ToString.contains("Success") && LDAPResult.ResultCode)

(LDAPAbandonRequest)

(http.Response.StatusCode.StringToNumber >= 400)

Then choose an appropriate color, I chose red, and exit. Now any problem frames that match our filter will show up as red. Color filters are global to NM3.1, so any new instance of NM3 or any new traces you open will use this new color filter automatically.

Expand to your favorite Protocols

You could continue to do this for every protocol you work with. Sometime trying to find the proper filter is the trick, so hopefully these examples will help you understand different ways of doing this.

Wireless Capturing With Network Monitor 3.1

PaulELong — Fri, 15 Jun 2007 17:22:00 GMT

One of the exciting new features in NM3.1 is the ability to capture wireless network data and management packets on Vista. This new feature provides Network Monitor a useful tool for trouble shooting wireless problems.

What do you mean, wireless Management packets?

With the introduction of NDIS6, we now have the ability to query the OS in a standard way to receive information regarding data that is specific to wireless transmission. The first piece of info we see on wireless frames is stuff like signal strength and data rate. This is available for any wireless card that supports Native WiFi; more on that later. We now append a WiFi structure which contains the 802.11 MAC frame plus Metadata such as Signal strength.

But even more exciting than that, (ok I’m a geek, but I’m guessing you may be one too! J), we can now sniff management packets. These are the cool packets that need to occur in order to find a WiFi Access Point (AP) and that the AP can send out in order to announce itself. Now you can find out what’s going on when your WiFi signal disappears. Or you can see what other AP’s are broadcasting in your area.

Supported Hardware

In this section I will list the current hardware with MS drivers which support Native WiFi, and thus sniffing of management packets. This list is sure to change and be updated as drivers are updated, new adapters are added, or new hardware appears. There is more hardware out there that uses the same chipsets. (We do not have the time to test every single adapter on the market). I will attempt to keep this section up to date, though contacting your vendor may be the most reliable way to get accurate information.

Warning: OEMs (Original Equipment Manufacturer) may change the chipset without modifying the product name or in some instances the version number.

Chipset	Driver	OEM Retail Model
RTL8185	6.1099.312.2007	Xterasys2526g Belkin F5D7010v7 Belkin F5D7000v7 Netgear JWAG511 CompUSA 54Mbps Wireless G PC Card
Ralink RT73	3.0.2.0	Dlink WUA-1340
Ralink RT61	2.0.3.0	Hawking HWPG1
Marvell Libertas (USB)	1.0.0.49	Dlink DWL G122d1
Marvell Libertas (PCCard)	1.0.0.49 1.0.0.52	Trendnet TEW-421PCH/W:B1 Netgear WG511v2 Netgear WG511U
Atheros 5002..5005	7.3.1.42	Dlink DWL G650 Dlink DWI G520 Dlink DWA-642 Netgear WG511U D link DWA-556 Dlink DWA-643 Dlink DWA-552 Dlink DWA-542 Dlink DWA-645

Last updated 6/28/2007 2:10 pm PST

NOTE: That the Windows Logo Kit 1.0c has released. Please verify with your manufacture that your NIC has passed this certification to determine if NM3.1 supports wireless sniffing. The list above will no longer be updated now that the certification is complete.

Manufactures may provide their own drivers which may also support Monitor mode, but you’ll have to contact them directly to see if that is the case. Some information may be altered or omitted by the NIC upon reception of a data or management packet and thus not be correctly presented to NM3. An example is the CRC of packets.

Important Note: Switching into this mode with a driver that has not been verified, may cause your system to hang or blue screen. Be careful and save you data before using NM3.1 on a system with a wireless card.

Wireless Meta Data

As I mentioned above, each wireless packet will have a header. Like Ethernet, this contains the hardware address info, but this may also contain information about the transmission. While this metadata may differ for each vendor, there are some common fields which we return from the driver and display in the frame details. Some of the more interesting fields are listed below:

PhyType – Shows you the physical media type for this packet, for example, 802.11b.

Channel – The physical WiFi channel for this packet. This is usually a number, but the range of which depends on the PhyType and manufacturer. Normally channels for 802.11b range from 1-11. Now you can see if you are using the same channel as your neighbor, and change your AP base channel to improve your connection.

lRSSI – Receive Signal Strength Indicator is a measurement of RF Energy as detected by the hardware. This value does not measure signal quality, only its strength. It is possible to have high strength but not high quality. But you can use this to get an idea of the power of the signal at a given location.

Rate – The current transfer rate. Wireless will change the transfer rate based on the quality of the signal. While you may think you are getting 11 Mbps or 54 Mbps, you may only be getting 1 Mbps!

Cool Wireless Tricks

Now you can track down the dead spots at your location and see if there’s a way to affect your signal strength. For instance you could continually ping your router as you walk around the house. Then setup color filters to signal packets with low or marginal signal strength and/or data Rate. A sample color filter could be set as follows:

WiFi.MetaData.lRSSI < 20 OR WiFi.MetaData.Rate < 10

It’s important to note, that the RSSI value is based on your adapters definition of a max. For instance some cards return a value between 0 and 60, and others between 0 and 100. You’ll have to check with your manufacture for details, but you can probably get a good idea of the max by getting close to your Wireless AP, and using that to approximate your max.

So with your continuous ping going, walk around to places where you normally sit with your laptop and look for any RED frames, or whatever color you chose. You can also experiment with the orientation of your wireless router. You may find you get a better signal strength when you face it a different direction, or even when you turn it on its side.

Working with WiFi Monitor Mode

By default when you start a trace with a wireless adapter, you are normally already connected to a wireless AP. In this mode, you only see traffic to and from your machine and various types of broadcast traffic. But before you have already connected to an AP, the wireless NIC is sending network traffic in order to find an AP to connect to. NM3.1 can put your wireless NIC into monitor mode to see this type of traffic.

Important Note: When you place you WiFi NIC in monitor mode, you will disconnect your current wireless network connection! You will not be able to access the internet or your local network in this mode.

So with a NIC that supports the NWifi standard, NM3.1 can now place your NIC in monitor mode and do some interesting things. With NM3.1 you can perform two types of scanning modes. In the first mode, you select a specific PhyType and Channel to sniff on, and you’ll see all traffic only on that Channel.

In the dialog above, we choose the radio button for “Select a layer and channel”, and then we have the ability to choose one of the PhyTypes (802.11a, 802.11b etc…). And with each PhyType, you get another drop down with all of the available channels for that PhyType.

Once you hit the Apply button, your NIC will disconnect from the AP (you’ll lose your network connection), and set the NIC to monitor traffic on the selected channel. If NM3.1 is currently capturing, the traffic will start capturing this channel only. Also, while in this mode, you must keep this dialog box open. It is actually a separate EXE which will bring up the LUA dialog and ask for permissions when you click on the Properties for a Wireless NIC. Once you close this dialog box, the NIC will return to normal operation and reconnect to the AP as if the machine was trying to connect for the first time. If NM3.1 is capturing, you will see traffic that occurs after the AP negotiation is complete.

You can also put the NIC in a scanning mode. This briefly scans each Channel in each PhyType you have checked and captures traffic. Once the timeout is reached, it moves on to the next selected channel.

If focus is on this dialog, you can see which channel is currently being scanned. This information is updated in the status bar at the bottom of the dialog.

This gives you the ability to capture a swath of data from each channel and determine stuff like, how many APs are available in reach of my machine and what strengths? Or what channels are not being used at all? This could allow you to pick a channel that’s not so crowded and thus increase your wireless throughput. You can also use this to t-shoot why you can’t get connected at all, given you have two wireless NICs or two machines, one to capture and the other to attempt to connect.

A Brand New Sniffing Experience

NM3.1’s new WiFi Features give you a new experience and present new ways to t-shoot problems that were not easy to figure out before. Determining wireless signal strengths and channel usages are just a few of the ways you can improve your wireless experience.

Follow the Stream

PaulELong — Thu, 05 Apr 2007 17:11:00 GMT

This is not some existential trip or search for life's meaning. Rather this refers to a feature protocol analyzers use to narrow down traffic in a network trace. I mentioned this briefly in my Cable Talk Blog back on November 15^th, 2006. In fact you should refresh your memory as we'll refer to topics discussed in that article.

http://blogs.technet.com/netmon/archive/2006/11/15/conversations-in-network-monitor-3-0-cable-talk.aspx

To follow a stream in a general sense means to narrow down the network traffic to a specific conversation. This could mean between two machines, between two specific TCP ports, or even two applications. You can also see how these conversations could be hierarchical; where a conversation between two machines could be further broken into conversations between specific TCP ports.

What's so good about that?

Why is this useful, you may ask? Given that a network trace could have thousands of connections occurring, you'll need a way to find that needle in the haystack. Also, you may be looking at a problem frame and want to look at the rest of the related traffic. Being able to quickly narrow down the packets for related network traffic can help speed up your analysis time on complex traces.

Turn On Conversations

By default we have disabled conversation tracking to save memory and provide better performance out of the box. But in order to benefit more fully from this protocol analyzer, conversations should be enabled before you start a new capture or open a preexisting capture.

Cat Skinning: Method 1

Using the conversation tree is one way to skim through the various conversations that NM3 has exposed. Remember that the parsers define what a conversation is to NM3 and the conversation tree is simply a visual representation of this conversation data. By clicking on a node in the tree, you see the trace summary information reflect only those frames associated with this conversation as well as every conversation built below it.

This is a really nice way to step through each conversation and get an overview of what's happening. In fact, by opening the tree for an IPv4 level conversation with sub-conversations, you can tell how many connections a server has and get some idea of the types of things that are happening on this machine. This is a fast way to differentiate a busy machine from an idle one. A virus that scans ports would be evident because it would create a series of TCP conversations.

Cat Skinning: Method 2

Often, you'll already have a frame in focus and now you'd like to see the rest of the conversation for this frame. Now as hinted to before there may be multiple streams which include this same frame. So you must first decide what context you want to relate the data in.

In NM3, all possible streams are described by the Conv Id Column. This lists each conversation with the protocol and a number which defines the unique number assigned for that conversation. NM3 simply increments a counter for each new conversation, but you can't guarantee the numbers will be the same on two different machines if the parsers are different. Here's an example of that column:

{HTTP:81, TCP:80, ESP:78, IPv4:77}

So using this information you can create a filter to view any of the conversations that this frame is listed a part of. For TCP, a filter of "Conversation.TCP.ID==80" will return all frames that have the same port pair and IP address pairs as this particular frame. What makes this really flexible is that you can show two streams at the same time by combining two separate conversation filters. You might find this helpful when looking at a trace where the server acts as an intermediary (like a proxy server or front end for a SQL DB or Exchange Server). So for instance the following filter will show both TCP conversations 80 and 81.

Conversation.TCP.ID==80 OR Conversation.TCP.ID==81

One missing feature is the ability to track back to the conversation tree from the currently selected frame. While making it a click away would be more ideal, you can make some NPL changes as mentioned in the Cable Talk Blog.

http://blogs.technet.com/netmon/archive/2006/11/15/conversations-in-network-monitor-3-0-cable-talk.aspx

So where's the Data?

While looking at your specific TCP stream, you may want to see the payload data to give you even a better idea of what is going on. For protocols we don't have parsers for, you could use the information in my "Using Columns and Properties" blog:

(http://blogs.technet.com/netmon/archive/2007/03/01/using-columns-and-properties.aspx)

We mention in this article that you can add the TCPPayload column. This payload data described as Text may help to discover what is going on. For other streams, you could use the techniques in the previously mentioned blog to create your own property to display info you need to see. More than likely, however, for any public parsers the summary information should be of great help already.

When you're lost in the jungle…

They often tell you to follow a stream as this will lead you to civilization. Somehow the analogy seems to have similar results in that you can derive some order from the chaos by following a conversation stream. Once you become more accustomed to look at data in this light, you can tame the most unruly of network traces.

Using Columns and Properties

PaulELong — Thu, 01 Mar 2007 20:26:00 GMT

You might have had an occasion to add a new column in Network Monitor 3.0. But the list of available choices might be quite daunting. What you may not know, however, is that the list is derived from properties in the NPL script that makes up each parser. This means you can add any kind of information you want as a column.

This blog will attempt to show you some of the more useful columns you can add. But we will also explore the creation of properties in NPL for more advanced analysis.

The Skinny on Columns

It’s probably important to give some background about how columns work in NM3. A common misconception is that the column information is actually the data, but in reality it’s a string describing the data. That means that what’s in the Source Column is not the hex data for 192.168.0.1, but a string that describes it.

This is important because a property is just a variable in NPL that can change based on other factors. For instance the Source column can display the Hardware Address, IPv4 Address, or IPv4 Address based on the frame in question. But in each case, the property is still just a string representation.

Time Related Properties

For starters, let’s display what the default column layout is.

By default, NM3 show “Time Offset” as one of its columns. But it’s often useful to see either the Time of Day or the Time Delta (time from last packet). Well both of these items are available for addition. To add these in, right mouse click any of the column headers and select “Choose Columns…”.

Note that you can also save the current column layout as the default for new sessions, or restore the default column layout. Once you select the menu item, you will see a dialog like the one below.

On the left is a list of column headers you can add, and on the right, your currently enabled column headers. To add a column, select the column on the left and hit add. Or to remove, click on an item on the right and select remove. You can also order the columns using the Move Up/Move Down buttons. It is also possible to move the columns around from the Frame Summary by drag and dropping the columns around, so you don’t need to go to the Choose Frame Summary Columns dialog to do this.

Finding the Column to Add

The first problem you may encounter is that the list is huge, which is why I want to highlight some of the more useful headers you can add without NPL modification. But you still have to find the column, which you could do by just scrolling through the list. But there is a faster way! If you start typing a few of the letters, it should get you to that section more quickly. So, in this example I want to show you how to add the “Time of Day” and “Time Delta” columns. So first click in the Disabled Columns portion of the dialog, and start typing “T I m e” without the spaces, and you see that the items that start with Time appear. The first one you can see is “Time Delta”, so let’s add this to the list by clicking the “Add” button. Then also click on the “Time Of Day” and add it.

Once you click OK from the dialog, you should now see the new columns appear. The “Time Of Day” column will show you the time when the frame was captured. The “Time Delta” displays the time from the last frame. This is updated when a filter is applied, so if frames 1 and 2 are 1 second apart, and frames 2 and 2 are 1 second apart, a filter which only shows frames 1 and 3 will display a time delta of 2 seconds. For example given the following data:

Time Of Day	Time Delta	Frame	Time Offset
15:41:35.331	0.000000	1	0.000000
15:41:36.331	1.000000	2	1.000000
15:41:37.331	1.000000	3	2.000000

If filter that includes frames 2 and 3 are added, the resulting Rime Delta column would look as follows.

Time Of Day	Time Delta	Frame	Time Offset
15:41:35.331	0.000000	1	0.000000
15:41:37.331	2.000000	3	2.000000

Note: If you try to filter on the property for Time Delta in NM3.0, say to find all frames with a delta greater than 1 second, you won’t return any frames. We currently don’t have a way to properly apply this property in a filter. We hope to address this in future version of Network Monitor.

Other Useful Properties

So I wanted to provide a list of other useful properties and their descriptions. This should provide you a reference of some of the more popular column entries.

TCPDescription

It’s often useful to always see the TCP Description rather than the upper protocols. By default, NM3 shows the highest level protocol in the Frame Summary Description field. So by adding the TCPDescription property to the columns, you can always see this information. This is very useful for t-shooting strictly TCP problems.

Other Protocol Description Fields

As with TCP, you may want to see other protocol header rather than other upper level protocols. For instance SMBDescription or HTTPDescription, could be added as columns.

TCPAckNumber, TCPSequenceRange, and TCPFlags

These three properties are also great for t-shooting TCP issues. You may actually find this more useful than the TCP Description as the column information lines up the ACK/SEQ number for easy reference.

SourceNetworkAddress and DestinationNetworkAddress

The way the Source/Destination columns are populated today, you don’t always see the real IPv4 or IPv6 address. Instead we show this based on the following rules. If a higher numbered item exists, we show that item.

Alias for the IP address
Resolved Name of IP address
Real IP address
Hardware Address

So in cases where you’d like to see the real IP address and a resolved name exists, turning off the aliases doesn’t show you the real IP address. So you view the real IP address all the time by adding these columns.

SourceHardwareAddress and DestinationHardwareAddress

Like the IP address, the Source and Destination Hardware addresses don’t always show up because of the same rules above. So adding these columns will allow you to always see the Hardware Addresses.

Creating Your Own Properties

On occasion you might find it useful to create your own properties for viewing as a column in NM3. There may be a frame summary data field that you want to show up as a column. You might also want to combine a few data fields and create a column that combines that information. So let’s create a few example properties to show you how this is done.

IPv4 Identification: Adding just a simple property

In this case we’ll create a property for IPv4’s Identification field. This is the field that uniquely tags an IPv4 packet and can be used to associate the same frame from two different captures. We’ll start by opening ipv4.npl. In NM3, you can do this in the parsers tab by searching for the file in the Parser Files in the Object View. Once you find IPv4.npl, double click it to edit. Next, search for the field called Identification, it should look like this:

UINT16 TotalLength;
UINT16 Identification;

UINT16 FragmentFlags
{
…

Now we add in a property by placing it in square brackets above the data field we want to create a property for.

UINT16 TotalLength;
[IPv4Identification]
UINT16 Identification;

UINT16 FragmentFlags
{
…

Now save your changed NPL, and reload the parser. From the menu select Tools, Reload parsers. Once the build is complete you can load a trace with IPv4 traffic and add the column you just created.

TCP Port Pair: Adding a derived property with two data fields

In this example, we are going to get a bit fancier. We will create a property that shows both the source and destination port in Hex, along with the friendly port name. Remember that since a property is just a string, we can set it to anything we want. The property does not have to only represent one value.

So in this case we will edit TCP.NPL like we did IPv4.NPL before and look for this section of code.

UINT16 SrcPort = PortNameTable(this);
[Pair = Port, DestinationPort]
UINT16 DstPort = PortNameTable(this);

We’ll want to add in our property right before the last data field we will reference. In this case there is already a bracketed section above DstPort, but these directive sections can have multiple lines separated by a comma. So we will change this to

UINT16 SrcPort = PortNameTable(this);
[
    Pair = Port, DestinationPort,
    TcpPortDesc=FormatString(“%d (%s) -> %d (%s)”, 
    SrcPort, 
    PortNameTable(SrcPort),
    DestPort,
    PortNameTable(DstPort))
]
UINT16 DstPort = PortNameTable(this);

As you see we’ve called our new property TcpPortDesc and we are using FormatString, which is like printf in C, to format the way our property will look. We have 4 parameters for FormatString, the first two are the Source port and friendly name, and the second two are for the destination. We use PortNameTable to convert the number of the port to a descriptive string. PortNameTable is just a table that has already been defined for you in GlobalTables.NPL. Tables are simple structures that given one value, we convert and return a different value.

Once you add in this new column, as described before, you will see a column that displays as follows:

0x50 (HTTP(80)) -> 0xC0E6 (49382)

TCPPayload Info: Adding a property to display TCP payload as ASCII

Often you want to look at the TCP data as ASCII. For FTP conversations, the text reads like a story. But we must also work around a bug in NM3 which limits the text in a field to 0x103 bytes. So what we’ll do is limit the text when we collect it.

Here’s the original section of TCP.NPL we are going to modify.

//This maybe useful for TCP payload data filter for all TCP based protocols
//A possible filter maybe: Property.TCPPayload.Contains("*****")
//[TCPPayload = AsciiString(frameData, offset, TCPPayloadLength)]
[
DataFieldFrameLength = frameOffset + TCPPayloadLength,

In this case the statement for the entire payload is commented out. You can see that this property may be useful to enable if you want to search TCP Payloads using something like

Property.TCPPayload.Contains(“Anything”)

So we are going to enable this property and add another. Let’s change the code to this:

//This maybe useful for TCP payload data filter for all TCP based protocols
//A possible filter maybe: Property.TCPPayload.Contains("*****")
[
TCPPayload = AsciiString(FrameData, FrameOffset, TCPPayloadLength),
TCPPayloadDisp = AsciiString(FrameData, FrameOffset, 0x103),
DataFieldFrameLength = frameOffset + TCPPayloadLength,

This adds in two new properties. The first, TCPPayload, will allow us to do searching like described above. The first parameter is the data we are going to search in. When you use FrameData, it means the current frame information. The second parameter is the offset in the buffer, and another global property FrameOffset points to the current location in the frame. The final parameter is the length, and the property TCPPayloadLength holds that value for TCP.

But we can’t use TCPPayload for display because if the length is greater than 0x103 bytes, it won’t get displayed at all. For TCPPayloadDisp we fix this by explicitly setting the length.

It’s All About What You Want to See

Using columns for displaying useful information can save you time and help you t-shoot problems. Perhaps in future version of NM3 we’ll have a way to define standard column setups so you can switch from you TCP T-shooting setup to your SMB t-shooting column setup. Also we do plan to provide some organization to the properties to make it easier to find things in that long list.

Part 2: TCP Performance Expert and General Trouble Shooting

PaulELong — Fri, 26 Jan 2007 21:58:00 GMT

Performance issues are one of the more difficult problems to trouble shoot. Without a baseline, it's often hard to determine if something is really slower. But TCP does contain some built-in behavioral patterns that can be used as a signal to tell you something may be wrong with your network.

So the purpose of this article is to provide some indicators in TCP you can look at to investigate and a way to provide a simple graph of TCP traffic that can help you determine if there is a problem and if so what kind.

TCP Clues

TCP is the layer that is in charge of making sure your packet gets delivered. It tags each packet with a sequence number and when something is missing, the client informs the sender. Below I've listed some general things you can filter on in NM3 to give you clues to see if your network is working properly.

TCP Retransmits:

When dissecting a TCP trace, one of the more obvious problems you can spot are TCP retransmits. A retransmit occurs when a client detects a missing packet. From the sender's perspective, he now has sent the packet twice, so the second packet is called a retransmit. While a certain number of retransmits may occur without causing problem, excessive retransmits may be an indication that your network is sick. In NM3, you can search for retransmitted frames by using the following filter.

Property.TCPRetransmit

One you apply the filter, all frames that have been retransmitted will be displayed. Also each displayed frame will tell you the original frame that it is a retransmit of in the TCP Frame Summary. Some level of retransmits may be acceptable, but varies based on your network topology. Here's an example of how it displays in NM3:

Frame	Time Offs	Source	Destination	Description
457	16.375976	Sndr	Rcvr	TCP: [Continuation to #402]Flags=....A..., SrcPort=1236, DstPort=Microsoft-DS(445), Len=1460, Seq=658111387 - 658112847, Ack=2995420839, Win=65484 (scale factor 0) = 65484
464	16.577148	Sndr	Rcvr	TCP: [ReTransmit #457][Continuation to #402]Flags=....A..., SrcPort=1236, DstPort=Microsoft-DS(445), Len=1460, Seq=658111387 - 658112847, Ack=2995420839, Win=65484 (scale factor 0) = 65484

TCP Fast Retransmits

In some cases you may see multiple ACKs one after another in quick succession. The receiver can send these ACKs to the sender to indicate it is missing a TCP sequence range. Normally, a timeout would occur for the acknowledgement of a particular sequence before a retransmit occurs. However, if the TCP sender supports fast retransmit then it will occur after receiving these multiple ACKs. A retransmission generated by fast retransmit also changes the back-off algorithm used. If a retransmit occurs due to a timeout, then the sender reverts back to "slow start." However, if a retransmit occurs because of a fast retransmit then the sender goes into "congestion avoidance." [See RFC 2581 for more information on Congestion Avoidance and Slow Start.]

The response is called a "Fast Retransmit". This can be the behavior you see from one side when packets get lost in another segment of your network. In NM3 you can search for Fast Retransmits with this filter.

Property.TCPFastRetransmits

An example of a Fast retransmit looks like this:

TCP: [Request Fast-Retransmits #370]Flags=....A..., SrcPort=1268, DstPort=LDAP(389), Len=0, Seq=2021124596, Ack=1458852541, Win=64240 (scale factor 0) = 0

TCP SACK option

The SACK option (selective acknowledgments) is like an ACK, but the difference is that it can keep track of multiple sections of missing data. A normal ACK acknowledges the last consecutive sequence number that it received. In contrast a SACK can keep track of multiple missing segments. The SACK option contains multiple segments relating which pieces it has acknowledged and which are now lost. The number of segments is constrained to the amount of space available for TCP options. You can filter on these as well to see if your network is losing packets.

tcp.TCPOptions.Option.SACK

TCP Resets

Resets aren't always a sign that something is wrong. You should try to look at the traffic around a reset to determine if it looks normal or not. Resets can occur when an application shuts down, or if a router is configure to block a port. But they also occur when a problem occurs in a TCP session. So these can sometimes be an indication that something is wrong. The filter to find resets is:

tcp.Flags.Reset

Where's Waldo – Spotting a bad TCP Connection

Being able to take a trace and visualize it can be a useful way to look for performance issues. Most humans are better at looking at a picture and finding differences than analyzing data. Especially the large sequence numbers involved with TCP traffic.

Limitations with this Expert

Unfortunately, there are limitations to that amount of data this expert can deal with. The specific limitations will be due to the memory/CPU power of the machine you are work on. Excel, which this expert relies on, isn't build to plot 1000's of points. So you may want to limit that amount of data you try to analyze. For the following examples, a 500 MB file was transferred from the client to the server.

Using the TCP Expert

If you are familiar with the Part 1, (http://blogs.technet.com/netmon/archive/2006/11/30/part-1-poor-man-s-expert-using-excel-top-users.aspx), expert that locates the Top Users, then the procedure is much the same. Once you have the Excel Sheet Ready and the NM3 columns aligned, it's just a matter of copying the data in to the clipboard and hitting a button which launches a macro in Excel and creates the graphs we will examine later on.

Setting Up Your Excel Spreadsheet

Basically you just create a new spreadsheet, create a new macro (TCPPerf) and edit it, then paste the code at the bottom of this article. Once you complete this step, you can then take one of the sheets, (I delete all but one of them), and give it a default name like TCPPerf. And finally, create a button on this sheet and attach the TCPPerf macro to it.

Grabbing the data to Analyze from Network Monitor

This section describes how to prepare NM3 so we get the necessary columns for our calculations to appear. In NM3 we can add columns for any property that is exposed by the parsers. Actually you can also add any properties you want as well, so basically any piece of data is fair game. In the case of TCP, we want to add in the Seq/Ack Numbers as well as the Window Size and Payload length. So specifically add in columns for TCP Seq Number, TCP Ack Number, Windows Size, and TCPPayload Length in that order. Place them right after Time Offset. The resulting layout should look as follows.

After opening an existing trace or taking a new one, the next step is to filter down the specific data you want to analyze. In my case, I copied a file from my machine to a server. Since Window Size is negotiated in the TCP 3-way handshake, I made sure to disconnect to my client from the server so that may trace contains the entire conversation. I did this from the server in Computer Management under Shared Folders, Sessions. You can simply right click the session in question and select Close Session. Obviously you don't want to do this if you have something important occurring between this session and the server.

In NM3 it's easy to filter the conversations down, by using the Conversation Tree on the left. [Note: This requires that conversations are enabled when the trace is opened or a capture is started. You can set this option from the Start Page.]

Once you find the IP address pair, you can select each TCP conversation below, and look for the traffic relating to your copy. This traffic will appear as a bunch of SMB Reads (or SMB Writes if you copy to the server), intermixed with a bunch of TCP Continuation traffic.

SMB: R; Write Andx, FID = 0x4004 (\t1_up.tst@#24), 61440 bytes

SMB: C; Write Andx, FID = 0x4004 (\t1_up.tst@#24), 61440 bytes at Offset 184320

TCP: [Continuation to #256]Flags=....A..., SrcPort=1236, DstPort=Microsoft-DS(445), Len=1460, Seq=657940191 - 657941651, Ack=2995420737, Win=64118 (scale factor 0) = 64118

TCP: [Continuation to #256]Flags=....A..., SrcPort=1236, DstPort=Microsoft-DS(445), Len=1460, Seq=657941651 - 657943111, Ack=2995420737, Win=64118 (scale factor 0) = 64118

Once you have located and selected the appropriate TCP Conversation, highlight all the frames involved and copy them to the clipboard. I often use keystrokes, so I did this by selecting the first frame, hit Shift+Ctrl+End, and then right mouse click and copied them to the clipboard.

Now you simply open the Excel Spread sheet you created earlier and click the button. This will results in 4 sheets. The first sheet, PerfData, is just a copy of the data from NM3, plus some new columns that are based off this data. The second sheet, TCPPerf_PerfData, is data copied from the first sheet so that we can sort based off the data we calculated. The final two sheets contain the charts for each side of the transfer. The chart is named based on the machine adress that is sending the data.

Interpreting the Data

Since the resulting data we'll examine is a graph, it's useful to examine different graphs that are a result of different issues so we can refer to these examples as an indicator to the type of problem we may have. In my tests, I have duplicated the following situations: Increased Round Trip Time, Packet Loss, Small Window Size, and Bandwidth Reduction. All traces are taken from the sender (client) which is sending data to the server.

The data is graphed so that the left side axis contains the sequence numbers scaled for Length and UnACKed data. The right side axis is the scaled for the Window Size. Two different scales are used because often the Window size is much larger than the data being sent. UnACKed data is data which have been sent by the sender but has not been acknowledged by the receiver after the TCP timeout expires.

The Graphs

Each test was a copy of around a 500 Meg file from my machine to a server. I used the CMD prompt to do the copy to avoid unwanted Explorer traffic. So we'll start by looking at a base line capture. In this case the Round-Trip-Delay is less than a millisecond, and there are no packets lost. The bandwidth is around 100 MB.

Baseline - < 1 Millisecond RTT, 100 MB, No Packet Loss

In many of the examples I change the horizontal axis min/max so that the data isn't so compressed. You may find it useful to adjust both the max/min scales on the X-axis depending on how much extra trace traffic you took in your original trace.

The pink line represents the length of the data we are sending. For the most part it's a full packet size of 1480. The only reason it dips any lower than that is because SMB sends 61440 bytes of info (0xF000), so the dip at the end is the remainder.

Let's look at the UnACKed data (yellow line). The client continues to send data as fast as it can until it reaches the advertised window size (blue line). Note that since the scales for Window Size and Packet size can be vastly different, window size is put on the right vertical Axis. In this case, however, they happen to line up. This is helpful, because it shows that we keep sending data until the UnACKed data reaches the max advertised window size. Once we get to this point, we have to wait for an ACK from the server before we send more data. So we get in a state where we have to wait for an ACK before sending more data. Then once this particular SMB command completes, another delay occurs while waiting for the SMB response which for the next WRITE command.

Since our RTT is very low, we tend to see little effect of this delay. But note that if we had a larger window size we would have been able to even send more data before waiting for an ACK and thus improve the transfer time.

100 Millisecond RTT, 100 MB

In this sample, I purposely set the Round Trip Time to 100 Milliseconds. The basic effect is that anything that requires a response before it can continue, will incur a 100 millisecond delay. So this will certainly affect the time required to transfer the 500 MB file. As you can see here, a total of about 4 seconds is needed now. Another side affect is that since it's slower, the server is able to keep up with the request so the amount of UnACKed data is generally lower.

100 Millisecond RTT DownStream, 100 MB, 5376 Window Size

In this example we've cut the Windows size down to 5376 bytes. I've zoomed into a small segment of the entire transfer to show the details. The main thing to note is that we cannot fill the pipe up more than two segments. This means the number of segments we have to wait for an ACK for goes up, thus the total time to transfer also goes up. You can see here, for instance that there are many times we have to wait the return ACK before we can send a new packet (about 20 as compared to 5 in the baseline capture).

Down Stream 100 Millisecond RTT, %5 Packet Loss

Now we'll add in some packet loss. In this case the loss is on the Down Stream side, which means that responses from the server never make it to the client. Remember that the client is where the capture is being taken, so the resulting trace won't show any retransmits. Since the server's ACKs are being dropped, the client is affected because he cannot move his sliding window due to the fact that he thinks there is more unACKed data than there truly is. Thus the client has a difficult time sending data at a rate that fills the server's receive window. This is shown in the graph by the slow approach of the UnACKed data to the servers advertised window size.

Down Stream 100 Millisecond RTT, Up Stream %5 Packet Loss

The difference between this graph and the one above it is that in this case the packet loss is on the Up Stream side. So now the client does have to send retransmits, because now the server is complaining that data is missing to the client, instead of the other way around. So now the graph shows up inverted because data to the client can never fill up the window. Instead the client has to resend old data that has been lost. So this resets the UnACKed data to something lower than it was before.

56K Bandwidth Up and Down Stream

The final example is to show the difference when bandwidth is reduced. This is similar to the baseline test, but the main difference is the time line below is much longer. For each SMB Write it takes around 10 seconds. Another difference is that since there is a RTT delay inherent in this connection, you don't see much overlap once we hit the window size. Basically every request has enough of a delay so the we see a acknowledgement before sending the next TCP segment. So we tend to stay right at the Window edge rather than fluctuating, like we do in the baseline test.

TCPPerf Macro Code

You should be able to copy this into Excel's Macro Editor. The one problem I can foresee is that if formatting in your browser causes the text to wrap, Excel will complain. So keep this in mind.

A general overview of this code is that it copies the text from the clipboard and creates some columns to calculate UnACKed data and Advertised Window. We must also recalculate the Seq/Ack columns as there are not represented as numbers (they are numbers with hex in parens). Then we copy all the formulated data to another sheet so we can sort the resulting data. And finally we create a chart for the both sides of the conversation.

Sub TCPPerf()
' TCPPerf Macro

Application.ScreenUpdating = False
Application.Calculation = xlManual

' You can name your sheet different for multiple traces. The resulting
' sheet is created based on this name.
CurSheet = ActiveSheet.Name
' Populate the column headers
[A1].Value = "Frame"
[B1].Value = "Time"
[C1].Value = "TCPSeqData"
[D1].Value = "TCPAckData"
[E1].Value = "Window"
[F1].Value = "Len"
[G1].Value = "ConvID"
[H1].Value = "Source"
[I1].Value = "Dest"
[J1].Value = "Prot"
[K1].Value = "Desc"
[L1].Value = "Seq"
[M1].Value = "Ack"
[N1].Value = "Unack"
[O1].Value = "SrcData"
[P1].Value = "DstData"
  [Q1].Value = "SrcWindow"
[R1].Value = "DstWindow"
  [S1].Value = "AdvertisedWindow"

' Paste In Data from clipboard
Range("A2").Select
ActiveSheet.Paste

' Find Last Row in Data and save in LastRow
Range("A2").Select

Selection.End(xlDown).Select
Dim LastRow As Integer
LastRow = ActiveCell.Row

' Next take the text version of Seq/Ack from NM and convert to a number
Call SeqAckForm(LastRow)

' Create a column for UnAck'd data populate with calculation
Call UnAckData(LastRow)

  ' Create a column that gets the Src/Dest Seq and Advertised Window data
  ' depending on the sender.
Call SrcDestData(LastRow)

' Since we diabled calculations, cause one to occur now before we
' copy data around.
Calculate

' Define the name of the sheet we'll use to build our chart from
DataSheetName = "TCPPerf_" + CurSheet

' Transfer the data and calculated data to a new chart so we can sort.
Call TransferData(LastRow, CurSheet, DataSheetName)

' Build two charts, one for each client/server
Call BuildCharts(LastRow, DataSheetName)
Application.Calculation = xlAutomatic
Application.ScreenUpdating = True

End Sub

Sub SeqAckForm(LastRow)
'
' SeqAckForm Macro
'
' Just cut off the number at the first space and convert to a Number.
[L2].Value = "=VALUE(MID(RC[-9], 1, FIND("" "", RC[-9])))"
Range("L2").Select
Selection.AutoFill Destination:=Range("L2:L" & LastRow), _
Type:=xlFillDefault

[M2].Value = "=VALUE(MID(RC[-9], 1, FIND("" "", RC[-9])))"
Range("M2").Select
Selection.AutoFill Destination:=Range("M2:M" & LastRow), _
Type:=xlFillDefault
End Sub

Sub SrcDestData(LastRow)
' If the Source matches the first source, then take this seq, otherwise
' take the last value found.
[O2].Value = "=IF(H2=H$2, O1, M2)"
Range("O2").Select
Selection.AutoFill Destination:=Range("O2:O" & LastRow), _
Type:=xlFillDefault

' If the Source matches the first dest, then take this seq, otherwise
' take the last value we found.
[P2].Value = "=IF(H2=I$2, IF(P1<>0, P1, L2), M2)"
Range("P2").Select
Selection.AutoFill Destination:=Range("P2:P" & LastRow), _
    Type:=xlFillDefault

' If the Source matches the first source, then take window to be the
' src window, otherwise take the last value we found.
[Q2].Value = "=IF(H2=H$2, Q1, E2)"
Range("Q2").Select
Selection.AutoFill Destination:=Range("Q2:Q" & LastRow), _
    Type:=xlFillDefault

' If the Source matches the first dest, then take window to be the
' src window, otherwise take the last value we found.
[R2].Value = "=IF(H2=I$2, R1, E2)"
Range("R2").Select
Selection.AutoFill Destination:=Range("R2:R" & LastRow), _
Type:=xlFillDefault

' Now get the advertised window size from the other side based on which
' is the source address
[S2].Value = "=IF(H2=H$2, Q2, R2)"
Range("S2").Select
Selection.AutoFill Destination:=Range("S2:S" & LastRow), _
    Type:=xlFillDefault
End Sub

Sub UnAckData(LastRow)
' Calculate the Unack'd data by looking at the seq/ack columns we created
' before and the len field.
[N2].Value = _
    "=IF(IF(H2=H$2,L2+F2-O2,L2+F2-P2)<0,-1,IF(H2=H$2,L2+F2-O2,L2+F2-P2))"
Range("N2").Select
Selection.AutoFill Destination:=Range("N2:N" & LastRow), _
    Type:=xlFillDefault
End Sub

Sub TransferData(LastRow, OriginalSheetName, DataSheetName)
' TransferData Macro
'
' Add a new sheet for new data and charts.
Sheets.Add
ActiveSheet.Name = DataSheetName

' Copy all of the various columns we need from the original sheet.
' This is done so that when we resort the data, we reference the
' formula results.

Sheets(OriginalSheetName).Select
Range("B1:B" & LastRow).Copy
Sheets(DataSheetName).Select
Range("A1").Select
ActiveSheet.Paste

Sheets(OriginalSheetName).Select
Range("F1:F" & LastRow).Copy
Sheets(DataSheetName).Select
Range("C1").Select
ActiveSheet.Paste

Sheets(OriginalSheetName).Select
  Range("N1:N" & LastRow).Copy
Sheets(DataSheetName).Select
Range("D1").Select
Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, _
    SkipBlanks:=False, Transpose:=False

Sheets(OriginalSheetName).Select
Range("H1:H" & LastRow).Copy
Sheets(DataSheetName).Select
Range("E1").Select
ActiveSheet.Paste

Sheets(OriginalSheetName).Select
Range("L1:M" & LastRow).Copy
Sheets(DataSheetName).Select
Range("F1").Select
Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, _
    SkipBlanks:=False, Transpose:=False

Sheets(OriginalSheetName).Select
Range("A1:A" & LastRow).Copy
Sheets(DataSheetName).Select
Range("H1").Select
ActiveSheet.Paste

Sheets(OriginalSheetName).Select
Range("S1:S" & LastRow).Copy
Sheets(DataSheetName).Select
Range("B1").Select
Selection.PasteSpecial Paste:=xlPasteValues, Operation:=xlNone, _
    SkipBlanks:=False, Transpose:=False

' Now sort this data by Source so we can split and create 2 charts.
Range("A1:I" & LastRow).Select
Selection.Sort Key1:=Range("E2"), Order1:=xlAscending, Header:=xlGuess, _
    OrderCustom:=1, MatchCase:=False, Orientation:=xlTopToBottom, _
DataOption1:=xlSortNormal
End Sub

Sub BuildCharts(LastRow, MainSheetName)
' Find where the source changes to destination.
Range("A1:G1").Copy

For Each Cell In Range("E2:E" & LastRow)
    If Cell.Value <> [E2] Then
      Exit For
    End If

    Cell.Select
Next

' Paste in the original column headers
CurCellRow = Selection.Row + 1
Range(CurCellRow & ":" & CurCellRow).Insert Shift:=xlDown

' Create two names for each chart based on the the senders name.
ChartName1 = Range("E" & (CurCellRow - 1)).Value
ChartName2 = Range("E" & (CurCellRow + 2)).Value
Range("A1:D" & CurCellRow).Select

' Now create a chart for each address.
Call Chart(1, CurCellRow - 1, ChartName1, MainSheetName)
Call Chart(CurCellRow, LastRow + 1, ChartName2, MainSheetName)
End Sub

Sub Chart(FirstRow, LastRow, Name, MainSheetName)
' Set the range of the data we will use for our chart.
MinScale = Range(MainSheetName & "!A" & FirstRow + 1).Value
Sheets.Add

' Create a Name for this chart and set teh active sheet to that name.
TopUsersChart1Sheet = "Chart_" + Name + CurSheet
ActiveSheet.Name = TopUsersChart1Sheet

' Add in a new chart.
Charts.Add
ActiveChart.Location Where:=xlLocationAsObject, Name:=TopUsersChart1Sheet
ActiveChart.ChartType = xlXYScatterLines
ActiveChart.SetSourceData Source:= _
    Range(MainSheetName & "!$A" & FirstRow & ":$D" & LastRow)

' Create a secondary access
ActiveChart.SeriesCollection(1).AxisGroup = 2

' Set the min/max scale based on the time in the first/last row.
ActiveChart.Axes(xlCategory).MinimumScale = _
    Range(MainSheetName & "!A" & FirstRow + 1).Value
ActiveChart.Axes(xlCategory).MaximumScale = _
    Range(MainSheetName & "!A" & LastRow).Value

' Make the min Y scale -1
ActiveChart.Axes(xlValue).MinimumScale = -1

' Make the long time lables slant a bit.
ActiveChart.Axes(xlCategory).TickLabels.Orientation = -25
End Sub

And Much More…

The general idea here is that you can take the TCP data and look at it in a graphic form to help you to see at a high level if there's a problem. There are so many other things that one could add. Resets could be added in to visually indicate those in the graph. You could also create other graphs to represent the seq/ack responses that would give you another view of the data. But hopefully this will give you a simple tool and some specific filters to spot check performance issues on your network.

Part 1: Poor Man’s Expert Using Excel – Top Users

PaulELong — Fri, 01 Dec 2006 01:36:00 GMT

One item we are evaluating for future versions of Network Monitor are experts. These are the tools that among other things, allow you to get a high level view of a problem. But using a simple new feature in the released version of NM3 will allow us to do some simple expert-like analysis.

Cut and Paste of Multiple Frame Summaries

NM3 allows you to select multiple frames, then right-click those frames and store the resulting output in the clipboard buffer. The resulting data is tab delimited and based on the columns you have showing in your frame summary. This is the key to creating simple experts with Excel. This TAB delimited data can be imported into Excel and manipulated to pull the information we want to summarize.

The Top Users Expert

The idea of this simple expert is to display the chattiest machines on your network. So it basically sorts the Source/Destination/Protocol fields and provides a count of each. This expert provides the top users that send and receive data. It also shows a protocol usage, but only at the top most level. So while this may not be as useful as a count of all protocols used, this still may help show where most of your bandwidth is being used protocol wise.

This expert can be useful to find a machine that is infected with a virus and attempting to pass that virus on to another machine. It can also identify a machine that is overloaded with requests and thus the center of a bottle neck.

How it works

You start by selecting the frames you want in NM3. Then right click those frames and select Copy. You could also just type Ctrl+C to copy these frames into the clipboard. Next you run Excel and paste the data, starting at line number 2. This is so we can add column headers for the data. Then you create 3 pivot tables, one each for Source/Destination/Protocol. For each pivot table, you select the appropriate column for the row data and row count. Once you do this you can sort the data, and the count of the highest users appears at the top.

Devil's in the Details

So rather than explaining each step, I'll annotate a Macro I created to do this job. If you cut and paste this macro into Excel and run, it will copy the data in the clipboard, and create the column labels, and then create a new page with the 3 pivot tables. NOTE: the data is assumed to be in the default layout (Frame Number, Time Offset, ConvID, Source, Destination, Protocol Name, Description). If you have a different layout, you'll have to modify the columns section in this macro.

This macro was created for Excel 2003. It should be easy to modify for future versions as well. In Excel 2003, I go to Tools, Macros. Then I typed in a name, TopUsers, and hit create. This gives me a blank macro, which you can populate with the following information.

Sub TopUsers()
' This creates the text for each column heading
' Match these to your column layout in NM3.
[A1].Value = "Frame"
[B1].Value = "Time"
[C1].Value = "ConvID"
[D1].Value = "Source"
[E1].Value = "Dest"
[F1].Value = "Protocol Name"
[G1].Value = "Description"

' Now make Cell A2 the current one and Past the clipboard results into Excel.
Range("A2").Select
ActiveSheet.Paste

' Get the range of all the data you've pasted in.
Dim CapRange As Range
Set CapRange = ActiveSheet.UsedRange

' You can name your sheet different for multiple traces. The resulting
' sheet is created based on this name.
CurSheet = ActiveSheet.Name

' Add a new sheet and define a variable for its name. Set it to the active sheet.
Sheets.Add

TopUsersSheet = "TopUsers_" + CurSheet
ActiveSheet.Name = TopUsersSheet

' Create Source Pivot Table
ActiveWorkbook.PivotCaches.Add(SourceType:=xlDatabase, SourceData:= _
    CapRange).CreatePivotTable _
    TableDestination:=TopUsersSheet + "!R3C1", TableName:="Source"

' Add Count of Source as xlCount of this Pivot Table.
ActiveSheet.PivotTables("Source").AddDataField ActiveSheet.PivotTables( _
    "Source").PivotFields("Source"), "Count of Source", xlCount

' Add Source as xlRowField of this Pivot Table.
With ActiveSheet.PivotTables("Source").PivotFields("Source")
    .Orientation = xlRowField
    .Position = 1
End With

' Sort data based on the Count.
ActiveSheet.PivotTables("Source").PivotFields("Source").AutoSort _
    xlDescending, "Count of Source"

' Create Dest Pivot Table, same as Source
ActiveWorkbook.PivotCaches.Add(SourceType:=xlDatabase, SourceData:= _
    CapRange).CreatePivotTable _
    TableDestination:=TopUsersSheet + "!R3C4", TableName:="Dest"

ActiveSheet.PivotTables("Dest").AddDataField ActiveSheet.PivotTables( _
    "Dest").PivotFields("Dest"), "Count of Dest", xlCount

With ActiveSheet.PivotTables("Dest").PivotFields("Dest")
    .Orientation = xlRowField
    .Position = 1
End With

ActiveSheet.PivotTables("Dest").PivotFields("Dest").AutoSort _
    xlDescending, "Count of Dest"

' Create Prot Pivot Table Same as Source

ActiveWorkbook.PivotCaches.Add(SourceType:=xlDatabase, SourceData:= _
    CapRange).CreatePivotTable _
    TableDestination:=TopUsersSheet + "!R3C7", TableName:="Protocols"

ActiveSheet.PivotTables("Protocols").AddDataField ActiveSheet.PivotTables( _
    "Protocols").PivotFields("Protocol Name"), "Count of Prot", xlCount

With ActiveSheet.PivotTables("Protocols").PivotFields("Protocol Name")
    .Orientation = xlRowField
    .Position = 1
End With

ActiveSheet.PivotTables("Protocols").PivotFields("Protocol Name").AutoSort _
    xlDescending, "Count of Prot"

' Label each of our tables.
[A2].Value = "Source Addresses"
[D2].Value = "Destination Addresses"
[G2].Value = "Top Protocols, highest level only"
End Sub

Adding a Button for Flare

To make things even easier to use, I added a button on the main page. All it does is call the TopUsers macro. So you just copy the data in NM3, and click the button in Excel. Magically, the new sheet is populated with the table showing you the top users.

So to do this, I insert a picture. In my case I used an autoshape that looks like a rounded rectangle. But any picture will do, as long as you can assign a macro to it. To assign the macro, I just right clicked the shape and chose, Assign Macro. I also added some text to my rectangle like, "Copy Frame Summary in NM3 and then Click Here".

More to Come

While this is a simplistic expert, it should be possible to create more complicated ones. NM3 allows you to add columns to the interface. The columns you can choose are based on properties exposed the by the parsers. And you can go one step further by adding properties to the parsers. Stay tuned for a more complex example!

Conversations in Network Monitor 3.0 – Cable Talk

PaulELong — Wed, 15 Nov 2006 20:48:00 GMT

Conversations for network protocols have been around for ages. But protocol analyzers have not been built to take advantage of them in the way NM3 does. Using the conversation tree and filters that reference conversations, make NM3 a powerful ally when trying to narrow down traffic.

It's important to note that conversations are disabled by default in NM3. This is because conversations tend to eat up memory and we wanted to be able to capture for long periods of time. You can turn on conversations from the start page or in options.

What is a Conversation with regards to networking?

In layman terms, a conversation is simply a communication stream, normally between two machines. When you call and talk to your friend on the phone, the stuff you talk about is your conversation. With networking protocols, it is much the same thing, but as with everything else in computers there are more levels of complexity.

When two machines talk to each other with a specific protocol, there is often a set of parameters that each frame has in common. Normally there is a value or values that are associated with that connection. When you look at that protocol in any frame, you should be able to determine what other frames are related by looking for the same values.

The most familiar type of conversation is the one TCP sets up when it creates its communication stream. When you computer talks to another using TCP, the first thing it does is negotiate which ports to use. This source/destination port pair defines what the conversation is for these two machines.

Conversations are Hierarchical!

Now one catch is that the source/dest port pair for TCP is specific to the pair of machines that are talking. So you may find other frames with the same source/dest port pairs, but these are not part of the same TCP Conversation. So it's important to understand that conversations can be hierarchical. The TCP source/dest pair is also dependant on the IP source/dest addresses.

So for a pair of machines, defined by their source/dest IP address, there may be many TCP conversations. And then on top of TCP, there may be multiple NBT, SMB, HTTP or other types of conversations.

Conversations not limited to connection oriented protocols

Certain protocols like UDP or ARP are called connectionless. They don't guarantee delivery of a packet and have no sense of sequence numbers. But this doesn't mean that they can't be associated in a conversation. For UDP we can use the port numbers to group those frames together. For ARP we associated the sender/target address and combine those frames into a single conversation. The only thing we need for a conversation is some basic set of parameters that we can match to say one frame is related to another.

Mommy, where do conversations come from?

When a parser is written, you have the option to define conversations for that parser. In fact you could define multiple conversations for the same parser. I won't go into all the details, but basically you tell the engine what parameters to use to correlate like packets. You can build the conversation based on the parent, or base them solely on parameters in the current frame. When you build them on the parent, you get the hierarchical nature I'm talking about above.

How can I use conversations to troubleshoot problems?

In Network Monitor 3.0, when you click on a node in the conversation tree, it automatically filters and shows you only traffic pertaining to that conversation. So for instance, if you click on an IPv4 node that is equivalent to Conversation ID 5, a filter of "Conversation.IPv4.Id == 5" is enabled. This doesn't change the display filter physically, but implicitly applies this filter so you only see that traffic displayed.

You are of course free to filter further by applying a display filter. If you right click the node in the tree and select "Copy Conversation Filter to Clipboard", you can see what filter is being applied. This will require you paste the clipboard text somewhere so you can see it. This is an easy way to add this permanently to your display filter.

This is basically part of the same kind of functionality Wireshark users know as "follow the stream". The difference though is that you can follow TCP, IPv4 and many other types of streams.

Since the conversation tree is hierarchical you can quickly see the traffic flowing between two IPv4 nodes. So if you know the machine you are interested in, you can see all traffic by clicking on the node. Further more you can drill down into each TCP conversation below it.

By the way, you'll notice the ConvID in my display that you may not have in yours. I'll explain more on this later.

So you can continue to drill down until you find the traffic you'd like to example more closely. Different protocols have different levels of information. For example you can see SMB broken down by file name followed by the SMB File ID.

In this example, you can see that HTTP traffic will list the initial HTTP command and URL. This makes it easy to find web traffic in question.

Certain parser features depend on conversations

Conversations have a purpose other than grouping frames. Today they are also used to hold state information that may be useful to other frames in the conversation. For instance, TCP keeps track of sequence numbers so it can detect retransmits and lost segments. This is done in the conversation so that you don't get collisions with duplicate sequence numbers on different ports.

Info on the ConvID = lines in My Display

Until we get some easy way to associate displayed frames with the conversation tree, I added some NPL code to display this info. This is fairly simple to add if you want the same functionality. Here's an example of how I did it for IPv4.NPL. The same thing applies to any conversation.

In NPL we create the description by calling ConversationDescription. So below you can see I simple add in the property ConvID when the conversation description for IPv4 is created.

Post.Conversation.ConversationDescription = FormatString("(%s - %s) ConvID = %d", Source, Destination,ConvID)

The Future of Conversations

Conversations are new and over time will evolve and change. There are already requests to associate the current frame with the node in the tree. Others have suggested we provide a way to filter the tree to only show relevant information. We are also hoping to someday to show specific processes and break out the traffic specific to each process.

NMCap: the easy way to Automate Capturing

PaulELong — Tue, 24 Oct 2006 19:59:00 GMT

OK, I'm not going to blow smoke up your Async port. I don't mean to say that the NMCap is necessarily easy to use, though it's not that hard. But any command line utility always has its quirks. Isn't that why GUI was invented?

What NMCap does make easy, is automating how you get your captures. And presenting somebody with a script is always much easier. I don't know how many folks have tried to walk a parent or friend through some simple procedure over the phone or email, but I'm sure you can understand how challenging it can be. "Double click faster Mom…no not there, on the thingy that looks like a spider monkey!"

NMCap is a tool that runs from the command line and allows you to set all kinds of options to control when it starts, when it stops, how it stops, what it captures, where it captures, in all kinds of variations. This allows you to script it so that when you want somebody to get a trace; you get exactly what you want.

NMCap is…

Low profile – If you want to take a trace without affecting the server performance, use NMCap with no filters.
Configurable – A host of options to allow you to start/stop traces with full control.
Scriptable – Since it's just a command line utility, you can use it in your batch files.

How can I stop my trace when my process is finished?

The other application that NMCap makes easier is automation. You'll often want to start or stop a trace under certain conditions. And while you can't communicate with NMCap directly, you can tell it to start and stop when specific trace data occurs. This means that you can PING some address, for instance, and cause your trace to stop. This is the key behind automating a capture.

The Situation: You need to start a capture, run your test pass, and stop the capture.

So imagine your application is blah.exe. This task requires two different processes. One to run NMCap to take the trace and look for the stop criteria, The other process is for your test application. Our batch file looks like this.

start nmcap /network * /capture /file t.cap /stopwhen /frame (ipv4.address == ipconfig.localipv4address) AND (Ipv4.DestinationAddress == 1.2.3.4)

Sleep 5

Blah.exe

Ping 1.2.3.4

We start by running nmcap with the START command. This lets NMCap run as another process in another window (we could use /b to make it run in the same window if we choose).

The next set of parameters, "/network *" tells NMCap to capture on all NICs. You can alternatively select a specific network adapter by number. To list the number to adapter mappings, type "NMCap /DisplayNetworks".

The "/capture /file t.cap" parameters describes where to store the information and what to use for our capture filter. In this case, we don't have a capture filter. If we wanted to supply one, we could add a filter after the "/Capture" parameter.

The final portion "/stopwhen /frame …" determines how NMCap will stop. When used with the "/frame" parameter, this allows you to stop when a specific filter criteria is met. Once we see a frame that passes this filter, we stop the capture and exit NMCap. We look for a filter whose sending IP address matches the local IPv4 address AND the IPv4 destination address is 1.2.3.4.

The next line of the batch file simply waits a few seconds to make sure NMCap is up and ready to capture packets. Once 5 seconds pass, we call the application that we want to capture the traffic for. And then finally the PING that NMCap is waiting for to single it to stop capture.

It probably doesn't matter if this address exists or not. At least on Windows machines, the PING goes out whether it's valid or not. But you could also change the traffic you use to stop the trace. There is more than one way to generate traffic that you could trigger on.

The most basic of examples:

So let's take a step back and give you the most simple of examples. The following captures on all network adapters and does no filtering.

NMCap /network * /capture /file test.cap

Now let's take the above command and add a filter to it. I now want to get rid of any traffic on port 3389, since I know my Terminal Server session rides on that port and I don't want to see any of that traffic in my trace.

NMCap /network * /capture "!(tcp.port == 3389)" /file test.cap

You can use any complex filter you want here. You can reference and protocol we have a parser for. No longer are you limited to using offsets in protocols, like you were with Netmon2.x.

Stopping and Starting

The default stopping criteria is to stop when the user hits Ctrl+C or Ctrl+Break. You can use the "/stopwhen /keypress x" or any other letter to make it stop when a specific single character is entered.

There are many stopping and starting events. You can just as easily have a network event start NMCap capturing. You can also start/stop after a given amount of time with the "/TimeAfter" parameter. In this case you supply a number and units, like "/TimeAfter 30 mintues". Or instead of a time delta, you can specify and absolute time instead, for example "/Time 10:30:00 am 9/10/2006". The format of the time depends on your locale settings.

Capture File Output, creating chained captures

When you specify the capture file name with the "/File" parameter, you tell NMcap what type of capture file you want by the extension you add to the file. If you use a ".cap" extension we save the data to a single capture file and limit the size to 20 Megs. But you can change the default size by adding a colon and the size after the file. For example, "/File t.cap:50M", sets the max file size to 50Megs. Once we reach this limit we do continue to capture, but the file doesn't grow anymore.

But if you want chained captures, you can use the ".chn" extension. Again you can specify the size of each chained file with the colon. When you use chained capture files, it names each by attaching parens with a number in between which tells you the sequence in the list of capture files. So for example, "/file t.chn:1M", will create files t(1).chn and t(2).chn, and so on. Each capture file will be 1 Meg in size.

Cool NMCap trick, using another capture file as the input source

NMCap also allows you to accept a capture file as input. This can be useful for cleansing your traces before you use them. Or you could also parse traffic by different ports or by IP addresses. The following example takes all the traffic going to 10.0.0.1 in the trace test.cap, and puts the resulting traffic in c1.cap.

NMCap /InputCapture test.cap /capture Ipv4.Address == 10.0.0.1 /file c1.cap

Seeing more examples

NMCap with the "/examples" switch will show you some more examples that should help you understand how to use the various parameters. With the host of capturing options, you should be able to fulfill most of your capturing needs.