From: David Rivshin DRivshin@allworx.com

While doing DHCP the interface IP is set to 0.0.0.0. This causes the check in net.c on dst_ip to be effectively skipped, and all IP datagrams are accepted up the IP stack. In the case of an ICMP_ECHO_REQUEST for the matching MAC address (regardless of destination IP), the result is that an ICMP_ECHO_REPLY is sent. The source address of the ICMP_ECHO_REPLY is 0.0.0.0, which is an illegal source address.

This can happen in common practice with the following sequence: DHCP (U-Boot or OS) acquires IP address 10.0.0.1 System reboots U-Boot starts DHCP and send DHCP DISCOVER DHCP server decides to OFFER 10.0.0.1 again (perhaps because of existing lease or manual configuration) DHCP server tries to PING 10.0.0.1 to see if anyone is squatting on it DHCP server still has our MAC address in its ARP table for 10.0.0.1 U-Boot receives PING, and responds with an illegal source address This may further result in a the DHCP server seeing the response as confirmation that someone is squatting on 10.0.0.1, and picking a new IP address from the pool to try again

Signed-off-by: David Rivshin drivshin@allworx.com --- net/ping.c | 3 +++ 1 file changed, 3 insertions(+)

diff --git a/net/ping.c b/net/ping.c index 0e33660f6c..075df3663f 100644 --- a/net/ping.c +++ b/net/ping.c @@ -90,6 +90,9 @@ void ping_receive(struct ethernet_hdr *et, struct ip_udp_hdr *ip, int len) net_set_state(NETLOOP_SUCCESS); return; case ICMP_ECHO_REQUEST: + if (net_ip.s_addr == 0) + return; + eth_hdr_size = net_update_ether(et, et->et_src, PROT_IP);

debug_cond(DEBUG_DEV_PKT,

base-commit: 050acee119b3757fee3bd128f55d720fdd9bb890