All:

I was trying to use libpcap on BSDi to capture packets on a network
with extremely low traffic -- like one packet per minute.

The timeout on pcap_open_live() didn't seem to do the trick -- I
wasn't seeing the packets until maybe an hour had passed, then I'd
get a bunch.

So I put the BPF into immediate mode with:

        if (ioctl(p->fd, BIOCIMMEDIATE, &v) < 0) {
                snprintf(ebuf, PCAP_ERRBUF_SIZE, "BIOCIMMEDIATE: %s",
                    pcap_strerror(errno));
                goto bad;
        }

That sorta did the trick, and packets now come up immediately from the
BPF.  The problem is, the packet buffers sent up aren't padded to a
multiple of 4 bytes like the following [abbreviated for consiseness]
pcap-bpf.c pcap_read() code requires...

pcap_read(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
{
        int cc;
        int n = 0;
        register u_char *bp, *ep;

 again:
        cc = p->cc;
        if (p->cc == 0) {
                cc = read(p->fd, (char *)p->buffer, p->bufsize);
                [snip]
                bp = p->buffer;
        } else
                bp = p->bp;

        #define bhp ((struct bpf_hdr *)bp)
        ep = bp + cc;
        while (bp < ep) {
                register int caplen, hdrlen;
                caplen = bhp->bh_caplen;
                hdrlen = bhp->bh_hdrlen;
                (*callback)(user, (struct pcap_pkthdr*)bp, bp + hdrlen);
                bp += BPF_WORDALIGN(caplen + hdrlen);
                if (++n >= cnt && cnt > 0) {
                        p->bp = bp;
                        p->cc = ep - bp;
                        return (n);
                }
        }
        p->cc = 0;
        return (n);
}

The result of this is that if the packets on the wire are not a
multiple of 4 bytes long(say, 90 bytes long), then the first packet
received works fine, but leaves "p->cc" set at -2.  This means that
the above code will not issue a read for the second packet!  A hack
fix is to change the above code so that if p->cc ever becomes less
than 0, then clamp it at 0.

My question is: would you folks consider this a bug with the BSDi
kernel BPF code, or a bug with the pcap-bpf.c code?  What would be
considered a "proper" fix for this problem?

CC'ing me on any replies would be appreciated, as I am not a regular
member of this list.

-Rick


-- 
Rick Richardson  [EMAIL PROTECTED]      http://home.mn.rr.com/richardsons/
Twins Cities traffic animations are at http://members.nbci.com/tctraffic/

Toyota and Honda are smarter than GM, OPEC, and SUV buyers.  Hybrid
and fuel cell vehicles will be in high demand very shortly.  Order
yours now and laugh at the pumps next summer.

-
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