net: Do not respond to ICMP_ECHO_REQUEST if we do not have an IP address

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>

diff --git a/net/ping.c b/net/ping.c
index 0e33660f6c5faf8db51940826491c256d7c685ba..075df3663fe073132687212df5d385f6cb9f04b0 100644 (file)
--- 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,