Network Captures

We've all been in the position where we want to gain some more clear insight into what's happening on a device we own, be it a Domain Controller, Radius Server, Web Server, or perhaps our client.

In today's case I want to give the example where we just want to capture some tcp traffic on our Windows device, but we don't want to go through the trouble of installing WireShark or some other network sniffing tool.

Not installing stuff on the device we're trying to troubleshoot is always a good thing because installing things constitutes a change and worst case scenario can muddy the water a little bit, and really there's no need to do this.

Tools Required

netsh is a command line utility included in Windows operating systems since Windows 2000. It can of course be used for a myriad other networking actions besides performing a network capture, but that's the case we'll be using it for today. If you're on a NIX operating system there's a good chance your distro shipped with tcpdump, which does pretty much the same job.

So the only tools you need on the device performing the capture are builtin tools.

As far as the device you'll be reading the results on, we'll want Microsoft Message Analyzer (to convert our capture file to a Wireshark readable) and Wireshark.

Starting our Capture

In this case we'll be starting our capture without filters. This is the most broad use of the tool, and therefore easy to remember since it can serve you in almost any scenario. With that in mind since the trace is very broad you only want to run it for a limited period of time to ensure the results are more easily consumable by you.

At a Windows cmd line run: You'll see a return stating the status is "Running" and where your trace file is located. Once you see this your trace is running. Perform whatever test you're trying to troubleshoot, and then run netsh trace stop

Simulating Traffic

So sometimes the person you're trying to troubleshoot with doesn't have time when you do. In this case if you know the ports and protocols you're trying to use we can still do a couple easy network based tests to make sure traffic can successfully get from point A to point B. It's no guarantee their thing will work at all when they go to test it, but you can at least feel reassured that infrastructure isn't in your way.

For traffic simulation NIX distros are going to do the job easier, since traceroute has switches you can flip to make it UDP or TCP over a specific port.

On Windows the only builtin way I know of to do a socket connection, and whether this is truly "built in" or not is somewhat debatable, is to use the .net sockets library. Here's an example of testing a connection to 192.168.1.1 over port 445: Now of course the error messaging on this isn't exactly fantastic, basically if you get a returned object with a "Connected" value of "True" then the connection was successful. Error messaging can commonly be either:

No connection could be made because the target machine actively refused it - Just like it reads, you could reach the machine but it wasn't listening on that port.
or
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond - This one is pretty similar to a destination host unreachable. Either the dns name you entered didn't resolve right or the IP You entered couldn't be reached at all, this could also be firewalls or routing devices dropping your traffic along the way and not telling you.

Converting our Capture

Now that we got a .etl and .cab file, transfer these files to your workstation where you've got Microsoft Message Analyzer and Wireshark installed. This is also your opportunity to clean up after yourself and delete these files from the server or other device we were troubleshooting.

Open the .etl using Microsoft Message Analyzer and wait patiently while it loads. It's not very clear when it's done loading your trace, but to date, at the bottom left corner you'll see a spinning wheel while it's still loading the messages and a "Ready" when it's done. Once you see "Ready" you can either proceed to viewing the trace using Microsoft Message Analyzer, or if you prefer Wireshark like I do to export the data for Wireshark to read.

To export these logs into Wireshark compatible .cap, go to File->Save As, make sure the All Messages radio button is selected, and then pick export and save your file as a .cap, like mytracefile.cap.

Reading our Capture

Reading the capture file is probably the hardest part in this whole process and there's an awful lot to it. It also depends alot on what you're trying to find in the file. Some common filters I like to use are as follows, but you can just do a google search on "common wireshark filters" and see some good stuff around the web too.

ip.addr==192.168.1.5 - shows traffic to/from 192.168.1.5
tcp.port==389 - shows tcp traffic over 389
tcp contains mike - only messages where the content contains the word "mike". This one's useful if you're looking for a particular webpage that's receiving the GET, or a particular account name you were hoping for a message from.

And of course sometimes the lack of messages can help you troubleshoot all by itself. Expecting to see traffic from client X to server Y? Take a capture on both the client and the server. If the traffic is seen leaving the client en route to the server, but never receiving then you know you've got a problem somewhere along the way. Maybe it's a bad route? Maybe you have a network firewall blocking your traffic? Maybe you even have a host based firewall blocking the traffic on your server you forgot about!

Hopefully this helps take some of the fear out of taking a network capture as one of your troubleshooting steps, since even if the server you're troubleshooting "isn't yours" you can safely do a capture without doing any installs or reboots or other changes.