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

["Matthias" <matthias.nyffenegger@xxxxxxxx>]

Guy Harris wrote:
> On Mon, Jun 18, 2001 at 02:36:41PM +0200, Matthias wrote:
> > 3.2. The ringbuffer
> >      A ringbuffer would be implemented by creating multiple dump files
and
> >      overwriting them in round-robin fashion thus having only the most
recent
> >      packets stored in the dump files.
> >
> >      A process synchronization mechanism must be defined to synchronize
access
> >      to multiple dump files in case of real time capturing where we have
two
> >      processes, the parent process which acts as the reader and the
child
> >      process which acts as the writer. This implies ipc capabilities for
the
> >      sync. mechanism.
> >
> >      Ethereal currently supports a single dump file only. Dump file
access
> >      is encapsulated through the 'wiretap' library, but it's not always
> >      used throughout the Ethereal 0.8.18 core. The 'wiretap' lib should
be
> >      enhanced to be able to handle multiple dump files but not showing
this
> >      to the application. The sync. pipe used for ipc should also be
> >      encapsulated in the 'wiretap' library.
> >
> >      The following work must be considered:
> >
> >      - 'wiretap' file access must support a configurable number of files
> >        of configurable size. The fact that there are multiple files must
> >        not be visible outside 'wiretap'.
>
> How would that appear to the user of Ethereal?  Remember that a user can
> not only specify a file with the "-r" flag on the command line, but can
> also specify a file with the "File->Open" menu item.

There would be a new tab in the preferences dialog e.g. "dump file" where
the
user could specify the number of files and the filesize (all have the same
size)
should be used for ringbuffering. In the capture dialog there would be a new
checkbox e.g. "enable ringbuffer". The new checkbox is not selectable when
"Update list of packets in real time" is selected and vice versa. The names
of the dump files used for ringbuffering would be indexed automatically.
e.g.
<user defined filename>.<auto-index>.<timestamp>.<user defined extension>

>
> >      - A synchronization mechanism between parent and child process for
> >        multiple dump file access must be defined, preferably also
encapsulated
> >        in the 'wiretap' lib.
>
> Note that the Wiretap library knows nothing whatsoever about the parent
> and child process, so any such synchronization mechanism should be
> something that could be *used* by Ethereal, but should not itself know
> about parent and child processes.  The current parent/child scheme is
> not necessarily going to be used forever; it should be treated as an
> implementation detail of Ethereal, and should not be exposed to Wiretap.

Implementation of synchronization for multiple dump files is obsolete if
"Update list of packets in real time" is not supported when ringbuffering
is enabled.

>
>      - All file access in the Ethereal application must be done by means
>        of the 'wiretap' library, i.e. file descriptors, -handles should
>        not be visible outside 'wiretap'. The filename is the only
>        reference directly visible to the application.
>
> Note that "wtap_dump_fdopen()" was added in order to close a security
> hole found by the OpenBSD folk - from the CVS log for "capture.c":
>
> 	When creating the temporary file for a capture, use
> 	"create_tempfile()", to close a security hole opened by the fact
> 	that "tempnam()" creates a temporary file, but doesn't open it,
> 	and we open the file with the name it gives us - somebody could
> 	remove the file and plant a link to some file, and, if as may
> 	well be the case when Ethereal is capturing packets, it's
> 	running as "root", that means we write a capture on top of that
> 	file....  (The aforementioned changes to Wiretap let you open a
> 	capture file for writing given an file descriptor,
> 	"fdopen()"-style, which this change requires.)
>
> Any change that removes "wtap_dump_fdopen()" *must not* reopen that
> security hole.
>
> >      - The dump file header for file type WTAP_FILE_PCAP must be
extended
> >        for multiple dump file support.
>
> If you *must* change the file header, the first thing you must change is
> the magic number - if the file format is changed, the file *must* not
> use any of the current magic numbers used by libpcap.
>
> I.e., it must neither use 0xa1b2c3d4 nor 0xa1b2cd34.

This point is also obsolete because the ringbuffer dump files would not be
'merged' automatically i.e. would be treated like 'single' dump files.

Thanks very much for your feedback.

Regards

Matthias