Snaplen requires BPF filter to be applied

[dmiller-nmap]

Inherited problem from WinPcap: snaplen is implemented as a modification to BPF filter in pcap_compile(), which means that the only way to have it work is to follow this procedure (as pcap_open_live() does internally):

1. Set snaplen with pcap_set_snaplen()
2. Compile any filter, even "" empty string with pcap_compile()
3. Set that BPF filter with pcap_setfilter()

Doing this in any other order will not work.

Solution: we need to implement a snaplen set operation, probably as a new IoControl code, and expose it via the existing PacketSetSnapLen() function. Then libpcap has to call PacketSetSnapLen() in the appropriate places, which it currently only does for DAG cards. This would be fine for them to do even with backwards compatibility in mind, since on non-DAG adapters, PacketSetSnapLen() has historically been a no-op.

[guyharris]

pcap-bpf.c initially sets an "accept all" filter in the activate routine, so if no filter is explicitly set with pcap_setfilter(), there's still a filter that causes packets to be trimmed off at the snapshot length.

pcap-npf.c could do the same.

(And I should check to make sure pcap-linux.c does the same for memory-mapped capture, if that's the only way the snapshot length gets passed to the kernel.)

[dmiller-nmap]

@guyharris I thought of this, but I kept running into difficulties, primarily this one:

It doesn't appear there's anything preventing pcap_setfilter() from being called prior to pcap_activate(), which means the "accept all" filter would clobber the other one. On the other hand, I'm guessing doing this means that the call to PacketSetBpf() in pcap_setfilter_npf() is done when p->adapter == NULL, which would fail, leading to install_bpf_program() being called, and filtering being done in userland. I think this is not a code path that should be open.

[guyharris]

@guyharris I thought of this, but I kept running into difficulties, primarily this one:

It doesn't appear there's anything preventing pcap_setfilter() from being called prior to pcap_activate(),

There is.

The setfilter_op pointer, which pcap_setfilter() calls through, is initially set to pcap_setfilter_not_initialized(), which just returns an error of "not activated". Only after the pcap_t is activated is it set to the module's "set filter" routine.

(Note that, if it could get to the module before the pcap_t is activated, that would be an issue for pcap-bpf.c as well.)

[dmiller-nmap]

We will cherry-pick the-tcpdump-group/libpcap@6c893c13 to nmap/libpcap's wpcap-1.9 branch for the next release and mark this issue resolved in our changelog. Thanks for the help!

[guyharris]

We will cherry-pick the-tcpdump-group/libpcap@6c893c1 to nmap/libpcap's wpcap-1.9 branch for the next release and mark this issue resolved in our changelog. Thanks for the help!

That, and 141253c471119db0761d73c2fc095b82a2017eb3, are commits to a test program, to allow the test program not to set the snapshot length and not to set the filter; I made them in order to be able to test the change I'm proposing to pcap-npf.c. I'll test the latter change today and, if it works, check it in; that will be what you'll want to cherry-pick to get the bug fixed.

[guyharris]

Oops, that commit checked in my "add a filter when activating" change before it was tested - it doesn't compile. It was intended to check in only a fix to the test program; I've backed out the pcap-npf.c change. I'll get it fixed and check it in later.

[guyharris]

OK, that's the commit you want - the-tcpdump-group/libpcap@a0a9c27. (I had to hammer on libpcap a bit - AppVeyor must have installed a new version of VS 2019, because a bunch of switch-statement warnings started popping up and, as we're building with /WX, the build failed - because I wanted the build to succeed before I signed off on the commit.)

[guyharris]

This is fixed now, right?

[dmiller-nmap]

Yes, I just promised my family an early start to the weekend if I got the Npcap release out, so I haven't had time to go through the issues and close them.

…

On Sat, Jul 11, 2020, 3:27 AM Guy Harris ***@***.***> wrote: This is fixed now, right? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#201 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPVSFONMRBCY3HA3TSHOZTR3AO7TANCNFSM4OPJVQIA> .

[dmiller-nmap]

This issue is fixed in Npcap 0.9995 by backporting an unreleased changed from upstream libpcap.