"encryption failed" warnings in dmesg

"encryption failed" warnings in dmesg

[Anton Sviridenko]

I send packets through raw socket on ieee802154 network interface using at86rf212b transceiver
and sometimes get lot of these messages in dmesg:

ieee802154 phy0 wpan0: encryption failed: -22

I've traced place in source that generates them:
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/mac802154/tx.c

Can someone explain what happens?
Isn't it supposed for raw packets to be passed as is? I think if packet is encrypted, 
it should be already encrypted by userspace software that prepared this raw packet.
Btw, software that sends raw packets is OpenThread, I'm trying to run it on Linux,
if that matters

How encryption keys are expected to be set up when encryption is used?
It seems wpan-tools do not contain such commands.

Anton

Re: "encryption failed" warnings in dmesg

[Alexander Aring]

Hi,

On Wed, Mar 7, 2018 at 8:35 AM, Anton Sviridenko <anton@picapica.im> wrote:
> I send packets through raw socket on ieee802154 network interface using at86rf212b transceiver
> and sometimes get lot of these messages in dmesg:
>
> ieee802154 phy0 wpan0: encryption failed: -22
>
> I've traced place in source that generates them:
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/mac802154/tx.c
>
> Can someone explain what happens?
> Isn't it supposed for raw packets to be passed as is? I think if packet is encrypted,

it should be, but what you see... yea no. This is a very long
discussion what's is wrong in encryption/decryption handling... it's
made in the wrong places and move it away from it need to solve other
issues - sorry nobody really works on llsec at the moment.

> it should be already encrypted by userspace software that prepared this raw packet.
> Btw, software that sends raw packets is OpenThread, I'm trying to run it on Linux,
> if that matters
>

Yes I did already the same several years ago... See [0].

You need to use monitor interfaces to make it somehow working but be prepared:

1. no hardware address filtering
2. no hardware ack handling

Have fun!

We really like to support Thread stuff on socket layer... and _NOT_ as
user space stack.

> How encryption keys are expected to be set up when encryption is used?
> It seems wpan-tools do not contain such commands.
>

There is a hacky experimental branch. Please prepared:

1. frame counter sync is not defined by peer to peer networks

IEEE doesn't solve this practical issue:

I have a very strong opinion about it:

IETF solved it with MLE, MLE was shutting down, MLE lives still (as a
fork in Thread) which is _closed_ spec.
It was myself a surprise that the MLE is a fork and they made it
forced incompatible with IETF MLE.
Welcome to the world of politics in open standards, where people use
all open standards _except_ the bootstrapping protocol which is
necessary to make something working.

In my opinion Thread should be look more on what they doing on top of
transport layer and rest should be open, but this isn't the case...

2. Framecounter overflow -> you need to distribute new keys

---
Now what I want to see:

I am not part of Thread group and I don't want to be, because I am
sure it doesn't allow me to do open source stuff anymore in some parts
and then I don't know what I can do and what I can't.
I also don't have the money for that.

IDEA, (because we need to deal with that SOMEHOW):

Use open implementation OpenThread and make a library wrapper around
it to use MLE stuff in Linux as daemon and _important_ use Linux stack
and please don't use user space stacks!
I did this [0] for development.

This is my opinion on what way we need to go to provide Thread in Linux.

(btw: my talk at netdev2.1 in Montreal exactly was about MLE and the
mess that we need to support it to talk with "commercial" products
outside) [1]

I am close to release my stuff from [2] which makes the development a
lot of easier.

- Alex

[0] https://groups.google.com/forum/#!msg/openthread-users/BXOk9JfDsqY/r4E6T5RmBwAJ
[1] https://www.youtube.com/watch?v=rseB3PsPWHg
[2] https://www.youtube.com/watch?v=iMYCaqHVmS0

Re: "encryption failed" warnings in dmesg

[anton]

On Wed, Mar 07, 2018 at 10:43:09AM -0500, Alexander Aring wrote:

> 
> You need to use monitor interfaces to make it somehow working but be prepared:
> 
> 1. no hardware address filtering
> 2. no hardware ack handling
> 
> Have fun!
> 

Thank you for detailed answer, can you give more info about why monitor interface is
required?

Anton

Re: "encryption failed" warnings in dmesg

[Alexander Aring]

Hi,

On Sat, Mar 10, 2018 at 12:29 PM,  <anton@picapica.im> wrote:
> On Wed, Mar 07, 2018 at 10:43:09AM -0500, Alexander Aring wrote:
>
>>
>> You need to use monitor interfaces to make it somehow working but be prepared:
>>
>> 1. no hardware address filtering
>> 2. no hardware ack handling
>>
>> Have fun!
>>
>
> Thank you for detailed answer, can you give more info about why monitor interface is
> required?
>

There exists two filter mechanism:

 - Hardware (e.g. address filter, CRC, etc.)
 - Software (e.g. address filter, CRC, etc.)

Of course we do it again in Software, because we don't trust hardware filters...
Anyway advantage of hardware filters is only: you get less IRQs

With monitor interfaces you disable hardware side and Software side as
well... (CRC on tx not, but this is another issue which we cannot
change directly..., because UAPI changes. Anyway we need to fix this
mess somehow).

NOW... some feature which I have in my mind but doesn't exists yet...

Disable Software filter and enable Hardware filters... Then using RAW sockets...
_IMPORTANT_ Then address settings of user space stacks e.g.
OpenThread, RIOT need to be in sync with Hardware (which is possible
by doing some netlink foo).

Anyway this goes too far for me and is a use case for running user
space stacks only, which means: I don't like it, but I think we could
accept such feature... It's just node interface without monitor...

- Alex

Re: "encryption failed" warnings in dmesg

[Alexander Aring]

Hi,

I need to correct some stuff.

On Sat, Mar 10, 2018 at 6:43 PM, Alexander Aring <aring@mojatatu.com> wrote:
> Hi,
>
> On Sat, Mar 10, 2018 at 12:29 PM,  <anton@picapica.im> wrote:
>> On Wed, Mar 07, 2018 at 10:43:09AM -0500, Alexander Aring wrote:
>>
>>>
>>> You need to use monitor interfaces to make it somehow working but be prepared:
>>>
>>> 1. no hardware address filtering
>>> 2. no hardware ack handling
>>>
>>> Have fun!
>>>
>>
>> Thank you for detailed answer, can you give more info about why monitor interface is
>> required?
>>
>
> There exists two filter mechanism:
>
>  - Hardware (e.g. address filter, CRC, etc.)
>  - Software (e.g. address filter, CRC, etc.)
>
> Of course we do it again in Software, because we don't trust hardware filters...

CRC is offloaded by hardware, address we do again, because we need to
parse it anyway.

> Anyway advantage of hardware filters is only: you get less IRQs
>
> With monitor interfaces you disable hardware side and Software side as
> well... (CRC on tx not, but this is another issue which we cannot
> change directly..., because UAPI changes. Anyway we need to fix this
> mess somehow).
>
> NOW... some feature which I have in my mind but doesn't exists yet...
>
> Disable Software filter and enable Hardware filters... Then using RAW sockets...
> _IMPORTANT_ Then address settings of user space stacks e.g.
> OpenThread, RIOT need to be in sync with Hardware (which is possible
> by doing some netlink foo).
>
> Anyway this goes too far for me and is a use case for running user
> space stacks only, which means: I don't like it, but I think we could
> accept such feature... It's just node interface without monitor...
>

s/monitor/promiscuous mode/

promiscuous mode according 802.15.4 -> disable all filtering

If we do that we need to disable AACK, but node without software
filtering will still have AACK and address filter... but to make it
work with user space stack -> you need to held them (addresses) in
sync with 802.15.4 MAC layer.

- Alex

Re: "encryption failed" warnings in dmesg

[anton]

On Sat, Mar 10, 2018 at 11:49:44PM -0500, Alexander Aring wrote:
> Hi,
> 
> I need to correct some stuff.
> 
> On Sat, Mar 10, 2018 at 6:43 PM, Alexander Aring <aring@mojatatu.com> wrote:
> > Hi,
> >
> > On Sat, Mar 10, 2018 at 12:29 PM,  <anton@picapica.im> wrote:
> >> On Wed, Mar 07, 2018 at 10:43:09AM -0500, Alexander Aring wrote:
> >>
> >>>
> >>> You need to use monitor interfaces to make it somehow working but be prepared:
> >>>
> >>> 1. no hardware address filtering
> >>> 2. no hardware ack handling
> >>>
> >>> Have fun!
> >>>
> >>
> >> Thank you for detailed answer, can you give more info about why monitor interface is
> >> required?
> >>
> >
> > There exists two filter mechanism:
> >
> >  - Hardware (e.g. address filter, CRC, etc.)
> >  - Software (e.g. address filter, CRC, etc.)
> >
> > Of course we do it again in Software, because we don't trust hardware filters...
> 
> CRC is offloaded by hardware, address we do again, because we need to
> parse it anyway.
> 
> > Anyway advantage of hardware filters is only: you get less IRQs
> >
> > With monitor interfaces you disable hardware side and Software side as
> > well... (CRC on tx not, but this is another issue which we cannot
> > change directly..., because UAPI changes. Anyway we need to fix this
> > mess somehow).
> >
> > NOW... some feature which I have in my mind but doesn't exists yet...
> >
> > Disable Software filter and enable Hardware filters... Then using RAW sockets...
> > _IMPORTANT_ Then address settings of user space stacks e.g.
> > OpenThread, RIOT need to be in sync with Hardware (which is possible
> > by doing some netlink foo).
> >
> > Anyway this goes too far for me and is a use case for running user
> > space stacks only, which means: I don't like it, but I think we could
> > accept such feature... It's just node interface without monitor...
> >
> 
> s/monitor/promiscuous mode/
> 
> promiscuous mode according 802.15.4 -> disable all filtering
> 
> If we do that we need to disable AACK, but node without software
> filtering will still have AACK and address filter... but to make it
> work with user space stack -> you need to held them (addresses) in
> sync with 802.15.4 MAC layer.
> 
> - Alex

Ok, but why exactly hardware filtering cannot be used?
OpenThread sets it's own extended addr/short addr/pan_id,
so I tried some probably hacky way - when these settings
are changed by OpenThread, I delete interface and create
new one, with new extended addr, pan_id and short_addr,
using system() call and calling "iwpan" with appropriate args.
Then raw socket is reopened on a new interface.
Seems working so far, at least instances are able to see each
other, pair up and even occasionally ping each other from CLI.
Maybe more proper way is to set everything over netlingk,
but seems that extended addr cannot be changed on the fly anyway,
without bringing interface down

Re: "encryption failed" warnings in dmesg

[Alexander Aring]

Hi,

2018-03-11 8:37 GMT-04:00  <anton@picapica.im>:
> On Sat, Mar 10, 2018 at 11:49:44PM -0500, Alexander Aring wrote:
>> Hi,
>>
>> I need to correct some stuff.
>>
>> On Sat, Mar 10, 2018 at 6:43 PM, Alexander Aring <aring@mojatatu.com> wrote:
>> > Hi,
>> >
>> > On Sat, Mar 10, 2018 at 12:29 PM,  <anton@picapica.im> wrote:
>> >> On Wed, Mar 07, 2018 at 10:43:09AM -0500, Alexander Aring wrote:
>> >>
>> >>>
>> >>> You need to use monitor interfaces to make it somehow working but be prepared:
>> >>>
>> >>> 1. no hardware address filtering
>> >>> 2. no hardware ack handling
>> >>>
>> >>> Have fun!
>> >>>
>> >>
>> >> Thank you for detailed answer, can you give more info about why monitor interface is
>> >> required?
>> >>
>> >
>> > There exists two filter mechanism:
>> >
>> >  - Hardware (e.g. address filter, CRC, etc.)
>> >  - Software (e.g. address filter, CRC, etc.)
>> >
>> > Of course we do it again in Software, because we don't trust hardware filters...
>>
>> CRC is offloaded by hardware, address we do again, because we need to
>> parse it anyway.
>>
>> > Anyway advantage of hardware filters is only: you get less IRQs
>> >
>> > With monitor interfaces you disable hardware side and Software side as
>> > well... (CRC on tx not, but this is another issue which we cannot
>> > change directly..., because UAPI changes. Anyway we need to fix this
>> > mess somehow).
>> >
>> > NOW... some feature which I have in my mind but doesn't exists yet...
>> >
>> > Disable Software filter and enable Hardware filters... Then using RAW sockets...
>> > _IMPORTANT_ Then address settings of user space stacks e.g.
>> > OpenThread, RIOT need to be in sync with Hardware (which is possible
>> > by doing some netlink foo).
>> >
>> > Anyway this goes too far for me and is a use case for running user
>> > space stacks only, which means: I don't like it, but I think we could
>> > accept such feature... It's just node interface without monitor...
>> >
>>
>> s/monitor/promiscuous mode/
>>
>> promiscuous mode according 802.15.4 -> disable all filtering
>>
>> If we do that we need to disable AACK, but node without software
>> filtering will still have AACK and address filter... but to make it
>> work with user space stack -> you need to held them (addresses) in
>> sync with 802.15.4 MAC layer.
>>
>> - Alex
>
> Ok, but why exactly hardware filtering cannot be used?
> OpenThread sets it's own extended addr/short addr/pan_id,
> so I tried some probably hacky way - when these settings
> are changed by OpenThread, I delete interface and create
> new one, with new extended addr, pan_id and short_addr,
> using system() call and calling "iwpan" with appropriate args.
> Then raw socket is reopened on a new interface.

Yes that's what I said with "the user space stack need to be in sync
with MAC layer".

> Seems working so far, at least instances are able to see each
> other, pair up and even occasionally ping each other from CLI.

be prepared that the kernel will filter some stuff, you should change
it that it will not do it. I think we would accept a patch to make
that possible. The kernel is filtering -> you don't running a user
space stack.

> Maybe more proper way is to set everything over netlingk,
> but seems that extended addr cannot be changed on the fly anyway,
> without bringing interface down
>

The reason why we don't change address filtering at runtime is that we
are in RX mode and we don't change RX parameters when we are in
receive mode. If OpenThread, RIOT, etc. do that it's fine, but I see
problems with that.

- Alex

Re: "encryption failed" warnings in dmesg

[anton]

On Sun, Mar 11, 2018 at 09:34:39AM -0400, Alexander Aring wrote:
> 
> > Seems working so far, at least instances are able to see each
> > other, pair up and even occasionally ping each other from CLI.
> 
> be prepared that the kernel will filter some stuff, you should change
> it that it will not do it. I think we would accept a patch to make
> that possible. The kernel is filtering -> you don't running a user
> space stack.

I tried to remove llsec_encrypt/llsec_decrypt from kernel, recompiled/rebooted,
pings started passing only after that, but still not all IPv6 addresses are pingable.
Seems that half of the packets are still filtered out somewhere.
What could be the other possible places in kernel where raw packets can be dropped?

Now I am trying to compare tcpdump dumps from both devices, with "node" type interfaces.

> 
> > Maybe more proper way is to set everything over netlingk,
> > but seems that extended addr cannot be changed on the fly anyway,
> > without bringing interface down
> >
> 
> The reason why we don't change address filtering at runtime is that we
> are in RX mode and we don't change RX parameters when we are in
> receive mode. If OpenThread, RIOT, etc. do that it's fine, but I see
> problems with that.
> 
> - Alex

Re: "encryption failed" warnings in dmesg

[Alexander Aring]

Hi,

2018-03-11 13:30 GMT-04:00  <anton@picapica.im>:
> On Sun, Mar 11, 2018 at 09:34:39AM -0400, Alexander Aring wrote:
>>
>> > Seems working so far, at least instances are able to see each
>> > other, pair up and even occasionally ping each other from CLI.
>>
>> be prepared that the kernel will filter some stuff, you should change
>> it that it will not do it. I think we would accept a patch to make
>> that possible. The kernel is filtering -> you don't running a user
>> space stack.
>
> I tried to remove llsec_encrypt/llsec_decrypt from kernel, recompiled/rebooted,
> pings started passing only after that, but still not all IPv6 addresses are pingable.
> Seems that half of the packets are still filtered out somewhere.
> What could be the other possible places in kernel where raw packets can be dropped?
>

You do it too hacky, look how monitor tx and rx works... they have
different callbacks and are not changable during runtime *yet*.

> Now I am trying to compare tcpdump dumps from both devices, with "node" type interfaces.

The tip above is the only thing what I can give you... you need to
disable all software side filtering up to AF_PACKET raw layer (I hope
you don't use af802154 raw - it's terrible broken).

---

I will not respond anymore to this mail, I gave you all my
knowledge... it would for me very simple for me to implement it, but
the last years I discovered more and more: "freelancer ask questions,
I implement - because fun" and their make profit about it. So I _only_
want to implement stuff which makes this subsystem as a benefit.
Running user space stacks is not a benefit to this subsystem, so I am
not interested.

Sorry :-(

- Alex