["Viral Mehta" <viral.mehta@xxxxxxxxxxxxxx>]

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

Title: RE: [Ethereal-dev] tcpdump endianness

 

Hi

Thanks for your valuable input..

Now I m stuck up with "what is Link Layer Type". I googled it and find some number assigned to particular type and etc etc.. But what is it? Is it the protocol I am using at DataLinkLayer?

 

Secondly, Why do we have TimezoneOffset and TimeStampAccuracy fields if they are not used at all?

 

What is a per-packet header? Will we have it when we don’t write information to a file? As far as I know they give information about time after 1 Jan 1970 and such things.. But if I don’t do tcpdump -w sample.cap and instead give a simple command tcpdump sample.cap... Will I have all these information? That is will I have per-packet header? (That is info about time, packet length, and packet's actual length)

 

 

 

Thanks,

Viral Mehta

Embedded Engineer,

eInfochips Ltd.

 

-----Original Message-----

From: ethereal-dev-bounces@xxxxxxxxxxxx [mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Guy Harris

Sent: Thursday, August 17, 2006 11:13 PM

To: Ethereal development

Subject: Re: [Ethereal-dev] tcpdump endianness

 

-------------------

The Ethereal project is being continued at a new site.  Please go to http://www.wireshark.org and subscribe to wireshark-dev@xxxxxxxxxxxxx.

Don't forget to unsubscribe from this list at http://www.ethereal.com/mailman/listinfo/ethereal-dev

-------------------

 

viral.mehta@xxxxxxxxxxxxxx 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).

_______________________________________________

Ethereal-dev mailing list

Ethereal-dev@xxxxxxxxxxxx

http://www.ethereal.com/mailman/listinfo/ethereal-dev

 

 

eInfochips Business Disclaimer:

This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by eInfochips Limited and/or eInfochips Inc("eInfochips") unless sent with that express intent and with due authority of eInfochips. eInfochips has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.

 

 

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev