Evan Ross

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

6 years, 9 months ago.

Can't connect more than one mesh node to Nanostack 6LoWPAN Border Router

My setup consists of the SPIRIT1 sub-GHz radios, the NUCLEO_L152RE target for the mesh nodes and the NUCLEO_F429ZI target for the border router. The setup is configured according to the project instructions on GitHub.

I have the nanostack-border-router project built and running with suitably modified hardware (according to GitHub project documentation). The 6LoWPAN bootstrap completes (in dynamic mode) and both the Ethernet and air interfaces come up.

I have the mbed-os-example-mesh-minimal project built and running on multiple mesh nodes. Each node runs identical firmware EXCEPT for the MAC address which is altered for each node. The nodes are configured for HOST mode to test the simplest network topology.

I have full tracing enabled for both border router and mesh node projects.

Expected Result: Multiple mesh nodes join the network and I can ping each one individually.

Actual Result: Only one node joins the network successfully and can be pinged from a PC. The other node continuously attempts then fails to connect, citing "[DBG ][m6LND]: app_parse_network_event() 8".

Additional Information: When the currently connected node is powered down, the other node quickly joins the network.

Below is the debug output from the node that FAILS to connect:

[INFO][m6LND]: Start 6LoWPAN ND Bootstrap
[DBG ][SPIRIT]: rf_interface_state_control (165) - channel: 1
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_interface_state_control (153)
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=6, adr1=91, val=1681
[DBG ][SPIRIT]: rf_interface_state_control (165) - channel: 1
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=6, adr1=91, val=1681
[DBG ][SPIRIT]: rf_set_short_adr (248), adr0=ff, adr1=ff, val=65535
[DBG ][SPIRIT]: rf_interface_state_control (153)
[DBG ][m6LND]: app_parse_network_event() 8
[DBG ][m6LND]: ND/RPL scan new network
[DBG ][m6LND]: Restart bootstrap
[DBG ][m6LND]: Link-layer security NOT enabled.
[DBG ][m6LND]: Channel: 1
[DBG ][m6LND]: Channel page: 2
[DBG ][m6LND]: Channel mask: 2
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=ff, adr1=ff, val=65535
[DBG ][SPIRIT]: rf_set_short_adr (248), adr0=ff, adr1=ff, val=65535
[INFO][m6LND]: Start 6LoWPAN ND Bootstrap
[DBG ][SPIRIT]: rf_interface_state_control (165) - channel: 1
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_interface_state_control (153)
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=6, adr1=91, val=1681
[DBG ][SPIRIT]: rf_interface_state_control (165) - channel: 1
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=6, adr1=91, val=1681
[DBG ][SPIRIT]: rf_set_short_adr (248), adr0=ff, adr1=ff, val=65535
[DBG ][SPIRIT]: rf_interface_state_control (153)
[DBG ][m6LND]: app_parse_network_event() 8
[DBG ][m6LND]: ND/RPL scan new network
[DBG ][m6LND]: Restart bootstrap
[DBG ][m6LND]: Link-layer security NOT enabled.
[DBG ][m6LND]: Channel: 1
[DBG ][m6LND]: Channel page: 2
[DBG ][m6LND]: Channel mask: 2
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=ff, adr1=ff, val=65535
[DBG ][SPIRIT]: rf_set_short_adr (248), adr0=ff, adr1=ff, val=65535
[INFO][m6LND]: Start 6LoWPAN ND Bootstrap

Below is the debug output from the node that connects SUCCESSFULLY:

[INFO][m6LND]: Start 6LoWPAN ND Bootstrap
[DBG ][SPIRIT]: rf_interface_state_control (165) - channel: 1
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_interface_state_control (153)
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=6, adr1=91, val=1681
[DBG ][SPIRIT]: rf_interface_state_control (165) - channel: 1
[DBG ][SPIRIT]: rf_set_pan_id (255), adr0=6, adr1=91, val=1681
[DBG ][SPIRIT]: rf_set_short_adr (248), adr0=ff, adr1=ff, val=65535
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][SPIRIT]: rf_extension (196)
[DBG ][m6LND]: app_parse_network_event() 0
[INFO][m6LND]: 6LoWPAN ND bootstrap ready
[DBG ][m6LND]: ND Access Point: 2001:56a:71ff:2c00:0:ff:fe00:face
[DBG ][m6LND]: ND Prefix 64: 20:01:05:6a:71:ff:2c:00
[DBG ][m6LND]: GP IPv6: 2001:56a:71ff:2c00:1211:1213:1415:1617
[DBG ][m6LND]: MAC 16-bit: ff:ff
[DBG ][m6LND]: PAN ID: 06:91
[DBG ][m6LND]: MAC 64-bit: 10:11:12:13:14:15:16:17
[DBG ][m6LND]: IID (Based on MAC 64-bit address): 12:11:12:13:14:15:16:17
[DBG ][m6LND]: Channel: 1

I have attached the mbed_app.json file for the mbed-os-example-mesh-minimal project and the nanostack-border-router project.

The mbed-os-example-mesh-minimal project is compiled with 'mbed compile -t GCC_ARM -m NUCLEO_L152RE' and the nanostack-border-router project is compiled with 'mbed compile -t GCC_ARM -m NUCLEO_F429ZI'.

/media/uploads/firmwareguru/mbed_app-nanostack-border-router-.json /media/uploads/firmwareguru/mbed_app-mbed-os-mesh-minimal-.json

1 Answer

Kevin Bracey
6 years, 9 months ago.

The obvious question is - are you absolutely sure the two devices have different MAC addresses?

The next proposal would be to switch the feature to NANOSTACK_FULL or LOWPAN_BORDER_ROUTER or LOWPAN_ROUTER, while keeping the node as NET_6LOWPAN_HOST.

If any of those work, that means there's an error in the cut-down host-only binary. Most testing (even for host mode) is performed on the full binary - it's possible there is an error that only occurs in the cut-down binary.

If that still fails, try changing the device mode to NET_6LOWPAN_ROUTER. Most testing is performed with full routers, rather than host-only devices, and also most stack tests are performed with Atmel RF212/233 radios (or in a simulator).

So maybe there's some combinatorial problem not seen in testing whereby specifically host mode doesn't work on this radio. (Can't think why that would be though).

I wish I could say that did it, but here's what worked.

Nothing wrong with your stacks - I think our problems were specifically related to the STM SPIRIT1 radio driver. First thing we did was disable all trace output on the nodes and the border router. There are printf's in suspect places in the driver so I'm sure there was some effect on PHY layer timing. This seemed to allow the 2 nodes to connect as HOSTs.

Next, we pulled in the latest commit (at the time) claiming updates to the broadcast PAN IDs. This seemed to make the system work in ROUTER mode.

Since then, I've noticed more commits addressing fundamental operation of the PHY. So, it is very clear that the SPIRIT1 driver for nanostack is still in active development. One can only expect behavior consistent with that design stage. Lesson learned.

posted by Evan Ross 06 Jul 2017