11.14. Migrating from Anjay 3.8, 3.9 or 3.10

11.14.1. Introduction 

Starting from Anjay 3.11.0, the behavior regarding the maximum Hold Off Time for bootstrap connections has changed.

11.14.2. Limiting the maximum Hold Off Time for Bootstrap 

A limit has been introduced on the maximum Hold Off Time (LwM2M Security Object, Resource ID: 11) to avoid excessive delays when initiating the Bootstrap process. Previously, the upper bound was implicitly 120 seconds, but it is now explicitly limited to 20 seconds by default.

This behavior can be customized at build time using the MAX_HOLDOFF_TIME macro.

11.14.3. Handling of Trust Store for certain Certificate Usages settings 

avs_commons 5.5.0 that is used by Anjay 3.11.0 does not pass the configured Trust Store (whether manually provided or acquired through the EST process) to Mbed TLS when the certificate usage is set to DANE-TA or DANE-EE, if the Data Model already contains a Server certificate intended for verifying the Server during a secure connection.

If the Server certificate is missing from the Data Model, Anjay falls back to PKIX verification, provided that a Trust Store is available, even when the certificate usage is set to DANE-TA or DANE-EE.

For more information on how Anjay manages the Trust Store and the Certificate Usage resource, see Certificate Usage.

11.14.4. Addition of resource_instance_remove handler 

LwM2M TS 1.2 introduced possibility to delete a Resource Instance, so one additional data model handler had to be added.

New resource_instance_remove handler (and its associated anjay_dm_resource_instance_remove_t function type) has been introduced. It is analogous to the instance_remove handler; its job is to remove a specific Resource Instance from a multiple-instance Resource.

Its implementation is required in objects that include at least one writeable multiple-instance Resource, if the client application aims for compliance with LwM2M 1.2.

11.14.5. Python environment isolation 

All Python-based tools (e.g. integration tests) must be executed within a Python virtual environment. See Virtual environments for more information.

11.14.6. Dropping built-in support for TinyDTLS as a crypto backend 

Built-in support for TinyDTLS as a (D)TLS backend has been removed.

In previous versions of Anjay, TinyDTLS could be selected as a lightweight crypto backend, primarily intended for constrained environments. However, due to its limited feature set, lack of ongoing maintenance, and incompatibility with newer security requirements and LwM2M specifications, it is no longer supported.

Users are now required to use one of the supported and actively maintained (D)TLS backends, such as Mbed TLS or OpenSSL (via avs_commons abstraction layer) or creating there own Custom (D)TLS layer.

11.14.7. Changing Server Initiated Bootstrap behavior 

Previously, Anjay did not use the Client Hold Off Time resource (/1/x/11) during Server Initiated Bootstrap. This was because the description of /1/x/11 states that its value should be used during Client Initiated Bootstrap.

The LwM2M specification also states that Server Initiated Bootstrap causes the LwM2M Client to enter Client Initiated Bootstrap. For consistency with this behavior, Anjay now applies the Client Hold Off Time resource in this scenario as well.

To avoid additional delay, adjust resource /1/x/11 as needed.

11.14.8. Default ciphersuite list 

If neither the DTLS/TLS Ciphersuite Resource (/0/x/16) nor anjay_configuration_t::default_tls_ciphersuites is configured, Anjay now uses a built-in allowlist of secure ciphersuites instead of all ciphersuites supported by the TLS backend.

Applications that require ciphersuites outside this list must configure them explicitly through anjay_configuration_t::default_tls_ciphersuites or /0/x/16.

11.14.9. Changes in Anjay configuration 

The ANJAY_MAX_PK_OR_IDENTITY_SIZE configuration option has been renamed to ANJAY_EST_CSR_BUFFER_SIZE to better reflect its actual purpose. The option specifies the size of the buffer used when generating certificate signing requests during EST enrollment and re-enrollment.

Users with custom Anjay configuration files should replace ANJAY_MAX_PK_OR_IDENTITY_SIZE with ANJAY_EST_CSR_BUFFER_SIZE while preserving the previously configured value.

The ANJAY_MAX_SECRET_KEY_SIZE configuration option has been renamed to ANJAY_EST_SECRET_KEY_BUFFER_SIZE to better reflect its actual purpose. The option specifies the size, in bytes, of the buffer used for generating and storing a private key during EST enrollment.

Users with custom Anjay configuration files should replace ANJAY_MAX_SECRET_KEY_SIZE with ANJAY_EST_SECRET_KEY_BUFFER_SIZE while preserving the previously configured value.

11.14.10. Message cache size configuration 

The type of anjay_configuration_t::msg_cache_size has changed from size_t to size_t *. NULL pointer now indicates that the default value of 4000 will be used.

Applications that previously relied on the zero/default value to disable the message cache must now explicitly set this field to point to a size_t value equal to 0, for example:

size_t msg_cache_size = 0;
anjay_configuration_t config = {
    .msg_cache_size = &msg_cache_size,
    // other fields...
};

11.14.11. Disable unsecure configuration 

Anjay added a new configuration define ANJAY_WITH_UNSECURE_CONNECTIONS which is unset by default in the configuration. Having this option unset will prevent Anjay from using unecrypted communication. If you relay on a NOSEC communication you must set this define.

Also Anjay added a new configuration define AVS_COMMONS_WITH_LEGACY_SSL_VERSIONS, which is unset by default in the configuration. Having this option unset will prevent Anjay from using legacy SSL, TLS and DTLS protocol versions, including SSLv2, SSLv3, TLS 1.0, TLS 1.1 and DTLS 1.0.

If you rely on any of these legacy protocol versions, you must enable AVS_COMMONS_WITH_LEGACY_SSL_VERSIONS.

11.14.12. Changes in automatic reconnection in the event loop 

Previously, anjay_event_loop_run_with_error_handling() called anjay_transport_schedule_reconnect(anjay, ANJAY_TRANSPORT_SET_ALL) when all configured LwM2M servers were unreachable. This also forced reconnection of ongoing downloads.

The event loop now schedules reconnects for individual Server Object instances using anjay_server_schedule_reconnect(). Ongoing downloads using dedicated downloader sockets are no longer reconnected as a side effect of LwM2M server connection failures. Downloads that share a socket with a LwM2M server remain dependent on that server’s connection.

Applications that relied on this side effect to reconnect ongoing downloads must now request it explicitly:

Use anjay_download_reconnect() with the download handle for downloads started through anjay_download().
Use anjay_fw_update_pull_reconnect() for PULL-mode downloads managed by the Firmware Update module.

If reconnecting all sockets on selected transports is intentional, call anjay_transport_schedule_reconnect() explicitly with the appropriate transport set.

Automatic CoAP download retries configured through anjay_configuration_t::coap_downloader_retry_count and anjay_configuration_t::coap_downloader_retry_delay remain available and operate independently of this event loop recovery mechanism.

Applications that did not rely on the transport-wide reconnect side effect require no changes.