On Wed, Feb 27, 2002 at 07:34:05PM -0500, Ebright, Don wrote:
> 1. The DLPI support (bos.rte.tty 4.3.3.75) on my test system must be
> broken, because I get these error messages attempting to enter promiscuous
> mode:
>
> WARNING: DL_PROMISC_MULTI failed (recv_ack: promisc_multi: Primitive issued
> in improper state)
> WARNING: DL_PROMISC_SAP failed (recv_ack: promisc_sap: Primitive issued in
> improper state)
> tcpdump: WARNING: recv_ack: promisc_sap: Primitive issued in improper state
> tcpdump: listening on en0
Lovely. I'm curious whether it's always had this problem, or if it only
happens on some AIX releases, or if some change we made caused it to
start happening.
I'd have to go read the AIX DLPI documentation (the online version at
http://publib.boulder.ibm.com/cgi-bin/ds_form?lang=en_US
) to see what the problem might be.
> Running tcpdump 3.6.2 on this system gives me warning messages similar to
> the first two, but without the text decode of the 0x03 response code.
Yeah, I put the text decode in after 3.6.2 was released.
> 2. There is a lot of good news regarding the libpcap BPF support for AIX.
> It compiles, the timestamps appear to be OK, the IP address filtering works
> OK, so I presume that the ethernet linktype is being recognized correctly,
> and it runs for a while. The bad news is that it fails after a few packets
> with the message:
>
> tcpdump: pcap_loop: read: Bad address
>
> I presume that this message is generated at line 129 of pcap-bpf.c when the
> read returns errno 14 (EFAULT). This would seem to indicate a buffer
> handling problem somewhere.
That's odd, as the "read()" passes "p->buffer" as the argument, and,
unless something's scribbling on the "pcap_t" structure (which would be
a bug), "p->buffer" always refers to the buffer allocated when the
device was opened.
It might be interesting to put in:
errno = 0;
before the "read()" call;
fprintf(stderr, "buf %p, count %d, errno %d\n",
p->buffer, p->bufsize, errno);
after the "if (cc < 0)";
and see
1) whether "errno" is still EFAULT;
2) what the buffer address and count are;
when the EFAULT is returned.
> 3.
> I haven't looked very far into either of the previous problems, but I did
> track down an issue which prevented the libpcap BPF support from ever
> starting in a multithreaded environment. On my system, at least, the
> largest bpf device buffer size that succeeds is 16K, and the BIOCSETIF ioctl
> on line 253 of pcap-bpf.c consistently fails with errno zero instead of
> ENOBUFS when called by my threaded program. It properly returns ENOBUFS
> when called by a non-theaded program such as tcpdump. This appears to be an
> AIX bug, but I worked around it by changing line 256 from:
> if (errno != ENOBUFS) {
> to
> if (errno && (errno != ENOBUFS)) {
>
> I don't know that this situation warrants a "fix" since it is clearly an AIX
> problem,
Yeah, they might have a per-thread errno that they're not handling
correctly in their treading code.
> but someone else who wants to use libpcap in a threaded environment
> on AIX may benefit from this workaround if the problem is widespread.
Yup, that's probably a reasonable workaround.
> 4.
> If anyone is interested in token-ring, I intend to try that next week if
> time permits. That should be interesting.
Yes, I'd be curious to see how well it works with both DLPI and BPF.
-
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
