[Guy Harris <guy@xxxxxxxxxxxx>]

On Oct 27, 2003, at 9:30 AM, sford@xxxxxxxxxxxxx wrote:

> But I do have a problem.  When I DON'T provide a capture filter (to
> cut down the incoming rate), it does seem to run far behind and
> miss lots of packets.  (Even though the cpu is mostly idle and it's
> not taking all that much memory!)  Then when it exits, it thinks there
> were 0 dropped packets!

Just because libpcap thinks there are 0 dropped packets, that doesn't 
mean there weren't any.  Perhaps  either

	1) the code in the OS kernel isn't counting dropped packets properly;

	2) the packets are being dropped at a layer where the PF_PACKET code 
doesn't get to count them;

	3) you're running on a system with a 2.2[.x] kernel and no turbopacket 
patches, in which case the kernel simply doesn't report dropped packet 
statistics when capturing;

	4) you're running on a system whose libpcap wasn't built on a system 
with the packet-statistics stuff available, so it doesn't even know it 
*can* get the packet statistics.

> When I read in the captured file (without using ANY filters at all),
> it seems to take very long time, even though the cpu STAYS mostly idle.

It's trying to do IP-address-to-name resolution?

> Ronnie Sahlberg wrote:
> > ... display filters ... require all the packets to be fully
> > disected.  This ... starts consuming more and more memory while
> > tethereal runs.  ... capture filters does not ... cause
> > the internal state in tethereal to start building up.
>
> That sounds bad.  I did not realize that the longer tethereal runs,
> the more memory it will consume if display filters are used.  Why
> is this?  Memory leak bug?  Or just the nature of display filters?

Just the nature of display filters.  They have to fully dissect 
packets, and correctly dissecting packets might require various bits of 
state to be kept around, as per replies to your messages asking about 
that.

> As far as implementing stop condition with a capture filter, I
> can't see how to do that.  Capture filters are handled within
> the pcap lib with pcap_setfilter().  My understanding is that
> it performs the packet parsing and filtering in kernel space.

It does that in kernel space if it's doing a live capture, rather than 
reading a capture file, and if the kernel can do that.  Otherwise, it's 
done in user mode.

> Is there a user-mode interface to do it?

"bpf_filter()".  It takes as arguments:

	1) a pointer to the first instruction of a compiled BPF program (as 
compiled by "pcap_compile()") - the "bf_insns" member of a "struct 
bpf_program" is such a pointer;

	2) a pointer to the first byte of the raw packet data;

	3) the length of the packet as it appeared on the wire (the "len" 
member of a "pcap_pkthdr");

	4) the captured length of the packet (the "caplen" member of a 
"pcap_pkthdr");

and returns the return value of the BPF program - if it's zero, the 
packet didn't match the filter, and if it's non-zero, it did.

That's not documented; we ("we" the libpcap developers, not "we" the 
Ethereal developers) should either document it, or write a pcap wrapper 
and document that.

> Ideally the capture filter stop condition would be applied in kernel
> space with only one packet parse.  Is there a way to communicate back
> to user space that the trigger has happened?  I assume this would
> require a change to the pcap lib.

It would require a change to the *kernel* - and that won't help if the 
kernel doesn't have a BPF interpreter (as is the case in many OSes).

Also, it could be done with one packet parse only if the input filter 
and stop filter programs were combined *and* there were a way to return 
separately return to the kernel code that calls it an indication of 
whether the packet passed the capture filter and an indication of 
whether it passed the stop filter.