slip radio not sending data to RF channel afetr AES encryption enable in 6lbr

[bbhagasra1]

is there any change in slip radio for AES encryption enable.

[msolters]

This problem still presents itself on the develop branch of 6LBR. When I configure the BR like so:

And then configure my nodes as such:

#undef LLSEC802154_CONF_ENABLED
#define LLSEC802154_CONF_ENABLED           1
#undef NETSTACK_CONF_FRAMER
#define NETSTACK_CONF_FRAMER              noncoresec_framer
#undef NETSTACK_CONF_LLSEC
#define NETSTACK_CONF_LLSEC               noncoresec_driver
#undef NONCORESEC_CONF_SEC_LVL
#define NONCORESEC_CONF_SEC_LVL           7

#define NONCORESEC_CONF_KEY { 0x00 , 0x01 , 0x02 , 0x03 , \
                              0x04 , 0x05 , 0x06 , 0x07 , \
                              0x08 , 0x09 , 0x0A , 0x0B , \
                              0x0C , 0x0D , 0x0E , 0x0F }

I stop seeing any wireless_input traffic in /etc/6lbr/6lbr.log, and the nodes lose their route to the internet. I also get a lot of br-rdc: send failed, slip ack timeout messages.

On the node side, I have started exploring different PRs such as https://github.com/contiki-os/contiki/pull/1425. Should I be recompiling 6LBR against these PRs as well??

[laurentderu]

The inclusion of LLSEC into 6LBR had unforeseen consequences, the previous fix needed modification in the slip-radio, otherwise the slip-radio would drop the packets.

I pushed today a better fix that completely isolate the slip-radio from the LLSEC modifications, could you give a try ? Btw, modifications in #1425 are conflicting with some of the modifications in 6LBR that we made in the past to achieve the same result. It should be unified again in the next merge from Contiki.

[msolters]

I am compiling a fresh develop branch now. Can you please clarify: should I use the slip-radio from the official Contiki master, or should I compile the slip-radio from 6LBR?

[laurentderu]

You can recompile it from 6LBR tree, but a standard slip-radio from Contiki should work too with this fix.

[msolters]

Yes! It works, using the following configuration!

• Raspberry Pi: using a freshly compiled develop branch with your latest commits.
• Slip radio: CC2650 compiled against Contiki master branch
• Node: CC2650, compiled against Contiki master & including https://github.com/contiki-os/contiki/pull/1425 (see above project-conf.h)

A million thanks.

[msolters]

Actually, I have discovered a (in my case severe) limitation. It seems this only works for UDP datagrams up to (about) 47 bytes.

I have a node that is simply emitting UDP datagrams with strings:

char msg[47] = "some fixed text...";
 uip_udp_packet_send(udp_client_conn, msg, strlen(msg));

In this case udp_client_conn corresponds to a UDP connection with the host of 6LBR (a UDP server on the raspberry pi).

• Without encryption, this works fine: even when msg is many hundreds of bytes long.
• When I enable encryption, any msg up to about 46 bytes long reliably is seen by 6LBR and forwarded on as appropriate. However, for any message 47 bytes or longer it becomes highly unreliable -- over 99% loss. It seems that only one UDP packet is encrypted and sent, then decrypted and read by 6LBR, and then no more.

I don't know if this is a 6LBR issue or an issue with Contiki on the devices. All I know is that is encryption-specific.

[laurentderu]

If you don't have slip-radio errors, this looks like more a 6LoWPAN fragmentation issue. The default parameter in Contiki is to drop fragmented packet when another packet, not related to the message being reassembled is received. So, if you have some traffic on your network this could cause all fragmented packet to be dropped. There is a pending PR on Contiki to solve this properly.

A workaround is to change the default policy : in sicslowpan.c, change PRIORITIZE_NEW_PACKETS to 0

[msolters]

I don't think that's what's causing this. If you mean this PR (https://github.com/contiki-os/contiki/pull/1258) it's been merged already.

There is no instance of PRIORITIZE_NEW_PACKETS anywhere in Contiki's master branch.

I wonder if altering the packet's attributes, as was done to fix this issue, somehow caused further problems for the fragmentation assembly process?

[msolters]

So I've made this reproducible. I am using

• CC2650 for the slip-radio (built against Contiki master)
• CC2650 node, running this simple contiki example: https://github.com/msolters/encrypted-udp-test
• Latest develop 6LBR

I also set DEBUG to DEBUG_FULL inside sicslowpan.c in the node, so that I could see what I (think) is actually being sent. I found something very interesting.

Encryption off

In the case of encryption being off for both 6LBR and the node, I see full output from sicslowpan.c debugging, and I see the traffic in the 6LBR log.

Encryption on

Once I turn on encryption (for both) however, I stop seeing the traffic in 6LBR. And, regardless of the length of the message I am sending, sicslowpan.c debug output becomes like this:

Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
sicslowpan output: sending packet len 46
sicslowpan output: header of len 41
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]
Client sending to: [bbbb:0000:0000:0000:0000:0000:0000:0001] (msg: aaaaaaaaaaaaaaaaaaa ) [20]

(Client sending to... is my application printing out that it is calling the UDP transmission method, in this case with a msg 20 bytes long.)

So, with encryption, the node keeps claiming it is sending UDP packets (uip_udp_packet_send()), but sicslowpan.c only claims an IP packet is being sent after very many such calls, and it reports that the packet being sent is 46 chars long, regardless of msg length! It does not indicate any fragmentation (which does occur without encryption), and I don't see the traffic on 6LBR.

[laurentderu]

I tried using your code and latest Contiki, I have the same issue, the few frames coming out of the node are wrong (e.g. the frame type is set to beacon iso data) and incoming data is corrupted either when entering 6LoWPAN layer (wrong dispatch byte).

When I recompile your code in 6LBR tree, it works without issue using encryption (You need an additional define : #define LLSEC802154_CONF_SECURITY 1) and the frames are correctly decrypted by Wireshark, so I believe they are correct.

So I think there is a bug in the latest llsec framer.

[msolters]

I'm having a hard time getting that code to run by compiling under 6LBR as you asserted.

I can compile by changing the BOARD=sensortag (without /cc2650), and it flashes just fine to a sensortag, but I get no response. No UART output via debugger pack, nor any apparent radio traffic.

Same goes for compiling for BOARD=srf06. Neither of these boards give any UART output.

This is true across all the examples. The one I provide here, ipv6/slip-radio, cc26xx-demo, etc. If I compile under 6LBR develop the cc2650 just does nothing.

Have you made any changes to your CC26XX source under your tree? Did you add or change any additional configuration data?

UPDATE: I can get UART working on the srf06 board. So my results are:

• security disabled: I get radio traffic in the 6LBR router
• security enabled: no radio traffic detected by 6LBR

[msolters]

@laurentderu, do you think you could confirm that those packets you sniffed with Wireshark are actually showing up in 6LBR's log?

[laurentderu]

I don't think you can see them in 6LBR log, as the frame are non standard, I think the framer drops them. (Or maybe wireshark displayed garbage, that's always a possibility). I'll try again in Cooja to see what's going on

[msolters]

Yes the problem here is that compiling this test application under 6LBR causes total packet failure on my side.

And worse, even if compiling the node applications under 6LBR worked, it would not be a viable solution because the Contiki master branch contains many, many hardware & driver improvements such as energy usage that are not present in 6LBR.

Turning on encryption in the 6LBR router causes me to miss

• 100% of packets send from a 6LBR-compiled app
• 100% of packets 46 bytes and greater in a Contiki-compiled app.

[laurentderu]

I'm missing something obvious because, pinging using 200 bytes payload is working with encryption as well as CoAP in the 6LBR non regression tests

[msolters]

Ok;

1. would you mind showing me the exact project-conf.h you are using?
2. you are using a fresh clone of the latest develop branch of 6LBR for this testing?
3. what tree was your slip-radio compiled under?

Pursuant to the third point here I would like to point out that under no conditions can I get any application compiled under 6LBR tree with BOARD=sensortag to work with UART, which means I cannot compile slip-radio under 6LBR for the sensortag.

[laurentderu]

It's indeed the latest develop from github, and the project-conf.h is available in examples/6lbr-demo. I modified it to enable llsec and use level 7.

[msolters]

I really don't understand. I built 6lbr-demo as you suggest, WITH_LLSEC=1 (and security level changed to 7), and it does not function with encryption at all. There must be some difference in our configurations!

Could you answer the third question? Were you using a slip-radio built under Contiki or 6LBR? I have tried both with no success. As soon as encryption is turned on in the 6LBR web control panel, I stop receiving both encrypted and non-encrypted traffic.

[msolters]

So I've just recompiled 6LBR itself from a fresh clone, on a different PC. As soon as encryption is enabled on the client node, the slip radio stops reporting any wireless input, regardless of whether encryption is enabled in the 6LBR web console.

I'm becoming fairly confident this is a slip radio localized problem, which brings me back to my question as to what you are using and under what branch you are compiling the slip radio software to get a working configuration.

[laurentderu]

The error was actually quite trivial, in your project-conf.h, you don't define the NETSTACK_FRAMER as noncoresec_framer, and so your frame are not encrypted/decrypted at all.

If you add :

#undef NETSTACK_CONF_FRAMER
#define NETSTACK_CONF_FRAMER noncoresec_framer

it works properly using your example and latest contiki master.

To answer your third question, I tested with a pure contiki slip-radio, the purpose of the original fix was to be able to use again standard slip-radio even with LLSEC enabled.

[msolters]

Yes, you are absolutely correct -- that line is critical! Unfortunately, that does not fix the actual problem here. (Notice even that even in my first comment here, https://github.com/cetic/6lbr/issues/115#issuecomment-188511267, I was using noncoresec_framer.)

Ensuring I do not forget that that line again, the behaviour is as follows:

• I can see in sicslowpan.c that my encrypted packets are now being fragmented and sent! Before I wasn't even getting those messages.
• However, messages 47 characters and longer are still "ignored" by 6LBR. They just don't show up as wireless_input, where all messages less than 47 chars are received.

[laurentderu]

Indeed, I didn't no check and so I kept the default packet size of 20 byte, hence I did not test the same setup as you (It's easy to lose track of thing in a lengthy discussion). I will retest and come back to you

[laurentderu]

Actually, it's a Contiki bug in LLSEC (see https://github.com/contiki-os/contiki/issues/1537)

A quick workaround is to comment the condition in add_security_header() in noncoresec.c

[msolters]

Almost! Commenting out the condition as suggested does fix the issue insofar as now I can transmit UDP datagrams many hundreds of bytes.

BUT... It requires me to restart the slip-radio! Here's an example test:

1. I am running the encrypted-udp-test program with MSG_LENGTH=50 or some other number
2. I am receiving the encrypted, fragmented packets correctly in 6LBR
3. I recompile encrypted-udp-test program with a different MSG_LENGTH. Longer or shorter, it does not matter. Let's just say 200.
4. All of a sudden, I stop receiving the new packets.
5. If I restart 6LBR, I start receiving the packets again!

I wonder if the modifications we've made here to 6LBR cause it to hang if we receive some of the fragments of a packet but not all of them? Which is to say, when I flash the modified binary to my sensortag, it might interrupt the uC mid-packet transmission, and so the slip-radio is waiting for another fragment. But that fragment never comes, so we must force-restart it by restarting 6LBR?

[laurentderu]

Well, that looks like the normal behaviour of 'noncoresec'. The anti replay mechanism of 'noncoresec' does not support node reboot, the whole network has to be restarted. There is a workaround in the develop branch of 6LBR that should help, but it's not the best. (What's strange is that it should have worked in your case) A new llsec layer, adaptivesec, that will solve this issue correctly, should be included soon in Contiki.

Btw, the slip-radio, rdc, csma and sicslowpan are all protected by timeouts, so the BR or the slip-radio should never get stuck.

[msolters]

Aha! Well then, it seems we just have this one bug in Contiki to contend with to get noncoresec functional with 6LBR and we can close this issue.

However, I do have one final question regarding adaptivesec. I have looked at that source over at https://github.com/kkrentz/contiki. My question is, would not that layer have to be merged into 6LBR itself as well? It seems fairly trivial to pull this into Contiki but I'd imagine 6LBR will require a bit more configuration?

[msolters]

I've been playing around with the two new settings in develop -- disable anti-replay & anti-replay reboot workaround.

Turning on both features, I can reboot a node once and it will then rejoin the mesh! Awesome!

But if I reboot it again, it does not work. It stops showing up as wireless_input in the 6LBR log.

It seems the device will sometimes or perhaps eventually rejoin the mesh, but it can take many minutes sometimes. I waited for at least 10 minutes once with no luck, but in other cases the second reboot takes about 5 minutes for the device to be recognized again.

Is this perhaps the result of some sort of "backing off" time-dependent factor?

[laurentderu]

Actually you have to also disable the anti-replay, or copy the workaround, in the mote too. Otherwise the mote will reject the 6LBR until the counter reach the previous value.

[laurentderu]

Integrating adaptivesec would solve the issue properly, but it's not a trivial merge. So it has to wait the release of 1.4.0 and the following merge.

[msolters]

OK, I understand. Well, how would I approach implementing the anti-replay fix in the motes (other than compiling under the 6LBR tree)? There's a lot of commits so I'm not too sure what specific changes I should be folding in.

[laurentderu]

You should copy the modification in noncoresec.c from https://github.com/cetic/6lbr/commit/6c09e0dc4d9cf581247b084b8f32fe181e3302e8 and in your project-conf.h either disable anti replay or activate the workaround.

[msolters]

Hi @laurentderu, just wondering now that 1.4.0 is released what the status of encryption (adaptivesec) is here in 6LBR land? I also saw the frame counter issue was opened in the main Contiki tree.

[laurentderu]

The roadmap is to have first a stable 6LBR rebased on the latest Contiki, once done I'll look at integration adaptive sec or at least a subset of it.

[msolters]

Hi @laurentderu I am back at it again with @kkrentz 's adaptivesec PR for Contiki.

I've had a small amount of success today, and most of the struggle seems to be centered around the SLIP radio.

I left some comments at the end of the PR describing the results when a SLIP radio compiled with adaptivesec is paired with 6LBR (SLIP radio is a sensortag in this case).

• I'm pretty sure it all comes down to getting the right combination of MAC, RDC and FRAMER configurations such that adaptivesec and 6LBR are both happy.
• There is the second sub problem of whether or not 6LBR must also have some form of LLSEC enabled (?) to understand the wireless_input if its coming from adaptivesec through a nullrdc SLIP radio. And to what extent perhaps this can be done through the web interface?

I am going to continue probing this to try to get better traffic out of this SLIP radio, but I wonder if you might have any insight on this matter, esp. what kind of RDC and MAC configuration I should be using for a SLIP radio to work nicely with 6LBR. (Generally, with 6LBR, i use nullmac and nullrdc...)

adaptivesec certainly looks like it has become more or less complete judging by other people's experiences (who are not using SLIP radios), and I bet a lot of other people would appreciate its utility if we can get it up and running in 6LBR.

[msolters]

Well, after a time consuming but fruitful session of testing I have identified at least one usable configuration.

• 6LBR: Router mode, MAC is CSMA, no LLSEC
• SLIP radio: CC2650, built against vanilla Contiki, with @kkrentz's adaptivesec PR merged in
• Mesh nodes: Built against vanilla Contiki, with @kkrentz's adaptivesec PR merged in

I have tested using SEC_LVL (adaptivesec specific terminology) set to 2 (authentication) and 7 (authentication + encryption); both work, so long as all mesh nodes AND the SLIP radio have the same SEC_LVL. Any mismatch, and the SLIP radio stops picking up any wireless_input.

Here's how I built it.

First, I defined an encryption.h:

#undef NETSTACK_CONF_MAC
#define NETSTACK_CONF_MAC     csma_driver

#undef NETSTACK_CONF_RDC
#define NETSTACK_CONF_RDC nullrdc_driver

#if ENABLE_ADAPT_SEC
  #undef ADAPTIVESEC_CONF_UNICAST_SEC_LVL
  #define ADAPTIVESEC_CONF_UNICAST_SEC_LVL 7
  #undef ADAPTIVESEC_CONF_BROADCAST_SEC_LVL
  #define ADAPTIVESEC_CONF_BROADCAST_SEC_LVL 7
  #define SINGLE_CONF_KEY { 0x00 , 0x01 , 0x02 , 0x03 , \
    0x04 , 0x05 , 0x06 , 0x07 , \
    0x08 , 0x09 , 0x0A , 0x0B , \
    0x0C , 0x0D , 0x0E , 0x0F }

  #undef CSPRNG_CONF_SEEDER
  #define CSPRNG_CONF_SEEDER iq_seeder

  #include "net/llsec/adaptivesec/noncoresec-autoconf.h"
#endif

I included this into the project-conf.h of BOTH the slip-radio as well as the Contiki firmware I was using for my mesh nodes.

Then, I added the following to the Makefile for both the slip-radio as well as the Contiki firmware I was using for my mesh nodes:

ifeq ($(ADAPTIVESEC),1)
    CFLAGS += -DENABLE_ADAPT_SEC=1
    MODULES += core/net/llsec/adaptivesec
endif

Thus, I was able to add a ADAPTIVESEC=1 argument to my make commands to easily build devices with or without adaptivesec. e.g.:

make TARGET=srf06-cc26xx BOARD=sensortag/cc2650 slip-radio.bin ADAPTIVESEC=1

By default, vanilla Contiki slip-radio does not properly implement the make clean command. Make sure to manually delete the obj_* build output directory in examples/ipv6/slip-radio or else you will get adaptivesec compile errors.

Lastly, I had to make some modifications to the SLIP radio source as per https://github.com/contiki-os/contiki/pull/1703#issuecomment-278323905.

Finally, building both SLIP radio and my node firmware with ADAPTIVESEC=1 arguments, I was able to use the SLIP radio with 6LBR, and it picked up traffic from the mesh nodes! Unfortunately, this means the SLIP radio will reject (or ignore?) any traffic originating from devices without the appropriate adaptivesec configuration. Arguably, for most applications, this is acceptable (so what if it doesn't pick up other traffic? We only care about our own, secure data...).

I tried a lot of different combinations for the NETSTACK_CONF_MAC and NETSTACK_CONF_RDC for both the SLIP radio and the mesh nodes before arriving at this recipe. I do not fully understand why only csma_driver works (or conversely, why other combinations such as using nullmac_driver do not work) but I wanted to document this for others who may be looking at implementing encryption in 6LBR moving forward.

Perhaps @kkrentz can tell us more, but either way, this is a proof of concept and a place to start. Adaptivesec can be used with 6LBR, even through a SLIP radio, with native Contiki applications.

[msolters]

Hi @laurentderu, I have been going through the adaptivesec implementation already existing in 6LBR's develop branch. I have also created a branch wherein I have merged the latest adaptivesec changes from @kkrentz, taking care to try not to break any 6LBR specific changes.

adaptivesec does indeed work by simply enabling it via 6LBR's web interface! Selecting akes as the LLSEC security, and ensuring the key matches the single conf key defined in the Contiki nodes, I am able to successfully send messages with adaptivesec enabled, from mesh nodes -> 6LBR.

The nodes show up in the sensors page of 6LBR as well. It can take up to 20-30 seconds sometimes before the traffic begins to be recognized.

However, for some reason, I cannot manage to send anything from 6LBR -> mesh nodes. I can't ping6 them, make CoAP requests to the nodes, nothing. (However, I can successfully make a CoAP request from the nodes to the border router!) I am sure that my routes are all in place between my aaaa:: and bbbb:: subnets.

If I make requests to the nodes, I do see wireless_input almost immediately come back (e.g. right after I start ping6 I begin getting a regular stream of wireless_input). But, no frames appear to ever be routed to any of the services waiting for the requests. How should I proceed to debug this?

On the Contiki node side, I definitely see a lot of this type of akes activity:

akes: broadcasting HELLO
akes: Received HELLO
...
akes: Received HELLO
akes: Will send HELLOACK in 4s
akes: Sending HELLOACK
akes: Received ACK

et. cetera. But I think that may be surrounding the node -> 6lbr traffic, which does work...

[imashoksundar]

Hi @msolters ,

I did all the changes that you've mentioned here, in slip radio and the mesh node firmware but still I'm unable to see the sensors in the sensors web page of 6lbr. (I've tried refreshing the page and looked for more than 5 mins) I've found this in my 6lbr log file,

2017-04-15 11:10:32.050290: INFO: LLSEC: Using 'adaptivesec' framer 2017-04-15 11:10:32.050296: INFO: LLSEC: Using 'adaptivesec (noncore)' llsec strategy 2017-04-15 11:10:32.050302: INFO: LLSEC: Using 'adaptivesec (noncore)' llsec driver 2017-04-15 11:10:32.050384: INFO: 6LBR: Tentative local IPv6 address fe80::212:4b00:60e:31f4 2017-04-15 11:10:32.050403: INFO: 6LBR: Tentative global IPv6 address (WSN) fd00::212:4b00:60e:31f4 2017-04-15 11:10:32.050419: INFO: 6LBR: Tentative global IPv6 address (ETH) bbbb::100 2017-04-15 11:10:32.050428: INFO: 6LBR: RA Daemon enabled 2017-04-15 11:10:32.050433: INFO: 6LBR: Checking addresses duplication 2017-04-15 11:10:33.712022: ERROR: PF: Trying to send empty packet 2017-04-15 11:10:44.056527: INFO: 6LBR: Configured as DODAG Root fd00::212:4b00:60e:31f4 2017-04-15 11:10:44.056584: INFO: 6LBR: Starting as RPL ROUTER 2017-04-15 11:10:44.057031: WARN: CONFIG: Can not open /etc/6lbr/nvm.conf : No such file or directory 2017-04-15 11:10:44.057308: INFO: HTTP: Starting webserver on port 80 2017-04-15 11:10:44.057654: INFO: NODECFG: Node Config init 2017-04-15 11:10:44.057694: INFO: NODECFG: No node_config.conf file specified 2017-04-15 11:10:44.057729: WARN: CONFIG: Can not open /etc/6lbr/nvm.conf : No such file or directory 2017-04-15 11:10:44.058282: INFO: UDPS: UDP server started CoAP push started CoAP server started 2017-04-15 11:10:44.058370: INFO: DNS: DNS proxy started 2017-04-15 11:10:44.058397: INFO: PLUGIN: Initialising lwm2m-client 2017-04-15 11:10:44.058423: INFO: LWM2M: LWM2M Client init 2017-04-15 11:10:44.058454: INFO: PLUGIN: Initialising dummy 2017-04-15 11:10:44.058474: INFO: DUMMY: Dummy init 2017-04-15 11:10:44.058511: WARN: CONFIG: Can not open /etc/6lbr/nvm.conf : No such file or directory 2017-04-15 11:10:44.058536: INFO: 6LBR: CETIC 6LBR Started RD client started 2017-04-15 11:12:01.388322: ERROR: BR-RDC: br-rdc: send failed, slip ack timeout (1) 2017-04-15 11:12:01.589771: ERROR: BR-RDC: br-rdc: send failed, slip ack timeout (2) 2017-04-15 11:12:01.624464: ERROR: BR-RDC: br-rdc: ack received for unknown packet (1) 2017-04-15 11:12:01.627510: ERROR: BR-RDC: br-rdc: ack received for unknown packet (2) .

If you can enlighten me on this it would be a great help. If it's possible if you can share a working firmware for Slip radio and mesh node? Im working with TI's cc2538 chip.

[msolters]

Hi @Ashokrlz,

Here's how I've been building my configuration:

Use the regular SLIP radio provided by 6LBR/examples/ipv6/slip-radio. I didn't modify this in any way.

With 6LBR, make sure to set to set the WSN prefix to aaaa::, which is the default in latest Contiki. Set security to the AKES option, and make sure it is using 128 bit AES (security level 7). Leave the default key (0x00 through 0x0F).

Next, make sure that after 6LBR instantiates your tap0 or br0 or whatever the case may be, the appropriate routes between your host and WSN subnets are created, e.g. something like:

route -A inet6 add aaaa::/64 gw bbbb::100

Then, on the Contiki side, I merely merged kkrentz/adaptivesec and then added the following to the end of my project-conf.h for the nodes:

#define ENABLE_ADAPT_SEC 1

#if ENABLE_ADAPT_SEC
  #undef NETSTACK_CONF_RDC
  #define NETSTACK_CONF_RDC nullrdc_driver

  #undef ADAPTIVESEC_CONF_UNICAST_SEC_LVL
  #define ADAPTIVESEC_CONF_UNICAST_SEC_LVL 7
  #undef ADAPTIVESEC_CONF_BROADCAST_SEC_LVL
  #define ADAPTIVESEC_CONF_BROADCAST_SEC_LVL 7

  #undef CSPRNG_CONF_SEEDER
  #define CSPRNG_CONF_SEEDER iq_seeder

  #include "net/llsec/adaptivesec/noncoresec-autoconf.h"
#endif

With this configuration, I am able to successfully get some data (CoAP requests, in my case) from the nodes to e.g. a host-local server running on bbbb::100. However, debugging the 802154 framer inside the nodes, I see errors about headers being too large.

Finally, the biggest (and so far as I can tell only) remaining issue is that no traffic ever makes it back from 6LBR -> nodes. Based on information from other developers, I think it has something to do with the headers missing fields (due to not having enough space), but I am not certain. I think the missing headers are security related. I do not understand packetbuf deeply enough to solve this issue yet.

But in summary, this configuration should at least get wireless_input recognized by 6LBR, properly decoded, and then transmitted on to your host services. But no information will be returned. This only works when the nodes are in nullrdc, so far.

[arurke]

@msolters I have not been following this discussion so not sure if this solves anything for you, but I noticed you mention aaaa:: as default prefix in latest Contiki. This was changed some time ago to fd00:: in https://github.com/contiki-os/contiki/pull/1297

[msolters]

Hi @arurke, you're absolutely right -- I had it backwards.

@Ashokrlz, if you're using the latest Contiki with 6LBR, you can safely ignore my earlier sentence about changing the prefix in 6LBR, which should not be necessary. I will amend my previous response as well. Thanks Andreas!

[imashoksundar]

Thank you @msolters for the response.

[laurentderu]

Hi @msolters I had no time to look more into details at adaptive sec lately, so maybe some later changes of adaptive sec break the current support in 6LBR.

Normally AdaptiveSec/Noncore should work in the latest develop snapshot and the non-regression tests are ok, that's why I changed the default configuration from Noncoresec to Adaptivesec/Noncore. But writing this I realize that there are two unsaid constraints :

• First, the slip-radio of the non-regression test is not the vanilla contiki one, but built from 6lbr tree where there are some still unmerged modifications. Two of them being a bigger maximum packet size and a larger input buffer. Normally, that should not influence the behaviour of the slip-radio as everything should be transparent for the slip-radio, but that could indicate a remaining problem.
• The second difference is that the non-regression tests are using the Coojamote platform, which is perfect for pur functional testing, but an actual radio may have problem with non standard packets.

Activating the debug traces in slip-radio.c and slip-net.c could help checking if the packets are at least received by the slip-radio or not.

[msolters]

Hi @laurentderu, I know you're busy so I appreciate the time.

Adaptivesec does kind of work in 6LBR. To follow up on your points:

I am already using the 6LBR SLIP radio in all my trials, as I recommended to @Ashokrlz:

(Use the regular SLIP radio provided by 6LBR/examples/ipv6/slip-radio. I didn't modify this in any way.)

Secondly, the good news is the 6LBR SLIP radio does receive wireless_input from adaptivesec-enabled nodes! (The sensors even show up in the 6LBR sensors page).

The problem is actually the opposite: either the SLIP radio never really sends wireless_output or else, when adaptivesec is enabled, it is sending outbound packets that are unintelligible to the nodes. This is true on 6lbr/develop, even without merging any newer adaptivesec changes!

What I do know is that the nodes are reporting header overflow problems (e.g. trying to put too much info into the headers) whenever they send the packets. Clearly, enough data makes it into the border-router bound packet headers to be received by the SLIP radio and decrypted and routed by 6LBR; but maybe not enough for 6LBR to then properly ACK or otherwise respond?

@laurentderu, based on your information I have 2 concrete follow-up questions:

• You mention the SLIP radio has a larger max packet size. Which variable, specifically, has been modified? I have tried changing almost every packetbuf related define I can find, in the 6LBR and the nodes, but nothing seems to help. But maybe I have been too clumsy in my modifications.
• What variable, specifically, was modified to increase the input buffer size?

I am guessing the changes that need to be made are actually on the node side, to ensure that outgoing packets can fit all the security-related headers into the headers. But it is not clear to me what, specifically, should be changed, and whether or not changing anything in the nodes would require further adjustments elsewhere in the network.

Thanks again for all you do Laurent!

[laurentderu]

So the problem is clearly on the node and somehow platform related. I just run again the non-regression tests and the pings are successful up to 230 bytes (which is the test current limit). Both 6LBR and the test node are using "noncoresec-autoconf.h" configuration parameters.

What I know for sure is that the packets are send by 6LBR towards the slip-radio, so either the slip-radio itself drops the packet or the destination node refuses it. For packets send by the node, I never saw header overflow problem, so that also points towards a platform specific issue (Maybe a bug in the Coojamote that accepts wrongly formatted packets). Could you send me some logs from the node and from 6LBR and the slip-radio when those errors occurs ?

Note, he modifications in the slip-radio project-conf.h to increase the intermediate buffers are the following :

#define SLIP_CONF_BUF_NB        16

#undef UIP_CONF_BUFFER_SIZE
#define UIP_CONF_BUFFER_SIZE    (127+20*3+3)

[msolters]

@laurentderu , for context:

I have Contiki nodes, patched with the adaptivesec branch. I have 6LBR develop branch (no modifications) running with a 6LBR SLIP radio. I have enabled AKES in the 6LBR web interface, and the key matches what the nodes have been configured to use. I ensure #define UIP_CONF_BUFFER_SIZE (127+20*3+3) on all test devices.

Nodes I have the nodes repeating CoAP requests to the border router. If they fail or timeout they repeat forever. If the server returns a 1 as the payload, they stop. When the node sends the CoAP request, framer-802154.c complains:

15.4-OUT: too large header: 26

However, after giving adaptivesec a bit of time to negotiate the Hello's and ACK's and so forth (generally takes <= 30 seconds), there is a flurry of 15.4-OUT and 15.4-IN activity. At this point I can even ping6 aaaa::212:4b00:7ae:9603 successfully!

But actual CoAP requests are not working. I see the requests being made and returning with no payload (they should have returned "1") extremely fast. This is not a time out. The following log entry is being repeated many, many times per second:

[CoAP]:-----CoAP Request Started-----
Message:
URL:    /device-ping
Method: GET
k:      1
Payload:        {"type":"device-ping","dev_id":"00007","dev_type":"gadget","fw":62,"upd":0}
State:  UNSENT
15.4-OUT:  1 0012:4b00:0790:4a01 26 87 (113)
15.4-OUT:  1 0012:4b00:0790:4a01 26 54 (80)
15.4-IN:  2 0000:0000:0000:0000  0000:0000:0000:0000 3 0 (3)
15.4-IN:  2 0000:0000:0000:0000  0000:0000:0000:0000 3 0 (3)
15.4-IN:  1 0012:4b00:0790:4a01  0012:4b00:07ae:9603 26 69 (95)
[coap-sender]:  Received 0 bytes
[CoAP]: -----CoAP Request Terminated-----

6LBR Over in /var/log/6lbr.log I begin seeing highly repetitive log data as well, indicating both that these requests are being made, understood, and even apparently replied to:

2017-04-21 14:32:03.336677: PACKET: PF: wireless_input
2017-04-21 14:32:03.336682: PACKET: PF: wireless_input: dest: 00:12:4b:00:07:90:4a:01
2017-04-21 14:32:03.336707: PACKET: PF: wireless_input: processing frame
2017-04-21 14:32:03.336719: PACKET: PF: bridge_output: Sending packet to 02:0a:0b:ff:ff:0c:0d:0e
2017-04-21 14:32:03.336740: PACKET: PF: dest prefix eth : bbbb::
2017-04-21 14:32:03.336747: PACKET: PF: dest eth : bbbb::1
2017-04-21 14:32:03.336755: PACKET: PF: eth_output: 02:0a:0b:ff:ff:0c:0d:0e
2017-04-21 14:32:03.336776: PACKET: PF: eth_output: Sending packet to Ethernet
2017-04-21 14:32:03.336781: PACKET: ETH: write: 143
2017-04-21 14:32:03.336804: PACKET: TAP: write: 143
2017-04-21 14:32:03.337428: PACKET: TAP: read: 66
2017-04-21 14:32:03.337440: PACKET: ETH: read: 66
2017-04-21 14:32:03.337445: PACKET: PF: eth_input: Processing frame
2017-04-21 14:32:03.337455: PACKET: PF: bridge_output: Sending packet to 00:12:4b:00:07:ae:96:03
2017-04-21 14:32:03.337475: PACKET: PF: dest prefix wsn : aaaa::
2017-04-21 14:32:03.337482: PACKET: PF: dest prefix wsn : aaaa::212:4b00:7ae:9603
2017-04-21 14:32:03.337514: PACKET: PF: wireless_output: sending packet
2017-04-21 14:32:03.337556: PACKET: BR-RDC: write: 69 (sid: 5, cb: 1)
2017-04-21 14:32:03.337561: PACKET: SLIP: write: 108
2017-04-21 14:32:03.357178: PACKET: SLIP: read: 5
2017-04-21 14:32:03.357208: PACKET: SCMD: Packet data report for sid:5 st:0 tx:1
2017-04-21 14:32:03.357213: PACKET: BR-RDC: sid ack: 5 (0, 1)
2017-04-21 14:32:03.408386: PACKET: SLIP: read: 123
2017-04-21 14:32:03.408435: PACKET: BR-RDC: read: 123
2017-04-21 14:32:03.416793: PACKET: SLIP: read: 90
2017-04-21 14:32:03.416817: PACKET: BR-RDC: read: 90
2017-04-21 14:32:03.416856: PACKET: PF: wireless_input
2017-04-21 14:32:03.416862: PACKET: PF: wireless_input: dest: 00:12:4b:00:07:90:4a:01
2017-04-21 14:32:03.416888: PACKET: PF: wireless_input: processing frame
2017-04-21 14:32:03.416902: PACKET: PF: bridge_output: Sending packet to 02:0a:0b:ff:ff:0c:0d:0e
2017-04-21 14:32:03.416923: PACKET: PF: dest prefix eth : bbbb::
2017-04-21 14:32:03.416931: PACKET: PF: dest eth : bbbb::1
2017-04-21 14:32:03.416939: PACKET: PF: eth_output: 02:0a:0b:ff:ff:0c:0d:0e
2017-04-21 14:32:03.416960: PACKET: PF: eth_output: Sending packet to Ethernet
2017-04-21 14:32:03.416965: PACKET: ETH: write: 143
2017-04-21 14:32:03.416989: PACKET: TAP: write: 143
2017-04-21 14:32:03.417620: PACKET: TAP: read: 66
2017-04-21 14:32:03.417634: PACKET: ETH: read: 66
2017-04-21 14:32:03.417639: PACKET: PF: eth_input: Processing frame
2017-04-21 14:32:03.417648: PACKET: PF: bridge_output: Sending packet to 00:12:4b:00:07:ae:96:03
2017-04-21 14:32:03.417689: PACKET: PF: dest prefix wsn : aaaa::
2017-04-21 14:32:03.417697: PACKET: PF: dest prefix wsn : aaaa::212:4b00:7ae:9603
2017-04-21 14:32:03.417713: PACKET: PF: wireless_output: sending packet
2017-04-21 14:32:03.417751: PACKET: BR-RDC: write: 69 (sid: 6, cb: 1)
2017-04-21 14:32:03.417756: PACKET: SLIP: write: 108
2017-04-21 14:32:03.435197: PACKET: SLIP: read: 5
2017-04-21 14:32:03.435222: PACKET: SCMD: Packet data report for sid:6 st:0 tx:1
2017-04-21 14:32:03.435227: PACKET: BR-RDC: sid ack: 6 (0, 1)
2017-04-21 14:32:03.496077: PACKET: SLIP: read: 123
2017-04-21 14:32:03.496122: PACKET: BR-RDC: read: 123
2017-04-21 14:32:03.496996: PACKET: SLIP: read: 90
2017-04-21 14:32:03.497026: PACKET: BR-RDC: read: 90
2017-04-21 14:32:03.497116: PACKET: PF: wireless_input
2017-04-21 14:32:03.497130: PACKET: PF: wireless_input: dest: 00:12:4b:00:07:90:4a:01
2017-04-21 14:32:03.497193: PACKET: PF: wireless_input: processing frame
2017-04-21 14:32:03.497220: PACKET: PF: bridge_output: Sending packet to 02:0a:0b:ff:ff:0c:0d:0e
2017-04-21 14:32:03.497292: PACKET: PF: dest prefix eth : bbbb::
2017-04-21 14:32:03.497347: PACKET: PF: dest eth : bbbb::1
2017-04-21 14:32:03.497370: PACKET: PF: eth_output: 02:0a:0b:ff:ff:0c:0d:0e
2017-04-21 14:32:03.497426: PACKET: PF: eth_output: Sending packet to Ethernet
2017-04-21 14:32:03.497439: PACKET: ETH: write: 143
2017-04-21 14:32:03.497480: PACKET: TAP: write: 143
2017-04-21 14:32:03.500296: PACKET: TAP: read: 66
2017-04-21 14:32:03.500328: PACKET: ETH: read: 66
2017-04-21 14:32:03.500420: PACKET: PF: eth_input: Processing frame
2017-04-21 14:32:03.500445: PACKET: PF: bridge_output: Sending packet to 00:12:4b:00:07:ae:96:03
2017-04-21 14:32:03.500501: PACKET: PF: dest prefix wsn : aaaa::
2017-04-21 14:32:03.500521: PACKET: PF: dest prefix wsn : aaaa::212:4b00:7ae:9603
2017-04-21 14:32:03.500564: PACKET: PF: wireless_output: sending packet
2017-04-21 14:32:03.500662: PACKET: BR-RDC: write: 69 (sid: 7, cb: 1)
2017-04-21 14:32:03.500675: PACKET: SLIP: write: 108
2017-04-21 14:32:03.518082: PACKET: SLIP: read: 5
2017-04-21 14:32:03.518126: PACKET: SCMD: Packet data report for sid:7 st:2 tx:1
2017-04-21 14:32:03.518139: PACKET: BR-RDC: sid ack: 7 (2, 1)

And so forth.

The next couple steps are promising:

• The CoAP test server does receive all the incoming messages, apparently successfully decrypted. The server then claims to be responding with a valid payload.
• I do in fact see wireless_output in the log above, containing what I presume to be the CoAP request response, being sent back to the node.

But the node says it is getting 0 payload.

Needless to say, this all works fine without adaptivesec, so I know the server and client are not themselves the culprit. I'm definitely seeing bidirectional traffic from 6LBR, but whatever it's sending is apparently not being transmitted or framed correctly. The adaptivesec handshake works fine, and the decryption appears to work fine as well.

I suspect that perhaps the node's initial 802.15.4 complaint (15.4-OUT: too large header: 26) is perhaps hinting at the underlying issue.

I have also wondered how CoAP, in particular, may need to be tweaked -- e.g. the maximum REST chunk sizes, etc. -- I do not fully understand how their sizes are related to header sizes and buffer sizes. Perhaps this is why even small CoAP requests are failing while ping continues to work, once adaptivesec is brought into the picture.

[imashoksundar]

Hi,

Has anyone successfully implemented AES 128 encryption (CTR/CCM) using the rom_crypto drivers located in the cc26xxware/driverlib/crypto.c for cc2650/cc1350? Because I don't see any examples on that ?

I was able to build and compile the below given code for cc2650 but when running it on the device I see no output after calling AES_CTR_EncryptData function? If anyone can enlighten me on this it would be a great help.

PROCESS_BEGIN();

uint8_t aesKey[16] = {
0x5a, 0x69, 0x67, 0x42, 0x65, 0x65, 0x41, 0x6c,
0x6c, 0x69, 0x61, 0x6e, 0x63, 0x65, 0x30, 0x39
};

uint8_t inputData[]= {
  0x06, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
  0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F
};

uint8_t nonce_en[] = {
  0x12, 0x01, 0x03, 0x0D
};

uint8_t nonce_de[] = {
  0x00, 0x01, 0x00, 0x00
};

uint8_t iv_en[] = {
  0x08, 0x02, 0x0B, 0x0D, 0x0E, 0x0F, 0x90, 0x01
};

uint8_t iv_de[] = {
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x90, 0x01
};

   uint8_t encryptedData[sizeof(inputData)] = { 0 };
   uint8_t outputData[sizeof(inputData)]    = { 0 };

   //StandaloneRomCryptoInit();

   memcpy(encryptedData, inputData, sizeof(inputData));

   printf("Plain text: \n");
   hexdump(inputData, sizeof(inputData));

   printf("Encrypt function returned: %d\n", AES_CTR_EncryptData(encryptedData, sizeof(inputData), aesKey, nonce_en, iv_en));