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>

Move the checksum code out into its own file so it can be used elsewhere.
Also use a new version which supports a length which is not a multiple of
2 and add a new function to add two checksums.

Signed-off-by: Simon Glass <sjg@chromium.org>

Currenly when CONFIG_BOOTP_SERVERIP is defined, the SERVERIP is not changed
when receive the BOOTP packet. But BOOTFILE is changed via BOOTP packet.

As we will load the BOOTFILE from SERVERIP, if the BOOTFILE is modified
by bootp packet but SERVERIP is not, that is not make sense.

This patch make SERVERIP and BOOTFILE be consistent. If we define the
CONFIG_BOOTP_SERVERIP, then SERVERIP and BOOTFILE will not changed by
BOOTP packet. Only IP address is changed.

Signed-off-by: Josh Wu <josh.wu@atmel.com>

Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>

If we know the file size, display it after loading the file.

Signed-off-by: Simon Glass <sjg@chromium.org>

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>

This would be useful to start moving various config options.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

When a DNS query is sent out, the ethernet packet can get directed to
the MAC address of a server that was communicated to before.  This is
wrong when the previously stored MAC address corresponds to a different
server's IP address, i.e. when the IP address of the previous and the
current communication are different.

The error can get reproduced by running a sequence of e.g. a TFTP
download and a DNS query, where the TFTP and DNS servers reside on
individual machines.

The fix is to clear the server's MAC address that might be left from a
previous operation, and to fetch the peer's MAC address in a new ARP
lookup, before the DNS query is sent.  This is the approach taken in
other network services, like 8e52533d1095 ("net: tftpsrv: Get correct
client MAC address").

Reported-by: Dirk Zimoch <dirk.zimoch@psi.ch>
Signed-off-by: Gerhard Sittig <gsi@denx.de>

It's not unusual for DHCP servers to take a couple hundred milliseconds
to respond to DHCP discover messages. One possible reason for the delay
can be that the server checks (typically using an ARP request) that the
IP it's about to hand out isn't in use yet. To make matters worse, some
servers may also queue up requests and process them sequentially, which
can cause excessively long delays if clients retry too fast.

Commit f59be6e850b3 ("net: BOOTP retry timeout improvements") shortened
the retry timeouts significantly, but the BOOTP/DHCP implementation in
U-Boot doesn't handle that well because it will ignore incoming replies
to earlier requests. In one particular setup this increases the time it
takes to obtain a DHCP lease from 630 ms to 8313 ms.

This commit attempts to fix this in two ways. First it increases the
initial retry timeout from 10 ms to 250 ms to give DHCP servers some
more time to respond. At the same time a cache of outstanding DHCP
request IDs is kept so that the implementation will know to continue
transactions even after a retransmission of the DISCOVER message. The
maximum retry timeout is also increased from 1 second to 2 seconds. An
ID cache of size 4 will keep DHCP requests around for 8 seconds (once
the maximum retry timeout has been reached) before dropping them. This
should give servers plenty of time to respond. If it ever turns out
that this isn't enough, the size of the cache can easily be increased.

With this commit the DHCP lease on the above-mentioned setup still takes
longer (1230 ms) than originally, but that's an acceptable compromise to
improve DHCP lease acquisition time for a broader range of setups.

To make it easier to benchmark DHCP in the future, this commit also adds
the time it took to obtain a lease to the final "DHCP client bound to
address x.x.x.x" message.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>

Currently, the BOOTP code sends out its initial request as soon as the
Ethernet driver indicates "link up". If this packet is lost or not
replied to for some reason, the code waits for a 1s timeout before
retrying. For some reason, such early packets are often lost on my
system, so this causes an annoying delay.

To optimize this, modify the BOOTP code to have very short timeouts for
the first packet transmitted, but gradually increase the timeout each
time a timeout occurs. This way, if the first packet is lost, the second
packet is transmitted quite quickly and hence the overall delay is low.
However, if there's still no response, we don't keep spewing out packets
at an insane speed.

It's arguably more correct to try and find out why the first packet is
lost. However, it seems to disappear inside my Ethenet chip; the TX chip
indicates no error during TX (not that it has much in the way of
reporting...), yet wireshark on the RX side doesn't see any packet.
FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is
reported too early or based on the wrong condition in HW, and we should
add some fixed extra delay into the driver. However, this would slow down
every link up event even if it ends up not being needed in some cases.
Having BOOTP retry quickly applies the fix/WAR to every possible
Ethernet device, and is quite simple to implement, so seems a better
solution.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Joe Hershberger <joe.hershberger@ni.com>