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

[Florian Westphal <fw@strlen.de>]

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).