0d2badf42c
RFC3315 specifies the following: "The relay agent MAY send the Interface-id option to identify the interface on which the client message was received. If a relay agent receives a Relay-reply message with an Interface-id option, the relay agent relays the message to the client through the interface identified by the option." The current implementation of the DHCP relay reply handling, the interface ID field from the server response is ignored. Managing the interface ID is very important especially as DHCP requests/replies use link-local addresses. The consequence of this is that the interface must always be specified because the routing layer cannot guess the correct interface. Moreover, Mbed provides a mechanism to enable/disable the interface ID option on a DHCP relay instance, so it is important to fully support it. The reason why this issue has not been discoverd until now is that the DHCP relay is mainly used on systems that use only one interface (such as Wi-SUN routers). By default, when no interface ID is specified for the socket, the latter will choose 6loWPAN interface by default. This means that if two interfaces are used on the same device, the 6loWPAN interface is always selected. The commit adds code to retrieve the interface-id value contained within the DHCP relay reply message and write it to a control message header that is added to the socket message. This tells the socket which interface to choose. If the interface-id option is not enabled on the relay, this procedure is simply ignored. |
||
|---|---|---|
| .. | ||
| doxygen | ||
| nanostack | ||
| source | ||
| .gitattributes | ||
| .gitignore | ||
| .mbedignore | ||
| CMakeLists.txt | ||
| DOXYGEN_FRONTPAGE.md | ||
| Doxyfile | ||
| LICENSE-Apache-2.0 | ||
| LICENSE-BSD-3-Clause | ||
| Makefile | ||
| NOTICE | ||
| README.md | ||
| include_dirs.mk | ||
| mbed_lib.json | ||
| sources.mk | ||
README.md
ARM Mesh networking stack
This repository contains the ARM mesh networking stack that provides support for the following mesh protocols:
- 6LoWPAN with Neighbor Discovery (ND) and Mesh Link Establishment (MLE)
- Wi-SUN
All networking stacks are using IEEE 802.15.4 based radios.
The full documentation is hosted in Mbed OS documentation.
On mbed OS, mesh networking stacks can be used through Mbed Mesh API and Network Socket API.
To see, how the mesh networking stack works, check the example application mbed-os-example-mesh-minimal.
6LoWPAN with ND and MLE
This networking stack is using standard 6LoWPAN and uses:
- Neighbor Discovery Protocol (RFC4861) to locate other devices in the mesh network.
- Mesh-Link-Establishment (draft-kelsey-intarea-mesh-link-establishment-06) is used for establishing and configuring secure radio links.
Wi-SUN
Wi-SUN (Smart Utility Networks) specification is standardized by Wi-SUN Alliance.
License
The software is partially provided under a Apache 2.0 license and partially BSD-3-Clause as described below.
This project also contains code from other projects as listed below. The original license text is included in those source files.
- Public header files are provided under Apache 2.0 license.
- Source code excluding Thread protocol, is provided under Apache 2.0
- Source code implementing Thread protocol is provided under BSD-3-Clause
- mDNS library is from FNET project and provided under Apache 2.0 license.