On Mon, 19 Oct 2020 15:54:30 -0400
Alexander Aring <alex.aring@xxxxxxxxx> wrote:
> That should fix it.
Thank you, that fixed it indeed!
Well, insofar that I don't get any netlink errors anymore during setup.
I still get
[ 331.928242] ieee802154 phy0 wpan0: encryption failed: -126
[ 332.971098] ieee802154 phy0 wpan0: encryption failed: -126
when trying to send packets. No plaintext traffic is sent either, the
radio just remains silent.
Receiving encrypted frames (from RIOT) also doesn't work (I assumed that mrf24j40
bug was fixed by now)
My complete setup script is
KEY="c0:c1:c2:c3:c4:c5:c6:c7:c8:c9:ca:cb:cc:cd:ce:cf"
WPAN=wpan0
PANID=$(iwpan dev $WPAN info | grep pan_id | head -1 | awk '{print $2}')
SHORTADDR=$(iwpan dev $WPAN info | grep short_addr | head -1 | awk '{print $2}')
EXTADDR=$(iwpan dev $WPAN info | grep extended_addr | head -1 | awk '{print $2}')
iwpan dev $WPAN set security 1
iwpan dev $WPAN key add 2 $KEY 0 $PANID 3 $EXTADDR
iwpan dev $WPAN seclevel add 0xff 1 0
iwpan dev $WPAN device add 0 $PANID $SHORTADDR $EXTADDR 0 0
iwpan dev $WPAN set out_level 0x05
iwpan dev $WPAN set out_key_id 0 $PANID 2 $SHORTADDR 3 $EXTADDR
> > > - 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?
> >
>
> No, just use a monitor interface to see what the on air traffic is.
> Don't trust local captures.
Don't worry, I'm using a CC2531 dongle with whsniff, only looking at
traffic that's actually on the air.
Best,
Benjamin
