Why is LWIP ARP Request message 60 bytes long instead of 42 bytes.

[GJohn]

Just discovered that ARP request messages are padded with 18 bytes of trailing zero bytes, making them 60 bytes long instead of 42 bytes. A third party device doesn't like this and fails to respond to the ARP request message. I'm using a STM32F476 device to generate the ARP request. Does anybody have a fix for this issue?

[GJohn]

Sorry folks. I'm using a STM32F429, NOT a STM32476.

[Walid ZRELLI]

Hello @GJohn​ ,

Can you provide us with the version of LwIP used?

BeST Regards,

Walid

[GJohn]

LWIP version is 2.1.2

[Pavel A.]

This is because 60 bytes is the minimal legal length of ethernet packet.

IIRC the padding is added automatically by the hardware and this can be disabled by some register bit.

-- pa

[GJohn]

Well you're sort of correct. According to some Google searches, the minimum frame length is 64 octets, including the FCS. Wireshark shows me ARP requests from my PC are 42 octets long. ARP requests from my STM32 controller using LWIP are 60 octets long. The Ethernet header and FCS are not passed to the

protocol stack. So adding those octets to the displayed message length adds 18 octets. But the bottom line is still that the number of pad bytes being added to my ARP request messages by LWIP is excessive. The third party device, a data acq unit, doesn't respond to the long frames from my device. But does respond to my PC's ARP messages.

[Walid ZRELLI]

Hello @GJohn​ ,

Can you provide the Wireshark trace?

[GJohn]

Apparently not. Your bulletin board software is telling me that I can only upload files with specific extensions.

If you can specify an extension that is acceptable to both your bulletin board and Wireshark, I can try again.

[GJohn]

Actually, I can provide screen captures of the ARP transactions. Your bulletin board does allow posting of jpeg's.

Apparently, I can only attach one file to a message. So I'll need to generate two messages

Some related information:

PC is at 192.168.0.2

Gateway is 192.169.0.1 (none present)

data acq unit is at 192.168.0.100

Controller is at 192.168.0.10

Netmask is 255.255.255.0

ARP requests are at lines 7 (PC) and 47 (Controller)

[waclawek.jan]

Your problem is probably something else, not the padded ARP packets. See explanation e.g. here, why you think PC is sending an unpadded packet ("Wireshark is lying").

JW

[GJohn]

You hit it on the nose. The link in your response describes my problem exactly. My network is connected together using an unmanaged hub. So the data acq module's ARP reply to my controller isn't visible to Wireshark. I was able to verify that my data acq module is responding as designed to my controller's ARP request. And I wasn't aware that Wireshark reports the wrong frame length for packets originating on the PC that Wireshark is running on.

Thank you everyone for your assistance is resolving this issue. Your assistance is greatly appreciated. George

[Piranha]

A nice "good to know" topic! I'll add another link confirming and explaining the same:

https://ask.wireshark.org/question/21800/ethernet-frame-ii-outgoing-frames-dont-show-padding/