Whentwo boards are connected together, each running the lwIP stack on top of EMACLite, the ARP reply from lwIP contains 1500 bytes of data with a lot of padded zeros. This normally would not be an issue when the ARP reply is targeted to a PC, but like in this case, when the ARP reply is received by lwIP on the remote side, it cannot recognize that it is a correct ARP reply.
This is primarily an lwIP problem.
Looking at the lwIP code, the ARP reply actually uses the pbuf that is previously allocated for receiving the incoming ARP request; in this example, a size of 1518 bytes. That iswhy there are so many trailing zeros at the end of the payload area.
One possible work-around is to adjust the length of the pbuf for the incoming ARP by using the pbuf_realloc() function to eliminate the trailing zeros. So, the code for receiving the incoming ARP request should look something like the following in xemacliteif.c:
/* receive the packet */
len = XEmacLite_Recv(instance, p->payload);
if (len == 0) {
#if LINK_STATS
lwip_stats.link.drop++;
#endif
return;
}
/* XILINX FIXME */
pbuf_realloc(p, len);
For designs using XPS LL TEMAC, please contact Xilinx Technical Support.