-------------------
The Ethereal project is being continued at a new site. Please go to
http://www.wireshark.org and subscribe to wireshark-dev@wireshark.org.
Don't forget to unsubscribe from this list at
http://www.ethereal.com/mailman/listinfo/ethereal-dev
-------------------
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@ethereal.com
[mailto:ethereal-dev-bounces@ethereal.com] 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@wireshark.org.
Don't forget to unsubscribe from this list at
http://www.ethereal.com/mailman/listinfo/ethereal-dev
-------------------
viral.mehta@einfochips.com 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@ethereal.com
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.
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@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev
The Ethereal project is being continued at a new site. Please go to
http://www.wireshark.org and subscribe to wireshark-dev@wireshark.org.
Don't forget to unsubscribe from this list at
http://www.ethereal.com/mailman/listinfo/ethereal-dev
-------------------
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@ethereal.com
[mailto:ethereal-dev-bounces@ethereal.com] 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@wireshark.org.
Don't forget to unsubscribe from this list at
http://www.ethereal.com/mailman/listinfo/ethereal-dev
-------------------
viral.mehta@einfochips.com 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@ethereal.com
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.
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@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev