ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Ethereal-users: Re: Fwd: Re: [Ethereal-users] Shomiti/snoop format

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: Mon, 19 Aug 2002 13:12:57 -0700
On Mon, Aug 19, 2002 at 01:58:11PM -0400, Tony Fortunato wrote:
> I found out the following when playing with the (Fluke Optiview Expert - 
> OPE) Finisar product:
> OK. I open an OPE capture in Ethereal.  I check what format Ethereal thinks 
> its in (Tools -> Summary) and it says Sun Snoop.
> Not OK.

"Not OK"?  Why?  Perhaps it *is* in snoop format!

Shomiti's^H^H^H^H^H^H^H^H^HFinisar's Surveyor uses snoop format; they
used the fact that snoop format aligns file records on 4-byte
boundaries, *and* explicitly indicates the amount of padding for a
record in the header for the record by giving the total length of the
record, as well as the amount of packet data in the record, to add some
additional per-packet information - they "pad" the record by more than
the 0 to 3 bytes needed, and stuff additional information in the
padding.

Unfortunately, they didn't understand that the "Datalink Type" field in
RFC 1761 has values that aren't just random values chosen by Sun, but
are DLPI DL_ values as defined in

	http://www.opengroup.org/onlinepubs/9638599/apdxf.htm

and that

	1) the set of values grew between the point at which Sun
	   originally released snoop and the present

*and*

	2) Sun actually used at least one of those values (DL_IPATM,
	   which they use in atmsnoop captures)

and they added their own values to indicate the speed of the interface
and some other things, so Ethereal assumes that, if the version number
in the snoop file header is 2, the file probably doesn't use a Surveyor
data link type, it probably uses a DLPI data link type.

> I open an OPE trace in Ethereal, save a few packets in Sun Snoop 
> format and try to open the trace file in OPE.
> Not OK.

If that's "not OK", then a Sun snoop-format capture from, err, umm,
Sun's snoop program will be "not OK" as well.  If Finisar don't claim
to be able to read Sun snoop files, that's fine; a copy of the Shomiti
Surveyor 3.1 manual I downloaded says

	Support for Internet Advisor

	     Translators are available from the Tools menu of Surveyor
	     for Internet Advisor.  Translators convert capture files
	     in snoop format used by Surveyor to files that can be
	     used with Internet Advisor.

and

	File Formats
	     The following file formats are supported in Surveyor:

	.CAP Extension - Capture Files

	     Capture files contain packets collected from the network.
	     Capture file format is compliant with RFC 1761, referred
	     to as Snoop format. However, capture files include
	     extensions that expand the information provided by snoop
	     format.

so they don't seem to *explicitly* say they can't read Sun snoop
captures.

But, frankly, I'd be a little peeved if they couldn't read them, unless
the *sole* reason for picking snoop format and hijacking the padding was
to allow snoop to read *their* captures, not for Surveyor to read snoop
captures - and, even then, I'd be a little peeved, because I could
imagine somebody who had a capture from snoop wanting to read it in
Surveyor, and it's probably not *that* hard to have the file-reading
code just report to the rest of Surveyor that the extra information
Surveyor stuffs into the padding (which, from the spec they had for it,
appears to be

	the physical length of the frame, perhaps including a CRC;

	a bunch of receive status bits, e.g. "bad CRC";

	a 40ns-resolution time stamp;

	a "frame ID" of some sort)

isn't present, so that the rest of Surveyor doesn't use that
information, doesn't display the CRC/receive status/frame ID and shows
the boring old 1us-resolution time stamp.

> Why would Ethereal be able to open the trace file from OPE, identify it as 
> Sun Snoop but not save it in the same format.

It can save files in snoop format.  I've often read those files in snoop
(and, besides, RFC 1761 is pretty detailed, so it's not as if it's hard
to write files in that format).

Nobody's written code to save them in Surveyor's modified snoop format
because

	1) we'd assumed that Surveyor could read ordinary snoop-format
	   files;

	2) the extra information they stuff into the padding isn't
	   available to Ethereal;

	3) I, at least, don't have a copy of Surveyor on which to try
	   it, don't want to fill out the form to get a free copy, don't
	   do most of my development on Windows (the only OS on which
	   Surveyor runs, making testing a pain), and already have a
	   list of other unfinished projects and haven't the time to add
	   another one.

Perhaps somebody else can be coaxed into having Ethereal write out
Surveyor files as well as snoop files, although I'm *still* curious why
Surveyor can't just read ordinary snoop files.

> I understand the spirit of submitting this information to the generic 
> ethereal support address, but thought you may be interested.  If you would 
> prefer I could resend this to the support address instead.

"ethereal-users@xxxxxxxxxxxx" *is* the support address.