When an ethernet driver fails to send a frame we print an error in lwIP.
But depending on how often that error is it might significantly delay
transmissions.

For example downloading a big file with the rpi4 spams the console with
'send error: -101', but removing the print makes the file download with
an average speed of ~8.5MiB/s since the packets are retransmitted.

So let's move it to a 'debug' in lwIP and expect ethernet drivers to handle
the failure if it's severe.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Jerome Forissier <jerome.forissier@linaro.org>

do_ping() expects ping_loop() to return a negative value on error, so
that it can propagate it to the caller as CMD_RET_FAILURE. This is not
the case when no ethernet device is found, so fix that.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>

When enabling net console and console multiplexing, a boot crash was
observed using mtk_eth driver with stdin/stdout set to "serial,nc"
in persistent environment:

> CPU:   MediaTek MT7981
> Model: OpenWrt One
> DRAM:  1 GiB
> Core:  35 devices, 15 uclasses, devicetree: separate
> spi-nand: spi_nand spi_nand@0: Winbond SPI NAND was found.
> spi-nand: spi_nand spi_nand@0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 64
> Loading Environment from UBI... SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
> mtd: partition "ubi" extends beyond the end of device "spi-nand0" -- size truncated to 0x7f00000
> Read 126976 bytes from volume ubootenv to 000000007f7bf0c0
> Read 126976 bytes from volume ubootenv2 to 000000007f7de100
> OK
> "Synchronous Abort" handler, esr 0x96000004, far 0xeafffffeea000018
> elr: 0000000041e63cd4 lr : 0000000041e1b844 (reloc)
> elr: 000000007ff9ecd4 lr : 000000007ff56844
> x0 : eafffffeea000018 x1 : 000000007fb552e0
> x2 : 00000000000000fe x3 : 0000000000000000

The cause is that "serial,nc" forced the console subsystem to
initialize the ethernet driver before ethernet subsystem
initialization (console_init_r() is called before initr_net()).

During the mtk_eth driver initialization, mdio_register() will be
called, and miiphy_get_dev_by_name() will then be called.

The miiphy_get_dev_by_name() will check the list "mii_devs" to see
if the passed device name exists. However the mii_devs is defined
without initialization:
> static struct list_head mii_devs;
and the actual initialization is done in the following chain:
initr_net -> eth_initialize -> eth_common_init -> miiphy_init
Since initr_net() hasn't be called, iterating over the mii_devs
will access to physical address 0 (mii_devs.next == NULL) and will
cause the crash.

The fix is to define mii_devs using:
> static LIST_HEAD(mii_devs);

As the "current_mii" is defined as a static variable, it will
always be NULL in board_r stage and initializing it will NULL is
unnecessary. So the entire miiphy_init() can be remove.

Signed-off-by: Weijie Gao <hackpascal@gmail.com>

Check wget_info->buffer_size for overflow and do not clean the wget_info struct
on failure, let the owner of the struct handle the error. The latter is necesary
, e.g., for when a request fails because the provided buffer was too small.

Signed-off-by: Adriano Cordova <adriano.cordova@canonical.com>

net/lwip/wget.c/mbedtls_hardware_poll() is calling dm_rng_read() but
dependency is not recorded anywhere that's why depend on DM_RNG
when WGET_HTTPS is used.

Suggested-by: Michal Simek <michal.simek@amd.com>
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>

Move the initialization of the ethernet devices out of the new_netif()
function. Indeed, new_netif() accepts a struct device argument, which
is expected to be valid and active. The activation and selection of
this device are achieved by eth_init() (on first time the network
stack is used) and eth_set_current(). This is what takes care of the
ethrotate and ethact environment variables. Therefore, move these calls
to a new function: net_lwip_set_current(), and use it whenever a
net-lwip command is run.

This patch hopefully fixes the incorrect net-lwip behavior observed on
boards with multiple ethernet interfaces [1].

Tested on an i.MX8MPlus EVK equipped wih two ethernet ports. The dhcp
command succeeds whether the cable is plugged into the first or second
port.

[1] https://lists.denx.de/pipermail/u-boot/2025-January/576326.html

Reported-by: E Shattow <e@freeshell.de>
Tested-by: E Shattow <e@freeshell.de>
Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>

Currently when booting dhcp_run() may be executed multiple times:
once in eth_bootdev_hunt() and once in the network booting bootmeth.

We need to call eth_bootdev_hunt() when setting up the EFI sub-system to
supply the simple network protocol. We don't need an IP address set up.

We can reduce the bootime by not executing dhcp_run() in
eth_bootdev_hunt().

Furthermore eth_bootdev_hunt() with autostart=yes leads on the legacy
network stack leads to downloading a file via TFTP and to booting the
downloaded file.

Instead of running dchp_run() just check that there is a network device
in eth_bootdev_hunt().

Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

When a successful neighbor advertisement is received, the ethernet
address should be saved for later use to avoid having to redo the
neighbor discovery process.

For example, with TFTP the address should get saved into
"net_server_ethaddr".  This is being done correctly with ARP for IPv4,
but not for neighbor discovery with IPv6.

Signed-off-by: Sean Edmond <seanedmond@microsoft.com>
Reviewed-by: Viacheslav Mitrofanov <v.v.mitrofanov@yadro.com>

timeout_count is never reset once a tftpput transfer has started. If for
whatever reason timeouts occur frequently, but the server keeps replying
nonetheless, the transfer may be needlessly aborted.

Reset timer_count on reception of an ACK to avoid this situation.

Signed-off-by: Jerome Forissier <jerome.forissier@linaro.org>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

We have a some boards that rarely starts networking abnormally, so there are
many timeouts during file transfer. In the same time there is a normal transfer
between timeouts. In this case we can continue transfer (instead of connection
aborting) by just clearing timeout counter on every successful block.

This patch does not affect the case when several timeouts happen one after
another. The transfer will be aborted. Thus the transfer will be
continued in the case of unstable link, but will be aborted in the case
of inaccessible server.

Feature downside: it may greatly slowdown (instead of abort) file transfer
in the case of unstable link.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>