> Ok, I can easily reproduce the problem with wiretap with a flood ping even
> on my slow ppp link, but I can't see any weird things with libpcap. So I
> suspect that simultaneous dump/read with libpcap was safer than with wiretap
> (but I can't see why yet :-).
The only thing I can think of is that, somehow, when reading with
"libpcap", if the file is too short, the read that fails somehow leaves
the stream pointer in the right position, so that the next read starts
at the same position that the failed read does.
Either that, or it leaves it in a position that otherwise causes
subsequent reads by "libpcap" to work OK, even if it may cause packets
to be skipped.
> I will try to fix that. I already have a easy
> fix but it will slow down the display process so I have to look further.
It might be that "capture_pcap_cb()" fflushes out "(FILE *)ld->pdh",
causing complete packets to be written to the file, and then sends a
message to the display process telling it to read the file - but, before
that process starts reading the file (or while it's reading the file),
enough *other* packets get written out that the standard I/O buffer gets
flushed and a partial packet gets written to the file.
Could the sync mode message include a *count* of packets to be read,
which is the number of complete packets added to the file since the last
sync mode message, with the display process then reading only that
number of packets? We'd have to add to make "wtap_loop" honor the
"count" argument, but that looks trivial.
