From: Alexander Aring <alex.aring@gmail.com>
To: Benjamin Valentin <benjamin.valentin@ml-pa.com>
Cc: linux-wpan - ML <linux-wpan@vger.kernel.org>, koen@bergzand.net
Subject: Re: iwpan with LLSEC - attribute type 1 has an invalid length
Date: Sun, 18 Oct 2020 19:20:53 -0400 [thread overview]
Message-ID: <CAB_54W5VgY+DeqdjiQ7BJsmXw-G=POwGE7tzYuwAwYixe6y9XQ@mail.gmail.com> (raw)
In-Reply-To: <20201018170934.2c03c9e3@rechenknecht2k11>
Hi,
On Sun, 18 Oct 2020 at 11:48, Benjamin Valentin
<benjamin.valentin@ml-pa.com> wrote:
>
> Hi,
>
> I'm trying to use the Linux WPAN stack with link-layer security.
> I checked out the nl802154_llsec branch of wpan-tools and enabled the
> IEEE802154_NL802154_EXPERIMENTAL config option.
>
> I followed the steps outlined in [0], but configuring the seclevel
> would always fail with
>
> > netlink: 'iwpan': attribute type 1 has an invalid length.
>
> in dmesg.
> I followed the commands from the GitHub wiki:
>
> 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 # works fine
> iwpan dev --debug $WPAN key add 2 $KEY 0 $PANID 3 $EXTADDR # works fine
>
> -- Debug: Sent Message:
> -------------------------- BEGIN NETLINK MESSAGE ---------------------------
> [NETLINK HEADER] 16 octets
> .nlmsg_len = 112
> .type = 24 <0x18>
> .flags = 5 <REQUEST,ACK>
> .seq = 1603033315
> .port = 1971323733
> [GENERIC NETLINK HEADER] 4 octets
> .cmd = 23
> .version = 0
> .unused = 0
> [PAYLOAD] 92 octets
> 08 00 03 00 03 00 00 00 54 00 25 00 05 00 02 00 ........T.%.....
> 02 00 00 00 14 00 04 00 c0 c1 c2 c3 c4 c5 c6 c7 ................
> c8 c9 ca cb cc cd ce cf 34 00 01 00 28 00 03 00 ........4...(...
> 06 00 01 00 23 00 00 00 08 00 02 00 03 00 00 00 ....#...........
> 06 00 03 00 00 ab 00 00 0c 00 04 00 8f d7 0c a1 ................
> 9c 41 04 92 08 00 01 00 00 00 00 00 .A..........
> --------------------------- END NETLINK MESSAGE ---------------------------
> -- Debug: Received Message:
> -------------------------- BEGIN NETLINK MESSAGE ---------------------------
> [NETLINK HEADER] 16 octets
> .nlmsg_len = 36
> .type = 2 <ERROR>
> .flags = 256 <ROOT>
> .seq = 1603033315
> .port = 1971323733
> [ERRORMSG] 20 octets
> .error = 0 "Success"
> [ORIGINAL MESSAGE] 16 octets
> .nlmsg_len = 16
> .type = 24 <0x18>
> .flags = 5 <REQUEST,ACK>
> .seq = 1603033315
> .port = 1971323733
> --------------------------- END NETLINK MESSAGE ---------------------------
>
> iwpan --debug dev $WPAN seclevel add 0xff 2 0 # dmesg says attribute type 1 has an invalid length.
>
2 is ack frame, I think you mean 1.
> -- Debug: Sent Message:
> -------------------------- BEGIN NETLINK MESSAGE ---------------------------
> [NETLINK HEADER] 16 octets
> .nlmsg_len = 56
> .type = 24 <0x18>
> .flags = 5 <REQUEST,ACK>
> .seq = 1603033355
> .port = 1535116138
> [GENERIC NETLINK HEADER] 4 octets
> .cmd = 32
> .version = 0
> .unused = 0
> [PAYLOAD] 36 octets
> 08 00 03 00 03 00 00 00 1c 00 22 00 08 00 01 00 ..........".....
> ff 00 00 00 08 00 02 00 02 00 00 00 05 00 04 00 ................
> 00 00 00 00 ....
> --------------------------- END NETLINK MESSAGE ---------------------------
> -- Debug: Received Message:
> -------------------------- BEGIN NETLINK MESSAGE ---------------------------
> [NETLINK HEADER] 16 octets
> .nlmsg_len = 36
> .type = 2 <ERROR>
> .flags = 256 <ROOT>
> .seq = 1603033355
> .port = 1535116138
> [ERRORMSG] 20 octets
> .error = 0 "Success"
Success? Like above? Can you tell me the command line error message
please? What does tell you "type 1 has an invalid length"
> [ORIGINAL MESSAGE] 16 octets
> .nlmsg_len = 16
> .type = 24 <0x18>
> .flags = 5 <REQUEST,ACK>
> .seq = 1603033355
> .port = 1535116138
> --------------------------- END NETLINK MESSAGE ---------------------------
>
> I then continue with
>
> 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
>
> But I can not receive encrypted frames nor can I send any - instead I get
>
> [ 502.970528] ieee802154 phy0 wpan0: encryption failed: -126
> [ 503.972415] ieee802154 phy0 wpan0: encryption failed: -126
>
It tells you -ENOKEY, the whole thing has an ACL and somehow the
lookup cannot find a key (if sec is enabled).
> in dmesg.
>
> iwpan dev wpan0 info gives:
>
> Interface wpan0
> ifindex 3
> wpan_dev 0x1
> extended_addr 0x9204419ca10cd78f
> short_addr 0xffff
> pan_id 0x0023
> type node
> max_frame_retries 3
> min_be 3
> max_be 5
> max_csma_backoffs 4
> lbt 0
> ackreq_default 0
> security 1
> out_level 5
> out_key_id
> mode implicit
> pan_id 0x0023
> addr_mode 2
> short_addr 0xffff
> frame_counter 0x00000000
>
> Is LLSEC broken or am I configuring it wrong?
It's been a long time since I worked with it, it's good to have the
802.15.4 standard right beside you, the implementation is very close
to that structure that they describe.
There are known issues:
- 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.
- 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..
Please dump more:
iwpan dev $WPAN_DEV seclevel dump
iwpan dev $WPAN_DEV device dump
iwpan dev $WPAN_DEV devkey dump
iwpan dev $WPAN_DEV key dump
- Alex
next prev parent reply other threads:[~2020-10-18 23:21 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-18 15:09 iwpan with LLSEC - attribute type 1 has an invalid length Benjamin Valentin
2020-10-18 23:20 ` Alexander Aring [this message]
2020-10-19 6:07 ` Benjamin Valentin
2020-10-19 19:54 ` Alexander Aring
2020-10-19 20:13 ` Benjamin Valentin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB_54W5VgY+DeqdjiQ7BJsmXw-G=POwGE7tzYuwAwYixe6y9XQ@mail.gmail.com' \
--to=alex.aring@gmail.com \
--cc=benjamin.valentin@ml-pa.com \
--cc=koen@bergzand.net \
--cc=linux-wpan@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).