Re: tcpdump endianness

-------------------
The Ethereal project is being continued at a new site.  Please go to
http://www.wireshark.org and subscribe to [email protected].
Don't forget to unsubscribe from this list at
http://www.ethereal.com/mailman/listinfo/ethereal-dev
-------------------

[email protected] wrote:

> I am analyzing tcpdump file.
> I want to know how endianness can affect when file is being written.
> Or rather, who affects? Application which is writing? or Network byte
> order? or what?

The endianness of a libpcap-format file (the format used by tcpdump, 
Wireshark, etc.) is affected by the byte order of the machine writing it.

> I read somewhere that magic number of a tcpdump file can be either
> 0xa1b2c3d4 or 0xd4c3b2a1. How can it be?

It can be if the code that writes the magic number writes it out from a 
4-byte integral value of 0xa1b2c3d4 *without* putting it into network 
byte order first.  A machine with the same byte order as the machine 
that wrote the file will see a magic number of 0xa1b2c3d4; a machine 
with the opposite byte order will see a magic number of 0xd4c3b2a1.

> If endianness is architecture
> dependant then how would I know that I have to swap 2 bytes or 4 bytes?

You have to swap if the magic number is 0xa1b2c3d4.

You have to swap 2 bytes if you have to swap and you're processing a 
2-byte quantity.

You have to swap 4 bytes if you have to swap and you're processing a 
4-byte quantity.

Note, by the way, that this applies *ONLY* to the per-file and 
per-packet headers.  It does not apply to the packet data, which is in 
whatever byte order it was put into on the wire.

> really, A bit confusing...

Perhaps - the intent was, as I remember reading, to do as little work as 
possible when capturing packets (the less work done, the less likely you 
are to drop packets), and do all the byte-order work when reading the 
capture file.

That's why applications typically use libpcap to read the file, rather 
than reading it directly - it also means that the application won't have 
to change if the file format changes.

> One more thing, does this file have any extension? .tcpdump or .cap

No, there is no standard extension for those files.  (It originated on 
UN*X, and UN*X systems are, by and large, not as insistent on standard 
extensions as, say, Windows.)

> I mean there are so many possible or there is not anything like that.. one
> can recognise file from its magic number only...

That's how it'd be done on the free-software UN*X desktops (on KDE, for 
example, a PDF file doesn't have to have a name ending in ".pdf" in 
order to be recognized as a PDF file).