Support for Filter Flags such as IP Address, Protocol, etc

[jamescussen]

netsh comes with quite a few filter flags when capturing the ETL file. I have noticed when using these filters that the resultant pcapng file has packets missing when comparing directly to wireshark capturing on the same interface (with the same filter).

Example filter:
netsh trace start capture=yes report=disabled tracefile=".\NetTrace.etl" persistent=no Protocol=17 Ethernet.Type=IPv4

This should capture all IPv4 UDP traffic, however, once I convert the file using etl2pcapng there are many packets missing. I have found this also using IP Address filters using the IPv4.Address flag. When using IPv4.SourceAddress or IPv4.DestinationAddress I don't seem to get any output in the pcapng file.

Are these filters supposed to work with etl2pcapng?

[maolson-msft]

Hi, first question: how do you know that packets are missing in the pcapng file?

Second question: how do you know that the packets are NOT missing in the original ETL file (which seems to be implied by your issue description)?

[jamescussen]

Hi, If I open the pcapng file with Wireshark the packets are not displayed. So I assume they are not in the file.

I don't know that the packets are not missing in the ETL file. I have made an assumption that netsh works correctly as it's been around for a long time. I would have liked to open up the ETL in message analyser, however, it's not available anymore and has been replaced with this project :)

[dgcom]

To verify if original ETL file has packets you are missing in the converted output, you can use two tools:

• UI tool for ETL - microsoft/perfview: PerfView is a CPU and memory performance-analysis tool
• tracerpt | Microsoft Docs - you can convert ETL data to CSV

[jamescussen]

Thanks, I was able to open the ETL with perfview and it looks like the packets are also missing in the ETL file. It appears that the netsh filters don't behave as expected.

[maolson-msft]

@jamescussen, thanks for checking! I'm on the team at Microsoft that maintains the netsh filters too, so I'm still interested in your issue. We might as well keep discussing here to keep it simple.

Now my next question is: which specific packets are missing in the ETL file, and how do you know they were sent? Do you have a packet capture on the device that they were sent to that recorded the packets?

[jamescussen]

Great, thanks. I looked into this further to see if it wasn't just something to do with my laptop. I tried testing the same filter across three machines. Two of the machines were laptops running Windows 10 and the other a desktop using Windows 11. I used the same filter on each machine:

netsh trace start capture=yes report=disabled tracefile=".\NetTrace.etl" persistent=no IPv4.Address="10.0.0.1" Ethernet.Type=IPv4

I ran a Wireshark capture on the interface also with a filter:

ip.addr == 10.0.0.1

From here I pinged 10.0.0.1 and did a nslookup (10.0.0.1 is the DNS server).

The outcome on the Windows 10 laptops was the same: Most of the inbound return packets were missing from the ETL capture. However, on the Windows 11 machine it worked fine. From this I conclude that the issue must be Windows 10 specific and may well have been fixed in Windows 11 at some point. Hopefully, this gives you enough information to reproduce on Windows 10.

[maolson-msft]

@jamescussen, you still haven't told me which exact packets are missing from the capture. You mentioned ping and nslookup, so was it ICMP packets that were missing? DNS responses from the DNS server?

[jamescussen]

In this case, all the response packets coming back from 10.0.0.1 were missing. I have attached an example of the Wireshark and etl2pcapng outputs for you to compare.

Capture Comparison.zip