Re: changing filter on running capture

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

On Nov 21, 2003, at 2:28 AM, Stephan Knabe wrote:

> Another interesting aspect would be, what happens when I change the 
> filter
> in the callback-function (which runs in the same thread). Will the old 
> one
> be replaced for the next packets?

On platforms where the filtering is done in userland, that should work.

On platforms where it's done in the kernel and changing the filter 
causes the kernel code to flush unread packets (such as the BSDs), it 
should work (with the potential loss of some packets).

On platforms where it's done in the kernel and changing the filter 
*doesn't* cause the kernel code to flush unread packets (Linux with 
in-kernel packet filtering configured in), in libpcap 0.7 and later 
libpcap itself does flushing (by giving the kernel a "discard all 
packets" filter, reading packets in non-blocking mode until there are 
no more to read, and then giving the kernel the real filter), so that 
should work (with the potential loss of some packets); with earlier 
libpcaps, you might get packets that passed the old filter but wouldn't 
have passed the new filter.

(That might be one way of doing it - queue up the new filter in the 
"build a new filter" thread for the capture thread to use.)

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe