[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tcpdump-workers
Subject:    Re: [tcpdump-workers] Strange behavior of pcap filter
From:       Guy Harris <guy () alum ! mit ! edu>
Date:       2006-04-06 23:49:27
Message-ID: 667A3538-4980-4985-887E-DF833211FD66 () alum ! mit ! edu
[Download RAW message or body]


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.
[prev in list] [next in list] [prev in thread] [next in thread]