A proper error code is returned if a key with unsupported (either by the implementation or the AES algorithm) length is passed to aes_init.
This fixes Issue #10175
Unstructured static initializer like { 0 } lead to compilation errors on ESP8266, MSP430 and MIPS. Error messages are:
error: (near initialization for 'queue.event_list') [-Werror=missing-braces]
error: (near initialization for 'queue.waiter') [-Werror=missing-field-initializers]
This change fixes the compilation problem.
Check for the usage of `newlib_nano` module instead of the
`USE_NANO_SPECS` variable.
This allows also benefiting from the `printf_float` and `scanf_float`
behaviour on `arm7` and `riscv` cpus.
- Add SEMTECH_LORAMAC_ALREADY_JOINED ret code for semtech_loramac_join
- Add SEMTECH_LORAMAC_TX_CNF_FAILED ret code for semtech_loramac_send
- Update shell commands to notify when no ACK is received on cnf tx
stm32eth: Move to stm32_common periph
cpu/stm32_periph_eth: Rebase to current master branch
- Update DMA to use new vendor headers
- Update send to use iolist. It looks like the packet headers are now transfered as seperate iolist entries which results in the eth periph sending each header as own packet. To fix this a rather ugly workaround is used where the whole iolist content is first copied to a static buffer. This will be fixed soon in another commit
- If MAC is set to zero use luid to generate one
- Small code style fixes
cpu/stm312f7: Add periph config for on-board ethernet
boards/nucleo-f767zi: Add config for on board ethernet
tests/stm32_eth_lwip: Remove board restriction
boards/common/nucleo: Add luid module if stm32 ethernet is used
tests/stm32_eth_gnrc: Add Testcase for gnrc using the stm32 eth periph
stm32_eth: Rework netdev driver layour
tests/stm32_eth_*: Use netdev driver header file for prototypes
stm32_eth: Add auto init for stm32 eth netdev driver
boards/stm32: Enable ethernet conf for nucleo boards
stm32_eth_auto_init: Add dont be pendantic flag
stm32_eth: Remove dma specific stuff from periph_cpu.h
Looks like this was implemented in PR #9171 and 021697ae94 with the same interface.
stm32_eth: Remove eth feature from stm32f4discovery boards
stm32_eth: Migrate to stm32 DMA API
stm32_eth: Add iolist to module deps
stm32_eth: Rework send function to use iolist
stm32_eth: Fix ci build warnings
stm32_eth: Fix bug introduced with iolist usage
stm32_eth: Remove redundant static buffer
stm32_eth: Fix feature dependencies
stm32_eth: Fix wrong header guard name
stm32_eth: Implement correct l2 netstats interface
stm32_eth: Rename public functions to stm32_eth_*
stm32_eth: Fix doccheck
stm32_eth: Move register DEFINE to appropriate header file
stm32_eth: remove untested configuration for f446ze boards
stm32_eth: Move periph configuration struct to stm32_common
stm32_eth: Fix naming of eth_phy_read and eth_phy_write
stm32_eth: Remove obsolete test applications
When reworking the reception of IPv6 packets I reset a previously set
`ipv6` snip as follows when the IPv6 extension handler returns a
packet (see first hunk of this commit):
```C
ipv6 = pkt->next->next
```
With `gnrc_ipv6_ext` this makes *somewhat* sense, `pkt->next` was
previously equal to `ipv6` and after the function call `pkt->next`
is the marked extension header, while `pkt->next->next` is the IPv6
header. However, since `ipv6` is already write-protected i.e.
`ipv6->users == 1` (see ll. 665-675), any additional call of
`gnrc_pktbuf_start_write()` [won't][start-write-doc] duplicate the
packet. In fact, the only `gnrc_pktbuf_start_write()` in
`gnrc_ipv6_ext` is used to send the *result* to the subscribers of that
extension header type, leaving the original packet unchanged for the
caller. As such `ipv6` remains the pointer to the IPv6 header whether
we set it in the line above or not. So we actually don't need that
line.
However, the extension header handling also returns a packet when
`gnrc_ipv6_ext` is not compiled in. In that case it is just a dummy
define that returns the packet you give provide it which means that
this still holds true: `pkt->next == ipv6`.
So setting `ipv6` in this case is actually harmful, as `ipv6` now
points to the NETIF header [following the IPv6 header][pkt-structure]
in the packet and this causes the `user` counter of that NETIF header
`hdr` to be decremented if `hdr->users > 1` in the write-protection I
removed in hunk 2 of this commit:
```C
/* pkt might not be writable yet, if header was given above */
ipv6 = gnrc_pktbuf_start_write(ipv6);
if (ipv6 == NULL) {
DEBUG("ipv6: unable to get write access to packet: dropping it\n");
gnrc_pktbuf_release(pkt);
return;
}
```
But as we already established, `ipv6->users` is already 1, so we don't
actually need the write protection here either.
Since the packet stays unchanged after the `ipv6` snip, we also don't
need to re-search for `netif_hdr` after the other two lines are
removed.
[start-write-doc]: https://doc.riot-os.org/group__net__gnrc__pktbuf.html#ga640418467294ae3d408c109ab27bd617
[pkt-structure]: https://doc.riot-os.org/group__net__gnrc__pkt.html#ga278e783e56a5ee6f1bd7b81077ed82a7
Summary for Users
=================
Deprecation is scheduled for 2020.01.
Users which depend on this module and cannot switch libraries may copy
the code into to their own application.
As expressed in PR #11724, the UBJSON module has issues which are not easy
or worth fixing.
Before removing the module, it should be marked as deprecated to give users
time to either migrate to another library, or copy the code to their own
private repo.
The deprecation warning has been supressed from the unit tests. This has the
ugly side-effect of supressing deprecation warning in other unit tests too,
but that should not last long, only until the module is finally deleted.
