Ethereal-users: Re: [Ethereal-users] big-endian and little-endian

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 24 May 2002 12:15:23 -0700
On Fri, May 24, 2002 at 05:37:01PM +0200, Ernst Pisch wrote:
> I have problems to read a capture file which was made by tcpdump from a RM400 
> (SINIX V5.43 with MIPS-processor).
> I want to read it on my Laptop with Linux and ethereal V0.9.0 because I have 
> much more possibilities for diagnosis than with tcpdump on the origin system.
> But I'm getting nonsense - ethereal isn't capable to interpret this capture.
> It seems to be because of the different architecture 'big-' or 
> 'little-endian'!?

That's *extremely* unlikely, given that:

	1) the magic number in a libpcap capture file (the format used
	   both by tcpdump and Ethereal) is written out in the byte
	   order of the host writing the file, and thus can be used by
	   the host reading the file to determine whether it's in the
	   reading host's byte order or if it has to byte-swap
	   multi-byte numbers in the file header and in the header
	   before each packet's data;

	2) both libpcap (as used by tcpdump to read captures) and
	   Ethereal's Wiretap library (as used by Ethereal to read
	   captures) do, in fact, check the magic number and byte-swap
	   the numbers as necessary;

	3) I've read, on a big-endian SPARC machine, captures from
	   little-endian machines (both PC's running various OSes and
	   Network Appliance machines whose "pktt" command also writes
	   out libpcap-format captures);

	4) the packet *data* is written out in byte-serial fashion, so
	   whether it's big-endian or little-endian depends not on the
	   byte order of the machine capturing the packets, it depends
	   either on the protocol (if it mandates a particular byte
	   order) or on the hosts exchanging the packets (if the byte
	   order is controlled by one of those hosts or is negotiated by
	   the host).

The problem is probably something else.

> The command 'file capturefile' gives me the following output:
> tcpdump capture file (big-endian) - version 2.1 (RFC 1483 ATM, capture length 
> 68)
> 
> Thank you!!
> 
> P.S.: Do you need a sample capture?

Yes, I'd need a sample capture in order to figure out what the problem
is.