developing custom border router applications -- ug116

UG116: Developing Custom Border RouterApplications

A Thread border router is a device in a Thread network that pro-vides connectivity to adjacent networks on other physical layers.The border router provides services for devices within the Threadnetwork, including routing services for off-network operations. Sil-icon Labs provides a Border Router Add-On Kit containing aRaspberry Pi device, example applications, and the underlyingAPIs required to build border router software. This user guideprovides information for developing custom border router applica-tions.

KEY POINTS

• Architecture• Operation• Build and installation instructions• Border Router configuration• Test router configuration• Utilities, files and services• Resources

silabs.com | Building a more connected world. Rev. 0.3

1. Introduction

This user guide is intended for software engineers who wish to develop a Thread Border Router System, and who are familiar with theThread specification, Silicon Labs Thread stack and Silicon Labs development kits. The hardware referenced in this document is availa-ble with the Thread Border Router Add-On Kit, part number RD-0004-0201.

This user guide assumes familiarity with these documents:• QSG102: Thread Border Router Add-On Kit Quick Start Guide• QSG113: Getting Started with Silicon Labs Thread• UG103.11: Application Development Fundamentals: Thread• AN1010: Building a Customized NCP Application

This user guide addresses the following topics:• Architecture: Shows the components, data paths, and management paths between the Thread commissioner, Thread Border Rout-

er host and NCP, and Thread end nodes.• Operation: Describes the operation of the Thread Border Router System, including commissioning, discovery and end-to-end IPv6

communication.• Build and Installation Instructions: Describes the build and installation procedure for the IP modem, IP driver, commissioning,

border router and web server applications.• Border Router configuration: Provides a reference to explain the modifications the silabs-border-router package installation makes

to the Raspbian Jessie Lite operating system installation.• Test router configuration: Provides a procedure to install the silabs-test-router package on the Border Router.• Utilities, Files and Services: Contains a listing that may be useful for Border Router configuration and development.• Resources: Includes additional information available for software engineers.

UG116: Developing Custom Border Router ApplicationsIntroduction

silabs.com | Building a more connected world. Rev. 0.3 | 2

2. Architecture

This section describes the components and features of the Thread Border Router System, including the Thread commissioner, ThreadBorder Router host and NCP, and Thread end nodes.

Figure 2.1. Border Router System Architecture

2.1 Thread Commissioning App for iOS/Android

The Thread commissioning app for iOS/Android is a utility and reference design for commissioning Thread devices. It exchanges com-missioner data via Wi-Fi with the commission-proxy-app on the Thread Border Router host and features a tool to securely commis-sion Thread end nodes on the 802.15.4 Thread network. More information about commissioning can be found in the Thread Commis-sioning white paper, which is publically available from the Thread Group.

The external Thread commissioner app and source for iOS/Android is provided by the Thread Group and can be acquired as describedin QSG102: Thread Border Router Add-On Kit Quick Start Guide. The steps for building the application are outside the scope of thisdocument.

2.2 Border Router Commissioning Proxy (commission-proxy-app)

The Border Router commissioner proxy (commission-proxy-app) on the Border Router host manages the communication between theThread stack and the external commissioner. Its features include:• Initiating mDNS advertisement with the Avahi service to the external Thread commissioning app for iOS/Android.• Running the DTLS/JPAKE handshake required to create a secure connection between the Thread network and an external commis-

sioner.

2.3 Border Router IP driver Application (ip-driver-app)

The IP driver application (ip-driver-app) on the Border Router acts as the main dispatch for the IP modem. Its features include theability to act as an intermediary, similar to a multiplexer / de-multiplexer, that can read from and write to different streams over a singleserial connection between the host and NCP.

2.4 Border Router IP Modem Application (ncp-uart)

The IP modem application (ncp-uart) on the Border Router runs the Thread stack software. Its features include a serial host interfacethat can run on Silicon Labs devices such as EM35x or EFR32MG. In the case of the Thread Border Router Add-On kit, the defaultNCP is the CEL EM3588 USB Thread Adapter, but can be an EFR32 Mighty Gecko 2.4 GHz Mesh Networking Starter Kit (WSTK)paired with an EFR32MG1 or EFR32MG12 radio board.

UG116: Developing Custom Border Router ApplicationsArchitecture


http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf

http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf

2.5 Thread End Node Sensor/Actuator Application (sensor-actuator-node)

The sensor/actuator application (sensor-actuator-node) on the Thread end nodes provides I/O for sensors, buttons and indicators. Itexchanges data and management packets via the Thread network with the ncp-uart application on the Border Router NCP. Its fea-tures include:• Secure commissioning by the Thread commissioning app for iOS/Android.• LED actuator control.• Push button and temperature telemetry reporting.

2.6 Border Router Management Application (border-router-mgmt-app)

The Border Router management application (border-router-mgmt-app) is a system management application that manages the stateof the border router during network bring-up and configuration, and tracks the state during normal operation. It features include:• Thread network configuration.• Device discovery.• Reacting to changes in network state.• Removal of Thread end nodes from the Thread network.• Removal of the Thread Border Router from the Thread network.

2.7 Web Server

The web server application on the Border Router host serves a user interface for the border-router application and is included to helpwith demonstration and diagnostics. It is similar in concept to a router administration server. Its features include:• Exposing border-router application features.• Controlling and monitoring Thread end nodes.• Removing devices from view.• Displaying system IP addresses.• Acting as the Node.js back-end server.• Providing React UI front-end implementation for rendering on computer or mobile device.

2.8 Web Browser

The web browser renders the web server user interface. Demonstration with the web browser is described in QSG102: Thread BorderRouter Add-On Kit Quick Start Guide.

2.9 Application

The application refers to an iOS/Android mobile device app, web browser plug-in such as Copper for the Mozilla browser, or any otherapplication capable of communicating with the ip-driver-app via CoAP. Demonstration with Copper plugin is described in QSG102:Thread Border Router Add-On Kit Quick Start Guide.

UG116: Developing Custom Border Router ApplicationsArchitecture


3. Operation

This section describes the operation of the Thread Border Router System, including commissioning, discovery and end-to-end IPv6communication.

3.1 Understanding the Border Router Management Application

The Thread Border Router Management Application (border-router-mgmt-app) orchestrates much of what happens during networkformation and in setting the parameters for use in a new Thread network. The state machine for the management application is shownin the following figure.

UG116: Developing Custom Border Router ApplicationsOperation


The left half of the state machine drawing corresponds to the status of the network layer. The Silicon Labs Thread Stack drives thisstate machine, and the border-router management application has no direct control over it. Instead, the border router application canindirectly influence the network state by calling various stack functions. These stack functions that influence the network state areshown above the arrows drawn from the border-router state machine to the network state diagram.

Note that the network state diagram is incomplete and only shows states of interest to the border-router application.

The right half of the figure describes the state of the border-router management application. Each state is briefly described here:

RESET_NETWORK_STATE: Calls stack function emberResetNetworkState. This clears network information from the NCP and im-mediately drops the border router from whatever network it was previously attached to.

User CLI command network-management reset is a method provided to users to achieve the same effect as going to the RE-SET_NETWORK_STATE. It is essentially equivalent to calling stack function emberResetNetworkState.

RESUME_NETWORK: The border router always transitions to this state if the stack transitions to the EMBER_SAVED_NETWORKstate. It calls the stack function emberResumeNetworkState, which causes the stack to attempt to re-join a previously-known network.This is usually what will happen if the border-router is rebooted during the UP_STATE.

FORM_NETWORK: The border router always transitions to this state if the stack transitions to the EMBER_NO_NETWORK state. De-pending on the value of AUTO_FORM_NETWORK, the border router either attempts to form a network using default settings or to forma network using manual settings. AUTO_FORM_NETWORK may be set in two ways:

1. In the /etc/siliconlabs/border-router.conf file.2. Via the CLI commands set-auto-form-off and set-auto-form-on.

If AUTO_FORM_NETWORK = 1, then default settings are used. emberFormNetwork is called, which generates a random NetworkMaster Key

If AUTO_FORM_NETWORK = 0, then manual settings are used. The border-router will wait in the FORM_NETWORK state untilthe user provides the network settings on the CLI by using the network-management commission command.

JOIN_NETWORK_COMPLETION: This state only applies to manual network formation. It is reached once the user enters appropriatedata using the network-management commission command, and tells the stack to use that data to join the network.

GET_COMMISSIONER: This state is always reached when the stack transitions to EMBER_JOINED_NETWORK_ATTACHED. Thetransition to that network state means that the border router can communicate as a member of a Thread network, but has not yet con-figured other settings appropriate for a border router. This state sets the commissioner pre-shared key.

CONFIGURE_BORDER_ROUTER: This state is reached upon successful completion of emberGetCommissioner. It informs the stackof some of the services available, such as routing, DNS (domain name system) and SLAAC (stateless autoconfiguration) using a call toemberConfigureGateway.

INITIALIZE_BORDER_ROTUER: Reached upon a successful call to emberConfigureGateway. It does some final configuration andsets up DNS.

UP_STATE: The border-router should remain in this state as long as it is on a stable network and the user takes no action otherwise. Aheartbeat is issued periodically as long as we remain in this state.

3.2 Network Formation

To form a new network means to erase the network settings, such as the Network Master Key and Extended PAN ID, and generatenew ones. A border router will no longer be able to communicate with its old network after it forms a new one. The Silicon Labs BorderRouter Add-On Kit provides two methods for network formation: Network formation with default settings, and network formation withmanual settings. Using default settings is the most secure because a random Network Master Key will be generated. Once generated,the Silicon Labs Thread Stack does not provide any mechanism for retrieving the key. Even when new devices join, the Network MasterKey is shared with them over a secure DTLS connection and cannot be intercepted by a third party.

The state of AUTO_FORM_NETWORK determines whether default or manual settings are used to derive a new network:

set-auto-form-on means to use default network settings, including a randomly-generated Network Master Key

set-auto-form-off means to use manual network settings, including a manually-entered Network Master Key

The sections below describe how to set this variable from the CLI.



3.2.1 Network Formation with Default Settings

In order to form a new network, issue a network-management reset command. There are two methods for doing this: One is to usethe CLI (described below) and the other is to issue the reset using the webserver GUI (as described in QSG102: Thread Border RouterAdd-On Kit Quick Start Guide). The GUI method is not recommended because no mechanism exists for ensuring the state of AU-TO_FORM_NETWORK.

In order to obtain CLI access to the border router, the user must kill the border-router-mgmt-app process and restart it in the fore-ground. The first step is to get the process ID of the application.

> ps aux | grep border-router-mgmt-app

To kill the application, type:

> sudo kill <PID>

Where <PID> is replaced with the actual PID number found above. Next restart the application in the foreground:

> sudo /opt/siliconlabs/threadborderrouter/bin/border-router-mgmt-app –m 4901

An example of the output of this command may be something like:

pi@br-0093:~ $ sudo /opt/siliconlabs/threadborderrouter/bin/border-router-mgmt-app -m 4901Reset info: 0x0B (SOFTWARE)Removing any IPv6 addresses configured on the host...Unbound from fe80::ba27:ebff:fe63:4ac4Unbound from 2001:db8:8569:b2b1::1Unbound from fe80::76da:38ff:fe66:135bBound to fd09:3a1f:d733:0:e524:c328:9cd5:5848Listening for CoAP on fd09:3a1f:d733:0:e524:c328:9cd5:5848Bound to fe80::a6a2:4804:5e6d:a097Listening for CoAP on fe80::a6a2:4804:5e6d:a097Rejoined network "br-0093"Bound to fd09:3a1f:d733:0:e524:c328:9cd5:5848Listening for CoAP on fd09:3a1f:d733:0:e524:c328:9cd5:5848Bound to fe80::a6a2:4804:5e6d:a097Listening for CoAP on fe80::a6a2:4804:5e6d:a097Init: 0x00Host: Thread 2.3.0.0 GA build 0 management 3584 (May 30 2017 11:06:43)NCP: Thread 2.3.0.0 GA build 0 management 3584 (May 30 2017 11:04:23)Stack initializedOTA Bootload Server Policy: GetImageNotifyInfo a=400:0:ec65:8b7e:74c3:400:f465:8b7e m=0x364C t=0x0005 v=0x00000000Setting fixed commissioner key: "COMMPW1234"Configuring default gateway for: 2001:db8:385:9318::/64Initializing border routerMaking 'all thread nodes' address: ff33:40:fd09:3a1f:d733::1Listening on all mesh nodes multicastListening for CoAP on ff03::1Listening on all mesh routers multicastListening for CoAP on ff03::2Listening on all thread nodes multicastListening for CoAP on ff33:40:fd09:3a1f:d733::1Configured DNS64Border router is upBorder router is up

At this point, we make sure that AUTO_FORM_NETWORK is turned on and issue the net reset:

border-router-mgmt-app> set-auto-form-onborder-router-mgmt-app> net resetRemoving any IPv6 addresses configured on the host...Unbound from fe80::ba27:ebff:fe63:4ac4Unbound from 2001:db8:8569:b2b1::1Unbound from fe80::76da:38ff:fe66:135bborder-router-mgmt-app> Forming network "br-0093"Reset network state completeBound to fdce:ecee:d514:0:6472:3b8e:ea39:a3a5Listening for CoAP on fdce:ecee:d514:0:6472:3b8e:ea39:a3a5



Bound to fe80::24bf:7bfe:2e72:4e86Listening for CoAP on fe80::24bf:7bfe:2e72:4e86Formed network "br-0093"OTA Bootload Server Policy: GetImageNotifyInfo a=400:0:ec65:8b7e:74c3:400:f465:8b7e m=0x364C t=0x0005 v=0x00000000Setting fixed commissioner key: "COMMPW1234"Bound to 2001:db8:385:9318:1b76:cb45:b2ab:3063Listening for CoAP on 2001:db8:385:9318:1b76:cb45:b2ab:3063Configuring default gateway for: 2001:db8:385:9318::/64Initializing border routerMaking 'all thread nodes' address: ff33:40:fdce:ecee:d514::1Listening on all mesh nodes multicastListening for CoAP on ff03::1Listening on all mesh routers multicastListening for CoAP on ff03::2Listening on all thread nodes multicastListening for CoAP on ff33:40:fdce:ecee:d514::1Configured DNS64Border router is up

The states traversed by the border router during this process are highlighted in the following figure.

In order to commission a device onto this network, proceed to section 3.3 Commissioning Using the External Commissioning Applica-tion.



3.2.2 Network Formation with Manual Settings

Using manual settings is less secure because it lets the Network Master Key escape the Thread network in plain text. It is still possiblefor a customer to contain this breach within their system, but there is some risk in doing so.

The advantage of using manual settings is that knowing the Network Master Key allows for some specific use cases:1. Debugging of the Thread network using packet capture: Packet capture tools, such as the Silicon Labs Network Analyzer, can-

not decrypt network traffic unless the Network Master Key is known. However, by design, it is impossible to read the key from thestack. Manually creating your own master key allows you to keep track of it and use it for debugging decryption.

2. Out-of-band commissioning of devices: A known master key can be preshared with devices so that they can join a Thread net-work without going through the in-band commissioning process.

As described above in section 3.2.1 Network Formation with Default Settings, the user must first to obtain CLI access to the borderrouter by killing the border-router-mgmt-app process and restarting it in the foreground. The first step is to get the process ID of theapplication:

> ps aux | grep border-router-mgmt-app

To kill the application, type:

> sudo kill <PID>

where <PID> is replaced with the actual PID number found above.

Restart the application in the foreground:

> sudo /opt/siliconlabs/threadborderrouter/bin/border-router-mgmt-app –m 4901

Turn AUTO_FORM_NETWORK off:

border-router-mgmt-app> set-auto-form-off

This time, when net reset is issued, the border router waits for user input in order to proceed out of the FORM_NETWORK state:

border-router-mgmt-app> net resetRemoving any IPv6 addresses configured on the host...Unbound from fe80::ba27:ebff:fe63:4ac4Unbound from 2001:db8:8569:b2b1::1Unbound from fe80::76da:38ff:fe66:135bborder-router-mgmt-app> Border Router is waiting on `network-management commission ...` command to form and join networkReset network state complete

As seen in the net reset response, the Border Router is waiting on a network-management commission command. The syntax for thiscommand is as follows:

network-management commission <preferred channel:1> <fallback channel mask:4> <network id:0--16> <ula prefix> <extended pan id:8> <key:16> [<pan id:2> [<key sequence:4>]]

For more information on these parameters, search for the emberJoinNetwork function in the Silicon Labs Thread API Reference Guide.The emberJoinNetwork function is the underlying API call for the network-management commission CLI command.

Here is an example of how to use this command as well as the border-router-mgmt-app output response:

border-router-mgmt-app> network-management commission 13 0 "example-id" "fd01::/64" {0102030405060708} {656D62657220454D3235302063686970} 1234 0border-router-mgmt-app> Pre-Commission stack call successful.Completing precommisioned joinemberJoinNetworkReturn pre-commissioned success.Bound to fd01::f815:7da5:a0e4:2c49Listening for CoAP on fd01::f815:7da5:a0e4:2c49Bound to fe80::1837:4661:128b:b86eListening for CoAP on fe80::1837:4661:128b:b86eRejoined network "example-id"OTA Bootload Server Policy: GetImageNotifyInfo a=400:0:ec65:8b7e:74c3:400:f465:8b7e m=0x364C t=0x0005 v=0x00000000Setting fixed commissioner key: "COMMPW1234"



Bound to 2001:db8:385:9318:5075:ebe1:7d18:db74Listening for CoAP on 2001:db8:385:9318:5075:ebe1:7d18:db74Configuring default gateway for: 2001:db8:385:9318::/64Initializing border routerMaking 'all thread nodes' address: ff33:40:fd01::1Listening on all mesh nodes multicastListening for CoAP on ff03::1Listening on all mesh routers multicastListening for CoAP on ff03::2Listening on all thread nodes multicastListening for CoAP on ff33:40:fd01::1Configured DNS64Border router is up



The state diagram for this operation is shown in the following figure.

In order to commission a device onto this network, either of two different methods can be used:1. To use an external commisioner, go to section 3.3 Commissioning Using the External Commissioning Application. Note that even

though the network parameters are specified manually, the origin of the parameters is unknown both to the Thread network and tothe external commissioner. Therefore, they behave the same in either case.

2. To provide network parameters to a Joiner device using the device CLI, go to section 3.4 Commissioning Using Out-of-Band Injec-tion of Network Data. This method can only be used if the Network Master Key is known.



3.3 Commissioning Using the External Commissioning Application

Commissioning via an external commissioner is the standard way of adding a device to a Thread network. The steps a user shouldfollow are outlined in QSG102: Thread Border Router Add-On Kit Quick Start Guide. Here we provide more detail about how the vari-ous Border Router applications participate in the process.

1. The border-router-mgmt-app forms a Thread network and establishes the commissioner key as described in section 3.1 Under-standing the Border Router Management Application.

2. The external commissioner uses the pre-shared commissioner key to perform a DTLS/JPAKE handshake with the commission-proxy-app and establish a secure connection to the Thread network.

3. The external commissioner uses a second pre-shared join key to perform a DTLS/JPAKE handshake with the Joiner and establisha secure connection to the Joiner via the Thread Network. If the commissioner is satisfied with the credentials of the Joiner, it al-lows the Network Master Key to be shared with the Joiner in a secure fashion from the Thread Network. The Network Master Keyis never known by the commissioner.

Figure 3.1. Commissioning

3.4 Commissioning Using Out-of-Band Injection of Network Data

If a network was formed using manual settings, then those settings can be injected into another device to allow it onto the Thread net-work directly without having to go through the in-band commissioning process. This section specifically refers to the sensor-actuator-node device that comes as part of the Border Router Add-On Kit.

This can be done by going to the CLI of the device in Simplicity Studio and running the following commands:

sensor-actuator-node> network-management resetsensor-actuator-node> network-management commission 13 0 "example-id" "fd01::/64"{0102030405060708} {656D62657220454D3235302063686970} 1234 0

Note that the parameters must be identical to the parameters of the commission command used in the border-router-mgmt-app CLIin order to put the border-router and the sensor-actuator on the same network.



3.5 Discovery

1. An application sends a discovery request via CoAP to the border-router-mgmt-app.2. The border-router-mgmt-app sends a discovery multicast request to the ncp-uart application.3. Each Thread end node responds to the multicast with its global IPv6 address and device type.

Figure 3.2. Discovery

3.6 End-to-End IPv6 Communication

1. The web server, or an application such as the Copper plugin for Mozilla, sends and receives messages via CoAP to and from theIPv6 address of the desired Thread end node. This assumes commissioning and discovery have completed.

Figure 3.3. End-to-End IPv6 Communication



4. Build and Installation Instructions

This section describes the build and installation procedure for the IP modem, IP driver, commissioning, border router, and web serverapplications. The following steps assume that you have installed Simplicity Studio, the Silicon Labs Thread stack, and the IAR-EWARMcompiler. Refer to QSG113: Getting Started with Silicon Labs Thread, for a detailed tutorial.

4.1 Build the Border Router IP Modem Application

The Silicon Labs Thread stack supports building NCP applications in Simplicity Studio AppBuilder, with customizations for target hard-ware, initialization, main loop processing, event definition and handling, and host/NCP command extensions. Refer to AN1010: Buildinga Customized NCP, for a detailed set of build instructions. Refer to CEL 0011-09-07-00-000 (Issue G) for a detailed set of programminginstructions for using an ISA3 debug adapter to install the application and bootloader. The bootloader for the CEL EM3588 USB ThreadAdapter is located at tool/bootloader-em3588/serial-uart-bootloader, relative to root of the Silicon Labs Thread stack installation.

4.2 Build the Border Router IP Driver Application

1. Copy the Thread stack (C:/SiliconLabs/SimplicityStudio/v4/developer/sdks/gecko_sdk_suite) to the Border Router (/home/pi), usingwinscp as described in section 8.5 Transfer Files To and From the Border Router.

2. It is not necessary to generate a project with AppBuilder because no configuration options are required.3. Change to the Thread directory:

$ cd /home/pi/gecko_sdk_suite/v1.0/protocol/thread_x.x/

4. Make the application from the root of the Thread stack directory:

$ make -f app/ip-ncp/ip-driver-app.mak

5. Copy the application to the executable directory from the root of the Thread stack directory:

$ sudo service border-router-apps stop$ sudo cp /home/pi/gecko_sdk_suite/v1.0/protocol/thread_2.2/build/ip-driver-app/ip-driver-app /opt/siliconlabs/threadborderrouter/bin

UG116: Developing Custom Border Router ApplicationsBuild and Installation Instructions


http://cortet.cel.com/docs/default-source/data-sheets/em357_usb_sticks_ds.pdf?sfvrsn=41

4.3 Build the Border Router Commissioner Proxy

1. Obtain the source code for the Rijndael cipher.2. The commission-proxy-app requires the AES-128 cipher. Silicon Labs cannot provide this software implementation of AES-128

because it is classified as strong cryptography and subject to export restrictions. An implementation of Rijndael known to be com-patible with the Thread commissioning application is:• http://www.efgh.com/software/rijndael.zip (md5: cd49617fa6593d2ab67a68f64ede2d78)

3. The cipher consists of the following files:• rijndael-alg-fst.c

• rijndael-alg-fst.h

• rijndael-api-fst.c

• rijndael-api-fst.h

4. The header files are included in the Silicon Labs Thread installation to assist you in locating the corresponding source files. OnceRijndael has been acquired, copy the source files to the following locations relative to the root of the Thread stack installation tocomplete the configuration:• hal/micro/generic/aes/rijndael-alg-fst.c

• hal/micro/generic/aes/rijndael-api-fst.c

5. Copy the Thread stack to the Border Router.6. It is not necessary to generate a project with AppBuilder because no configuration options are required.7. Make the application from the root of the Thread stack directory:

$ make -f app/thread-commissioning/commission-proxy-app.mak

8. Copy the application to the executable directory from the root of the Thread stack directory:

$ cp app/thread-commissioning/commission-proxy-app /opt/siliconlabs/threadborderrouter/bin

4.4 Build the Border Router Application

1. Create and generate the border-router example.2. Select generation directory “app/thread/sample-app/border-router/border-router” relative to the stack and select “Unix host” as the

target architecture. This generates the project in place within the Thread stack.3. Copy the Thread stack to the Border Router.4. Make the application from the root of the Thread stack: directory:

$ make -C app/thread/sample-app/border-router/border-router

5. Copy the application to the executable directory from the root of the Thread stack directory: :

$ cp app/thread/sample-app/border-router/border-router/build/exe/border-router /opt/siliconlabs/threadborderrouter/bin



http://www.efgh.com/software/rijndael.zip

4.5 Build the Web Server Application

The website React user interface source code is located at /opt/siliconlabs/threadborderrouter/src/reactui and the node.js server sourceis located at /opt/siliconlabs/threadborderrouter/webserver. Follow the instruction below to build these components.

1. Install dependencies:

$ cd /opt/siliconlabs/threadborderrouter/src/reactui$ sudo npm install -g gulp$ sudo npm install

2. Generate the React user interface, copy to the server directory, and restart the Apache server:

$ sudo gulp build-dev$ sudo service apache2 stop$ sudo rm –r /var/www/html/*$ sudo cp -r /opt/siliconlabs/threadborderrouter/src/reactui/dist/* /var/www/html$ sudo service apache2 start

3. Restart the node.js server:

$ sudo service border-router-apps {start | stop | restart}



5. Using the EFR32 Mighty Gecko Wireless Starter Kit as the NCP

Although the Border Router Add-On Kit ships with a CEL USB dongle intended to run the NCP application, it is possible to use a WSTKfor this purpose, by following three steps: flashing the NCP firmware, setting up the hardware, and modifying the border router.

5.1 Flashing the NCP Firmware

The NCP firmware can be flashed onto an EFR32MG12 device using the same steps as flashing the sensor actuator node firmware.The binaries are located in the following location of the border router file system.Device Programming File

EFR32MG12 /opt/siliconlabs/threadborderrouter/firmware/ncp-uart/efr32mg12p432f1024gl125/ncp-uart-efr32mg12p432f1024gl125.s37

A bootloader is required, and is also available in the border router file system.Device Bootloader

EFR32MG12 /opt/siliconlabs/threadborderrouter/firmware/sensor-actuator-node/efr32mg12p432f1024gl125/serial-uart-boot-loader.s37

IMPORTANT: Erase the device before programming.

5.2 Setting up the Hardware

To set up the hardware, connect a USB cable between the border router host Raspberry Pi and the WSTK. The WSTK provides theUART-to-USB translation between the EFR32MG12 radio chip and the host. The WSTK requires that the EFR32MG12 chip be config-ured for hardware flow control, which is already the case for the precompiled binaries available above. This hardware setup disablesdebugging capabilities of the WSTK over USB, since that would require connecting to a development computer running Simplicity Stu-dio rather than to the border-router host. However, full debugging capabilities are still available through the Ethernet port.

5.3 Modifying the border-router

Using a text editor, open the following file: /opt/siliconlabs/threadborderrouter/bin/silabsenv

Locate the NCP_DEVICE flag. Comment it out and make a new line that says NCP_DEVICE="/dev/ttyACM0"

You should end with the following lines in the silabs-scripts file:

#the ncp device is the /dev endpoint of the ncp#NCP_DEVICE="/dev/ttyUSB0"NCP_DEVICE="/dev/ttyACM0"

Reboot the border-router.

UG116: Developing Custom Border Router ApplicationsUsing the EFR32 Mighty Gecko Wireless Starter Kit as the NCP


6. Silicon Labs Thread Border Router Configuration

The silabs-border-router package is a collection of files describing Silicon Labs host application binaries, support scripts that enablehost applications and Linux utilities to interact, and modifications to common Linux utilities. Its installation configures the Raspbian Jes-sie Lite operating system to behave as a Border Router between the Thread mesh and IPv6 networks. This section provides a refer-ence to the modifications the silabs-border-router package makes to the Raspbian Jessie Lite operating system. The steps for installingthe silabs-border-router package are described in QSG102, Thread Border Router Add-On Kit Quick Start Guide.

6.1 The Border Router Configuration File

System variables that either modify multiple daemons on the Border Router or apply directly to configuration of the Silabs Host Applica-tions are installed into the Border Router Configuration file (/etc/siliconlabs/border-router.conf). This file includes network settings, hostapplication settings, and the ability to enable and disable advanced router features such as DNS64 or NAT64. The file is formatted as alist of key-value pairs and includes comments detailing the behavior of each key-value pair. The following table describes the defaultkey-value pairs that the border-router.conf file provides.

Table 6.1. Default Border Router Configuration Settings

Key Value Description

FILE_VERSION 1 The current version of the Border Router Configuration File.

AUTO_FORM_NETWORK 1 A Boolean describing if the Border Router should automatically form aThread network on startup using default settings, or if it should wait for theuser to enter manual settings.

NETWORK_ID br-XXXX A string providing a pseudorandom Thread network ID.

MESH_SUBNET 2001:db8:385:9318::/64 An IPv6 prefix and subnet width assigned to the Thread network (tun0).

HOST_SUBNET 2001:db8:8569:b2b1::/64 An IPv6 prefix and subnet width assigned to the Wi-Fi network (wlan0).

USE_PREFIX_DELEGATION 0 A Boolean describing if the Border Router should enable IPv6 Prefix Dele-gation on the Ethernet interface (eth0). Prefix delegation causes the MESHand HOST obtain dynamic prefixes from any prefix delegation server run-ning on eth0.

NAT64_PREFIX fc01:6464::/96 An IPv6 prefix whose subnet width must be exactly /96 used by the NAT64service to map IPv4-only destinations to an IPv6 address.

6.2 Silicon Labs Host Applications

The Silicon Labs Host Applications use the underlying Silicon Labs Thread Stack to form and operate the Thread network. Three hostapplications are part of the border-router package: ip-driver-app, commission-proxy-app, and border-router-mgmt-app. The ip-driver-app configures the 802.15.4 interface (tun0) and performs translation between the external IPv6 and internal 6LoWPAN networks, aswell as providing the host-side of a binary command pipe to the NCP. The commission-proxy-app advertises both the availability of theThread Commissioner service via mDNS to external commissioner candidates and also proxies communication between a connectedcommissioner and the thread network. The border-router-mgmt-app reads the Linux configuration and uses the Thread stack API tosend commands through the ip-driver-app to form and operate the Thread Network. The Silicon Labs Host Applications are installed inthe ‘bin’ folder within the SILABS_BORDER_ROUTER_ROOT directory: /opt/siliconlabs/threadborderrouter/bin.

6.3 Linux Configuration File Modifications

The silabs-border-router package has dependencies on a number of common Linux utilities. The utilities in the silabs-border-routerpackage have been adapted to provide the functionality of a standard router through modifications to their configuration files. The si-labs-border-router package modifies standard Linux configuration in one of four different ways: installation of new configuration files,automated injection of minor additional code into existing static configuration files, install-time complete replacement of existing staticconfiguration files, and by using a template to dynamically rewriting existing configurations as the network state changes. In all fileswhere configuration settings are required by the silabs-border-router package, comment sections between #SILABS_BORDER_ROUTERmarkers provide detailed information about each modification’s function and purpose, and provide hints for safely customizing the op-tion in question.

UG116: Developing Custom Border Router ApplicationsSilicon Labs Thread Border Router Configuration


6.4 New Configuration Files

In instances where a Linux utility does not provide its own default configuration, the silabs-border-router package installs a new configu-ration file to the appropriate directory within the Linux file system. All entries in these files should be considered ‘critical’ to the BorderRouter Add On Kit’s default functionality, and modifying them may result in the failure of an intended feature or service. The followingtable describes the ‘Installed Configuration Files’ silabs-border-router provides.

Table 6.2. New Configuration Files

Path Description

/etc/default/isc-dhcp-server Contains settings used by the initialization script for the DHCP service.

/etc/init.d/border-router-apps The initialization script that daemonizes the Silabs host applications on-startup.

/etc/logrotate.d/siliconlabs Adds the Silicon Labs logfiles to the logrotate daemon’s scheduler.

/etc/modules-load.d/silabs.conf Instructs the Linux Kernel to load drivers required by the Border Router Add On Kit.

/etc/siliconlabs/border-router.conf Defines common variables used to coordinate between the host applications andoperating system.

/etc/sysctl.d/30-silabs.conf System control settings with priority (30) that are executed to enable IP routing.

/etc/udev/rules.d/99-silabs.rules Startup rules at lowest priority (99) for the NCP.

/etc/iptables.ipv4.nat Adds NAT44 rules to enable Ipv4 routing.

/etc/dhcpcd.exit-hook A script run when Prefix Delegation occurs. This script reconfigures tun0 and wlan0to use a delegated prefix for their subnet.

6.5 Minor Configuration Files

In instances where only minor changes to a configuration file are required in order to enable a feature of the Border Router, the silabs-border-router package injects additional configuration settings between the text tags #SILABS_AUTOGEN_START and #SILABS_AUTOGEN_END. These tags denote that text between them is volatile and will be removed or overwritten if the silabs-border-router package is re-moved or upgraded, and that certain dynamic processes may also overwrite these sections during normal Border Router operation. Theconfiguration outside of these markers can usually be easily modified without disabling the Border Router’s intended functionality. Addi-tional configuration settings are recorded in files prepended with the keyword ‘additional’ followed by the filename they modify. For ex-ample: additional-dhcpd.conf contains additional settings that will be injected into the dhcpd.conf file, between #SILABS_AUTOGEN mark-ers. These additional configuration settings appear in files installed into the SILABS_BORDER_ROUTER_ROOT directory, which is lo-cated at /etc/siliconlabs/threadborderrouter. The following table describes the ‘Minor Configuration Files’ to which the silabs-border-rout-er package adds additional lines

Table 6.3. Minor Configuration Files

Destination File Source file Description

/etc/bash.bashrc additional-bash.bashrc Adds the Silicon Labs binary directory to PATH.

/etc/resolvconf.conf additional-resolvconf.conf Installs the optional DNS and DNS64 services to the host-resolve path.

/etc/dhcpcd.conf additional-dhcpcd.conf Disables the dhcpv4 client on wireless interfaces, enables Prefix Delega-tion on eth0.

/etc/dhcp/dhcpd.conf additional-dhcpd.conf Configures the DHCP server daemon, which assigns addresses on wlan0.

In instances where most of a configuration file must be modified in order to enable a feature of the Border Router, the silabs-border-router package backs up and replaces the previously installed configuration file. The silabs-border-router package first appends the ex-tension ‘.old’ to any existing configuration files to be overwritten. Next, a corresponding file with the extension ‘.new’ is copied from theSILABS_BORDER_ROUTER_ROOT directory to its destination, with the ‘.new’ extension removed. This behavior is equivalent to thefollowing commands:

mv /etc/network/interfaces /etc/network/interfaces.oldcp /opt/siliconlabs/threadborderroter/interfaces.new /etc/network/interfaces



All instances where major configuration modifications are required are considered ‘Critical’ for the default operation of the Border Rout-er. Customizing these files is not recommended. Because they have nontrivial interactions with other core systems, a modification toone critical file usually requires modifications to many other subsystems within the operating system. The following table describes themajor configuration files overwritten by the silabs-border-router package.

Table 6.4. Major Configuration Files

Destination File Source file Description

/etc/hosts hosts.new Sets the local resolve table used by the local DNS and mDNS services

/etc/hostname hostname.new Sets the hostname the Border Router will use for DNS and mDNSservices

/etc/network/interfaces interfaces.new Configures the Border Router’s network interfaces to read border-rout-er.conf

/etc/init.d/isc-dhcp-server isc-dhcp-server.new Forces the DHCP server to start in IPv4 and IPv6 mode (default isIPv4-only)

/etc/init.d/tayga tayga.new When enabled, causes the NAT64 transition technology service to run,allowing Thread devices to target IPv4-only servers

/etc/default/tayga default-tayga.new Overwrites defaults to ensure proper operation of NAT64

6.6 Templatized Configuration Files

In instances where a configuration must be continuously modified in during the Border Router’s operation, the silabs-border-routerpackage uses a template to configure hook scripts that then dynamically overwrite the configuration file. These hook scripts executewhen certain network-related events occur, such as obtaining an IPv6 address via Prefix Delegation – and the resultant configurationfile is likely to be overwritten. If your application requires a modification to any of these configuration files, you must either modify thehook scripts or the template to ensure your changes persist in configuration. For ease of reference, template files are installed into thesame directory as the configuration files they modify and are postfixed with a ‘.template’ extension. When the triggering event that re-quires a configuration rewrite occurs, these templates are combined with values from border-router.conf before the hook script replacesthe previous configuration. The following table describes ‘Templatized Configuration Files’ that are configured by the silabs-border-rout-er package to dynamically overwrite a configuration file during normal operation.

Table 6.5. Templatized Configuration Files

Path Configuration File Type Trigger Rewrite Result

/etc/bind/named.conf.options.template DNS64 MESH_PREFIX orHOST_PREFIX changescaused by Prefix Delega-tion

Enables wlan0 and tun0 to useDNS64

/etc/dhcp/dhcpd6.conf.template DHCPv6 server HOST_PREFIX changescaused by Prefix Delega-tion

Assigns the new prefix to the wlan0interface

/etc/ndppd.conf.template Neighbor Discovery Proto-col Proxy Daemon

MESH_PREFIX changescaused by Prefix Delega-tion

Proxies NDP for tun0

/etc/radvd.conf.template Router Advertisement Dae-mon configuration file

HOST_PREFIX changescaused by Prefix Delega-tion

Advertises the new prefix on wlan0

/etc/tayga.conf.template NAT64 MESH_PREFIX orHOST_PREFIX changescaused by Prefix Delega-tion

Adds the new prefixes to the ‘allow’list for NAT64



6.7 Default Network Interface Configuration

The Border Router Add-On Kit uses three default network interfaces:• Ethernet (eth0: Represents an ‘internet-facing’ interface• Wi-Fi (wlan0): Provides a wireless host access point• An 802.15.4 interface (tun0): Provides access to the Thread mesh network

The network interfaces can be configured through modifying the /etc/siliconlabs/border-router.conf file. Subnet assignments for the si-labs-border-router package are:Interface Type IPv6 Subnet Type IPv4 Subnet

Wi-Fi (wlan0) SLAAC HOST_SUBNET::/64 DHCP 192.168.42.1/24

Ethernet (eth0) DHCP client Dynamically assigned DHCP client Dynamically assigned

802.15.4 (Thread) SLAAC MESH_SUBNET::/64 Not applicable

On installation, the silabs-border-router package configures the wlan0 and Thread subnets to a static documentation-only address.However, if ENABLE_PREFIX_DELEGATION is set in border-router.conf, these addresses are overwritten whenever a real IPv6 ad-dress is obtained from a Prefix Delegating external router connected to the Ethernet interface.

IMPORTANT: The default 2001:0db8::/32 IPv6 subnets used for “documentation only” and should not be used on the IPv6 internet.

Figure 6.1. Thread Border Router Configuration

6.8 IPv6 Packet Forwarding and Router Advertisements

The Border Router must forward IPv6 packets between interfaces so that IPv6 devices on different interfaces such as wlan0 and eth0may communicate with each other. The Border Router must also reject router advertisements for interfaces on which it is a router, suchas wlan0, and accept router advertisements for interfaces on which it is not a router, such as eth0. Refer to Table 6.1 Default BorderRouter Configuration Settings on page 19 through Table 6.5 Templatized Configuration Files on page 21 to identify the componentsresponsible for packet forwarding and router advertisements, and consult their corresponding configuration files for commentary on howthe silabs-border-router enables this feature.

6.9 The Neighbor Discovery Protocol Proxy Daemon (ndppd)

Neighbor Discovery Protocol is specified in RFC 4861 and is a foundational component of IPv6 reachability, routing, and SLAAC. Inorder to discover neighbors on an IPv6 network, a router issues ‘Neighbor Solicitations’ designed to discover if a node exists at a targetIPv6 address. Neighbor Solicitations used in this fashion are similar to the use of ‘ARP’ in IPv4: a node is expected to reply to anyNeighbor Solicitations for its address with a ‘Neighbor Advertisement.’ Because Thread 6LowPAN only implements a subset of IPv6 inorder to save power, mesh devices do not provide Neighbor Discovery Protocol. Instead, the Border Router acts as a proxy for allNeighbor Advertisements directed to its mesh devices. The comments in the ndppd daemon’s configuration files explain in-detail howthe silabs-border-router package enables this feature.



https://tools.ietf.org/html/rfc4861

6.10 Avahi

Avahi is an implementation of the Apple mDNS bonjour protocol, which allows devices to register and advertise a human-readablename with other devices on the local network. The Border Router publishes the border router name with the avahi daemon via IPv4 sothat the iOS or Android commissioning is aware of the Border Router. The configuration file is /etc/avahi/avahi-daemon.conf and doesnot require modification. The avahi daemon is managed by the border-router-app service, which is detailed in section 6.2 Silicon LabsHost Applications.

6.11 NAT64

Network Address Translation IPv6 to IPv4 (NAT64) is a transition technology that enables IPv6-only mesh devices to communicate withIPv4-only destinations by translating packet headers from IPv6 to IPv4 and maintaining a translation table for return communication. Inorder to provide an IPv6-only list of destinations to the IPv6 side of the NAT, a NAT64 daemon utilizes a /96 subnet, using the 32-bitsuffix to map the entire IPv4 address space. When a packet arrives on the 96-bit NAT64_SUBNET, the NAT64 daemon removes theIPv4 destination address from the low-32 bits and inserts it into the ‘destination’ field of an IPv4 packet before substituting a ULA4 ad-dress as the source. Finally, before egressing at the ‘internet-facing’ interface, the Border Router performs NAT44 to substitute the pri-vate, internal ULA4 source address assigned by the NAT64 daemon for its external address and a return port. The packet, now transla-ted to IPv4, can traverse an IPv4-only network to its destination, which can respond using the Border Router’s source address and port.Because table entries do not appear in NAT64 until an IPv6 device initiates communication, internal Thread devices will not be availa-ble to the external network until after they initiate communication. If your application requires Thread devices to be reachable throughthe NAT at a static destination, NAT44 port mapping must be configured to map an external port to an internal Thread device. Seethe /etc/tayga.conf and Tayga manpage for more information.

6.12 DNS64

The Dynamic Name System for Ipv6 to Ipv4 (DNS64) is a transition technology that provides name resolution services for the IPv4internet to IPv6-only clients. DNS clients contacting the DNS64 server will obtain a special IPv6 destination address on a /96 prefix thathas an IPv4 address appended in the lower 32-bits to which they will send their traffic. By paring DNS64 with NAT64, an IPv6-onlydevice can lookup destination addresses that reside within the NAT64 translation prefix, allowing communication with IPv4 only destina-tions. The Border Router Add-On Kit uses BIND9/named as its DNS64 server, see /etc/bind/named.conf.options or the manpage forbind for more information.



7. Test Router Configuration

Because IPv6 is not fully deployed, a Border Router can be converted into a Test Router, which allows operation of an IPv6 networkindependent of the Internet. The border-router can then be tested and evaluated on an IPv6-only network, even if such a network is notavailable from the user’s ISP. This section provides a procedure to install the silabs-test-router package. The subnet assignmentsfor the test router are:Interface IPv6 Type IPv6 Subnet IPv4 Type IPv4 Subnet

Wi-Fi (wlan0) SLAAC 2001:0db8:8569:b2b4::/64 DHCP 192.168.141.1/24

Ethernet (eth0) SLAAC 2001:0db8:8569:b2b3::/64 DHCP 192.168.222.1/24

IMPORTANT: The 2001:0db8::/32 IPv6 subnets are classified as “documentation only” and should not be used on the IPv6 internet.

IMPORTANT: The test router Ethernet (eth0) should not be connected to a network that is not expecting IPv6 or IPv4 address assign-ment, such as a corporate network. To safely connect to a corporate network, stop the dnsmasq service with the command:

$ sudo service dnsmasq {start | stop | restart}

Figure 7.1. Test Router Configuration

UG116: Developing Custom Border Router ApplicationsTest Router Configuration


7.1 Install the Test Router Operating System and Packages

1. Power down the Thread Border Router and remove the SD card.2. Install the Raspbian Jessie Lite operating system on the SD card as described here: https://www.raspberrypi.org/downloads/raspbi-

an/. All Border Routers shipped after August 1, 2016 include an SD card with the Raspbian Jessie Lite operating system pre-instal-led.

3. Install the SD card in the Thread Border Router and power it on.4. Connect the Raspberry Pi’s Ethernet port to the Internet with an Ethernet cable.5. Login with the default username “pi” and password “raspberry.”6. Append the following text to the end of /etc/apt/sources.list:

deb http://devtools.silabs.com/solutions/apt/ jessie main

7. Configure the keys.

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys DE864524

8. Install the silabs-border-router package. Note that you will be asked to accept the Thread Border Router license agreement.

$ sudo apt-get update$ sudo apt-get install silabs-test-router$ sudo reboot

UG116: Developing Custom Border Router ApplicationsTest Router Configuration


https://www.raspberrypi.org/downloads/raspbian/

https://www.raspberrypi.org/downloads/raspbian/

http://devtools.silabs.com/

http://keyserver.ubuntu.com/

8. Utilities, Files and Services

The following utilities, files and services may be useful for Border Router configuration and development.

8.1 Write/Read a Disk Image to/from the microSD Card

It is possible to write a disk image to the microSD card or read a disk image from the microSD card using a Windows, Mac or Linuxcomputer. The reason to do this would be to copy the operating system disk image to the microSD card for first time installation, or toread the file system from microSD card to archive or duplicate the disk image. From a PC, use Win32DiskImager and from Linux/Macuse the dd command.

8.2 Expand the microSD Card File System

The file system may be expanded to the full capacity of the microSD card. The reason to do this would be to enable the full microSDcard to be used by the Border Router. From the Border Router use the sudo raspi-config command.

8.3 Change the Keyboard Settings

The Raspberry Pi uses an English (UK) keyboard mapping by default. Users may need to change this setting in order to access specialcharacters. From the Border Router use the sudo raspi-config command.

8.4 Remote Login to the Border Router

It is possible to login remotely to the Border Router once connected to the Border Router Wi-Fi access point or Ethernet. The reason todo this would be to avoid needing a separate monitor and keyboard. From a PC, open an SSH session using PuTTY at 192.168.42.1,port 22. From a Linux/Mac, use the ssh and ssh-copy-id commands to open a session to [email protected]. Login with the defaultusername “pi” and password “raspberry.”

8.5 Transfer Files To and From the Border Router

It is possible to transfer files between a Windows, Mac or Linux computer and the Border Router once connected to the Border RouterWi-Fi access point or Ethernet. The reason to do this would be to copy the Thread stack to the Border Router for the purpose of build-ing applications as described in section 4. Build and Installation Instructions. From a PC, open a session using WinSCP at192.168.42.1, port 22. From a Linux/Mac, use the scp command to open a session to [email protected]. Login with the default user-name “pi” and password “raspberry.” Use $ ip addr to find the IP address of the border router. Use the wlan0 address if the computeris connected to the wi-fi access point. Use eth0 if computer is not connected to access point. Files can only be copied to home/pi/.

8.6 Controlling the commission-proxy-app, ip-driver-app and border-router Applications

The silabs-scripts shell script exposes a useful capability of running applications in the foreground or background. The applicationsare normally run in the background, however, running the border-router application may be useful for command line control. Stop andthen start the border-router in the foreground with these commands:

$ /opt/siliconlabs/threadborderrouter/bin/silabs-scripts -b stop$ /opt/siliconlabs/threadborderrouter/bin/silabs-scripts -b fg

8.7 Files

File Purpose

/var/www/html/assets/version.json Specifies major, minor and sub revision of the silabs-border-routerpackage.

/opt/siliconlabs/threadborderrouter/ip-driver-app IP driver application

/opt/siliconlabs/threadborderrouter/commission-proxy-app Thread commissioning proxy

/opt/siliconlabs/threadborderrouter/border-router Border router application

/var/log/siliconlabs/ip-driver-app IP driver application log file (not size managed)

/var/log/siliconlabs/commission-proxy-app Thread commissioning application log file (not size managed)

/var/log/siliconlabs/border-router Border router application log file (not size managed)

UG116: Developing Custom Border Router ApplicationsUtilities, Files and Services


http://sourceforge.net/projects/win32diskimager/

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

mailto:[email protected]

http://winscp.net/eng/download.php

mailto:[email protected]

File Purpose

/etc/ndppd.conf ndppd configuration file

/etc/dnsmasq.d/silabsap.conf Dnsmasq configuration file

/etc/sysctl.d/30-silabs.conf Sysctl configuration file

/etc/hostapd/hostapd.conf Host APD configuration file

/etc/siliconlabs/border-router.conf Border router configuration file

8.8 Services

The following services may be useful for Border Router configuration and development.

File Purpose

border-router-apps The ip-driver-app, commission-proxy-app, and border-router applications are managed by this service.

dnsmasq Dnsmsaq service.

networking Networking service.

hostapd Host Wi-Fi access point service.

UG116: Developing Custom Border Router ApplicationsUtilities, Files and Services


9. Resources

9.1 Getting started with Thread

http://www.silabs.com/products/wireless/Pages/thread-getting-started.aspx

9.2 Thread Training Center

http://www.silabs.com/products/wireless/Pages/thread-networking-learning-center.aspx

9.3 Documentation

• QSG101: EM35x Development Kit Quick-Start Guide (included in development kit)• QSG102: Thread Border Router Add-On Kit Quick Start Guide• QSG113: Getting Started with Silicon Labs Thread• UG103.11: Application Development Fundamentals: Thread• AN1010: Building a Customized NCP Application• CEL 0011-09-07-00-000 (Issue G)

9.4 Community & Support

http://community.silabs.com/

http://www.silabs.com/support

UG116: Developing Custom Border Router ApplicationsResources


http://www.silabs.com/products/wireless/Pages/thread-getting-started.aspx

http://www.silabs.com/products/wireless/Pages/thread-networking-learning-center.aspx

http://cortet.cel.com/docs/default-source/data-sheets/em357_usb_sticks_ds.pdf?sfvrsn=41

http://community.silabs.com/

http://www.silabs.com/support

http://www.silabs.com

Silicon Laboratories Inc.400 West Cesar ChavezAustin, TX 78701USA

Smart. Connected. Energy-Friendly.

Productswww.silabs.com/products

Qualitywww.silabs.com/quality

Support and Communitycommunity.silabs.com

DisclaimerSilicon Labs intends to provide customers with the latest, accurate, and in-depth documentation of all peripherals and modules available for system and software implementers using or intending to use the Silicon Labs products. Characterization data, available modules and peripherals, memory sizes and memory addresses refer to each specific device, and "Typical" parameters provided can and do vary in different applications. Application examples described herein are for illustrative purposes only. Silicon Labs reserves the right to make changes without further notice and limitation to product information, specifications, and descriptions herein, and does not give warranties as to the accuracy or completeness of the included information. Silicon Labs shall have no liability for the consequences of use of the information supplied herein. This document does not imply or express copyright licenses granted hereunder to design or fabricate any integrated circuits. The products are not designed or authorized to be used within any Life Support System without the specific written consent of Silicon Labs. A "Life Support System" is any product or system intended to support or sustain life and/or health, which, if it fails, can be reasonably expected to result in significant personal injury or death. Silicon Labs products are not designed or authorized for military applications. Silicon Labs products shall under no circumstances be used in weapons of mass destruction including (but not limited to) nuclear, biological or chemical weapons, or missiles capable of delivering such weapons.

Trademark InformationSilicon Laboratories Inc.® , Silicon Laboratories®, Silicon Labs®, SiLabs® and the Silicon Labs logo®, Bluegiga®, Bluegiga Logo®, Clockbuilder®, CMEMS®, DSPLL®, EFM®, EFM32®, EFR, Ember®, Energy Micro, Energy Micro logo and combinations thereof, "the world’s most energy friendly microcontrollers", Ember®, EZLink®, EZRadio®, EZRadioPRO®, Gecko®, ISOmodem®, Micrium, Precision32®, ProSLIC®, Simplicity Studio®, SiPHY®, Telegesis, the Telegesis Logo®, USBXpress®, Zentri and others are trademarks or registered trademarks of Silicon Labs. ARM, CORTEX, Cortex-M3 and THUMB are trademarks or registered trademarks of ARM Holdings. Keil is a registered trademark of ARM Limited. All other products or brand names mentioned herein are trademarks of their respective holders.

developing custom border router applications -- ug116

Documents