When an arp request is received, it is passed to xSendEventStructToIPTask. From there it is passed to prvProcessEthernetPacket and ends up in eARPProcessPacket. The arp reply packet is then generated by reusing the buffer from the arp request. When done, the arp reply is sent to the network interface function vReturnEthernetFrame for transmission.
So far so good. The function prvProcessEthernetPacket checks that the packet length is greater than the size of an arp packet, but otherwise the packet length is not modified. In my setup, the arp packet received by the embedded code has been padded (presumably by the Windows 10 computer) and has a FCS (CRC).
Since the reply length has not been set, the returned arp reply has an out-of-date padding and FCS that render the transmitted Ethernet packet invalid. I think that the reply length needs to be set in prvProcessEthernetPacket after the call to eARPProcessPacket.
As a test I patched the function prvProcessEthernetPacket, adding the following code after the call to eARPProcessPacket
pxNetworkBuffer->xDataLength = sizeof( ARPPacket_t );
I no longer get FCS errors reported in Wireshark, so it looks better. I think there is a similar issue with ICMP handling as well.
