Thanks Guy, I like the idea of it being a published interface.
What are the ramifications of not ever calling pcap_setfilter? Since I'm looking at a plugin to a main program, I don't know if there will be a call to pcap_setfilter... I'd jsut want to call bpf_filter with the packet that snort hands me and the precompiled expression. Mark On Wednesday 24 October 2001 03:55 pm, Guy Harris wrote: > > I'd like to call bpf_filter() directly with a pre- pcap_compile(d) > > expression in some code that I'm working on. My question isn't whether > > it's possible, because I've successfully tested it, but whether it's safe > > to do so. Any chance the syntax for it will change? Any reason not to do > > what I'm suggesting? Is calling bpf_filter directly portable? > > libpcap is probably not necessarily going to be the only user of BPF > filters in userland - there was some recent mail on one of the Ethereal > mailing lists, asking for a way to have triggers to start and stop > captures, and the first scheme that comes to my mind for triggers is > packet filter expressions - so I think it might be a good idea to have > "bpf_filter()" be a published interface of libpcap. > > There is one tricky bit - currently, the code in libpcap to handle > platforms with BPF assumes that there's a global variable, set by the > BPF code generator, to indicate code generated to chase protocol chains > in IPv6 is present; the comment in "pcap-bpf.c" says > > /* > * It looks that BPF code generated by gen_protochain() is not > * compatible with some of kernel BPF code (for example BSD/OS 3.1). > * Take a safer side for now. > */ > > which means that if you compile more than one filter expression before > calling "pcap_setfilter()", you should compile the one being handed to > "pcap_setfilter()" *last*. > > We may be able to handle that by documenting that requirement. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
