Bill Fenner <fen...@gmail.com> wrote:
> I have a little program that basically calls pcap_open_dead(),
> pcap_compile(), and then dumps the instructions like a C struct, so
> that we can include a bpf program in some other code that will use it
> later. (Like "tcpdump -dd", but with a little extra formatting.)
Sounds like something that might go into libpcap as a subdirectory, like
rpcapd, and could be used with libpcap/tests too.
Should it do a JSON mode perhaps?
> We may know that we will be using this code on a kernel that requires
> BPF_SPECIAL_VLAN_HANDLING, and so I'd like to be able to set that flag
> on a "dead" handle. Obviously, the current mechanism is to test this
> dynamically when the handle is live.
Oh, yes. Hmm.
Will you perhaps also want eBPF stuff too? (which we haven't got).
> Does anyone have any opinions about how to implement this, through the
> generic pcap interface? I can think of two possibilities:
> 1. implement set_special_vlan_handling_op, and have it implemented by
> dead and linux, and have the default version return an error
> 2. implement set_bpf_codegen_flags_op, and have a generic
> implementation, assuming that the caller completely knows what they are
> doing. Then move the definition of BPF_SPECIAL_VLAN_HANDLING from
> pcap-int.h to the public header.
#2 sounds better to me.
In general, it seems to me like we ought to specify some kind of target BPF
processor option. As you say, pcap mostly just adapts itself to the current
kernel, and the dead version has no options.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
