Skip to content
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

Closed
kFYatek opened this issue Oct 26, 2016 · 3 comments
Closed

What happens when IP address changes during Bootstrap? #164

kFYatek opened this issue Oct 26, 2016 · 3 comments
Assignees

Comments

@kFYatek
Copy link

kFYatek commented Oct 26, 2016

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?

@dnav
Copy link
Member

dnav commented Oct 31, 2016

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.
In a Client Initiated Bootstrap, the Client should send again the boostrap request as it is the only way for the Bootstrap Server to know the Client's new address.

Regards

@hannestschofenig
Copy link

I agree with David. The question is whether we need to clarify this issue in the specification.

kFYatek pushed a commit to AVSystem/Anjay that referenced this issue May 26, 2017
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
kFYatek pushed a commit to AVSystem/Anjay that referenced this issue May 26, 2017
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
@hannestschofenig
Copy link

hannestschofenig commented Nov 1, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants