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
