Ethereal-dev: AW: [Ethereal-dev] Ethereal core enhancements

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Matthias" <matthias.nyffenegger@xxxxxxxx>
Date: Tue, 19 Jun 2001 19:32:00 +0200
Guy Harris wrote:
> On Mon, Jun 18, 2001 at 02:36:41PM +0200, Matthias wrote:
> >    2. Dump captured packets to ringbuffer, i.e. only the most recently
> > captured
> >       packets are available (includes support for multiple dump files).
>
> What defines "most recently captured" here?  The most recent N packets?
> The most recent M bytes worth of packet data captured?

The most recent N packets. N depends on configured number and size of
dump files used for the ringbuffer.

>
> Note also that "Update list of packets in real time" would presumably
> require that "unavailable" packets be removed from the CList that
> displays packets - as well as requiring that the linked list of packets
> have packets removed from it.
>
> In addition, if doing so removes some fragments that had previously been
> reasembled, this could cause problems for the IP/IPv6/CLNP reassembly
> code.
>
> It might well be that the combination of a ring-buffer capture and
> "Update list of packets in real time" is either impossible to implement
> correctly, impossible to implement sensibly, or impossible to implement
> without adding a lot of complexity to Ethereal and several of its
> dissectors, and shouldn't be supported (disappointing thought that might
> be to the user, but sometimes features users really really really really
> really want end up doing violence to the code and end up getting in the
> way of features that other users really really really really really
> want).

We agree with you. To simplify matters we suggest that "Update list of
packets
in real time" is not supported when ringbuffering is enabled and vice versa.

The main purpose for a ringbuffer here is to avoid running out of system
resources (e.g. disk space) when performing long time capturing in order to
track
down effects that occur only sporadically.

As a result of a ringbuffered capture we would have a number of dump files
that
can only be viewed separately in the GUI just like any other dump file
created
with ringbuffering disabled.

It is feasible to add support for more sophisticated stop conditions in a
later
stage which would make much sense in combination with a ringbuffer.

Thanks very much for your feedback.

Regards

Matthias