do_tftpb() parses the load address into a local variable laddr but
never updates the global image_load_addr. Commands that rely on
image_load_addr as their default address (e.g. 'bmp info')
therefore operate on the wrong address when called without
an explicit argument after tftpboot.

Update image_load_addr to laddr only on a successful transfer, so
that it accurately reflects where data was actually loaded.

Fixes: 4d4d7838127e ("net: lwip: add TFTP support and tftpboot command")
Signed-off-by: Pranav Sanwal <pranav.sanwal@amd.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

When resolving a symlink, nfs_path points into a heap allocated buffer
which is just large enough to hold the original path with no extra
space. If the symlink target name is longer than the original
filename, the write goes beyond the end of the buffer corrupting
heap memory.

Fix this by ensuring nfs_path always points to a buffer large enough
to accommodate the resolved symlink path.

Fixes: 230cf3bc2776 ("net: lwip: nfs: Port the NFS code to work with lwIP")
Signed-off-by: Pranav Tilak <pranav.vinaytilak@amd.com>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

Currently, the LWIP wget command prints excessive amount of progress
indicator '#' for very long file downloads, limit this to one line
that scales according to transfer size.

The HTTP server does report the size of the entire file in protocol
headers, which are received before the actual data transfer. Cache
this information and use it to adaptively print progress indicator
'#' until it fills one entire line worth of '#', which indicates the
transfer has completed. This way, long transfers don't print pages of
'#', but every transfer will print exactly one line worth of '#'. The
algorithm for '#' printing is the same as TFTP tsize one.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Jerome Forissier <jerome.forissier@rm.com>

The TFTP server can report the size of the entire file that is about to
be received in the Transfer Size Option, this is described in RFC 2349.
This functionality is optional and the server may not report tsize in
case it is not supported.

Always send tsize request to the server to query the transfer size,
and in case the server does respond, cache that information locally
in tftp_state.tsize, otherwise cache size 0. Introduce new function
tftp_client_get_tsize() which returns the cached tftp_state.tsize so
clients can determine the transfer size and use it.

Update net/lwip/tftp.c to make use of tftp_client_get_tsize() and
avoid excessive printing of '#' during TFTP transfers in case the
transfer size is reported by the server.

Submitted upstream: https://savannah.nongnu.org/patch/index.php?item_id=10557

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Jerome Forissier <jerome.forissier@arm.com>

Prefer use of a 'nfsserverip' env var before falling back to 'serverip'
when using the nfs command. Similar to how the 'tftpserverip' env var
is preferred over 'serverip' by the tftp command.

This also updates the error message to closer match the error message
used by the lwIP tftp command when a server ip is not set.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

The DHCP siaddr field contains the IP address of next server to use in
bootstrap. Typically this will be the IP address of a TFTP server or the
IP address of the DHCP server itself.

RFC 2131, 2. Protocol Summary, Page 10:

   DHCP clarifies the interpretation of the 'siaddr' field as the
   address of the server to use in the next step of the client's
   bootstrap process.  A DHCP server may return its own address in the
   'siaddr' field, if the server is prepared to supply the next
   bootstrap service (e.g., delivery of an operating system executable
   image).  A DHCP server always returns its own address in the 'server
   identifier' option.

Set the 'tftpserverip' env variable when the siaddr field contains an
IP address that is different compared to the DHCP server IP address.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

The ip_addr_t of lwIP has support for both IPv6 and IPv4 addresses.
Some lwIP commans is directly accessing the internal addr field of the
ip_addr_t instead of using ipaddr helper functions.

Change to use ipaddr helper functions where appropriate to remove direct
access of the internal addr field. Also change a few instances from ip4
to the version less ipaddr helpers.

There is no intended functional change, besides the change from using
ip4 addr helper to using version less ipaddr helper.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

The lwIP dns command handle env_set() calls from the found callback and
printf() to console in the dns loop. Making it more complex than it
needs to be.

Simplify and ensure any environment variable that is being set is the
same value that would have been printed on console.

There should not be any intended change in behavior, besides the change
from using ip4addr helper to using version less ipaddr helper.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

Use udevice name, similar to other lwip commands, instead of using the
legacy eth_get_name() when printing out the device being used.

Fixes: 230cf3bc2776 ("net: lwip: nfs: Port the NFS code to work with lwIP")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>

The lwIP dns command only prints out cached resolved IP addresses.

When a hostname is first resolved and ERR_INPROGRESS is returned the
dns command prints out 0.0.0.0 instead of the resolved IP address.

Fix this by printing out host_ipaddr instead of the temporary ipaddr
that only is valid when ERR_OK is returned.

Fixes: 1361d9f4f00a ("lwip: dns: do not print IP address when a variable is specified")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Jerome Forissier <jerome.forissier@arm.com>