Re: [PATCH next v3] iptables: add xt_bpf match

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Tue, Jan 22, 2013 at 10:46:17AM +0100, Jozsef Kadlecsik wrote:
> On Tue, 22 Jan 2013, Florian Westphal wrote:
> 
> > Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > On Fri, Jan 18, 2013 at 11:48:34AM -0500, Willem de Bruijn wrote:
> > > [...]
> > > > To compile code right now, the little bpf compiler that I emailed
> > > > before can be downloaded from
> > > > http://code.google.com/p/kernel/downloads/detail?name=bpf2decimal.c
> > > > 
> > > > I don't think that a compiler has to be shipped with iptables itself,
> > > > let alone make iptables link against libraries. That said,  it is not
> > > > impossible to detect pcap.h in configure.ac and optionally enable a
> > > > "-m bpf --string" mode that calls pcap_compile_nopcap from within
> > > > libxt_bpf, so let me know if you would like me to code that up. I can
> > > > also try to send a patch to tcpdump that extends compilation (`-ddd -y
> > > > <type>`) to arbitrary link layer types.
> > > 
> > > We have to decide if:
> > > 
> > > a) we add a new hard library dependency to iptables (libpcap) for just
> > > for one single module, that is, the libxt_bpf depends on libpcap.
> > > 
> > > or
> > > 
> > > b) provide a separate utility to generate the BPF filter in text-based
> > > format from some utility that accepts tcpdump-like syntax. The utility
> > > can be distributed in the utils directory and it would not be
> > > mandatory to compile it if libpcap is not present.
> > > 
> > > I'd like to hear pro and cons arguments from others on this.
> > 
> > a) is arguably more user friendly, however, I don't think we can
> >    retain the 'text representation' for iptables-save so users
> >    would still be confronted with the compiled data at some point
> >    (i.e., they need to write down the original expression anyway to
> >     figure out what the rule they added 6 months back actually does...)
> > 
> > I would go with b) for now; we can always move to a) later on, but not
> > the other way around (would kill backwards compatibility).
> 
> Yes, let's go with b). (But from packaging point of view 
> utils/bpf2decimal.c depending on libpcap is not much different from 
> extensions/libxt_bpf.c depending on libpcap.)

We can skip that dependency by adding an independent configure.ac and
Makefile for this under iptables/utils/nfbpf. Thus, iptables itself
will not depend on libpcap.