During a recent customer engagement, the task of gathering network traces and analyzing them to determine if certain traffic was moving through the proper connections was required. This particular customer was using Microsoft Groove and needed to ensure that its replication was transferred between a specific set of machines.
In this instance, Groove traffic should only have occurred between Groove Machine 1 and the relay servers, NOT between Groove Machine 1 and the other Groove machines.
By confirming this information, the customer was assured that the Groove Relay servers were handling the traffic as designed.
Process followed for validation
- We designed scaled down versions of existing test runs. They contained only enough transactions to return valid results.
- We set up the Bytes Sent/sec & Bytes Received/sec counters for the Network Interface Object on all the machines.
- Relay servers were restarted each time before each test run to insure Remote Desktop activity was not occurring.
For every test run, Netmon trace files were captured.
Opening the Netmon trace in Wireshark
These files can also be opened in Wireshark. In fact, you could also use Log parser to query them. That’s a very powerful alternative if you are doing some in depth analysis. But, be aware of some limitations when using Log parser to open Netmon captures on Windows 7 PC’s. This is covered towards the end of the article.
This is a view of Wireshark with a Netmon file opened.
From the “Statistics” drop down menu, click “Conversations”
Click the TCP tab to view only the TCP traffic.
All the column headers in the display are self-explanatory. We were looking for frames specific to Groove, so we searched for and found two frames that had the Source IP as 10.52.1.106 and the outgoing port of 2492. TCP port 2492 is used by Groove’s Simple Symmetric Transmission Protocol (SSTP).
By summing the outgoing bytes to both the Relay Servers (10.52.6.5 & 10.52.6.6), we could validate that the responses were equal or nearly equal to the total SSTP incoming bytes on these two machines.
Sent to (10.52.6.5 & 10.52.6.6) from 10.52.1.106 == Total Bytes Received at 10.52.6.5 from 10.52.1.106 + Total Bytes Received at 10.52.6.6 from 10.52.1.106
You could further click the “Copy” button and paste the content onto an Excel spreadsheet to do the rest of your analysis from there. Excel offers very powerful slice and dice options which could be very handy.
Also, if you unchecked the “Name Resolution” check box you would notice the actual Groove port that communication occurs on.
Writing custom Query Filters
Writing Filters in Netmon and Wireshark is fairly straightforward and very well documented in their help documentation.
To see all TCP traffic from 10.52.1.106 to 10.52.6.5 over TCP port 2492 to the destination TCP Port 2492, you could specify this filter:
ipv4.SourceAddress == 10.52.1.106 and ipv4.DestinationAddress == 10.52.6.5 and tcp.SrcPort == 2492 and tcp.DstPort== 2492
Make sure to select “All Traffic”
The match will pop up in the window below.
To do the same thing in Wireshark, the filter would be:
ip.src==10.52.1.106 and ip.dst==10.52.6.5 and tcp.srcport eq 2492 and tcp.dstport eq 2492
Log parser is a great tool which can be very handy when you are dealing with different log formats and important data needs to be mined. It can read IIS logs, Event Viewer logs and also Netmon Capture logs.
Find more information on Log parser here:
Known issues on Windows 7
If you are trying to parse the Netmon trace File through Log parser, the SrcIP and the DstIP fields might appear to be blank. This is a known issue with Windows 7. However parsing should work just fine on a Windows XP or Windows 8 machine.