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:[EMAIL PROTECTED]?body=unsubscribe
