Re: Strange behavior of pcap filter

[Guy Harris <guy () alum mit edu>]

On Apr 6, 2006, at 2:22 PM, J S wrote:

> I am developing an active monitoring system, which implements pcap  
> filter.

What do you mean by "implements pcap filter"?

> The requirement is to send probes with a high monitoring rate e.g.  
> 40 msec
> and the probe packets have data of 12 bytes. For each packet sent  
> by the
> sender the recipient sends a reply packet.

What protocol stack is being used for these probes?  Is the recipient  
using libpcap to receive the packets?

> I initially started with 10 probe packets sent by the sender with an
> interval of 40 msec between each of them. I used pcap_loop method  
> with a cnt
> of -1. to loop for ever . The pcap filter deployed at each end is  
> supposed
> to  capture 20 packets ( 10 from src to dst and 10 from dst to src  
> and  I am
> only capturing data packets). However I noticed that the number of  
> packets
> captured  are quite less (varied from 13 to 17) . but the total  
> size of the
> pay load i.e. the sum of the payload for all packets is always 240  
> (12 x 20
> =240).  For some of the packets the size of the payload is 24, or  
> even 48.
>
> When I increased the monitoring rate the payload size even changed  
> to 108
> bytes and the no of packets changed to 10. However in all cases the  
> total
> pay load size of all the packets was exact 240. I know there was no  
> packet
> lost , as I can see them through sockets. I think the number of  
> packets
> captured equaled to 20 when I changed the rate to 1 sec.
>
>
>
> I then switched to pcap_next method

Note that pcap_next() and pcap_loop() are just wrappers around the  
same underlying method; pcap_next() does

        struct singleton {
                struct pcap_pkthdr *hdr;
                const u_char *pkt;
        };

        static void
	pcap_oneshot(u_char *userData, const struct pcap_pkthdr *h, const  
u_char *pkt)
        {
                struct singleton *sp = (struct singleton *)userData;
                *sp->hdr = *h;
                sp->pkt = pkt;
        }

        const u_char *
        pcap_next(pcap_t *p, struct pcap_pkthdr *h)
        {
                struct singleton s;

                s.hdr = h;
                if (pcap_dispatch(p, 1, pcap_oneshot, (u_char*)&s) <= 0)
                        return (0);
                return (s.pkt);
        }

and pcap_dispatch() does

        int
        pcap_dispatch(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
        {

                return p->read_op(p, cnt, callback, user);
        }

and pcap_loop() does

        int
        pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user)
        {
                register int n;

                for (;;) {
                        if (p->sf.rfile != NULL) {
                                /*
                                 * 0 means EOF, so don't loop if we get 0.
                                 */
                                n = pcap_offline_read(p, cnt, callback, user);
                        } else {
                                /*
                                 * XXX keep reading until we get something
                                 * (or an error occurs)
                                 */
                                do {
                                        n = p->read_op(p, cnt, callback, user);
                                } while (n == 0);
                        }
                        if (n <= 0)
                                return (n);
                        if (cnt > 0) {
                                cnt -= n;
                                if (cnt <= 0)
                                        return (0);
                        }
                }
        }

so all the real work is done in the read_op routine for whatever OS  
you're capturing on.

> Since I sent only 10 packets on each side, 20 in total, this instable
> behavior may be due to high monitoring rate. I wonder does pcap has  
> any
> limit in terms of no of packets it can capture in a specific time.  
> Does it
> has any buffering issues.

The underlying packet capture mechanisms in the OSes that libpcap  
supports all have a finite amount of buffering, and if packets arrive  
faster than the libpcap-based application can consume them, so that  
the buffer fills up, packets that arrive when the buffer is full will  
not be delivered to the libpcap-based application.

> Is it suppose to combine the payload if the rate
> is high.

No, and it doesn't do so.

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.