Hello Pierre,
Pierre JUHEN [EMAIL PROTECTED] 11/30/06 6:33 AM
Maybe the problems lies here (capture_opts.c) :
[snip]
At least for me, it fixed the problem described in bugs 1181 et
1220.
I created bug #1220 because, sorry, the keywords I used wehre not the
right ones.
I attached a patch
Maybe the problems lies here (capture_opts.c) :
static gboolean capture_opts_output_to_pipe(const char *save_file, gboolean
*is_pipe)
{
int err;
if (save_file != NULL) {
/* We're writing to a capture file. */
if (strcmp(save_file, -) == 0) {
/* Writing to stdout. */
/*
Guy Harris wrote:
Richard van der Hoff wrote:
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.
It's
Richard van der Hoff wrote:
The only concern with this would be that dumpcap would presumably then
send a packet count after every packet - which might mean a significant
quantity of data.
Every batch of packets, at least.
Some OSes support packet batching, so that a single read from the
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
Richard van der Hoff wrote:
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.
It's likely to be quite
