On 24 July 2018 at 15:40, Joe Hershberger joe.hershberger@ni.com wrote:
Peter originally sent a fix, but it breaks a number of other things. This addresses the original reported issue in a different way.
That report was:
U-Boot has 1 common buffer to send Ethernet frames, pointed to by net_tx_packet. When sending to an IP address without knowing the MAC address, U-Boot makes an ARP request (using the arp_tx_packet buffer) to find out the MAC address of the IP addressr. When a matching ARP reply is received, U-Boot continues sending the frame stored in the net_tx_packet buffer.
However, in the mean time, if U-Boot needs to send out any network packets (e.g. replying ping packets or ARP requests for its own IP address etc.), it will use the net_tx_packet buffer to prepare the new packet. Thus this buffer is no longer the original packet meant to be transmitted after the ARP reply. The original packet will be lost.
This instead uses the ARP tx buffer to send async replies in the case where we are actively waiting for an ARP reply.
Signed-off-by: Joe Hershberger joe.hershberger@ni.com
Reported-by: Tran Tien Dat peter.trantiendat@gmail.com
include/net.h | 8 ++++++++ net/arp.c | 9 +++++---- net/arp.h | 1 + net/net.c | 8 ++++++++ net/ping.c | 7 +++++-- test/dm/eth.c | 6 ++---- 6 files changed, 29 insertions(+), 10 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org