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 atta
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. */
/*
Sorry for taking a while to get back to this...
Guy Harris wrote:
> 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
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
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.
>
>
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 non-p
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
