Re: AIX BPF driver load

[Shaun <delius () progsoc uts edu au>]

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:tcpdump-workers-request () tcpdump org?body=unsubscribe

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe