tcpdump mailing list archives
Re: AIX BPF driver load
From: Shaun <delius () progsoc uts edu au>
Date: Fri, 7 Feb 2003 17:10:50 +1100 (EST)
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 programsWhat 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
Current thread:
- AIX BPF driver load Shaun (Feb 05)
- Re: AIX BPF driver load Guy Harris (Feb 05)
- Re: AIX BPF driver load Guy Harris (Feb 05)
- <Possible follow-ups>
- Re: AIX BPF driver load Guy Harris (Feb 06)
- Re: AIX BPF driver load Shaun (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 06)
- Re: AIX BPF driver load Shaun (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 07)
- Re: AIX BPF driver load Shaun (Feb 09)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Shaun (Feb 10)
- Re: AIX BPF driver load Guy Harris (Feb 10)
- Re: AIX BPF driver load Shaun (Feb 06)
- Re: AIX BPF driver load Guy Harris (Feb 05)