On Sep 9, 2008, at 9:17 AM, lei wei wrote:
Thanks a lot for the reply Guy! According to your explanation, for
libpcap, the status struct:
struct pcap_stat {
u_int ps_recv; /* number of packets received */
u_int ps_drop; /* number of packets dropped */
the ps_recv field should be the total number of packets handed to
the filter regardless it was
matched or not. Is that correct?
It depends on what OS you're doing the capture, unfortunately.
Different OSes behave differently.
In *BSD and Mac OS X, it's the number of packets handed to the filter
regardless of whether the packet matched or not - i.e., the number of
packets handed to the filter to be filtered, not the number of packets
that passed the filter.
If so, I guess the only way to tell how many packets were matched
by the filter is to set up a counter in the pcap loopback function.
The only way to tell how many packets were matched by the filter *and*
that weren't dropped by BPF would be to set up a counter in the
callback function.
Note, however, that ps_recv counts packets that have been handed to
the filter but that you haven't read yet, so it counts packets that
wouldn't be counted by your counter.
Actually I do some extensive processing
on each packet when receiving it in the loopback function, so the
counter field I set up in it should
indicate how many packets it actually processed. If I want to know
the exact number of packets that
were actually passed the filter, do I have a way to do that? or the
only way is to look at the packets drop?
ps_drop won't help - it doesn't count the number of packets that
didn't pass the filter, it counts the number of packets that passed
the filter but were dropped because there wasn't enough space in the
buffer.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
