On Fri, 21 Nov 2003, Guy Harris wrote: > > 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.
Well, I have to use it on Linux and Solaris. > 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. This sounds good to me. Loosing only a few packets might be something I could live with, so I'll give it a try. > (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.) That's my plan. Thanks for reply, Stephan Knabe - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
