On Tue, Sep 19, 2000 at 12:39:53AM -0400, Gilbert Ramirez wrote:
> shomiti has a document describint their file format at
> http://www.shomiti.com/support/technotes.html
>
> I'll take a look at it and see if it applies to their v3.1
> file format (the file you provided).
Well, unless the powerful Microsoft-Word-to-text conversion program
"strings" discarded some data, it appears only to apply to their hacked
up snoop version 2 format.
I infer from the document that even Shomiti's version 2 adds extra
information to packets, but puts it *after* the packet data; snoop
format includes a record length, as well as a packet length and a packet
snapshot length, in the header - I suspect Brent wanted to allow packets
to begin on 4-byte-aligned offsets so that snoop could mmap the file and
not have to worry about alignment problems when looking at packet
headers - which also allows Shomiti's software to add more "padding"
than snoop would, and stuff their own extensions into it.
However, it also appears, from a quick experiment, that version 4 can be
handled by Ethereal, assuming that the capture consists of a pile of IPP
traffic between 13.32.8.151 and 13.32.8.155; if HP Roseville are
responsible for the squat plastic box sitting on the table to the right
of my computer's tower at home - the box with "Laserjet 2100M" on it
(yes, 2100M; this isn't a Windows-only computer, so I really *do* want
PostScript) - that might explain why he'd be capturing IPP traffic. :-)
Shomiti may well have changed, in version 4, only the additional stuff
they add after the packet data, in which case the format change would be
transparent to programs such as snoop and Ethereal that simply ignore
the "padding" after the frame data (even if it happens to be Shomiti
stuff; I guess we could, in theory, check to see if there's more than 3
bytes of padding, and interpret it as Shomiti stuff, but then we might
have to worry about what's in version 4, and we might get screwed if
somebody else used the same trick).
Given that, I'll just check my change in; I've attached it as a patch -
if Mike Kerwan has source and a C compiler for Windows, he can get the
relevant developer's kits for WinPcap and GTK+/GLib, install them, and
then either apply the patch on a UNIX system or get patch for Windows,
which might be part of CygWin, and apply the patch and rebuild.
Otherwise, he'd have to wait for the next release or wait for somebody
else to build a Windows binary.
? errs
? tvbtest
? tvbtest.c.DAMMIT
? tvbuff.c.DAMMIT
? MESSAGE-BOXES
? gtk/help_dlg.c.NEW
Index: wiretap/snoop.c
===================================================================
RCS file: /usr/local/cvsroot/ethereal/wiretap/snoop.c,v
retrieving revision 1.30
diff -c -r1.30 snoop.c
*** snoop.c 2000/09/07 05:34:19 1.30
--- snoop.c 2000/09/19 05:00:52
***************
*** 181,188 ****
wth->data_offset += sizeof hdr;
hdr.version = ntohl(hdr.version);
! if (hdr.version != 2) {
! /* We only support version 2. */
g_message("snoop: version %u unsupported", hdr.version);
*err = WTAP_ERR_UNSUPPORTED;
return -1;
--- 181,193 ----
wth->data_offset += sizeof hdr;
hdr.version = ntohl(hdr.version);
! switch (hdr.version) {
!
! case 2: /* Solaris 2.x and later snoop */
! case 4: /* Shomiti Surveyor 3.x */
! break;
!
! default:
g_message("snoop: version %u unsupported", hdr.version);
*err = WTAP_ERR_UNSUPPORTED;
return -1;
