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. |
||
|---|---|---|
| .github | ||
| TESTS | ||
| UNITTESTS | ||
| cmsis | ||
| connectivity | ||
| docker_images/mbed-os-env | ||
| docs | ||
| drivers | ||
| events | ||
| extern | ||
| features | ||
| hal | ||
| platform | ||
| rtos | ||
| storage | ||
| targets | ||
| tools | ||
| .astylerc | ||
| .codecheckignore | ||
| .coveragerc | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .lgtm.yml | ||
| .mergify.yml | ||
| .pylintrc | ||
| CMakeLists.txt | ||
| CONTRIBUTING.md | ||
| DOXYGEN_FRONTPAGE.md | ||
| Jenkinsfile | ||
| LICENSE-apache-2.0.txt | ||
| LICENSE.md | ||
| README.md | ||
| doxyfile_options | ||
| doxygen_options.json | ||
| logo.png | ||
| mbed.h | ||
| requirements.txt | ||
README.md
Arm Mbed OS is an open source embedded operating system designed specifically for the "things" in the Internet of Things. It includes all the features you need to develop a connected product based on an Arm Cortex-M microcontroller, including security, connectivity, an RTOS and drivers for sensors and I/O devices.
Mbed OS provides a platform that includes:
- Security foundations.
- Cloud management services.
- Drivers for sensors, I/O devices and connectivity.
Release notes
The release notes detail the current release. You can also find information about previous versions.
License and contributions
The software is provided under the Apache-2.0 license. Contributions to this project are accepted under the same license. Please see contributing.md for more information.
This project contains code from other projects. The original license text is included in those source files. They must comply with our license guide.
Folders containing files under different permissive license than Apache 2.0 are listed in the LICENSE file.
Getting started for developers
We have a developer website for asking questions, engaging with others, finding information on boards and components, using an online IDE and compiler, reading the documentation and learning about what's new and what's coming next in Mbed OS.
Getting started for contributors
We also have a contributing and publishing guide that covers licensing, contributor agreements and style guidelines.
Documentation
For more information about Mbed OS, please see our published documentation. It includes Doxygen for our APIs, step-by-step tutorials, porting information and background reference materials about our architecture and tools.
To contribute to this documentation, please see the mbed-os-5-docs repository.