On Tue, Jan 22, 2013 at 3:46 AM, Florian Westphal <fw@xxxxxxxxx> wrote: > Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> 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). This sounds like the consensus (for the record, I also prefer this less disruptive approach). In that case, I can submit a revised libxt_bpf with your suggested changes right away, Pablo, and we can leave the separate userspace tool for a later commit. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
