[Bug 1048] xt_bpf completely broken with kernel 4.3

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1048

--- Comment #3 from Daniel Borkmann <daniel at iogearbox.net> ---
(In reply to blaffablaffa from comment #2)
> It turns out that the problem is indeed the different 0 offset that xt_bpf
> and tcpdump use. In particular, it appears that offset 0 in tcpdump is at
> the very beginning of the packet (ethernet header included) whereas xt_bpf
> uses the beginning of the IP header. I've spoken with the author of the
> module, and he is probably going to just point this out more clearly in the
> man pages.

Right, what you can also try to do is to add SKF_LL_OFF or SKF_NET_OFF offset
to you load offsets in the K constant. It would require to use something like
bpf_asm to write your filters by hand.

F.e. if you look at bpf_internal_load_pointer_neg_helper() helper function in
the kernel, they check for SKF_NET_OFF/SKF_LL_OFF and then use K relative to
skb_network_header(skb) or skb_mac_header(skb), respectively. This should
resolve your use-case.

The problem is that with libpcap, the filters are generated for tcpdump
specifically, and tcpdump doesn't need to care about SKF_NET_OFF/SKF_LL_OFF as
it sees raw packet starting with Ethernet header. So, reusing libpcap is a bit
suboptimal, but perhaps the nfbpf_compile tool could be changed into rewriting
the offsets so it would work with iptables in all cases.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20160219/2bbf6812/attachment.html>