Examples have previously relied on the (really: some) nightly toolchain
to be the default. As that, in practice, is a problematic assumption,
the latest toolchain to use is now determined programmatically, and that
is set explicitly on the examples that use nightly.
Workaround-For: https://github.com/rust-lang/rustup/issues/3015
The netif list is used like a stack, so it needs to be
iterated in reverse to keep the registration order.
Time complexity in O(n^2), but the the list is normally very short
(1-2 items).
Before:
```
> ifconfig
Iface 10 HWaddr: 24:0A:C4:E6:0E:9C Channel: 0 Link: down
[..]
Iface 7 HWaddr: 24:0A:C4:E6:0E:9F Link: down
[..]
```
Now they are in the increasing order:
```
> ifconfig
Iface 7 HWaddr: 24:0A:C4:E6:0E:9F Link: down
[..]
Iface 10 HWaddr: 24:0A:C4:E6:0E:9C Channel: 0 Link: down
[..]
```
When lwIP is hacked to use the same shell command, it also
lists it interfaces in the expected order (was ET1,ET0 before):
```
> ifconfig
Iface ET0 HWaddr: 24:0A:C4:E6:0E:9F Link: down
[..]
Iface ET1 HWaddr: 24:0A:C4:E6:0E:9C Channel: 0 Link: down
[..]
```
Let's consider firmwares as identical if their flash files are matching.
This will have the side effect that hash mismatches for ESP32 due to
different .debug sections in the ELFFILE are prevented, as for ESP32
the BINFILE is used.
The source / destination address of the SDHC transfer needs to be
word-aligned.
Use the mtd buffer to fix the alignment if `mtd_write_page` is used,
otherwise return -ENOTSUP.
The assertion is a bit overeager.
In case of receiving a wrong message ID, we re-try receive without
entering the STATE_REQUEST_SEND state again, so it is expected that
we get a non-NULL ctx/response from sock_udp_recv_buf().
What this assert should actually check is that we don't get a non-NULL
ctx after calling sock_udp_recv_buf() with a non-NULL ctx.
So make this explicit to not falsely fail the assertion.
An network devices that supports netdev_driver_t::get(NETOPT_LINK, ...)
also has to emit NETDEV_EVENT_LINK_UP and NETDEV_EVENT_LINK_DOWN with
lwip for IPv6 duplicate address detection to work. The background is
that the STM32 Ethernet MAC requires a periodic timer to poll for the
state to emit these events. For this reason, `stm32_eth_link_up` was
introduced to allow applications to select if they need these events.
With this dependency in place, IPv6 addresses won't get stuck in a
tentative state any more.
`ESP_WIFI_EAP_USER` and `ESP_WIFI_EAP_PASS` have to be defined because this board is used in the CI to compile the optional module `esp_wifi_enterprise`.
In the board definition of `esp32_wrover_kit` default values for `ESP_WIFI_EAP_USER` and `ESP_WIFI_EAP_PASS` had to be defined because this board was used in the CI to compile the optional module `esp_wifi_enterprise`. Now that the CI compilation for the `esp_wifi_enterprise` module is realized by an external board definition `esp32-ci`, these default values should be removed to make the compilation fail if the user did not define these variables.
