New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NPCAP 0.99-r7 capture filter incorrectly ignores egress traffic when filtering on packet contents #68
Comments
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. |
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? |
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. |
Great, thanks. That sounds like a separate problem, then. A few followup questions:
|
BTW, is this connected with issue nmap/nmap#1406? |
@dmiller-nmap I tested with @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 |
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. |
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. |
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. |
We believe this issue was fixed in Npcap 0.991. @ChristopherJHart can you upgrade and confirm whether the issue is fixed? |
Hello, I seem to have a similar issue. 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. |
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. |
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! |
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:
In the compressed file attached to the bottom of this issue are two PCAPs captured on my computer (IP of 192.168.10.50):
udp[8:2] & 0xf = 1
udp
as a capture filterBoth 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 ofudp[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
The text was updated successfully, but these errors were encountered: