Adaptive 802.15.4 Security

[kkrentz]

Currently, the noncoresec_driver has various problems:

• At some point, nodes cannot accept further neighbors because anti-replay data of disappeared neighbors is never deleted.
• If a node reboots, its frame counter starts over. This causes neighbors to consider a rebooted node's frames as replayed and also ensues a nonce reuse in 802.15.4 security.
• Moreover, if a node reboots, its anti-replay data gets lost, thus exposing rebooted nodes to replay attacks.

This pull request adds the adaptivesec_driver, which avoids the problems above by establishing session keys. For usage details, see https://github.com/kkrentz/contiki/tree/adaptivesec/core/net/llsec/adaptivesec.

[alignan]

Newline here

[alignan]

Please also include the cc2538dk and zoul, it should be pretty much the same as the openmote-cc2538.

[alignan]

This is already defined in sys/cc.h, see here.

[alignan]

There is a frequency hopping block in core/lib/iq-seeder.c, is this part of the commit also? are you implementing frequency hop as well? sorry for asking something obvious,

[kkrentz]

Thanks for your comments. I will try to address them.

Concerning iq-seeder.c - that thing is responsible for generating a cryptographic seed at start up. For this purpose, I currently use I/Q LSBs as an entropy source. Yet, I/Q LSBs are potentially vulnerable to eavesdropping and interference. While I think it should be hard to launch successful attacks on this, channel hopping is intended to further complicate attacks. However, I am currently working on a seeder that is more secure than this one.

[kkrentz]

I applied the changes you suggested. Travis should pass after a restart.

[kkrentz]

I think it is also a good idea to remove noncoresec entirely, isn't it?

[alignan]

Using WITH_WEBSERVER=webserver produces the following error:

../../../../apps/webserver/httpd-cgi.c:158:11: error: 'uip_conns' undeclared (first use in this function)
   conn = &uip_conns[s->u.count];
           ^
../../../../apps/webserver/httpd-cgi.c:158:11: note: each undeclared identifier is reported only once for each function it appears in
../../../../apps/webserver/httpd-cgi.c: In function 'tcp_stats':
../../../../apps/webserver/httpd-cgi.c:197:9: error: 'uip_conns' undeclared (first use in this function)

[kkrentz]

This is probably because I disabled TCP in the corresponding project-conf.h. Also, note that I did not copy some files that are required for enabling the web server over to this example folder. I could do so if you like.

[alignan]

I'm testing using 2 nodes with the broadcast application running, I have a couple of questions (sorry in advance if this is something obvious):

• I only receive packets on one node, not in both as expected
• Using a generic sniffer I see the Test payload on the open, is this expected?

[kkrentz]

Thanks for testing. Indeed, it is expected that you see Test since the security level of the example is set to 2. Just change the security level to 5,6, or 7 to enable encryption. However, you should actually receive packets on both nodes.

[alignan]

Thanks for the fast response. I don't have a concrete preference, but to try to follow how an user would test the application based on what is documented. I think just adding a note about enabling back TCP should do. I will continue testing, thanks!

[bthebaudeau]

Building examples/llsec/ipv6-demos/rpl-border-router for Zoul Firefly generates a lot of warnings.

Nothing is received with examples/llsec/ipv6-demos/simple-udp-rpl on my Zoul Firefly boards, whereas examples/ipv6/simple-udp-rpl works fine.

[vamsi-chikati]

Is llsec supposed to be working on all platforms, theoretically?

We had limited success testing earlier version of llsec in econotag. If you
could confirm, we'll try testing on econotag.

14 జూన్ 2016 4:49 AMన, "Benoît Thébaudeau" notifications@github.com
వ్రాసినది:

Building examples/llsec/ipv6-demos/rpl-border-router for Zoul Firefly
generates a lot of warnings.

Nothing is received with examples/llsec/ipv6-demos/simple-udp-rpl on my
Zoul Firefly boards, whereas examples/ipv6/simple-udp-rpl works fine.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1703 (comment), or
mute the thread
https://github.com/notifications/unsubscribe/AH4a2iO8zLH-1GyxkCwgbWy3Pllk2pH7ks5qLeVngaJpZM4ItY88
.

[kkrentz]

@bthebaudeau Regarding examples/llsec/ipv6-demos/simple-udp-rpl, you may just have to wait for a little while until session key establishment is done. To see what is going on, you can enable debugging in akes.c. Concerning examples/llsec/ipv6-demos/rpl-border-router, I only tried this one on TelosB motes, yet. What is also on my TODO list is making SLIP work. I will see what I can do.

@vamsi-chikati Porting the adaptivesec_driver to econtags requires implementing an aes_128_driver, as well as a csprng_seeder. However, I actually could implement a general csprng_seeder that is configured with a static seed at compilation time to ease porting to other platforms.

[alignan]

@kkrentz send me an email and we'll fix your lack of RE-Motes 😉

[alignan]

Does this changes anything? checking the cc2538-rf there is:

#ifdef CC2538_RF_CONF_CCA_THRES
#define CC2538_RF_CCA_THRES CC2538_RF_CONF_CCA_THRES
#else
#define CC2538_RF_CCA_THRES CCA_THRES_USER_GUIDE /** User guide recommendation */
#endif /* CC2538_RF_CONF_CCA_THRES */

But in the actual code is pretty much hard-coded

REG(RFCORE_XREG_CCACTRL0) = CC2538_RF_CCA_THRES_USER_GUIDE;

[bthebaudeau]

@kkrentz With DEBUG set to 1 in akes.c, examples/llsec/ipv6-demos/simple-udp-rpl works fine, so there is probably a timing issue.

[g-oikonomou]

Hi folks. The bullets in the OP are things that need solved. However, I am finding it very difficult to understand the reasoning behind some of the commits proposed here. This includes all the pub-sub business and also the reboot app.

I cannot immediately understand why we need an LLsec-specific border router example. All project-conf.h files in those examples are very messy, with those #if 0 blocks.

I see that you enclose entire .c files inside #if guards. Is this really required? In other words, will the file fail to compile if those macros are not set?

I am finding it difficult to understand how you are deriving pairwise keys. Is this some sort of key agreement? If so, is this something well-established? Is this something that you have designed / published yourself?

For channel-hopping in the respective seeder, best not hard-code channels in [11, 26], since we are getting traction with sub-ghz radios. Perhaps get min/max through the radio API (RADIO_CONST_CHANNEL_MIN, RADIO_CONST_CHANNEL_MAX).

Generally speaking, security and crypto are things difficult to understand (and to therefore configure properly based on requirements). In this context, some documentation would be nice :) That's a general comment that applies to what we already have on master by the way.

Lastly, perhaps of zero consequence, those "Your Name committed" don't look very nice

[kkrentz]

• demos: I could remove the demos since I think that the description on https://github.com/kkrentz/contiki/tree/adaptivesec/core/net/llsec/adaptivesec is sufficient for getting started
• reboot app: It is part of the demos, which is why I could remove it, too
• pub-sub: This is a flexible way to handle incoming 802.15.4 MAC command frames. The way it works is that you register for 802.15.4 MAC command frames. Subsequently, you get called upon receipt of a command frame and report report back if you consumed it.
• pairwise keys: The key derivation process is pretty common. It derives a pairwise session key from two random numbers, which are contributed by both sides. Our whole key establishment scheme is explained in a paper, which is linked at the bottom of https://github.com/kkrentz/contiki/tree/adaptivesec/core/net/llsec/adaptivesec.
• seeder: I could do this.

[kkrentz]

Updates:

• I removed all the demo files.
• I updated the README.
• When adapting the current rpl-border-router example according to my README, the rpl-border-router now works on Sky-, Re-, and Open-Motes.

[kkrentz]

@g-oikonomou I was able to remove a couple of #if guards, but removing the remaining ones would cause compiler errors and warnings.

[bthebaudeau]

I've tested this update with examples/ipv6/simple-udp-rpl/broadcast-example.c on my Zoul Firefly boards:

• If this example is unchanged, it works fine.
• If I follow the instructions from your README:
  • I still get a range or timing issue with #define NETSTACK_CONF_RDC contikimac_driver.
  • The boards keep resetting with #define NETSTACK_CONF_RDC nullrdc_driver.

[bthebaudeau]

I confirm that examples/ipv6/simple-udp-rpl/broadcast-example.c now works fine with nullrdc_driver following your latest changes (f315bd1).

[kkrentz]

@bthebaudeau Is there anything left that does not work for you?

[bthebaudeau]

@kkrentz Now, my Zoul Firefly boards can successfully send and receive messages with all the supported adaptivesec configurations. However, I still have the feeling that using adaptivesec with ContikiMAC leads to less reliable transmissions than adaptivesec with nullrdc, or nullsec with ContikiMAC. This is only a feeling, because the reliability of transmissions changes from time to time, and my boards lack antennae. I've selected a channel supposed to be free, but there may be uncontrolled remote emitters on any channel from time to time. So I can't say for sure. If someone has a couple of motes with proper antennae, he or she can compare the adaptivesec and nullsec transmission ranges in an open field environment with ContikiMAC.

[kkrentz]

@bthebaudeau I also encountered reliability issues with ContikiMAC, but they seem to be independent of adaptivesec. This is one reason why I began to work on a re-implementation of ContikiMAC, as I told you already. For the time being, it might help to switch on CSMA and/or the ContikiMAC framer (which adds padding bytes to short frames).

[firmwareguru]

AdaptiveSec seems to be already available on cetic/6lbr, why is it taking so long to get integrated into Contiki mainline?

[kkrentz]

I, meanwhile, ported adaptivesec, along with my implementations of ContikiMAC and CSL to Contiki-NG https://github.com/kkrentz/contiki-ng. I will create a new pull request there.

[firmwareguru]

Excellent kkrentz. Your efforts to bring Contiki towards IIoT-level robustness are invaluable. I have a couple of comment-questions:

1. Where do we sit with bringing adaptive key exchange and compromise resliency to TSCH?

2. I notice no references between your papers and this one:
   Cryptographic Key Exchange in IPv6-Based Low Power,
   Lossy Networks
   Panagiotis Ilia, George Oikonomou, Theo Tryfonas

I'm sure you're aware of it, however.
How does your system compare?
I would like to see a system based on ECC/PKI on the TI 13x2 platforms. However if your system is just as compromise resilient without any central key distribution system, then fine by me.

[amitbhanja]

@kkrentz , thanks for the update. Please also inform us if you could, about the new pull request in contiki-ng.

[amitbhanja]

@kkrentz will the CSL work for cc26xx-cc13xx cpu drivers?

[kkrentz]

@firmwareguru I have little hope that we can add compromise resilience to TSCH anytime soon. Even if TSCH was changed to use pairwise keys, its time synchronization could still be attacked by compromised nodes. Because of this, I rather added channel hopping (and other nice features) to CSL. Regarding the paper, I think I saw this paper a long time ago. They are using unauthenticated ECDH and hence do not prevent unauthorized nodes from joining the network. Another limitation is that ECDH is quite energy- and time-consuming. By contrast, our system ensures authorization and avoids public-key cryptography.

@amitbhanja For the time being, I only implemented a driver for the CC2538: https://github.com/kkrentz/contiki-ng/blob/master/arch/cpu/cc2538/dev/cc2538-rf-async.c.

[amitbhanja]

@kkrentz , Thanks for the info. I was actually trying the adaptivesec (https://github.com/kkrentz/contiki) with rpl-border-router. The border router is on cc1310 and sensortag on cc1350. I enabled the prints of the security module.

#include "net/llsec/adaptivesec/coresec-autoconf.h"

#define AKES_SINGLE_CONF_KEY { 0x12 , 0x37 , 0x59 , 0x65 ,
0xC4 , 0xD5 , 0x8A , 0x76 ,
0x19 , 0xE7 , 0xA9 , 0x98 ,
0x1D , 0x51 , 0xCB , 0xFE }

#undef CSPRNG_CONF_SEEDER
#define CSPRNG_CONF_SEEDER null_seeder

#undef CONTIKIMAC_CONF_WITH_PHASE_OPTIMIZATION
#define CONTIKIMAC_CONF_WITH_PHASE_OPTIMIZATION 1

#undef NETSTACK_CONF_FRAMER
#define NETSTACK_CONF_FRAMER contikimac_framer
#undef CONTIKIMAC_FRAMER_CONF_ENABLED
#define CONTIKIMAC_FRAMER_CONF_ENABLED 1
#undef CONTIKIMAC_FRAMER_CONF_DECORATED_FRAMER
#define CONTIKIMAC_FRAMER_CONF_DECORATED_FRAMER adaptivesec_framer
#undef ADAPTIVESEC_CONF_DECORATED_FRAMER
#define ADAPTIVESEC_CONF_DECORATED_FRAMER framer_802154

I tried the above with both phase optimization and without that. However, I always get the prints of the ACK being received. But then a series of Invalid ACK prints, which I believe is because the entry becomes permanent and then it is not any more tentative. There has been occasions of ACK was not acknowledged prints. This i believe is because of no mac layer acknowledgments being sent. Would this be an issue?

but after that, I dont see the sicslowpan connection getting through. Dont see any sicslowpan input prints on either side.

Could you give some idea about what could be the issue?

[kkrentz]

This sounds like the ACK is not being acknowledged, although it was received successfully ...

[firmwareguru]

@amitbhanja I am looking at using adaptivesec + contikimac + cc13xx too; please update here any advances or resolutions, as will I.

[firmwareguru]

@kkrentz CSL-MAC: A low power channel hopping MAC with adaptive security and compromise resiliency? Sounds great. Where is it, and how can we get it rolled into here, or Contiki-NG, which seems to have only TSCH as the MAC layer??

[kkrentz]

I opened a PR for merging CSL into Contiki-NG contiki-ng/contiki-ng#506

[amitbhanja]

Hello @kkrentz , I have been using the adaptivesec protocol from ur github repository https://github.com/kkrentz/contiki. Thanks a lot for providing this. It is working fine. I have a setup with border router and 6 nodes. The nodes send data every 1 minute. There is a mechanism I implemented which deletes the parent from the neighbor list if UPDATE ACK is not received after two checks of update interval. After about 2 days, it has been observed that even though node is sending HELLO message with a different session key than what was present due to deletion of the border router from neighbor table, the border router is identifying it as new session with permanent neighbor but the HELLO ACK being sent is not received at the node. This is creating issue with starting a new session with the border router.
Could you give any tip about why it is happening?

[kkrentz]

Hello, thanks for using adaptivesec. It may happen that a HELLOACK is silently discarded because there is no need to start a new session. Maybe this mechanism interferes with your deletion of parents. I do not know what you are trying to achieve, but, normally, it is unnecessary to delete neighbors by hand since akes-delete.c already takes care of deleting uncommunicative neighbors. To trace down the problem, it would be useful to have the DEBUG output of akes.c. Also, I would need to know what MAC protocol, platform, and seeder you are using. That said, I meanwhile ported adaptivesec to Contiki-NG and actually stopped maintaining my Contiki repository. You can find the latest version there: https://github.com/kkrentz/contiki-ng, https://github.com/kkrentz/contiki-ng/wiki/CSL. As Contiki-NG also contains a lot of other fixes to Contiki, it probably makes sense for you to move to Contiki-NG, too. Kind Regards Konrad 2018-07-23 7:31 GMT+02:00 Amit Bhanja <notifications@github.com>:

…

Hello @kkrentz <https://github.com/kkrentz> , I have been using the adaptivesec protocol from ur github repository https://github.com/kkrentz/ contiki. Thanks a lot for providing this. It is working fine. I have a setup with border router and 6 nodes. The nodes send data every 1 minute. There is a mechanism I implemented which deletes the parent from the neighbor list if UPDATE ACK is not received after two checks of update interval. After about 2 days, it has been observed that even though node is sending HELLO message with a different session key than what was present due to deletion of the border router from neighbor table, the border router is identifying it as new session with permanent neighbor but the HELLO ACK being sent is not received at the node. This is creating issue with starting a new session with the border router. Could you give any tip about why it is happening? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1703 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPxfI47E78gUJUXviKQnteuJYpZn8jrks5uJV-XgaJpZM4ItY88> .

[amitbhanja]

Hi @kkrentz ,

Thanks for your quick response.
Mysetup: a node connecting to the border router. Trying to keep the radio off most of the time. Only on during the initial setup and then when data is being sent.
MAC: Contikimac along with CSMA. Channel check rate is 8.
However, I might have confused in the previous post. I am not deleting any entry on my own from the application layer. The only thing i did is added a callback to determine which neighbor has been deleted. If the neighbor is the preferred parent from RPL, I just reset the akes trickle timer , change the adaptivesec group key and reset the rpl timers. I do this because my node keeps the RADIO off most of the time, but when it knows that preferred parent has been deleted, it keeps the radio on. I checked that the restarts of the border router work properly. But after some time i see this issue.
The HELLO message from the node is received at the border router and it determines that a new session has started and sends the HELLO ACK. But nothing is received at the node. In fact, nothing is received at the node (although the radio is on) after the deletion of the border router happens due to the akes-delete thread. Please see the logs below of akes.

From the node:

Line 1: akes-delete: #permanent = 1
Line 4: akes-delete: Sent UPDATE
Line 44: AKES: deleted preferred parent
Line 45: adaptivesec_group_key = 6ffe9215bdf060a9e8f998e053619a11akes-trickle: Resetting Trickle
Line 53: akes-delete Setting update check timer
Line 54: akes-trickle: I=30s t=27s
Line 136: akes-trickle: Broadcasting HELLO
Line 139: akes: broadcasting HELLO
Line 148: akes-trickle: I=60s t=55s
Line 299: akes-trickle: Broadcasting HELLO
Line 302: akes: broadcasting HELLO
Line 316: akes-trickle: I=120s t=75s
Line 513: akes-trickle: Broadcasting HELLO
Line 516: akes: broadcasting HELLO
Line 641: akes-trickle: I=240s t=238s
Line 878: akes-delete: #permanent = 0
Line 879: akes-delete Setting update check timer
Line 1279: akes-trickle: Broadcasting HELLO
Line 1282: akes: broadcasting HELLO
Line 1286: akes-trickle: I=480s t=287s
Line 1682: akes-delete: #permanent = 0
Line 1683: akes-delete Setting update check timer
Line 2049: akes-trickle: Broadcasting HELLO
Line 2052: akes: broadcasting HELLO
Line 2482: akes-delete: #permanent = 0
Line 2483: akes-delete Setting update check timer
Line 2569: akes-trickle: I=960s t=504s
Line 3294: akes-delete: #permanent = 0
Line 3295: akes-delete Setting update check timer
Line 3924: akes-trickle: Broadcasting HELLO
Line 3927: akes: broadcasting HELLO
Line 4097: akes-delete: #permanent = 0
Line 4098: akes-delete Setting update check timer
Line 4904: akes-delete: #permanent = 0
Line 4905: akes-delete Setting update check timer
Line 5151: akes-trickle: I=1920s t=1390s
Line 5712: akes-delete: #permanent = 0
Line 5713: akes-delete Setting update check timer
Line 6516: akes-delete: #permanent = 0
Line 6517: akes-delete Setting update check timer
Line 7322: akes-delete: #permanent = 0
Line 7323: akes-delete Setting update check timer

From the border router:
Jul 27 08:54:19 raspberrypi bert[341]: akes: Received UPDATE from 00:12:4b:00:18:00:82:8f
Jul 27 08:54:20 raspberrypi bert[341]: His unicast counter 271
Jul 27 08:54:20 raspberrypi bert[341]: Received Counter 272
Jul 27 08:54:20 raspberrypi bert[341]: His unicast counter 272
Jul 27 08:54:20 raspberrypi bert[341]: Received Counter 272
Jul 27 08:54:20 raspberrypi bert[341]: akes-nbr: prolonging
Jul 27 08:54:20 raspberrypi bert[341]: akes-nbr: prolonged
Jul 27 08:54:20 raspberrypi bert[341]: Sending UPDATE ACK to 00:12:4b:00:18:00:82:8f
Jul 27 08:54:20 raspberrypi bert[341]: Setting unicast counter 503
Jul 27 08:55:02 raspberrypi bert[341]: akes: Received HELLO from 00:12:4b:00:18:00:82:8f
Jul 27 08:55:02 raspberrypi bert[341]: Deleting neighbor Status 1 00:12:4b:00:18:00:85:0d
Jul 27 08:55:02 raspberrypi bert[341]: noncoresec-strategy: Inauthentic frame
Jul 27 08:55:02 raspberrypi bert[341]: akes: Starting new session with permanent neighbor
Jul 27 08:55:02 raspberrypi bert[341]: akes: Will send HELLOACK in 2s
Jul 27 08:55:05 raspberrypi bert[341]: akes: Sending HELLOACK to 00:12:4b:00:18:00:82:8f
Jul 27 08:55:05 raspberrypi bert[341]: Setting unicast counter 504
Jul 27 08:56:00 raspberrypi bert[341]: akes: Received HELLO from 00:12:4b:00:18:00:82:8f
Jul 27 08:56:00 raspberrypi bert[341]: Deleting neighbor Status 1 00:12:4b:00:18:00:82:8f
Jul 27 08:56:00 raspberrypi bert[341]: noncoresec-strategy: Inauthentic frame
Jul 27 08:56:00 raspberrypi bert[341]: akes: Starting new session with permanent neighbor
Jul 27 08:56:00 raspberrypi bert[341]: akes: Will send HELLOACK in 1s
Jul 27 08:56:02 raspberrypi bert[341]: akes: Sending HELLOACK to 00:12:4b:00:18:00:82:8f
Jul 27 08:56:02 raspberrypi bert[341]: Setting unicast counter 505
Jul 27 08:57:20 raspberrypi bert[341]: akes: Received HELLO from 00:12:4b:00:18:00:82:8f
Jul 27 08:57:20 raspberrypi bert[341]: Deleting neighbor Status 1 00:12:4b:00:18:00:82:8f
Jul 27 08:57:20 raspberrypi bert[341]: noncoresec-strategy: Inauthentic frame
Jul 27 08:57:20 raspberrypi bert[341]: akes: Starting new session with permanent neighbor
Jul 27 08:57:20 raspberrypi bert[341]: akes: Will send HELLOACK in 1s
Jul 27 08:57:21 raspberrypi bert[341]: akes: Sending HELLOACK to 00:12:4b:00:18:00:82:8f
Jul 27 08:57:21 raspberrypi bert[341]: Setting unicast counter 506
Jul 27 08:59:09 raspberrypi bert[341]: akes: Received HELLO from 00:12:4b:00:16:7c:46:51
Jul 27 08:59:09 raspberrypi bert[341]: Deleting neighbor Status 1 00:12:4b:00:18:00:82:8f
Jul 27 08:59:09 raspberrypi bert[341]: noncoresec-strategy: Inauthentic frame
Jul 27 08:59:09 raspberrypi bert[341]: akes: Starting new session with permanent neighbor
Jul 27 08:59:09 raspberrypi bert[341]: akes: Will send HELLOACK in 2s
Jul 27 09:02:03 raspberrypi bert[341]: akes: Received HELLO from 00:12:4b:00:18:00:82:8f
Jul 27 09:02:03 raspberrypi bert[341]: Deleting neighbor Status 1 00:12:4b:00:16:7c:46:32
Jul 27 09:02:03 raspberrypi bert[341]: noncoresec-strategy: Inauthentic frame
Jul 27 09:02:03 raspberrypi bert[341]: akes: Starting new session with permanent neighbor
Jul 27 09:02:03 raspberrypi bert[341]: akes: Will send HELLOACK in 0s
Jul 27 09:02:03 raspberrypi bert[341]: akes: Sending HELLOACK to 00:12:4b:00:18:00:82:8f
Jul 27 09:02:03 raspberrypi bert[341]: Setting unicast counter 529
Jul 27 09:02:12 raspberrypi bert[341]: Setting unicast counter 530
Jul 27 09:02:12 raspberrypi bert[341]: Sending UPDATE to 00:12:4b:00:18:00:82:8f
Jul 27 09:02:13 raspberrypi bert[341]: akes-delete: Sent UPDATE
Jul 27 09:02:28 raspberrypi bert[341]: Deleting neighbor Status 0 00:12:4b:00:18:00:82:8f
Jul 27 09:18:29 raspberrypi bert[341]: akes: Received HELLO from 00:12:4b:00:18:00:82:8f
Jul 27 09:18:29 raspberrypi bert[341]: Deleting neighbor Status 1 00:12:4b:00:16:7c:46:32
Jul 27 09:18:29 raspberrypi bert[341]: akes: Will send HELLOACK in 2s
Jul 27 09:18:32 raspberrypi bert[341]: akes: Sending HELLOACK to 00:12:4b:00:18:00:82:8f
Jul 27 09:18:32 raspberrypi bert[341]: Setting unicast counter 544

I have some prints at the input of adaptivesec to check if any packet has been received.
I will try enabling prints at the possible error in contikimac or framer802154 parser.

Kindly please provide your inputs.

I will try to move to contiki-ng meanwhile.

[kkrentz]

The problem seems to be outside of adaptivesec. It could be due to ContikiMAC, which is known to suffer from some timing issues. Besides, I have also encountered a lot of trouble with CSMA in the past. If you are using a CC2538-based platform, you may try my CSL implementation https://github.com/kkrentz/contiki-ng/wiki/CSL instead.

[amitbhanja]

@kkrentz , thanks a lot for your advice. I am actually using srf06-cc26xx platform. What settings would you suggest to enable in contiki-ng for proper working? I am observing in the original contiki version that after using security, there have been issues of sometimes no packet being received at the gateway. Upon restarting those nodes, packets are being received. It seems to be issues with contikimac along with radio driver.

Well , I will test with contiki-ng. Please recommend what settings to do for cc26xx platforms.
Using null-seeder now.