Ethereal-dev: Re: [Ethereal-dev] Stop capture trigger. RFC

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 25 Jun 2003 10:05:32 -0700

On Wednesday, June 25, 2003, at 8:44AM, John McDermott wrote:


I have thought a bit about that, too. I am interested in both start and stop triggers. Here is what I have been thinking. Maybe it is flawed:
Given
F(S) - Start trigger filter string
F(P) - Stop trigger filter string
F(U) - User specified filter string
F'(P) - Filter string catching all packets except those matched by the stop trigger F(P)


Tell pcap to capture grabbing one packet at a time using filter F(S).
When a packet is found, switch pcap filter to F'(P) or F(U) if no F'(P).

Unfortunately, if you change the libpcap filter, you might lose packets - in at least some systems where BPF filtering is done in the kernel, the act of changing the filter causes any packets not yet read from the BPF device to be discarded, as they might not match the new filter. Recent versions of libpcap on Linux, where changing the kernel BPF filter *doesn't* cause packets to be discarded, do the discarding themselves; because you can't specify a filter when opening a live capture, the initial filter matches all packets, and you thus run the risk of seeing, at the beginning of a capture, packets that don't match the filter. (Yes, people *have* complained about that, which is why we put that discarding stuff in. Yes, there should arguably be a routine to open a capture *and* specify an initial filter.)

if using stop filter, when a packet is discarded by pcap, it must have matched F(P), so stop capturing.

If a packet is discarded by pcap, you won't see it, so you won't know when to stop capturing.

This means that using a Stop trigger prohibits use of user specified pcap filters F(U) which may be an unreasonable restriction.

See my other mail.  The filter to use if a stop capture is in effect is

	F(U) || F(P)

and you then have to check each packet to see if it matched F(U) (if not, discard it) or F(P) (if so, stop capturing).

In my Ideal World (tm) libpcap would have start and stop triggers built in.

In my ideal world, the kernel capture mechanisms that support BPF filtering would have start and stop triggers built in, so you don't have to copy packets to userland if the start filter hasn't been matched yet, and, once the capture has started, you can avoid copying to userland packets that match the stop filter but not the capture filter.

Fortunately, most kernel packet capture mechanisms that support BPF filtering are open-source and you can modify them ({Free,Net,Open}BSD, Linux, WinPcap). The ones you can't are Mac OS X, where you could I guess run a Darwin kernel (if Apple doesn't eventually pick up the BSD changes), and AIX, where you're probably out of luck given that the BPF in AIX is undocumented and appears not to be all that well supported.