#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
51723c55 |
|
14-Nov-2020 |
David Rivshin <DRivshin@allworx.com> |
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>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
f7ae49fc |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop log.h from common header Move this header out of the common header. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
90526e9f |
|
10-May-2020 |
Simon Glass <sjg@chromium.org> |
common: Drop net.h from common header Move this header out of the common header. Network support is used in quite a few places but it still does not warrant blanket inclusion. Note that this net.h header itself has quite a lot in it. It could be split into the driver-mode support, functions, structures, checksumming, etc. Signed-off-by: Simon Glass <sjg@chromium.org>
|
#
5d457ecb |
|
24-Jun-2018 |
Duncan Hare <DH@Synoia.com> |
net: Consolidate UDP header functions Make it possible to add TCP versions of the same, while reusing IP portions. This patch should not change any behavior. Signed-off-by: Duncan Hare <DH@Synoia.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
ac3f26cc |
|
26-Sep-2018 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Don't overwrite waiting packets with asynchronous replies 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> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>
|
#
2d8f25ed |
|
28-Mar-2018 |
Mario Six <mario.six@gdsys.cc> |
net: Always align tx packets Make sure that TX packets are always cache-aligned. Signed-off-by: Mario Six <mario.six@gdsys.cc> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
f739fcd8 |
|
07-May-2018 |
Tom Rini <trini@konsulko.com> |
SPDX: Convert a few files that were missed before As part of the main conversion a few files were missed. These files had additional whitespace after the '*' and before the SPDX tag and my previous regex was too strict. This time I did a grep for all SPDX tags and then filtered out anything that matched the correct styles. Fixes: 83d290c56fab ("SPDX: Convert all of our single license tags to Linux Kernel style") Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de> Signed-off-by: Tom Rini <trini@konsulko.com>
|
#
bc0571fc |
|
08-Apr-2015 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Fix checkpatch.pl failures in net.c Finish eliminating CamelCase from net.c and other failures Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
331db5a9 |
|
08-Apr-2015 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Clean up ping variables and functions Make a thorough pass through all variables and function names contained within ping.c and remove CamelCase and improve naming. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
85d25e0e |
|
08-Apr-2015 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Clean up ARP variables and functions Make a thorough pass through all variables and function names contained within arp and remove CamelCase and improve naming. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
1203fcce |
|
08-Apr-2015 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Cleanup internal packet buffer names This patch cleans up the names of internal packet buffer names that are used within the network stack and the functions that use them. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
0adb5b76 |
|
08-Apr-2015 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Name ethaddr variables consistently Use "_ethaddr" at the end of variables and drop CamelCase. Make constant values actually 'const'. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
049a95a7 |
|
08-Apr-2015 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Change IPaddr_t to struct in_addr This patch is simply clean-up to make the IPv4 type that is used match what Linux uses. It also attempts to move all variables that are IP addresses use good naming instead of CamelCase. No functional change. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
0da0fcd5 |
|
19-Jan-2015 |
Simon Glass <sjg@chromium.org> |
net: Use new checksum functions Drop the old checksum functions in favour of the new ones. Signed-off-by: Simon Glass <sjg@chromium.org> Acked-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
2ea91039 |
|
30-Sep-2014 |
Wolfgang Denk <wd@denx.de> |
SPDX License cleanup for LiMon imported files A number of network related files were imported from the LiMon project; these contain a somewhat unclear license statement: Copyright 1994 - 2000 Neil Russell. (See License) I analyzed the source code of LiMon v1.4.2 which was used for this import. It does not contain any "License" file, but the top level directory contains a file "COPYING", which turns out to be GPL v2 of June 1991. So it is legitimate to conclude that the LiMon derived files are also to be released under GPLv2. Mark them as such. Signed-off-by: Wolfgang Denk <wd@denx.de>
|
#
4ef8d53c |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Allow filtering on debug traces in the net subsystem Add several levels of DEBUG prints so that you can limit the noise to the severety of your problem. DEBUG_LL_STATE = Link local state machine changes DEBUG_DEV_PKT = Packets or info directed to the device DEBUG_NET_PKT = Packets on info on the network at large DEBUG_INT_STATE = Internal network state changes Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
e94070c4 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Don't copy every packet that waits for an ARP Use the NetArpTxPacket for the ARP packet, not to hold what used to be in NetTxPacket. This saves a copy and makes the code easier to understand. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
f1d2d284 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Remove static allocation for MAC address in PingSend() Don't force ARP clients to return the MAC address if they don't care (such as ping) Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Mike Frysinger <vapier@gentoo.org>
|
#
e7111015 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Add net_update_ether() to handle ARP and Ping replies When the network is VLAN or SNAP, net_update_ether() will preserve the original Ethernet packet header and simply replace the src and dest MACs and the protocol Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
22f6e99d |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Refactor to protect access to the NetState variable Changes to NetState now go through an accessor function called net_set_state() Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
adf5d93e |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Refactor to use NetSendPacket instead of eth_send directly Use this entry-point consistently across the net/ code Use a static inline function to preserve code size Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|
#
61da3c2a |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Refactor ping receive handler There is no need to call through the handler... inline it Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org>
|
#
00f33268 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Refactor packet length computations Save the length when it is computed instead of forgetting it and subtracting pointers to figure it out again. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org>
|
#
4b11c916 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Refactor IP, UPD, and ICMP header writing functions ICMP (ping) was reimplementing IP header code... it now shares code. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Mike Frysinger <vapier@gentoo.org>
|
#
e0a63079 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Un-typedef ICMP_t Remove typedef and lower-case name Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
cb487f56 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Un-typedef Ethernet_t Separate the Ethernet header from the 802 header. Base the size constants on the structs. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
c5c59df0 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Split struct ip_udp_hdr into ip_hdr Add a structure that only contains IP header fields to be used by functions that don't need UDP Rename IP_HDR_SIZE_NO_UDP to IP_HDR_SIZE Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
594c26f8 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: cosmetic: Un-typedef IP_t Rename IP header related things to IP_UDP. The existing definition of IP_t includes UDP header, so name it to accurately describe the structure. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
|
#
a36b12f9 |
|
23-May-2012 |
Joe Hershberger <joe.hershberger@ni.com> |
net: Move PING out of net.c Separate this functionality out of the net.c behemoth Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Acked-by: Simon Glass <sjg@chromium.org>
|