After testing the slipdev driver on a nucleo-f446, it appeared to me as if an extra 0xFF byte is transmitted by the UART driver. As somewhat described in #8041 (comment), this can be explicitly triggered with slipdev by having the node transmit a frame. An initial 0xff byte should appear as first byte (and by doing so crash the tunslip6 application).

More a suspicion than a confirmed bug, it would help if somebody can reproduce this (or refute this bug), I still have to test if this 0xff byte is also added to the UART interface of the shell.

Oh and close and ignore this issue if it is caused by the low on reset nature of the hardware and the active-low of UART.