On Sep 24, 2003, at 3:50 PM, Matthijs Melchior wrote:
The attached patch makes a change to tethereal in the way it changes
to a next ring buffer. The old behaviour is to write a packet to the
file, and than test for the switching critera. For the time criterion
in a situation where there are long time spans of silence this has the
unpleasant effect to write the first packet of a new series of packets
as the last packet of a file.
Checked in.
When looking at that change, I noticed that, when we switched ring
buffer files as a result of a timeout, and the switch failed, we didn't
do anything with the error indication.
I also noticed that:
1) we allow a ring buffer to be used when reading a capture file
rather than doing a live capture - this could be useful (a way of
splitting capture files) when "-a filesize:XXX" is specified (although
that doesn't actually *work*, as we check the file size only when doing
a live capture), but a duration value doesn't seem all that useful (as
it reflects time spent reading the capture file, not time stamps *in*
the capture file);
2) we have two ways of specifying a duration - with "-a duration:XXX",
and with "-b count:XXX".
I have also been looking to make the -l switch work with saving to
files,
so that the buffer is flushed to disk every second or so. This would
enable me to have tethereal in background looking at the network and
use ethereal to view the most recent history using the tethereal files.
Ethereal would need a mode to start polling its input file fore more
data [and to make it really clever to switch files when the capture
process switches...].
We already have some of that - that's how "Update list of packets in
real time" is implemented; there's one process doing the capture, and
another process that gets messages from that process over a pipe and
reads from the capture file when told by the capturing process that N
packets have been added to the capture file.
Perhaps having an option for Tethereal to send messages to a named pipe
file, and have Ethereal read messages from that named pipe file rather
than from a pipe to a child capture process, would handle that.
