Userspace filter drops all packets for DLT_LINUX_SLL

[guyharris]

Converted from SourceForge issue 3602873, submitted by None

When the kernel filter is turned off (e.g. by commenting it out as in the attached patch), and a filter is set, all packets are dropped. An example program is also attached.

0001-Disable-kernel-filter.patch userspacefilterissue.c.txt (really just userspacefilterissue.c, but GitHub is silly and doesn't accept "files of that type", as in "source code files", so we lie and give it an extra .txt)

[guyharris]

Submitted by guy_harris

(FYI - #if 0/#endif is a bit more convenient way to remove code.)

[guyharris]

Submitted by guy_harris

Works on eth0, doesn't work on the "any" device (which is what you get on Linux when you pass NULL as the device name; NULL might crash on other platforms, while "any" will return an error, so it's the better choice).

The problem is that, on devices were capturing is done in cooked mode, either the filter has to be run after the fake header is added to the packet, or has to be left in unmodified form, with bpf_filter() handling the "special" fields by looking in the metadata for the packet, just as is done in the kernel.

[guyharris]

Submitted by None

Interesting. Using a specific interface such as "eth0" solves the problem. I see, so in "any" mode, will raw+tp_mac point to meta-data when bpf_filter expects a data link layer (e.g. ethernet)?

I don't use userspace filters, but I ran into this problem because the userspace filter is applied on the packets that were on the ring before the kernel filter was applied (and it can apply the userspace filter even to packets that only arrived in the ring after the kernel filter was applied, because use_bpf = 1 + N, where N is an upper bound on the number of packets, instead of the exact number of packets).

I don't think it's worth it to change bpf_filter to handle the "special" fields to look for metadata, but instead the fake header should be added before bpf_filter is called. If a userspace filter isn't used, it doesn't make a difference. If a userspace filter is indeed used, it would make it work, right? In all the other cases (not using a cooked interface), that step would simply be skipped.

[guyharris]

Submitted by None

By the way, I found this while investigating this other bug:

#169

so they are directly related :)