Wi-SUN interface implementation. #8600

KariHaapalehto · 2018-10-31T10:07:47Z

This is a initial version of Wi-SUN interface implementation.
To get Wi-SUN mesh network working, also nanostack with Wi-Sun support is needed. ws_empty_functions.c and ws_management_api.h are temporary included here,
so that wisun_tasklet will compiled without problems.
They will replaced with the official versions with next nanostack release.

Description

Tested locally with Nucleo_F429ZI

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[X] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

0xc0170 · 2018-10-31T10:37:22Z

travis-ci/astyle — Passed, 547 files (+2 files)

@KariHaapalehto Can you run astyle on the changes (features are currently being updated so would like avoiding new styling issues) ?

To get Wi-Sun mesh network working, also nanostack with Wi-Sun support is needed. ws_empty_functions.c and ws_management_api.h are temporary included here, so that wisun_tasklet will compiled without problems. They will replaced with the official versions with next nanostack release.

KariHaapalehto · 2018-10-31T13:50:04Z

AStyle fixes done

KariHaapalehto · 2018-11-01T06:44:21Z

@artokin @juhhei01 @mikter @JarkkoPaso for your information

mikter · 2018-11-01T10:01:26Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "value": 0
+        },
+        "wisun-device-type": {
+            "help": "Device mode (NET_6LOWPAN_ROUTER or NET_6LOWPAN_HOST). Router is routing packets from other device, creating a mesh network.",


currently supported modes are border router and router. but through mesh API I don't know if border router is wanted at all

mikter · 2018-11-02T07:22:07Z

@JarkkoPaso please check

mikter · 2018-11-01T10:03:23Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "help": "Device mode (NET_6LOWPAN_ROUTER or NET_6LOWPAN_HOST). Router is routing packets from other device, creating a mesh network.",
+            "value": "NET_6LOWPAN_ROUTER"
+        },
+        "wisun-nd-channel-mask": {


channel mask in wish goes from 0 to maximum amount of channels defined by regulatory domain and class. the maximum amount possible is 8* uint32

mikter · 2018-11-01T10:04:00Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "help": "Channel mask, bit-mask of channels to use. [0-0x07fff800]",
+            "value": "0x7fff800"
+        },
+        "wisun-nd-channel-page": {


channel page is not needed in wi-SUN

mikter · 2018-11-01T10:04:30Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "value": 0
+        },
+        "wisun-nd-channel": {
+            "help": "RF channel to use when `channel_mask` is not defined. [0-26].",


not needed in wi-SUN

mikter · 2018-11-01T10:04:59Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "value": 0
+        },
+        "wisun-nd-panid-filter": {
+            "help": "Beacon PAN ID filter, 0xffff means no filtering. [0-0xffff]",


Not needed in Wi-SUN

mikter · 2018-11-01T12:12:33Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+    wisun_tasklet_data_ptr->channel_list.channel_page = (channel_page_e)MBED_CONF_MBED_MESH_API_WISUN_ND_CHANNEL_PAGE;
+    wisun_tasklet_data_ptr->channel_list.channel_mask[0] = MBED_CONF_MBED_MESH_API_WISUN_ND_CHANNEL_MASK;
+
+    if (channel > 0) {


Channel mask and channel selection is not needed to Wi-SUN

mikter · 2018-11-01T12:20:21Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+    arm_nwk_6lowpan_link_nwk_id_filter_for_nwk_scan(wisun_tasklet_data_ptr->network_interface_id, NULL);
+
+    arm_nwk_6lowpan_link_panid_filter_for_nwk_scan(
+        wisun_tasklet_data_ptr->network_interface_id,


Not needed for Wi-SUN

mikter · 2018-11-01T12:20:35Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+
+    // Enable MPL by default
+    const uint8_t all_mpl_forwarders[16] = {0xff, 0x03, [15] = 0xfc};
+    multicast_mpl_domain_subscribe(wisun_tasklet_data_ptr->network_interface_id,


Not Needed for Wi-SUN

mikter · 2018-11-01T12:25:58Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+        tr_error("MAC Address read fail\n");
+    } else {
+        uint8_t temp[2];
+        common_write_16_bit(app_link_address_info.mac_short, temp);


mac16 not used in wi-SUN

this is true

mikter · 2018-11-01T12:26:28Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+        tr_debug("IID (Based on MAC 64-bit address): %s", trace_array(app_link_address_info.iid_eui64, 8));
+    }
+
+    tr_debug("Channel: %d", arm_net_get_current_channel(wisun_tasklet_data_ptr->network_interface_id));


Channel is meaningless in channel hopping network do you really need this?

mikter · 2018-11-01T12:27:05Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+    network_layer_address_s app_nd_address_info;
+    link_layer_address_s app_link_address_info;
+    uint8_t temp_ipv6[16];
+    if (arm_nwk_nd_address_read(wisun_tasklet_data_ptr->network_interface_id, &app_nd_address_info) != 0) {


I don't know do these give meaningless information ?

Will remove these

juhhei01

Looks good for me.

JarkkoPaso · 2018-11-02T08:10:29Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "value": 0
+        },
+        "wisun-bc-dwell-interval": {
+            "help": "Broadcast dwell interval. Range: 15-250 milliseconds",


They have changed the dwell time range to 15-255ms in new spec. I know, it is still wrong in nanostack api also. Same thing in wisun-uc-dwell-interval.

jarlamsa

Fix the typo now to prevent issues later

jarlamsa · 2018-11-05T14:15:42Z

features/nanostack/mbed-mesh-api/mbed_lib.json

+            "help": "default network name for wisun network",
+            "value": "\"NETWORK_NAME\""
+        },
+        "wisun-regulator-domain": {


Fix typo: regulatory domain, also need to change to the tasklet code.

jarlamsa · 2018-11-05T14:16:07Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+        wisun_tasklet_data_ptr->operating_mode_extension);
+
+    ws_management_node_init(wisun_tasklet_data_ptr->network_interface_id,
+                            MBED_CONF_MBED_MESH_API_WISUN_REGULATOR_DOMAIN,


jarlamsa · 2018-11-05T14:16:19Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+                            fhss_timer_ptr);
+
+    tr_debug("Domain: %d, mode: %d, class: %d, network name: %s",
+        MBED_CONF_MBED_MESH_API_WISUN_REGULATOR_DOMAIN,


mikter · 2018-11-06T07:24:58Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+
+    tr_debug("Domain: %d, mode: %d, class: %d, network name: %s",
+        MBED_CONF_MBED_MESH_API_WISUN_REGULATORY_DOMAIN,
+        MBED_CONF_MBED_MESH_API_WISUN_OPERATING_MODE,


tracing mode and class is incorrect as those are not set really.

if those values are different from default use for example following way to configure

if (ws_conf.operating_mode != 255 || ws_conf.operating_class != 255 ) { ret = ws_management_regulatory_domain_set(mesh->net_rf_id, ws_conf.regulatory_domain, ws_conf.operating_class, ws_conf.operating_mode); if (ret != 0) { cmd_printf("Regulatory domain configuration failed %"PRIi32"\r\n", ret); return CMDLINE_RETCODE_FAIL; } }

mikter · 2018-11-06T07:27:15Z

features/nanostack/sal-stack-nanostack/source/6LoWPAN/ws/ws_management_api.h

@@ -0,0 +1,233 @@
+/*


This file is public API and is now on wrong place. is this intentional?

I'll move it to mbed-os\features\nanostack\sal-stack-nanostack\nanostack

artokin · 2018-11-07T07:48:39Z

features/nanostack/mbed-mesh-api/source/WisunInterface.cpp

+char *Nanostack::WisunInterface::get_gateway(char *buf, nsapi_size_t buflen)
+{
+    NanostackLockGuard lock;
+    if (wisun_tasklet_get_router_ip_address(buf, buflen) == 0) {


get_gateway is calling wisun_tasklet_get_router_ip_address and getRouterIpAddress is calling get_gateway?

This is implemented just like LOWPANNDInterface.
and WisunInterface::getRouterIpAddress is a api for wisun

artokin · 2018-11-07T07:50:47Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+
+// For tracing we need to define flag, have include and define group
+//#define HAVE_DEBUG
+#define TRACE_GROUP  "wisuND"


Not sure if we want to keep trace group max 4 characters long?

Will change it for 4 char

KariHaapalehto · 2018-11-08T12:21:05Z

@mikter Any other comments/change request?

mikter · 2018-11-08T12:46:06Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+    // TODO, read interface name from configuration
+    mac_description_storage_size_t storage_sizes;
+    storage_sizes.device_decription_table_size = 32;
+    storage_sizes.key_description_table_size = 6;


This should be 4

0xc0170 · 2018-11-12T12:35:50Z

@jarlamsa Can you rereview?

They will replaced with the official versions with next nanostack release.

@KariHaapalehto When is this happening? for 5.11 or later?

jarlamsa · 2018-11-12T13:52:45Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+            if (wisun_tasklet_data_ptr->tasklet_state != TASKLET_STATE_BOOTSTRAP_READY) {
+                tr_info("Wi-SUN bootstrap ready");
+                wisun_tasklet_data_ptr->tasklet_state = TASKLET_STATE_BOOTSTRAP_READY;
+                wisun_tasklet_network_state_changed(MESH_CONNECTED);


The local ula prefix needs probably to be checked similar to thread_tasklet.c to prevent reporting NSAPI_GLOBAL_UP with only ula prefix.

@juhhei01 @mikter please comment

Any comments about this? 6lowpan isn't doing it....

@kjbracey-arm can you comment on this?

I don't believe Wi-SUN has any inherent concept analogous to the "mesh-local" address. Thread only says "local" if it has specifically only the Thread mesh-local address, not any ULA.

I believe the logic was that a standard ULA could equally represent a connection tunnel to a cloud server as well as a site-specific ULA, so we treat ULAs as "global" - we've no idea how many networks we can get with them. There could even be NAT going on, so we have a ULA but NATted global connectivity.

Apps can check to see if "get_ip_address" returns a ULA themselves if they want to distinguish between a ULA or need a real global address.

However, all the IPv6 things should be saying "local" if they only have a link-local address. The Thread stuff is just stretching that to also cover the thread mesh-local link.

Maybe if there was some other was to detect definitely local connectivity? Both 6LoWPAN-ND and Wi-SUN could maybe look at the "grounded" flag of the DODAG. If that was exposed via API, you would be local if clear. But then you'd need an event mechanism for it changing. Would be an extension.

In IPv4, the global is actualy "We have a router and DHCP somewhere" so I think equal state should be indicated here.
I don't know how...

Do we have any API to ask that "is border router alive and does it have a backbone"

Because, the whole distinction between GLOBAL and LOCAL should not be about IP address scope. It should be answer to the question whether there is a route to "somewhere"
yes -> global
no -> local

And that information can be used in Mbed Client: "Should I try the TLS handshake again?" and the answer is the same.
GLOBAL -> yes
other states -> no

So there will most probably be cases where ULA prefix satisfies the requirement.

Not sure we have any existing logic about route existence, or at least don't recall seeing it.

I think maybe it's just convenient that having an IPv4 address implies a DHCPv4 server, and one assumes that a DHCPv4 server is a router. We assume we don't auto-assign ourselves a "link-local" 169.254.x.x address.

So, IPv6 for LwIP checks for non-link-local IPv6 addresses. As does MeshInterfaceNanostack. "MESH_CONNECTED" is turned into either LOCAL_UP or GLOBAL_UP depending on if we only have a link-local address.

The Thread special case is stopping the mesh-local ULA from being reported as global, as any other ULA is.

So I think this is correct for now - it's plausible to assume if you have a ULA you at least have a router giving out SLAAC prefixes, even if it's not connected to anywhere, just like you assume the same for DHCPv4.

Do we have any API to ask that "is border router alive and does it have a backbone"

Not sure whether it's easily or at all findable via public APIs, but RPL Grounded flag would be it, if the border router is maintaining it correctly. I think that's a general extension for 6LoWPAN-ND and Wi-SUN though - not something for this PR.

kjbracey

Approve - main reservation is on the name capitalisation, but I can live with this is others prefer it this way.

Not inspected the bulk of the code in detail, but I'm assuming it's faithfully cloned from the 6LoWPAN-ND stuff. At some point we should try to reduce the duplication, but this will do for starters.

kjbracey · 2018-11-16T08:55:16Z

features/nanostack/mbed-mesh-api/mbed-mesh-api/WisunInterface.h

+ *
+ * Configure Nanostack to use Wi-SUN protocol.
+ */
+class WisunInterface : public MeshInterfaceNanostack {


Not WiSUNInterface? We have LoWPANNDInterface with full silly capitalisation for 6LoWPAN-ND. Seems inconsistent, but maybe there's another factor.

kjbracey · 2018-11-16T09:00:53Z

features/nanostack/mbed-mesh-api/source/wisun_tasklet.c

+            if (wisun_tasklet_data_ptr->tasklet_state != TASKLET_STATE_BOOTSTRAP_READY) {
+                tr_info("Wi-SUN bootstrap ready");
+                wisun_tasklet_data_ptr->tasklet_state = TASKLET_STATE_BOOTSTRAP_READY;
+                wisun_tasklet_network_state_changed(MESH_CONNECTED);


I don't believe Wi-SUN has any inherent concept analogous to the "mesh-local" address. Thread only says "local" if it has specifically only the Thread mesh-local address, not any ULA.

I believe the logic was that a standard ULA could equally represent a connection tunnel to a cloud server as well as a site-specific ULA, so we treat ULAs as "global" - we've no idea how many networks we can get with them. There could even be NAT going on, so we have a ULA but NATted global connectivity.

Apps can check to see if "get_ip_address" returns a ULA themselves if they want to distinguish between a ULA or need a real global address.

However, all the IPv6 things should be saying "local" if they only have a link-local address. The Thread stuff is just stretching that to also cover the thread mesh-local link.

Maybe if there was some other was to detect definitely local connectivity? Both 6LoWPAN-ND and Wi-SUN could maybe look at the "grounded" flag of the DODAG. If that was exposed via API, you would be local if clear. But then you'd need an event mechanism for it changing. Would be an extension.

kjbracey · 2018-11-16T09:06:40Z

features/nanostack/sal-stack-nanostack/nanostack/ws_management_api.h

+#endif
+
+/* Regulatory domain values*/
+#define REG_DOMAIN_WW   0x00 // World wide


This is obviously for Nanostack, but really all these defines should have WS_ prefixes.

0xc0170 · 2018-11-19T12:24:01Z

@KariHaapalehto Can you review latest comments ? Is this targeting 5.11 ? (not yet labeled!)

KariHaapalehto · 2018-11-19T13:12:02Z

Yes, this can be targeted to 5.11.

0xc0170 · 2018-11-20T09:18:10Z

@KariHaapalehto @jarlamsa All review comments addressed ? @jarlamsa CAn you update your review feedback here?

0xc0170 · 2018-11-20T12:46:00Z

/morph build

mbed-ci · 2018-11-20T16:05:17Z

Build : SUCCESS

Build number : 3689
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/8600/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

mbed-ci · 2018-11-20T20:08:17Z

Exporter Build : FAILURE

Build number : 3290
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8600/

mbed-ci · 2018-11-20T21:06:51Z

Test : FAILURE

Build number : 3463
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/8600/3463

0xc0170 · 2018-11-21T11:10:40Z

/morph export-build

mbed-ci · 2018-11-21T12:59:41Z

Exporter Build : FAILURE

Build number : 3296
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/8600/

0xc0170 · 2018-11-21T13:19:47Z

Exporters failure ^^ pipeline closed, will restart or goes to rollup (most probably rollup )

cmonr · 2018-11-22T02:02:49Z

CI started.

mbed-ci · 2018-11-22T06:10:30Z

Test run: SUCCESS

Summary: 4 of 4 test jobs passed
Build number : 9
Build artifacts
Build logs

0xc0170 requested a review from a team October 31, 2018 10:35

0xc0170 added the needs: review label Oct 31, 2018

KariHaapalehto force-pushed the wisuninterface_created branch from 6ce4262 to 4440612 Compare October 31, 2018 13:48

0xc0170 requested a review from a team October 31, 2018 13:49

SeppoTakalo approved these changes Oct 31, 2018

View reviewed changes

mikter reviewed Nov 1, 2018

View reviewed changes

mikter reviewed Nov 2, 2018

View reviewed changes

juhhei01 reviewed Nov 2, 2018

View reviewed changes

JarkkoPaso reviewed Nov 2, 2018

View reviewed changes

0xc0170 approved these changes Nov 5, 2018

View reviewed changes

jarlamsa suggested changes Nov 5, 2018

View reviewed changes

cmonr added needs: work and removed needs: review labels Nov 5, 2018

KariHaapalehto force-pushed the wisuninterface_created branch from 92c9223 to 4c3015d Compare November 6, 2018 06:32

mikter reviewed Nov 6, 2018

View reviewed changes

KariHaapalehto force-pushed the wisuninterface_created branch from 4c3015d to d6c402d Compare November 6, 2018 08:14

0xc0170 added needs: review and removed needs: work labels Nov 6, 2018

artokin reviewed Nov 7, 2018

View reviewed changes

KariHaapalehto force-pushed the wisuninterface_created branch from d6c402d to 3161cb5 Compare November 7, 2018 13:12

mikter reviewed Nov 8, 2018

View reviewed changes

Review changes corrected

6163e6f

KariHaapalehto force-pushed the wisuninterface_created branch from 3161cb5 to 6163e6f Compare November 8, 2018 12:53

mikter approved these changes Nov 12, 2018

View reviewed changes

jarlamsa reviewed Nov 12, 2018

View reviewed changes

adbridge added needs: work and removed needs: review labels Nov 14, 2018

kjbracey approved these changes Nov 16, 2018

View reviewed changes

0xc0170 added the release-version: 5.11.0-rc1 label Nov 19, 2018

jarlamsa approved these changes Nov 20, 2018

View reviewed changes

cmonr added needs: CI rollup PR and removed needs: work labels Nov 21, 2018

0xc0170 added ready for merge and removed needs: CI rollup PR labels Nov 22, 2018

0xc0170 merged commit f1f6426 into ARMmbed:master Nov 22, 2018

0xc0170 removed the ready for merge label Nov 22, 2018

KariHaapalehto deleted the wisuninterface_created branch November 23, 2018 10:09

Wi-SUN interface implementation. #8600

Wi-SUN interface implementation. #8600

Uh oh!

Conversation

KariHaapalehto commented Oct 31, 2018

Description

Pull request type

Uh oh!

0xc0170 commented Oct 31, 2018

Uh oh!

KariHaapalehto commented Oct 31, 2018

Uh oh!

KariHaapalehto commented Nov 1, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikter commented Nov 2, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

juhhei01 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jarlamsa left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

KariHaapalehto commented Nov 8, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Nov 12, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!