Introduction to Network Trace Analysis Using Microsoft Message Analyzer - Part 2

First published on TechNet on Oct 12, 2014

Hi folks, Lakshman Hariharan here again with the second post in the series of posts introducing how to read network traces using Microsoft Message Analyzer, aka MA. The first post, which can be found here discussed how to capture a trace on a Windows machine, the basics of TCP session setup and teardown. We also discussed various concepts such as Sequence and Acknowledgement numbers etc.

Let us continue to build further on the first post. In the previous post how a TCP session is setup successfully. Now let us look at what happens when a client tries to connect to a server on a port it is not listening on. For that we will use our trusty old friend, telnet.exe again.

As described in the previous post, we start the trace using netsh.exe, connect to the port using telnet.exe and then stop the trace as highlighted in the screenshot below.

Now let’s open the trace in MA and see what happens. Since this is a small trace we will use a simple filter of TCP to analyze what we are interested in seeing. When we apply the filter of TCP we see that we now have three frames (or messages if you will) that are returned, all three of them an attempt to establish a connection to destination port 21 using a source ephemeral port of 49219. The client tries three times and gives up. The filter and the resulting SYN frames highlighted in red in the following screenshot.

If we click on the informational item on frame 12 we notice that MA is telling us that there was no acknowledgement (ACK) received for this SYN packet.

When we further analyze frames 22 and 28 we notice also that MA is telling us that they are retransmits of frame 12. Note that TCP retransmits are automatically detected by MA now.

So, to recap. In this case the client tries to connect to a port that the server is not listening. It sends three messages and having received no reply (ACK to its original SYN) it gives up.

There is another way the server could have responded and that is by issuing a reset (RST) in response to the client’s attempts to establish a connection.

Now that we have seen how a session is setup and torn down and also having seen what unsuccessful attempts to setup a connection look like, let us look at what happens in between. As in, after a session is setup successfully. For that let’s look at one of the most common protocols HTTP. We will, in the process look also at the different response codes returned in the trace, which are documented here .

For that let us look at a trace of launching IE and navigating to www.contoso.com a simple website setup on IIS 7 which is nothing but the default landing page.

Frames 22 through 24 establish the three way handshake successfully to the server on port 80 as shown in the following screenshot. Between messages 25 and 170 is where the HTTP (or application) part of the transactions happen and 173 is where the client terminates the connection with a Reset (depicted as …A.R.. in the Summary column) as a result of my closing the browser tab.

When we expand message 27 and look in the details pane we see a few other items of interest. For example the when we expand Headers and Server we see that the server we are talking to is IIS 7.5. Granted we know that in the context of this scenario but if all one had was access to a client side trace sometimes it helps to be able to glean from the trace what server OS and/or version we are running.

To continue looking at different status codes let us look at a trace from when one opens IE and forces a refresh to a page previously loaded by pressing Ctrl+F5 on the keyboard. In this case we get a status code of 304 (Not Modified) returned, indicating that the page hasn’t been modified since our last visit.

The following screenshots are from a trace when navigating to www.contoso.com . The first screenshot shows, in general terms the sequence of events. We navigate to www.contoso.com , are redirected to a different URL and then make a successful connection to the URL we are redirected to. Note the filter of tcp.port==64665 or tcp.port==64669 to just filter out the traffic we are interested in seeing, highlighted in yellow.

In this case on the server side a redirect has been configured to www.microsoft.com . Note the status code of 302 (redirect) highlighted in red in the screenshot below.

The following screenshot is of selecting frame 1192 in and looking in the Details pane. Here we see the location we have been redirected to, which happens to be www.microsoft.com/ms.htm

Now that we have seen how the HTTP protocol works on the wire and some of the status codes, next up we will discuss how a website setup for Windows Integrated authentication works. Stay tuned, and thanks for reading.

-Lakshman Hariharan