> The second IPTRACE file - various problems. It has GIOP packets which
> apparently Ethereal has some problems with. As I read the file in, I
> get several messages:
>
> WARNING giop: We don't yet dissect LOCATION_FORWARD
>
> It does read the file, but I can't convert it into anything. Except
> save under the different name, but only as another IPTRACE file (with
> this file, a pull-down menu shows only one option, IPTRACE 2.0. Now
> another problem. I've thought of filtering out the offending packets
> (with GIOP),
Those packets *aren't* what's causing your problem.
Ethereal's dissection function, and its capture file reading/writing
functions, are separate; when it writes out a capture file, it writes
out the raw packet data - whether there's something in the packet that
its dissection function can't handle is irrelevant.
(In fact, Ethereal comes with a program - editcap - which can also read
capture files in one format and write them in another; editcap does not
make *any* attempt whatsoever to dissect the contents of the packets.)
The most likely reasons why it only allows you to save the file as an
iptrace file are:
1) the file has packets of more than one link-layer type -
iptrace's capture file format supports that, but other
capture file formats don't;
2) the file has packets of only one link-layer type, but that's
a link-layer type not supported by the capture file format
you're trying to save as;
3) the file has packets of only one link-layer type, and the
capture file format you're trying to save as supports it, but
Ethereal doesn't know how to write out a capture file in that
format with that link-layer type.
What link-layer types are in the second iptrace file? Check all of the
packets - if, for example, some are Ethernet and some are token-ring,
you will probably not be able to save the file as anything other than an
iptrace file. (Snoop and Sniffer, for example, can only handle one
link-layer type per file.)