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?

[Pavel A.]

Have you tried to disable automatic padding?

-- pa

[GJohn]

Short answer: No. I have looked at the options settings in MX Cube, lwipopts.h, and opt.h. I didn't see anything

that looked like an automatic padding switch. Can you point me to the correct option/file?

[Pavel A.]

For STM32F4 I guess it is this.

To receive short frames, enable this.

[GJohn]

This is not the correct solution. I I need to eliminate the pad bytes on a transmitted

ARP Request - not a received request. Any thoughts?

[waclawek.jan]

ETH_DMATXDESC_DP sounds much like something related to Tx to me.

JW

[waclawek.jan · Accepted solution]

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/