On Wed, Jun 05, 2002 at 10:02:36PM +0100, Graeme Hewson wrote:
> Presently, if the argument to -r is a FIFO, ethereal and tetheral
> crash. It musn't be a FIFO because (t)ethereal wants to seek on it; the
> attached patch to wiretap/file.c prevents the user specifying a FIFO.
Ethereal is unlikely ever to support reading from a pipe or FIFO unless
it makes a copy of the *entire* pipe or FIFO either to memory or a
temporary file.
Tethereal, however, may someday be able to do so if we do some of our
own buffering, to allow a limited amount of backward seeking.
As such, I made "wtap_open_offline()" return an error on a FIFO only if
asked to open for random access; I added a new error for that, so the
user can be told "sorry, Ethereal doesn't read pipes".
> It turns out there's a more fundamental reason for the crash, though.
> There's a bug in zlib 1.1.3 and 1.1.4 (and presumably earlier versions
> too) where gzseek() doesn't save its internal error status if its call
> to fseek() fails. This means a subsequent call to gzerror() sets errnum
> to whatever the error was before the call to gzseek(), which is likely
> to be Z_OK (gzopen() and gzdopen() initialise the error status to
> Z_OK).
I changed "file_seek()" to take an additional "int *" argument, and had
it return an error code through that pointer if the seek fails. The
with-zlib version of the code assumes that if the seek fails but
"file_error()" returns 0, it's because of that bug; it returns "errno"
through that pointer in that case.
That hides the problem inside Wiretap, rather than having Ethereal and
Tethereal know about it.