Guy Harris wrote:
> ...or provide a "dissect_padding()" routine, and have them all call
> that.
>
> I'm somewhat inclined to see if that could be done in the Ethernet
> dissector, though, as
>
> 1) the padding data could perhaps be thought of as "belonging"
> to the Ethernet layer
>
> and
>
> 2) that would obviate the need to modify all dissectors.
I was thinking at this too but I didn't know how to do that. :(
I made that quick dirty patch just to show the idea and how it should look
like.
The only need for this is in ethernet dissector and in ethernet frames
encoded as ISL or 802.1q, but I think that those are handled by ethernet
dissector too (in the end).
>
>
> However, not all layers above Ethernet necessarily have a simple length
> field that's used to update "pi.len" or "pi.captured_len", as far as I
> know, so that might require the dissectors to update that field
> themselves, or otherwise indicate how much they've dissected. At least
> protocols that are only called from layers that do have such a length
> field, e.g. all dissectors for protocols that ultimately run only under
> IP, might not have to be modified in that fashion.
>
> The Ethernet padding is, as I remember, to ensure that a packet takes
> enough time to transmit that, by the time the last byte of the packet is
> put on the wire, the first byte of the packet has reached both ends of
> the wire, and thus to ensure that a collision will occur if anybody
> starts transmitting at any point during the transmission of the packet;
> I think most other link layers don't need that, and thus don't pad their
> packets, but we could add padding to those if necessary.
Yes you are right, in short the minimum ethernet length is for ensuring
that a collision cannot occur after the frame was transmitted completely.
The sender thinks that it was transmitted OK but in fact a collision may
occur after transmission.
