> 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.)

AIX 4.33 doesn't ship with a libpcap but the version compiled into
tcpdump does indeed load the driver and construct the necessary /dev
entries. The AIX 5.1 version of libpcap automatically loads the driver and
constructs the /dev entries as necessary when bpf_open is called.

> > 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;

Ok, I suspected it'd be something like that.

> > 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.

Sounds like a plan to me.

>       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?);

Yep, at least for 32 bit userland programs

> so there is currently no problem with using libpcap's "struct
> bpf_program" and "struct bpf_insn" when generating the code.

True, the version of pcap I have running can use filters just fine.

> 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").

That all sounds like a good solution to me. If you like I'll generate the
patches and send them over when the list reaches an agreement this
approach is acceptable.

Cheers,
Shaun


-
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

Reply via email to