Skip to main content

Using NETSH to Capture Packets

Outages. Aside from the massive pressure of having to restore service, they can be pretty useful to learn new things. One recent discovery that was news to me is that you can use netsh to capture network traces.

It appears on modern-ish operating systems (Windows 7/Windows 2008 R2 and above) you no longer need to install your favorite packet tracing application to capture packets. Who doesn’t like to cuddle up with a nice packet trace, eh? Obviously if you’re on a desktop OS, you should just load packet capturing utility of choice (and it had better be Network Monitor if you intend to open the .ETL trace) -- unless you like to read it in some other way. That would mean your skillz are simply amazing and are wasting your time here!

RUNNING A TRACE

The most basic way to start and stop a trace is by performing the following commands:
As you can see, netsh displays the trace configuration as well. It’s not the full configuration of defaults though.
netsh trace start capture=yes

Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\Users\me\AppData\Local\Temp\NetTraces\NetTrace.etl
Append:             Off
Circular:           On
Max Size:           250 MB
Report:             Off

netsh trace stop
 

KNOWING THE DEFAULTS

Pulling the help file (trace start help) will provide the list of defaults if you run the command as indicated above. I have them illustrated here for reference.
capture=no (specifies whether packet capture is enabled in addition to trace events)report=no (specifies whether a complementing report will be generated along with the trace file)
persistent=no (specifies whether the tracing session continues across reboots, and is on until netsh trace stop is issued)
maxSize=250 MB (specifies the maximum trace file size, 0=no maximum)
fileMode=circular
overwrite=yes (specifies whether an existing trace output file will be overwritten)
correlation=yes (specifies whether related events will be correlated and grouped together)
traceFile=%LOCALAPPDATA%\Temp\NetTraces\NetTrace.etl (specifies location of the output file)
I have highlighted the defaults which do not show up in the trace file output.

VIEWING THE RESULTS

Message Analyzer. You can open the file in Message Analyzer quite simply. (It’s also a brilliant tool.) By simply, I mean, just open the file once you have it running. This is my favorite way.

image

Network Monitor. You can expect the same results in Network Monitor but will need to do one additional step. Even without doing it, you’ll be able to read the frame details. The frame summary won’t make much sense though.
  1. Go to Tools | Options | Parser Profiles.
  2. Choose Windows and select Set As Active.
Wireshark. You are pretty much on your own. There are ways2 to convert .ETL to .CAP or whatever if you really need to stick that much to your guns.


REFERENCES

http://technet.microsoft.com/en-us/library/jj129382.aspx#bkmk_TraceUsingTrace
http://blogs.msdn.com/b/canberrapfe/archive/2012/03/31/capture-a-network-trace-without-installing-anything-works-for-shutdown-and-restart-too.aspx
2 http://blogs.technet.com/b/yongrhee/archive/2013/08/16/so-you-want-to-use-wireshark-to-read-the-netsh-trace-output-etl.aspx

Comments

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m