-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What happens when IP address changes during Bootstrap? #164
Comments
In a Server Initiated Bootstrap, the Bootstrap Server is informed of the Client availability by out-of-band ways, typically the network infrastructure. In this case, the Bootstrap Server can cope with the Client network issues. Regards |
I agree with David. The question is whether we need to clarify this issue in the specification. |
Features: * Added initial output-only support for JSON Content-Format * Added support for SMS-related Resources in security module * Refactored code to facilitate support for SMS Binding * Actual SMS Binding support now implemented in the commercial version Improvements: * BREAKING API CHANGE: Replaced rid_bound and resource_supported handler with statically declared list of supported resources * Improved handling of DTLS backends in build system * 5.03 Service Unavailable is now sent instead of Reset when an unexpected request arrives while waiting for a response to Register or Update * Improvements in demo client: * Fixed Firmware Update object state machine * Added default Access Control entries Bugfixes: * Fixed sending errnoeus 2.31 Continue if the last block payload chunk trigerred an error * Relaxed invariants for Client-Initiated Bootstrap as per OpenMobileAlliance/OMA_LwM2M_for_Developers#164 * Prevented sending Object Instance list in Update messages if only changes are in the Security object * Fixed various bugs in access_control module Other: * Fixed in-code version numbers
Features: * Added initial output-only support for JSON Content-Format * Added support for SMS-related Resources in security module * Refactored code to facilitate support for SMS Binding * Actual SMS Binding support now implemented in the commercial version Improvements: * BREAKING API CHANGE: Replaced rid_bound and resource_supported handler with statically declared list of supported resources * Improved handling of DTLS backends in build system * 5.03 Service Unavailable is now sent instead of Reset when an unexpected request arrives while waiting for a response to Register or Update * Improvements in demo client: * Fixed Firmware Update object state machine * Added default Access Control entries Bugfixes: * Fixed sending errnoeus 2.31 Continue if the last block payload chunk trigerred an error * Relaxed invariants for Client-Initiated Bootstrap as per OpenMobileAlliance/OMA_LwM2M_for_Developers#164 * Prevented sending Object Instance list in Update messages if only changes are in the Security object * Fixed various bugs in access_control module Other: * Fixed in-code version numbers
If the bootstrap operation fails then the client may re-initiate the bootstrap procedure. However, it is an implementation dependent policy what the client does, when he initiates the next bootstrap interaction and how long it keeps trying. If you believe that this gives implementations too much freedom please propose an alternative approach. |
When an LWM2M Client is in the process of exchanging Bootstrap Interface messages with the Bootstrap Server, and the underlying network connection is lost - what is the expected behaviour?
The Client device will probably get a new IP address from a DHCP server or a similar source, and so the endpoint onto which the Bootstrap Server was sending Bootstrap Interface RPCs will no longer be valid.
Should the Client send the REQUEST BOOTSTRAP message again? Should it do so only if the connection was lost during a Client-Initiated Bootstrap, or would it make sense to do so to inform the server of the new endpoint even if the process was Server-Initiated before the connection loss?
The text was updated successfully, but these errors were encountered: