Re: AIX BPF driver load

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

Sorry about earlier email, mis-send

> > 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.
>
> "bpf_open()", or "pcap_open_live()"?

bpf_open.... the logic used in the IBM implementation is:

static inline int
bpf_open(pcap_t *p, char *errbuf)
{
   int fd;
   int n = 0;
   char device[sizeof "/dev/bpf0000000000"];

#ifdef _AIX
   /*
    * Load the bpf driver, if it isn't already loaded
    */
   if (bpf_load() == -1)
   {
      snprintf(errbuf, PCAP_ERRBUF_SIZE, "bpf_load: kernel load failure:
%s",
               device, pcap_strerror(errno));
      return(-1);
   }
#endif

Where bpf_load() checks a flag to see if it has already been loaded or
otherwise proceeds to load the module. I have it all working but will need
to clean up my code a bit before submitting it, so I'll send it after the
weekend.

> > >   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
>
> What does it do for 64-bit userland programs?  As I remember from
> diffing the libpcap bpf.h and the AIX 4.3 bpf.h, it looks as if they use
> the same types in "bpf_program" and "bpf_insn", i.e.  they use u_int for
> "bf_len" in "bpf_program", and use a combination of "u_short", "u_char",
> and "bpf_int32" in "bpf_insn" - and "bpf_int32" is typedeffed to "int".
> Are "u_char" 8 bits, "u_short 16 bits", and "int" and "u_int" 32 bits
> for 64-bit programs?

Yeah, pretty much, I'm not sure if there is a real problem here but output
from the diff shows the following (Where the right hand side is the AIX
version, from 5.1)

151,152c173,174
<       bpf_u_int32     bh_caplen;      /* length of captured portion */
<       bpf_u_int32     bh_datalen;     /* original length of packet */
---
>       u_long          bh_caplen;      /* length of captured portion */
>       u_long          bh_datalen;     /* original length of packet */

So the bpf_hdr struct is now different in 64 bit, but also the new

/*
 * Structure prepended to each packet.
 */
struct bpf_hdr32 {
   struct timeval32 bh_tstamp;   /* time stamp */
   u_int    bh_caplen;  /* length of captured portion */
   u_int    bh_datalen; /* original length of packet */
   u_short     bh_hdrlen;  /* length of bpf header (this struct
                  plus alignment padding) */
};


has been added.

So I'm not sure if this will actually have any effect (i.e if the AIX
implementation will "just work" with the 64 bit sized version) or if I
should force use of the 32 bit version with a #define.

Sorry to sound so ignorant here, I'm not that familiar with the innards
and side-effects of bpf.

Thanks,
Shaun



-
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