Wireshark-dev: Re: [Wireshark-dev] Portability issue of capture files.

Date: Thu, 7 Sep 2006 05:34:12 +0200
On 9/7/06, Jeff Morriss <jeff.morriss@xxxxxxxxxxx> wrote:


Andreas Fink wrote:
> I recently compiled wireshark under MacOS X 10.4.7 on a intel machine.
> This time I succeeded even with GTK+2 after fiddling with a lot of options.
> I'm preparing an installer for it for users without "fink" or "darwin
> ports".
>
> But while using it, I find out a strange behaviour.
>
> I'm capturing data on a linux machine (fedora5) with tcpdump -s0
> -wdumpfile.cap. Transfer the file to the mac and try to open it with
> wireshark. I get weird errors saying it couldnt open it because packet
> size is bigger than 65k or something like that. Same is if I capture
> with ethereal on that linux box and transfer the file to the mac. I can
> capture on the mac fine with tcpdump and read it on the mac with
> wireshark but whatever comes from that linux machine is not working.

Most frequently that's due to using FTP and not setting binary mode.
Does the file's checksum change from machine to machine after copying it?

The PCAP/Wiretap library is supposed to figure out the endianism of the
host where the file was generated automatically so normally there's no
problem with that.  (I frequently look at capture files from SPARC
machines on my Intel laptop, including with 0.99.3.)

Which is not the case... I just tried to open some files with my intel
based minimac and they do not work... oddly enough capture works only
if you are seeing packets in real-time, if instead you try to capture
without it fails to open them.

The issue here is that it doesn't appear to be an endianess issue, the
file header is read ok, so it is the first packet's, with the second
packet I see a very odd thing:

pcapio.c writes this:

ts_sec 7D91FF44 44FF917D
ts_usec 5BE20800 0008E25B
incl_len 56010000 00000156
orig_len 56010000 00000156

wiretap's libpcap.c reads this:

ts_sec 07010016 16000107
ts_usec CB05E505 05E505CB
incl_len 32040A00 000A0432
orig_len 01053304 04330501

So there's an issue here but it has nothing to do with endianity...
neither it does with FTP which BTW i didn't use.

Luis

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan