u-boot.git/net, branch v2014.10

SPDX License cleanup for LiMon imported files

2014-10-10T13:44:43+00:00

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

kconfig: add blank Kconfig files

2014-09-24T22:30:28+00:00

This would be useful to start moving various config options.

Signed-off-by: Masahiro Yamada 
Acked-by: Simon Glass 
Tested-by: Simon Glass

net: dns: fix for DNS queries sent to the wrong MAC address

2014-09-16T16:24:00+00:00

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 
Signed-off-by: Gerhard Sittig

net: More BOOTP retry timeout improvements

2014-08-21T16:01:30+00:00

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 
Signed-off-by: Thierry Reding

net: BOOTP retry timeout improvements

2014-08-09T15:17:03+00:00

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 
Acked-by: Joe Hershberger

Ethernet: let user know if there is no valid ethernet address

2014-07-22T11:44:28+00:00

Improve error messages in case of invalid/unset ethernet addresses.

Signed-off-by: Pavel Machek

bootp can use mdelay

2014-07-22T11:44:25+00:00

Cleanup bootp code by using mdelay.

Signed-off-by: Pavel Machek 
Acked-by: Marek Vasut

fix: CONFIG_NETCONSOLE start/handle this stuff only outside SPL

2014-06-19T15:19:05+00:00

SPL stage does not support various networking things, and therefore
CONFIG_NETCONSOLE cannot be built within SPL.

Signed-off-by: Hannes Petermaier

net: rename and refactor eth_rand_ethaddr() function

2014-05-12T19:19:46+00:00

Some functions in include/net.h are ported from
include/linux/etherdevice.h of Linux Kernel.

For ex.
  is_zero_ether_addr()
  is_multicast_ether_addr()
  is_broadcast_ether_addr()
  is_valid_ether_addr();

So, we should use the same function name as that of Linux Kernel,
eth_rand_addr(), for consistency.

Besides, eth_rand_addr() has been implemented as an inline function.
So it should not be surrounded by #ifdef CONFIG_RANDOM_MACADDR.

Signed-off-by: Masahiro Yamada 
Acked-by: Joe Hershberger

lib: uuid: code refactor for proper maintain between uuid bin and string

2014-04-02T19:44:40+00:00

Changes in lib/uuid.c to:
- uuid_str_to_bin()
- uuid_bin_to_str()

New parameter is added to specify input/output string format in listed functions
This change allows easy recognize which UUID type is or should be stored in given
string array. Binary data of UUID and GUID is always stored in big endian, only
string representations are different as follows.

String byte: 0                                  36
String char: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
string UUID:    be     be   be   be       be
string GUID:    le     le   le   be       be

This patch also updates functions calls and declarations in a whole code.

Signed-off-by: Przemyslaw Marczak 
Cc: Stephen Warren 
Cc: Lukasz Majewski 
Cc: trini@ti.com