search

PelionIoT / nanostack-libservice

Other
2 stars 11 forks source link

mbed-client-example-6lowpan fails 6LoWPAN ND Bootstrap #41

Closed betzw closed 8 years ago

betzw commented 8 years ago

Since version 'v3.5.2' of this module example application mbed-client-example-6lowpan (branch master) fails to bootstrap together with k64f-border-router (branch master) generating the following trace:

Start mbed-client-example-6lowpan
[DBG ][m6La]: init()
[DBG ][m6La]: connect()
[DBG ][m6LND]: Link-layer security NOT enabled.
[DBG ][m6LND]: Channel: 12
[DBG ][m6LND]: Channel page: 0
[DBG ][m6LND]: Channel mask: 4096
[INFO][m6LND]: Start 6LoWPAN ND Bootstrap
[DBG ][m6LND]: app_parse_network_event() 8
[DBG ][m6LND]: ND/RPL scan new network
[DBG ][m6LND]: Restart bootstrap
[DBG ][m6LND]: app_parse_network_event() 8
[DBG ][m6LND]: ND/RPL scan new network
[DBG ][m6LND]: Restart bootstrap
...

Substituting file source/nsdynmemLIB/nsdynmemLIB.c with its version as of this commit makes the bootstrap being successful again.

Any idea?

ciarmcom commented 8 years ago

ARM Internal Ref: ONME-2718

hasnainvirk commented 8 years ago

Hi @betzw

This is not an application issue. You have configured your device wrongly. K64F-Border-Router Application enables PSK security by default on the linkl layer. Your client is not configured with any security as it is evident from the log message: [DBG ][m6LND]: Link-layer security NOT enabled.

Are you sure that you are not using security on Border Router side ? If not , add the following line (securit_mode) in the section shown below.

"6lowpan_nd": {
  "channel_page": 0,
  "channel": 12,
  "security_mode": "PSK"
}

Hope it will help.

hasnainvirk commented 8 years ago

@betzw I have reproduced the issue, but correct configuration, please check the output:

Start mbed-client-example-6lowpan

[DBG ][m6LND]: Using PSK security mode. [DBG ][m6LND]: Channel: 12 [DBG ][m6LND]: Channel page: 0 [DBG ][m6LND]: Channel mask: 4096 [INFO][m6LND]: Start 6LoWPAN ND Bootstrap [DBG ][m6LND]: app_parse_network_event() 0 [INFO][m6LND]: 6LoWPAN ND bootstrap ready [DBG ][m6LND]: ND Access Point: 2001:999:22:4491:0:ff:fe00:face [DBG ][m6LND]: ND Prefix 64: 20:01:09:99:00:22:44:91 [DBG ][m6LND]: GP IPv6: 2001:999:22:4491:fec2:3d00:4:b841 [DBG ][m6LND]: MAC 16-bit: ff:ff [DBG ][m6LND]: PAN ID: 07:00 [DBG ][m6LND]: MAC 64-bit: fc:c2:3d:00:00:04:b8:41 [DBG ][m6LND]: IID (Based on MAC 64-bit address): fe:c2:3d:00:00:04:b8:41 [DBG ][m6LND]: Channel: 12 mesh_network_handler() 0

                                      waiting 5s before sending registration...

send_registration() [DBG ][ns_wrap]: SOCKET_TX_DONE, 163 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=60 [DBG ][ns_wrap]: SOCKET_TX_DONE, 195 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=112 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=384 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=201 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=158 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=25 [DBG ][ns_wrap]: SOCKET_TX_DONE, 498 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 123 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 101 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 14 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 61 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=14 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=61 [DBG ][ns_wrap]: SOCKET_TX_DONE, 216 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=123 object_registered()

betzw commented 8 years ago

Ciao Hasnain,

sorry for the late answer! What I have forgotten to mention in my initial issue report is, that I have also modified the configuration of the k64f-border-router specifying to not use security:

...
  "border-router": {
    "debug-traces": 1,
    "name": "mbed OS Border Router",
    "model": "FRDM-K64F-BR",
    "manufacturer": "ARM",
    "network-mode": "ND_WITH_MLE",
    "security-mode": "NONE",
...

This is the reason why my setup normally led to a successful bootstrap! As described above, it is only since version 'v3.5.2' of file source/nsdynmemLIB/nsdynmemLIB.c of module nanostack-libservice that the bootstrap in my configuration (i.e. without security) fails.

So my question now becomes has the usage of security become mandatory? I do not hope so!

hasnainvirk commented 8 years ago

Hi @betzw ,

I just tested without security. It works.

Start mbed-client-example-6lowpan

[DBG ][m6LND]: Link-layer security NOT enabled. [DBG ][m6LND]: Channel: 12 [DBG ][m6LND]: Channel page: 0 [DBG ][m6LND]: Channel mask: 4096 [INFO][m6LND]: Start 6LoWPAN ND Bootstrap [DBG ][m6LND]: app_parse_network_event() 0 [INFO][m6LND]: 6LoWPAN ND bootstrap ready [DBG ][m6LND]: ND Access Point: 2001:999:11:b6b3:0:ff:fe00:face [DBG ][m6LND]: ND Prefix 64: 20:01:09:99:00:11:b6:b3 [DBG ][m6LND]: GP IPv6: 2001:999:11:b6b3:fec2:3d00:4:b841 [DBG ][m6LND]: MAC 16-bit: ff:ff [DBG ][m6LND]: PAN ID: 07:00 [DBG ][m6LND]: MAC 64-bit: fc:c2:3d:00:00:04:b8:41 [DBG ][m6LND]: IID (Based on MAC 64-bit address): fe:c2:3d:00:00:04:b8:41 [DBG ][m6LND]: Channel: 12 mesh_network_handler() 0

                                      waiting 5s before sending registration...

send_registration() [DBG ][ns_wrap]: SOCKET_TX_DONE, 163 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=60 [DBG ][ns_wrap]: SOCKET_TX_DONE, 195 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=112 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=384 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=202 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=158 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=25 [DBG ][ns_wrap]: SOCKET_TX_DONE, 499 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 123 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 100 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 14 bytes sent [DBG ][ns_wrap]: SOCKET_TX_DONE, 61 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=14 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=61 [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=61 [DBG ][ns_wrap]: SOCKET_TX_DONE, 216 bytes sent [DBG ][ns_wrap]: SOCKET_DATA, sock=1, bytes=123 object_registered()

hasnainvirk commented 8 years ago

Security usage is not mandatory. However, its a good indicator that alongwith transport layer security, TrustZone etc we also have link layer security.

betzw commented 8 years ago

Are you using the same HW setup as mine, i.e. two K64F boards, one for client and one for server?

hasnainvirk commented 8 years ago

Probably the issue was resolved in new release of nanostack-libservice (3.6.0). You can update your yotta modules. I hope this will help.

hasnainvirk commented 8 years ago

Yes. I am using exact same setup as yours.

mbed-client-example-6lowpan 0.0.3 ┣━ mbed-client 1.13.1 ┃ ┣━ mbed-client-c 2.7.7 yotta_modules/mbed-client-c ┃ ┃ ┗━ nanostack-libservice 3.6.0 yotta_modules/nanostack-libservice ┃ ┣━ mbed-trace 1.2.1 yotta_modules/mbed-trace ┃ ┣━ mbed-client-mbed-os 3.0.3 yotta_modules/mbed-client-mbed-os ┃ ┃ ┣━ mbed-drivers 1.5.0 yotta_modules/mbed-drivers ┃ ┃ ┃ ┣━ mbed-hal 1.3.0 yotta_modules/mbed-hal ┃ ┃ ┃ ┃ ┗━ mbed-hal-freescale 1.1.0 yotta_modules/mbed-hal-freescale ┃ ┃ ┃ ┃ ┗━ mbed-hal-ksdk-mcu 1.3.0 yotta_modules/mbed-hal-ksdk-mcu ┃ ┃ ┃ ┃ ┣━ uvisor-lib 2.1.2 yotta_modules/uvisor-lib ┃ ┃ ┃ ┃ ┗━ mbed-hal-k64f 1.3.0 yotta_modules/mbed-hal-k64f ┃ ┃ ┃ ┃ ┗━ mbed-hal-frdm-k64f 1.1.1 yotta_modules/mbed-hal-frdm-k64f ┃ ┃ ┃ ┣━ cmsis-core 1.2.0 yotta_modules/cmsis-core ┃ ┃ ┃ ┃ ┗━ cmsis-core-freescale 1.1.0 yotta_modules/cmsis-core-freescale ┃ ┃ ┃ ┃ ┗━ cmsis-core-k64f 1.1.0 yotta_modules/cmsis-core-k64f ┃ ┃ ┃ ┣━ ualloc 1.3.0 yotta_modules/ualloc ┃ ┃ ┃ ┃ ┗━ dlmalloc 1.1.0 yotta_modules/dlmalloc ┃ ┃ ┃ ┣━ minar 1.3.0 yotta_modules/minar ┃ ┃ ┃ ┃ ┗━ minar-platform 1.1.0 yotta_modules/minar-platform ┃ ┃ ┃ ┃ ┗━ minar-platform-mbed 1.3.0 yotta_modules/minar-platform-mbed ┃ ┃ ┃ ┣━ core-util 1.8.0 yotta_modules/core-util ┃ ┃ ┃ ┣━ compiler-polyfill 1.3.0 yotta_modules/compiler-polyfill ┃ ┃ ┃ ┗━ greentea-client 1.1.0 yotta_modules/greentea-client ┃ ┃ ┗━ sockets 1.3.0 yotta_modules/sockets ┃ ┃ ┗━ sal 1.3.1 yotta_modules/sal ┃ ┗━ mbed-client-mbedtls 3.0.3 yotta_modules/mbed-client-mbedtls ┃ ┗━ mbedtls 2.3.2 yotta_modules/mbedtls ┣━ atmel-rf-driver 2.1.1 ┃ ┗━ sal-stack-nanostack 4.1.0 yotta_modules/sal-stack-nanostack ┃ ┣━ sal-stack-nanostack-eventloop 1.1.0 yotta_modules/sal-stack-nanostack-eventloop ┃ ┃ ┗━ mbed-6lowpan-eventloop-adaptor 1.2.4 yotta_modules/mbed-6lowpan-eventloop-adaptor ┃ ┣━ nanostack-randlib 1.1.0 yotta_modules/nanostack-randlib ┃ ┗━ coap-service 2.2.1 yotta_modules/coap-service ┗━ mbed-mesh-api 2.3.0 ┗━ sal-iface-6lowpan 2.1.1 yotta_modules/sal-iface-6lowpan

betzw commented 8 years ago

Are you still using yotta for building and minar as scheduler?

hasnainvirk commented 8 years ago

Please check the yotta listing here. Do "yt update" at your example side. Check the same thing at your k64f-border router side.

For mbed-client-example-6lowpan , you can't use morpheous. For morpheous we have a seperate application. https://github.com/ARMmbed/mbed-os-example-client

hasnainvirk commented 8 years ago

k64f-border-router is ported to morpheous already. So you can test it with the above mentioned example application.

betzw commented 8 years ago

Great, I will go thru this and analyze (the non-morpheous story). Thanks in the meanwhile!

hasnainvirk commented 8 years ago

Pleasure is all mine. I have tested both with yotta and mbedOS-5. I hope you will not find any issue. Happy hunting. Your feedback is very important to us.

betzw commented 8 years ago

Just for your info, I have been able to get my mbed-client bootstrap being successful back again with k64f-BR using the same nanostack-libservice revision as yourself (i.e. v3.6.0). But in order to get it working I needed to update also the Atmel driver (atmel-rf-driver) from v2.1.0 to v2.1.1! Thanks again for your support!