Gianluca Varenni wrote:
> I was trying to feed tethereal (0.10.12) through stdin on windows, and
> I've seen that basically it doesn't work in all conditions:
One condition in which it doesn't work is "if you try it on UN*X":
$ cat somefile.cap | tethereal -r -
ethereal: The file "-" could not be opened: Illegal seek.
ksh: cat: somefile.cap: read error [Broken pipe]
"Illegal seek" is the key here. Wiretap (the capture-reading library in
Ethereal) determines the type of capture file by calling open routines for
all of the file types it knows about until one of them says "this is one
of my files"; it seeks back to the beginning of the file before each call.
(It also might do seeks to determine file subtypes, thanks to, for
example, various mutant flavors of libpcap format that use the standard
libpcap magic number.)
> tethereal -r - < somefile.cap works perfectly
That's a plain file, so seeks work.
> cat somefile | tethereal -r - fails (it simply returns without decoding
> any packet)
That's not a plain file; the only surprising thing is the lack of an error
message, but maybe fseek() on a pipe in Windows silently returns an EOF
indication after the read, or something such as that.
> The same commands work perfectly with tcpdump/windump (using the parameter
> "-r -")
libpcap/WinPcap only support libpcap format, and don't try to detect the
mutant flavors thereof, so they read the file purely sequentially.
At some point, Wiretap should probably buffer some amount of input, and
implement seeks by moving within the buffer; that'd allow the
seek-and-reread stuff to work on pipes. If I ever manage to do the "fast
random access to gzipped files" stuff, I might redo the way it reads
uncompressed files as well, reading into a buffer and doing seeks in that
fashion.
> I have the same problem if I try to use named pipes (windows). I have an
> app that creates a named pipe (\\.\pipe\foo) and writes some packets in
> libpcap format onto it.
>
> tethereal -r \\.\pipe\foo fails telling me "The file \\.\pipe\foo doesn't
> exist".
>
> Windump works perfectly with these pipes, as well ("windump -r
> \\.\pipe\foo").
That's a bit of a surprise; perhaps zlib is getting in the way, but,
otherwise, it should just be using fopen() in both cases. That's
*probably* a different problem, but I don't know what it is.