OpenCSW Bug Tracker


Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0002913 [wireshark] regular use block always 2008-06-20 08:58 2010-01-04 22:22
Reporter carlsonj View Status public  
Assigned To hson
Priority normal Resolution fixed  
Status closed  
Summary 0002913: wireshark no longer supports snoop capture format
Description 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
Additional Information
Tags No tags attached.
Attached Files

- Relationships

-  Notes
(0005355)
carlsonj (reporter)
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 (reporter)
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 (developer)
2010-01-04 22:22

Fixed in 1.2.3,REV=2009.12.25


Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker