Mailing List Archive

On Sun, Jun 11, 2006 at 09:03:33AM +0200, Eduardo Escudero S?nchez wrote:

> The most i can do only with the ethernet ii field is seeing if the
> data part of the frame has a length of 46 bytes and if it is the case
> i know there could be trailer bytes added to it. Anyone can explain me
> this to me a little more?(Or maybe give me a reference)

You're right that the Ethernet_II frame header doesn't tell us if there
is a trailer. There will always be a trailer added by the NIC upon
transmission if there is not enough data to make the frame at least 64
bytes (including the 14 byte header + 4 byte trailer). From a quick
glance at the code in packet-eth.c, Ethereal determines if there may be
a trailer present based on the size of the rest of the frame and
displays the last number of bytes that would be the trailer if
appropriate. It also takes into account whether the driver reported the
FCS along with the data or not (or even "maybe"). On my current
machine, I only see the trailer on received frames and not transmitted
since the NIC hasn't put the trailer on yet.

Let us know if you want more information :)


Steve

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

How can ethereal determine the size of the trailer based on the size of rest
of the frame? In the data part of the frame there could be a lot of
different protocol-dependent data. What im doing now is analize the data
inside the ethernet II frame and seeing if there is more data than the upper
protocol expects. For example, if i have an ethernet II frame with a
length/type field of 0x0800 (an IP frame) i take the data and analizes it as
an ip datagram and i retrieve the data length field of the datagram. The i
see with that length if it is the length of the data part of the ethernet
frame or if it is less than the legth of the data part of ethernet II. If
the second case is happening the i obtain the difference between both values
and get that way the trailer length But this is not a very efficient
approach because if i want to stay independent of upper protocols it means
that if i want to analize a MAC level frame i have to step onto uppper
levels to achieve it. That means too that i must have implememnted frame
analizers for all the upper protocols in order to ask any of them what is
the length of their data to obtain the real length of the ethernet II data.
Any idea? thanks


2006/6/11, Stephen Fisher <stephentfisher@yahoo.com>:
>
> On Sun, Jun 11, 2006 at 09:03:33AM +0200, Eduardo Escudero S?nchez wrote:
>
> > The most i can do only with the ethernet ii field is seeing if the
> > data part of the frame has a length of 46 bytes and if it is the case
> > i know there could be trailer bytes added to it. Anyone can explain me
> > this to me a little more?(Or maybe give me a reference)
>
> You're right that the Ethernet_II frame header doesn't tell us if there
> is a trailer. There will always be a trailer added by the NIC upon
> transmission if there is not enough data to make the frame at least 64
> bytes (including the 14 byte header + 4 byte trailer). From a quick
> glance at the code in packet-eth.c,Ethereal determines if there may be
> a trailer present based on the size of the rest of the frame and
> displays the last number of bytes that would be the trailer if
> appropriate. It also takes into account whether the driver reported the
> FCS along with the data or not (or even "maybe"). On my current
> machine, I only see the trailer on received frames and not transmitted
> since the NIC hasn't put the trailer on yet.
>
> Let us know if you want more information :)
>
>
> Steve
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>

Eduardo Escudero Sánchez wrote:
> How can ethereal determine the size of the trailer based on the size of
> rest of the frame? In the data part of the frame there could be a lot of
> different protocol-dependent data.

The Ethernet dissector relies on the dissector that it calls to set the
actual length of the tvbuff it handed to that dissector to the actual
length. The IPv4 dissector, for example, sets it based on the total
length in the IPv4 header.

> What im doing now is analize the data
> inside the ethernet II frame and seeing if there is more data than the
> upper protocol expects.

That is, in effect, what Ethereal does.

> But
> this is not a very efficient approach because if i want to stay
> independent of upper protocols it means that if i want to analize a MAC
> level frame i have to step onto uppper levels to achieve it. That means
> too that i must have implememnted frame analizers for all the upper
> protocols in order to ask any of them what is the length of their data
> to obtain the real length of the ethernet II data.

There is no alternative to that. The payload length of a protocol
encapsulated with an Ethernet type field is defined by the protocol, so
the only way to find out what that length is would be to have code that
understands enough of that protocol to determine the payload length.
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev

Many thanks for your acclarations, it has been very useful.

2006/6/14, Guy Harris <guy@alum.mit.edu>:
>
> Eduardo Escudero Sánchez wrote:
> > How can ethereal determine the size of the trailer based on the size of
> > rest of the frame? In the data part of the frame there could be a lot of
> > different protocol-dependent data.
>
> The Ethernet dissector relies on the dissector that it calls to set the
> actual length of the tvbuff it handed to that dissector to the actual
> length. The IPv4 dissector, for example, sets it based on the total
> length in the IPv4 header.
>
> > What im doing now is analize the data
> > inside the ethernet II frame and seeing if there is more data than the
> > upper protocol expects.
>
> That is, in effect, what Ethereal does.
>
> > But
> > this is not a very efficient approach because if i want to stay
> > independent of upper protocols it means that if i want to analize a MAC
> > level frame i have to step onto uppper levels to achieve it. That means
> > too that i must have implememnted frame analizers for all the upper
> > protocols in order to ask any of them what is the length of their data
> > to obtain the real length of the ethernet II data.
>
> There is no alternative to that. The payload length of a protocol
> encapsulated with an Ethernet type field is defined by the protocol, so
> the only way to find out what that length is would be to have code that
> understands enough of that protocol to determine the payload length.
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@ethereal.com
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>