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




Notify (confirmable)

Timeout (DTLS) [1]

Retry DTLS handshake [2]

Retry DTLS handshake [2]

Fall back to Register


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


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.