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 #1438

Open
ChristopherJHart opened this Issue Jan 21, 2019 · 8 comments

Comments

Projects
None yet
3 participants
@ChristopherJHart
Copy link

ChristopherJHart commented Jan 21, 2019

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

This comment has been minimized.

Copy link

dmiller-nmap commented Jan 24, 2019

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

@dmiller-nmap

This comment has been minimized.

Copy link

dmiller-nmap commented Jan 24, 2019

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

This comment has been minimized.

Copy link
Author

ChristopherJHart commented Jan 24, 2019

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

This comment has been minimized.

Copy link

dmiller-nmap commented Jan 24, 2019

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

This comment has been minimized.

Copy link

guyharris commented Jan 25, 2019

BTW, is this connected with issue #1406?

@ChristopherJHart

This comment has been minimized.

Copy link
Author

ChristopherJHart commented Jan 25, 2019

@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 #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

This comment has been minimized.

Copy link

dmiller-nmap commented Jan 28, 2019

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

This comment has been minimized.

Copy link

guyharris commented Jan 29, 2019

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 #1406 as well, although I'm guessing from the description that the packets not matching the filter in #1406 are incoming packets rather than outgoing packets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment