On Sun, 18 Oct 2020 19:20:53 -0400 Alexander Aring <alex.aring@xxxxxxxxx> wrote: > 2 is ack frame, I think you mean 1. Same error with 1 > Success? Like above? Can you tell me the command line error message > please? What does tell you "type 1 has an invalid length" dmesg tells me that when I enter that command: [ 156.899429] netlink: 'iwpan': attribute type 1 has an invalid length. So I assume that's why encryption fails. > - Don't trust wireshark, you will not see exactly what's sending out > on the wire. We just do the encryption on the wrong layer, but moving > it was causing other problems. I recently stumbled over something > which maybe can help us there, but didn't look closely at that, some > subsystems have special handling for tcpdump/wireshark things. Would that cause interoperability issues with other implementations? > - The frame_counter thing that you see above needs to be synchronized > on all nodes, if nodes join with a zero value you can do replay > attacks. 802.15.4 doesn't solve that on the link layer for peer to > peer, MLE can do that in a way to just make the attack window smaller. > - When the fame_counter overflows you need a new key, means key > management and key exchange. Biggest problem :-) I was talking with > Koen about that once... he showed me some interesting stuff, forgot > the name.. Urgh this just came up again in https://github.com/RIOT-OS/RIOT/pull/15150 Does the standard suggest anything here? How does Thread solve this? > Please dump more: > > iwpan dev $WPAN_DEV seclevel dump iwpan dev $WPAN_DEV seclevel add 0xff 1 0 > iwpan dev $WPAN_DEV device dump iwpan dev $WPAN_DEV device add 0x00000000 0x0023 0xffff 0x82b989a7f0d5decb 0 0 > iwpan dev $WPAN_DEV devkey dump [nothing] > iwpan dev $WPAN_DEV key dump iwpan dev $WPAN_DEV key add 0x02 c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:ca:cb:cc:cd:ce:cf 0 0x0023 3 0x82b989a7f0d5decb > - Alex Thank you for your help, Benjamin
