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.
> - 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.
> - 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.