On Thu, 6 Feb 2003, Guy Harris wrote:
> (Forwarding this to tcpdump-workers, as somebody else might have > something to say about this. > > The "working code" is code to load up the BPF driver and make the "/dev" > entries if necessary; AIX 5.x's libpcap presumably does that, and AIX > 4.x's tcpdump definitely does that.) > > On Fri, Feb 07, 2003 at 01:51:55PM +1100, Shaun wrote: > > I have working code for AIX (both 4.3* and 5.*) but I need a struct from > > the real system /usr/include/net/bpf.h, is there a reason pcap includes > > it's own and names it net/bpf.h? > > Because: > > on platforms that don't have BPF, it's necessary, as there's no > <net/bpf.h> to include in order to get "struct bpf_insn" and > "struct bpf_program" defined; > > on platforms that do have BPF, there *might* be an issue of > structures for the libpcap BPF interpreter (required when > reading saved capture files) vs. structures for the kernel's BPF > interpreter, and because nobody bothered to make the configure > script distinguish between those two cases. > > > Worse, why does the install step proceed to clobber the system ones? > > For the same reason. > > > I'm sure it's for a reason, I'm just wondering how I can get around it for > > my purposes. > > The right thing to do is *probably* to: > > have the code generator files include the one that comes with > libpcap; > > have "pcap-bpf.c" include the one that comes with the system. > > Currently, of those systems with BPF interpreters in the kernel: > > Linux's SO_ATTACH_FILTER "setsockopt()" call takes a pointer to > a structure that differs from "struct bpf_program" - but, > fortunately, it has a different name, so there's no collision, > and, equally fortunately, the instructions are binary-compatible > so it doesn't matter whether the program is an array of "struct > bpf_insn" or what; > > the BSDs I know of, Digital UNIX, and AIX 4.3 have "struct > bpf_program" and "struct bpf_insn" structures that are the same > as they are in libpcap (I suspect the same is true of 5.x - > Shaun, is that the case?); > > so there is currently no problem with using libpcap's "struct > bpf_program" and "struct bpf_insn" when generating the code. > > In addition, the actual BPF machine language is the same, modulo some > special Linux hacks for getting at information used to generate the > "cooked" packet header (which we handle by tweaking BPF instructions as > necessary if we're going to hand the BPF program to the kernel) and > modulo stuff *added* to BPF by BSD/OS (which we currently don't use). > > So that way of handling includes *should* be safe. > > However, given that "pcap.h" includes <net/bpf.h>, it's hard to do. > > I would suggest that we rename *our* <net/bpf.h> to "pcap-bpf.h", and > install it along with "pcap-namedb.h", and have "pcap.h" include it - > but only if some special #define, e.g. "PCAP_DONT_INCLUDE_PCAP_BPF_H" - > isn't defined. > > Then, we'd have "pcap-bpf.c" #define that before including "pcap.h", and > instead #include <net/bpf.h> itself. (We could make "pcap.h" include > <net/bpf.h> if it's defined, but I fear that might encourage users to > #define it in their applications, which is not what we'd want them to > do, as that means they would, for example, get the native OS's list of > DLT_ values, which wouldn't necessarily include all the values that > would show up in captures from other platforms.) > > This is all somewhat ugly, but I'm not sure there's a good solution that > doesn't involve breaking APIs (such as having the libpcap APIs use > libpcap-defined data structures instead of "struct bpf_program" and > "struct bpf_insn"). > - > 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 > - 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
