Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
NPCAP 0.99-r7 capture filter incorrectly ignores egress traffic when filtering on packet contents #1438
OS: Windows 10 Pro, version 1803, build 17134.556
When capturing traffic with Wireshark (with NPCAP 0.99-r7 installed as a dependency) while utilizing a capture filter that filters based upon packet data, egress traffic sourced from the local machine that should pass through the filter without issue does not pass through the filter. When capturing traffic without a capture filter that filters based upon packet data, egress traffic sourced from the local machine appears without issue.
An example of a capture filter that filters based upon packet data is as follows:
In the compressed file attached to the bottom of this issue are two PCAPs captured on my computer (IP of 192.168.10.50):
Both PCAP files result from captures taken at close to the exact same time. For reference, the first packet in "broken_udp" is the 217th packet in "working_udp" (almost exactly the same arrival time and epoch timestamp, and the rest of the packet is identical.) As you can see, all of the traffic in "broken_udp" is destined to my computer at 192.168.10.50, while "working_udp" has a considerable amount of traffic sourced from 192.168.10.50 that does not show up in "broken_udp".
One example of a packet in "working_udp" that should have been captured in "broken_udp" is packet 219 in "working_udp" (source 192.168.10.50, destination 18.104.22.168). The Message Type field in the STUN header has a value of 0x0001, which should be matched by the
These PCAPs demonstrate the current behavior with UDP, but I was able to reproduce the same behavior with a TCP capture filter as well. If you use the capture filter
Expected behavior is for a capture filter that filters based upon data within the packet itself to capture traffic in both ingress and egress directions.
I believe this is an issue with NPCAP 0.99-r7/r8 because this issue did not exist when WinPCAP v4.1.3 was installed on my computer. @vaindil originally encountered this issue when he was running NPCAP 0.99-r7, and we were puzzled over how the same capture filter yielded different results on our different computers. The biggest relevant difference between our machines was that he was using NPCAP, while I was using WinPCAP. When I uninstalled WinPCAP and NPCAP 0.99-r7, I was able to reproduce this issue.
A DiagReport is also included in the compressed file uploaded to the bottom of this issue.
Please let me know if you need any additional information about this issue!
To clarify what is happening, can you tell me whether the traffic appears to be being blocked by Npcap with the capture filter, or whether it is not captured when you expect it should be? In other words, does Npcap appear to be interfering with traffic flow, or only incorrectly displaying it?
Great, thanks. That sounds like a separate problem, then. A few followup questions:
@dmiller-nmap I tested with
@guyharris I do not believe this is connected with #1406. When constantly pinging a host on the same subnet as myself, I am able to capture both ingress and egress traffic with a capture-filter of
So the one consistency I see here is that when the offset is within the same header as the protocol symbol it starts from, the capture succeeds. The failures happen when you offset from the beginning of the IP header into the data or from the beginning of the UDP header into the data. So I'm guessing there may be some fragmentation in the kernel ring buffer that is accounted for when delivering the packets, but not when applying a capture filter. I will investigate this.
Meanwhile, I would suggest the following workaround: use the most-specific capture filter you can that does not reference the data within the UDP datagram (e.g. "udp") and then use a display filter to further refine what packets are shown. This is not ideal, I know, and we will do our best to see what can be done to fix it.
referenced this issue
Jan 29, 2019
That was my suspicion as well.