NPCAP 0.99-r7 capture filter incorrectly ignores egress traffic when filtering on packet contents

[ChristopherJHart]

Version Information

OS: Windows 10 Pro, version 1803, build 17134.556
NPCAP: 0.99-r7, tested and confirmed on 0.99-r8 as well

Current Behavior

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:

udp[8:2] & 0xf = 1

In the compressed file attached to the bottom of this issue are two PCAPs captured on my computer (IP of 192.168.10.50):

• npcap_broken_udp_capture_filter_with_data_filter.pcapng - Hereafter called "broken_udp", this capture utilized the above capture filter udp[8:2] & 0xf = 1
• npcap_working_udp_capture_filter.pcapng - Hereafter called "working_udp", this capture utilized udp as a capture filter

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 69.47.158.237). The Message Type field in the STUN header has a value of 0x0001, which should be matched by the udp[8:2] & 0xf = 1 capture filter. However, this packet does not appear in the "broken_udp" PCAP.

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 tcp[32:2] & 0xf = 1, only traffic that ingresses the machine will be displayed. Utilizing bit masks is not necessary to reproduce the behavior, either - I attempted to use a capture filter of udp[8:2]==0x0001 and encountered the current behavior as well.

Expected Behavior

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.

Additional Troubleshooting

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!

npcap_issue.zip

[dmiller-nmap]

Thanks for this very thorough bug report! I believe this may be related to nmap/nmap#1424, so I am hopeful we can fix both issues at once. Thanks for your patience.

[dmiller-nmap]

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?

[ChristopherJHart]

Based upon the tests I was doing, the traffic appeared to be not captured by NPCAP when I expect that it should be. NPCAP does not appear to be interfering with the traffic flow, only incorrectly displaying it.

[dmiller-nmap]

Great, thanks. That sounds like a separate problem, then. A few followup questions:

• Does it only happen when you use byte offsets like [8:2] or does it also happen with symbolic offsets or filters like tcp or host 192.168.10.50?
• Does it only affect filters that specify offsets into the transport layer header, or do offsets like ip[9]=17 (IP protocol field is UDP) work?

[guyharris]

BTW, is this connected with issue nmap/nmap#1406?

[ChristopherJHart]

@dmiller-nmap I tested with udp and host 192.168.10.50 and captured bidirectional traffic without an issue. I also tested with ip[9]=17 and was able to capture bidirectional traffic as well. However, ip[28:2]=0x1 only captured ingress traffic, no egress traffic at all. Interestingly enough, ip[28:2] & 0xf = 1 will occasionally catch egress TCP traffic.

@guyharris I do not believe this is connected with nmap/nmap#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 not (icmp[0]=3) and display-filter of icmp.

[dmiller-nmap]

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.

[guyharris]

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.

That was my suspicion as well.

That might be the cause of nmap/nmap#1406 as well, although I'm guessing from the description that the packets not matching the filter in nmap/nmap#1406 are incoming packets rather than outgoing packets.

[dmiller-nmap]

As I noted on nmap/nmap#1406, the issue is most likely not fragmentation in the kernel ring buffer but in the packet data as represented by non-contiguous MDLs when delivered to Npcap. I'm pretty confident that the fix will be the same for both of these issues.

[dmiller-nmap]

We believe this issue was fixed in Npcap 0.991. @ChristopherJHart can you upgrade and confirm whether the issue is fixed?

[pavemina]

Hello, I seem to have a similar issue.
Win10 Pro, Version 1809, build 17763.379
Npcap version 0.991

When using Wireshark (or tshark in CLI), capture filter works for example with "icmp" but not with e.g. RADIUS or HTTP ("port 1812" or "port 80") => egress packets are not shown, only ingress. (I did not test other ports/protocols)

On the other hand when I start the capture with no filter, and filter after capture on the results, I can see the egress packets.

Issue is the same even with version 0.98. I also tried the WinPcap compatibility-mode install with 0.991, without improvement. Same as ChristopherJHart, I did not use to have the problem when WinPcap was used.

If there's any debugs that would be useful to gather, please let me know.

[vaindil]

I was working with @ChristopherJHart on the original problem. I installed 0.991 and the problem has not been resolved. I still only get incoming traffic with the capture filter given in the OP, no outgoing traffic.

[dmiller-nmap]

There was a problem with the fix to nmap/nmap#1406 in Npcap 0.991 which was reported separately as nmap/nmap#1525. This was resolved in Npcap 0.992. I am closing this issue as fixed. If there are any new reports of packets not being matched by the BPF filter, please open a new issue. Thanks!