Why is LWIP ARP Request message 60 bytes long instead of 42 bytes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 7:50 PM
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?
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-03 10:19 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-01 8:23 PM
Sorry folks. I'm using a STM32F429, NOT a STM32476.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-02 2:10 AM
Hello @GJohn​ ,
Can you provide us with the version of LwIP used?
BeST Regards,
Walid
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-02 8:53 AM
LWIP version is 2.1.2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-02 10:30 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-02 11:20 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-03 1:23 AM
Hello @GJohn​ ,
Can you provide the Wireshark trace?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-03 1:58 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-03 3:31 PM
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2021-06-03 3:33 PM
Here's the other screen capture (ARP from PC)
