Ok, many moons went by since my last post. Also many things have happened, so I guess it was meant to be like this.
Anyhow, I’m back with a short, but useful blog.
One thing (ok, not one but quite a few) that Windows is missing when compare to Linux is packet capture tools. They used to have a very nice and powerful packet capturing tool called … I can’t remember, it is so old even Google deleted it from its caches.
But now days I guess most people install Wireshark on the Windows and, to be honest this is my prefer way of doing captures, but what if, for some reasons, we don’t have the comfort of using WS? We cannot download it or install it, we are forbidden to do so, we have concerns about traffic interruption while the drivers are installed, … I’m talking about servers, of course. So, what are our options?
We could go for WS portable version, which does not require installation, but in my recent troubleshootings it was proven not to work as expected.
Another try could be TCPDUMP for Windows. I did not try it, but looks like no installation needed, but it’s not free. There are many more options available, but they are not free, they need to be installed, they don’t work, they use their own file format, …
So, what’s left is, I guess plain old Windows netsh tool. Believe it or not, it can do a packet capture for us.
The scenario: we have a Windows server without packet capturing software and we need to do a tcpdump style troubleshooting. Let’s go…
First, we make sure that we don’t have already a running capture. Not sure what is going to happen if there was, but better check:
“netsh trace show status”
Fine, no captures are running. No we can start our new capture. It is good idea to put some basic capture filter, as we do with WS, so we can do:
“netsh trace start capture=yes IPv4.Address=22.214.171.124”
This is going to capture all packets to and from IP 126.96.36.199. We can also see what is the location of the capture file. I guess that we can tweak netsh parameters more, but for basic troubleshooting scenario, this will do. We can verify our capture status, but this output is ugly and the only usable info here is I guess status, which should be running:
“netsh trace show status”
Now we do our test. In this case, just ping Google server:
Ok, we completed our test, and we should now stop our capture:
“netsh trace stop”
Again, we can see the file location. The file has ETL extension, which WS cannot open (as far as I know). If it could, we would have one less step to do, but still we have to capture packets as described above. The “netsh stop” can take some time, so don’t worry and just wait for it to finish.
Just in case we need to do more captures, it could be a good idea to copy and perhaps rename our last capture. After this, we need a way to convert this ETL file to PCAP format (again, if WS cannot do this). So we may use an easy tool called, guess how, etl2pcapng. It is free and don’t require any installation, so we can run it on the server or client PC:
We can see here two files. One is ETL, the one we need, and another one is CAB file that contains God knows what, and it is very large. For a most simple capture it can go for 90MB or more. So, we only need to transfer ETL file to our desktop for conversion or already converted PCAP file which we can open in WS:
Yes, it has more steps than we would like to, but if we don’t have WS on the server in question, I guess this can help out.
Thanks for reading. Stay safe and healthy!