5.5. Network error handling

Like any software that needs to communicate with other hosts over the network, Anjay needs to be prepared to handle communication errors. This page documents the library’s behavior during various error conditions.

5.5.1. Outgoing request error handling table

The following table describes the behavior of Anjay when various error conditions happen while performing each of the client-initiated operations.

	Request Bootstrap	Register	Update	De-register	Notify (confirmable)
Timeout (DTLS) [1]	Retry DTLS handshake [2]	Retry DTLS handshake [2]	Fall back to Register	Ignored	Ignored by default; configurable; will be retried whenever next notification is scheduled
Timeout (NoSec) [1]	Abort all communication [3]	Abort registration
Network (e.g. ICMP) error			Fall back to Client-Initiated Bootstrap [4]		Fall back to Client-Initiated Bootstrap [4]
CoAP error (4.xx, 5.xx)			Fall back to Register		n/a
CoAP Reset			Fall back to Client-Initiated Bootstrap [4]		Cancel observation
Internal error					Cancel observation if “Notification storing” is disabled

5.5.2. The “Abort registration” condition

This condition corresponds to the registration failure as used in the Bootstrap and LwM2M Server Registration Mechanisms section of LwM2M Core TS 1.1.

If the ANJAY_WITH_LWM2M11 compile-time configuration option is enabled, the retry procedures as described in that section of the 1.1 TS will be performed, with respect to settings stored in the appropriate Server object instance, or the defaults values listen in the “Registration Procedures Default Values” table. According to this configuration, further failures may result in the “abort all communication” [3] or “fall back to Client-Initiated Bootstrap” [4] condition.

In builds of Anjay that do not support LwM2M 1.1, the “abort registration” condition is equivalent with the “fall back to Client-Initiated Bootstrap” [4] condition.

5.5.3. Other error conditions

• Connect operation errors can occur for several reasons, the most common being:

  • (D)TLS handshake errors. Handshakes are performed by the TLS backend library used. This includes handling non-fatal errors and retransmissions. In case of no response from the server, DTLS handshake retransmissions are expected to follow RFC 6347, Section 4.2.4. Timeout and Retransmission. The handshake timers can be customized during Anjay initialization, by setting anjay_configuration_t::udp_dtls_hs_tx_params.

    Ultimate timeout, network-layer errors, and internal errors during the handshake attempt will be treated as a failure of the “connect” operation.

  • Domain name resolution errors. If the getaddrinfo() call (or equivalent) fails to return any usable IP address, this is also treated as a failure of the “connect” operation.

  • TCP handshake errors. While the actual socket-level “connect” operation does not involve any network communication for UDP and as such can almost never fail, it performs actual handshake in case of TCP. Failure of this handshake is also treated in the same way as the other cases mentioned here.

  • In some cases, inconsistent data model state may be treated equivalently to a connection error, e.g. when there is no Security object instance that would match a given Server object instance.

  Note that all of the operations mentioned above (domain name resolution and both TCP and (D)TLS handshakes) are performed synchronously and will block all other operations.

  If any of the above conditions happen, Anjay will, by default, fall back to Client-Initiated Bootstrap [4] or, if the attempt was to connect to a Bootstrap Server, cease any attempts to communicate with it (note that unless regular Server accounts are available, this will mean abortion of all communication [3]).

  This behavior can be changed by enabling the connection_error_is_registration_failure. In that case, connection errors will trigger The “Abort registration” condition, and thus the automatic retry flow described in “Bootstrap and LwM2M Server Registration Mechanisms” section mentioned above will be respected.

• Errors while receiving an incoming request, or any unrecognized incoming packets, will be ignored

• Errors during anjay_download() data transfers will be passed to the appropriate callback handler, see the documentation to anjay_download_finished_handler_t for details.

Footnotes

[1] (1,2)

Retransmissions, as specified in RFC 7252, Section 4.2. Messages Transmitted Reliably, are attempted before performing the actions described above. The transmission parameters that affect specific retransmission timing can be customized during Anjay initialization, by setting the udp_tx_params and sms_tx_params (in versions that include the SMS feature) fields in anjay_configuration_t.

[2] (1,2)

To prevent infinite loop of handshakes, DTLS handshake is only retried if the failed operation was not performed immediately after the previous handshake; otherwise the behavior described in “Timeout (NoSec)” is used.

[3] (1,2,3)

Communication with all servers will be aborted and anjay_all_connections_failed() will start returning true. Operation can be restored by calling anjay_transport_schedule_reconnect() or anjay_enable_server().

[4] (1,2,3,4,5,6)

Client-Initiated Bootstrap will be performed only if all the following preconditions are met:

• a Bootstrap Server Account exists

• no other LwM2M Server has usable connection

• the Bootstrap Server Account has not aborted due to previous errors

Otherwise, further communication with the server with which the operation failed will be aborted. This may cause anjay_all_connections_failed() to start returning true if that was the last operational connection. Connection can be retried by calling anjay_enable_server() or anjay_transport_schedule_reconnect().