ARP message padding

[Roy Marples]

Hi list!

Whilst working on the IPv4LL part of dhcpcd, I was wondering why some frames I
was capturing were 60 bytes and some were 42 - which was the size I was
expecting. After some research, I find about minimum ethernet frame size
which is 64, including the 4 byte crc.

I'm asking this here, because NetBSD sends a gratuitous ARP when assinging and
address to an interface, which is 42 bytes in length according to my capture.
This is also what dhcpcd currently does.

So the question is, should both pad up to 60?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Roy Marples
Hi list!
Whilst working on the IPv4LL part of dhcpcd, I was wondering why some frames
I was capturing were 60 bytes and some were 42 - which was the size I was
expecting. After some research, I find about minimum ethernet frame size
which is 64, including the 4 byte crc.

Quite possibly you are capturing transmit packets before they get padded.
TX padding may be done by hardware MAC unit, or the low levels of the
ethernet driver.

David

[Roy Marples]

Post by David Laight

Post by Roy Marples
Hi list!
Whilst working on the IPv4LL part of dhcpcd, I was wondering why some
frames I was capturing were 60 bytes and some were 42 - which was the
size I was expecting. After some research, I find about minimum ethernet
frame size which is 64, including the 4 byte crc.

Quite possibly you are capturing transmit packets before they get padded.
TX padding may be done by hardware MAC unit, or the low levels of the
ethernet driver.

More research shows that every source I can find does not pad and neither does
a direct capture on devices I can, leaving it to something else (driver, OS,
hardware, etc).

Sorry for noise :)

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de