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:[EMAIL PROTECTED]
