The _parse_reply function iterates over the DHCPv6 message options
twice but only performs sanity checks on the option length in the
first iteration. As such, both loop iterations need to be identical.
Unfortunately, there aren't without this commit as (1) they use
different maximum length values and (2) the first iteration stops
parsing as soon as it encounters a zero option while the second
doesn't. As such, it is possible for out-of-bounds read to be
performed by the second loop iteration. This commit fixes this.
The handlers for these MQTT message lock the connection mutex on
function entry. During automated testing of asymcute, I discovered
return paths for these function which do not unlock the connection
mutex. This results in a deadlock which prevents asymcute from
sending any further messages.
Synchronize the RPL thread updating the RPL netstats with the RPL
shell command reading it by disabling IRQs. This will prevent printing
corrupted data on non-32bit platforms as well as printing inconsistent
data (e.g. TX count of old state in conjunction with TX bytes of new
state) for all platforms.
Co-authored-by: Martine Lenders <mail@martine-lenders.eu>
There is a repeating pattern in the struct that is split out into a
subtype in this commit. This makes handling the data easier, as now
done in the print routine.
Instead of retrieving a pointer with NETOPT_STATS, retrieve the current
data. This avoids data corruptions when reading from one thread (e.g.
the thread running the shell (ifconfig command)) while another thread
is updating it (e.g. the netif thread).
The issue affects all boards, as users typically expect the count of
TX packets and the number of TX bytes to refer to the same state. For
16 bit and 8 bit platforms even a single netstat entry can read back
corrupted.
This fixes the issue by just copying the whole netstat_t struct over
without requiring explicit locking on the user side. A multi-threaded
network stack still needs to synchronize the thread responding to
netopt_get with the thread writing to the netstat_t structure, but that
is an implementation detail no relevant to the user of the API.
An EUI provider can provide EUIs for multiple interfaces based on
their index.
For this is should get the index of the interface, not the index of
the EUI provider.
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
[..]
```
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.
