Tom Fulton wrote:
My Sniffer portable 4.7 crashes if I open an Ethereal capture which has
been saves as a Sniffer DOS file with a .caz extension. I suppose
that's predictable.
Perhaps predictable, given that programmers are often lazy...
...but unfortunate, given that
1) the DOS sniffer files and Windows Sniffer files begin with different
"magic numbers"
and
2) .caz files are just gzipped .cap files, and gzipped files begin with
a magic number that identifies them
so Sniffer Portable *should* be able to
1) recognize gzipped files
and
2) check whether the file data (un-gzipped if necessary) is a DOS
Sniffer file (compressed or uncompressed - the DOS Sniffer had its own
compression scheme), a Windows Sniffer file, or some other file that
happens to be gzipped
(after all, Ethereal certainly does all of that!), rather than just
assuming that the file's suffix reflects reality.
However, this is the file extension Sniffer 4.7
captures default to.
What that really means is "Sniffer 4.7 defaults to saving files in
gzipped Windows Sniffer format" - it doesn't mean that files should be
given that suffix *regardless* of the file format, given that Sniffer
Portable appears to think the file extension actually indicates the file
format.
It's an "unsupported File format" as a .cap.
If it's really silly enough to assume the extension indicates the file
format, it's probably treating it as if it's a Windows Sniffer file and
finding something wrong and rejecting it.
But, .enc can be opened with my Sniffer.
If it's saved as a DOS Sniffer file, it should be saved as ".enc" if
it's an Ethernet capture (.fdc for FDDI, .trc for Token Ring).
You might be able to save it in Windows Sniffer format and call it
".cap" rather than ".caz", but note that, unlike the DOS format which
was somewhat documented, the Windows format isn't documented, and we've
figured it out through reverse engineering. Reverse engineering for
reading is easier than reverse engineering for writing, because
1) parts of the file format you don't understand can often be ignored
when reading, but you might have to understand them and write the
correct data out if you expect code you *don't* control to be able to
read it;
2) as you don't control the code that's reading it, it's harder to
debug that code - you might just have to keep trying things and hand
them to the program that reads the file, and hope you find something
that works.
Presumably the people who've contributed code to write Windows Sniffer
files have gotten *some* versions of the Windows Sniffer to read them,
but perhaps later versions check for stuff that the earlier versions
don't check for, and that we're not writing correctly.