Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] Does mergecap work with named pipes ?

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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Fri, 2 Jul 2004 00:18:12 -0700
On Thu, Jul 01, 2004 at 10:32:07PM +0200, Pierre JUHEN wrote:
> I get
> 
> mergecap: skipping pipe1: Illegal seek
> 
> So I guess it would need modification.
> 
> Would it work just by modifying mergecap ?

No.

The problem is that the library used by Ethereal, Tethereal, mergecap,
and editcap to read capture files does not support reading from pipes.

The reason why it doesn't do so is that it seeks on the file from which
it's reading.  It does this

	1) as part of the process of trying to figure out what type of
	   file it is - it iterates through the open routines for all
	   file types, seeking back to the beginning of the file before
	   each routine, until it finds a routine that thinks the file
	   is a file of its type, and those routines read some amount of
	   the file to figure out whether the file is a file of its
	   type;

	2) for some file types (including libpcap), as part of the
	   process of trying to figure out what variant of that file
	   type it is (libpcap has some variants that have the same
	   magic number but different record formats).

In order to make it support reading from pipes, it'd need to do
something such as doing its own buffering, and supporting seeks within
that buffer, so that if the first file format check routine had read
some of the file and decided the file wasn't a file of its type, the
seek backwards would just reposition a pointer into the buffer into
which the first read was done, rather than attempting to reposition the
underlying file pointer.

I.e., you can't fix this by modifying mergecap, you'd have to fix it by
modifying the library that mergecap uses (it's in the "wiretap"
subdirectory of the Ethereal source tree), and fixing it isn't trivial.