Mantis - wireshark
Viewing Issue Advanced Details
2913 regular use block always 2008-06-20 08:58 2010-01-04 22:22
carlsonj  
hson  
normal  
closed  
fixed  
none    
none  
0002913: wireshark no longer supports snoop capture format
The latest version of wireshark in the CSW repository is:

  VERSION=1.0.0,REV=2008.06.11

... and it seems that it no longer understands snoop files. I get
a pop-up box that says this:

  The file \"snoop.out\" isn\'t a capture file in a format Wireshark
  understands. (snoop: version 33554432 unsupported)

The file in format came directly from \"snoop -o\", and snoop can read
it fine. The \"file\" command identifies it as:

  snoop.out: Snoop capture file - version 2

Downgrading to this previous version of wireshark fixes the problem:

  VERSION=1.0.0,REV=2008.04.02
Issue History
2008-10-27 14:00 carlsonj Note Added: 0005355
2009-02-19 19:52 Guy Harris Note Added: 0005550
2009-02-19 19:52 Guy Harris Issue Monitored: Guy Harris
2010-01-04 22:22 hson Assigned To calessio => hson
2010-01-04 22:22 hson Note Added: 0007165
2010-01-04 22:22 hson Status assigned => closed
2010-01-04 22:22 hson Resolution open => fixed

Notes
(0005355)
carlsonj   
2008-10-27 14:00   
Rolling back just /opt/csw/lib/libwiretap.so.0.0.1 will fix the problem.

The good library looks like this:

-rwxr-xr-x 1 root bin 306688 Apr 2 2008 /opt/csw/lib/libwiretap.so.0.0.1

The bad one is:

-rwxr-xr-x 1 root bin 305992 Jul 5 11:13 libwiretap.so.0.0.1
(0005550)
Guy Harris   
2009-02-19 19:52   
So how are the CSW GLib packages built?

Note that it is probably non-trivial to cross-compile them on SPARC for x86 and x86-64 (and vice versa). GLib needs to know the byte order of the host on which it'll be running; it offers byte-order-handling calls such as g_ntohl(). Wireshark uses that call when reading snoop files, as the values in the file and per-packet header in snoop files are in network byte order (big-endian) - even on x86 and x86-64 - and if g_ntohl() doesn't byte-swap on little-endian machines, Wireshark will have a number of problems, including but not limited to not being able to read snoop files.

This means that, when building for x86 and x86-64, the configure script has to set the byte order to little-endian - even if you're running on a big-endian machine. The script might test the byte order of the target machine by compiling and running code; unless Solaris has something like Mac OS X's Rosetta, to allow x86 binaries to be run on SPARC, or the configure script can be told to force the byte order to little-endian, this means you can't build GLib for x86 or x86-64 on SPARC without somehow manually intervening into the process and setting the byte order to little-endian.

It also means that, if you've configured and built GLib for SPARC in a given directory, before you build it for x86 and/or x86-64 in that directory, even if you're doing that on a PC, you have to run "make distclean" and re-run the configure script before building, as the results of running the configure script on SPARC are wrong for x86 and x86-64 even if the SPARC box and x86/x86-64 box are running the exact same version of Solaris with the exact same software installed.
(0007165)
hson   
2010-01-04 22:22   
Fixed in 1.2.3,REV=2009.12.25