[Richard van der Hoff <richardv@xxxxxxxxxxxxx>]

Has anybody else noticed, that when capturing in realtime with a filter 
that means that packets aren't captured very often, the last couple of 
packets to be captured get 'stuck' until some more data comes along?

Sorry for the terrible explanation. It might be easier if I point to the 
offending code:

In capture_loop.c, we have the following (simplified slightly):

>     inpkts = capture_loop_dispatch(capture_opts, &ld, errmsg, sizeof(errmsg));
>
>     /* Only update once a second (Win32: 500ms) so as not to overload slow displays */
>     cur_time = TIME_GET();
>     if (cur_time - upd_time > 0) {
>         upd_time = cur_time;
>
>         /* Let the parent process know. */
>         if (inpkts_to_sync_pipe) {
>           /* do sync here */
>           libpcap_dump_flush(ld.pdh, NULL);

So the problem is that that if the packet count isn't flushed out just 
after a packet is read, it then isn't written until another packet 
arrives - which may not be for some time!

One workaround for this is to #define MUST_DO_SELECT, so that 
capture_loop_dispatch uses a select() to wait for packets to turn up, 
and put a second's timeout on the select() - but i'm not sure how 
portable this is likely to be. Anyone got any better ideas?

Thanks,

Richard


--
Richard van der Hoff <richardv@xxxxxxxxxxxxx>
Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com