Skip to content
master
Go to file
Code

Latest commit

Mateusz Kwiatkowski
Mateusz Kwiatkowski Anjay 2.8.0
BREAKING CHANGES:
See below for breaking changes in avs_commons. Note that these are unlikely to
affect users that use CMake for building the library, but may require updating
configuration headers when using alternative build systems.

For more detailed information about breaking changes and how your code needs to
be updated, see:
https://avsystem.github.io/Anjay-doc/Migrating/MigratingFromAnjay27.html

Features:
- Made use of avs_commons' new floating point formatting functions, making it
  possible to link against libc implementations that don't support printf("%g")
- (commercial version only) Support for Enrollment over Secure Transports
  (EST-coaps) with key and certificate storage on Hardware Security Modules via
  avs_commons' OpenSSL engine support
- (commercial version only) Support for certificate chain reconstruction based
  on trust store when performing (D)TLS handshake - this is especially useful
  for EST-based security, as certificates provisioned via /est/crts can be used
  as client certificate chain during handshake

Improvements:
- Better CMake-level dependencies and error handling for compile-time
  configuration options
- Fixed various compile-time warnings
- Included avs_commons and avs_coap configuration in the TRACE-level
  configuration report log at initialization time
- Relaxed timeout for Deregister message in integration tests
- Integration test target logs path is now configurable in runtest.py
- Various improvements to documentation and examples:
  - Attribute storage module is now installed in most tutorials, making them
    more complete
  - https://avsystem.github.io/Anjay-doc/AdvancedTopics/AT-NetworkErrorHandling.html
    now mentions retry behavior of the commercial version in LwM2M 1.1
  - API documentation generated by Doxygen now properly includes all
    commercial-only APIs when run in commercial codebase
  - Updated installation instructions for CentOS that referred to non-existent
    URLs
  - Updated visual style to match corporate identity

Bugfixes:
- Data model persistence routines can no longer be successfully called during
  the bootstrap procedure, preventing from persisting potentially invalid data
- Fixed a regression in 2.7.0 that prevented ciphersuite setting from being
  properly respected for HTTP downloads
- Fixed a bug that could result in an assertion failure when showing demo
  client's help message
- Fixed a bug in "get_transport" command implementation in demo client
- Fixed erroneous setting of AVS_COMMONS_WITH_AVS_CRYPTO_ADVANCED_FEATURES in
  example configuration headers
- Removed duplicate file names that could prevent building with some embedded
  IDEs

Also updates avs_commons to version 4.5 which introduces the following changes:

BREAKING CHANGES:
- Moved URL handling routines to a separate avs_url component
- Implementation of avs_net_validate_ip_address() is no longer required when
  writing custom socket integration layer
- Hardware Security Module support has been reorganized to allow easier
  implementation of third-party engines

Features:
- Support for private key generation and removal on Hardware Security Modules
  via PKCS#11 engine
- Support for storing and removing certificates stored on Hardware Security
  Modules via PKCS#11 engine
- Support for certificate chain reconstruction based on trust store when
  performing (D)TLS handshake
- New AVS_DOUBLE_AS_STRING() API and AVS_COMMONS_WITHOUT_FLOAT_FORMAT_SPECIFIERS
  configuration options, making it possible to stringify floating point numbers
  on libc implementations that don't support printf("%g")

Improvements:
- Simplified URL hostname validation - it is now somewhat more lenient, but no
  longer depends on avs_net_validate_ip_address()
- Removed internal usage of avs_net_validate_ip_address() and reimplemented it
  as an inline function that wraps avs_net_addrinfo_resolve_ex()
- Better CMake-level dependencies and compile-time error handling for
  compile-time configuration options
- PEM-formatted security objects can now be loaded from buffer in the Mbed TLS
  backend

Bugfixes:
- Fixed conditional compilation clauses for avs_crypto global initialization
- Additional NULL checks when loading security information
- Removed duplicate file names that could prevent building with some embedded
  IDEs
7042222

Git stats

Files

Permalink
Failed to load latest commit information.
Type
Name
Latest commit message
Commit time
 
 
 
 
 
 
doc
 
 
 
 
src
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

Anjay LwM2M library

Build Status Coverity Status

What is Anjay?

Anjay is a C library that aims to be the reference implementation of the OMA Lightweight Machine-to-Machine (LwM2M) device management protocol. It eases development of fully-featured LwM2M client applications by taking care of protocol details, allowing the user to focus on device-specific aspects.

The project has been created and is actively maintained by AVSystem.

Supported features

This version includes full support for OMA LwM2M TS 1.0 features. Version that supports TS 1.1 is available commercially.

  • LwM2M Bootstrap Interface:

    • Request
    • Finish
    • Write
    • Delete
    • Discover
  • LwM2M Client Registration Interface:

    • Register
    • Update
    • De-register
  • LwM2M Device Management and Service Enablement Interface:

    • Read
    • Discover
    • Write
    • Write-Attributes
    • Execute
    • Create
    • Delete
  • LwM2M Information Reporting Interface:

    • Observe
    • Notify
    • Cancel Observation
  • LwM2M Security modes:

    • DTLS with Certificates (if supported by backend TLS library)
    • DTLS with PSK (if supported by backend TLS library)
    • NoSec mode
  • Supported TLS backends:

    • mbed TLS
    • OpenSSL
    • tinydtls
  • Supported platforms:

  • CoAP data formats:

    • TLV
    • Opaque
    • Plain Text (including base64 encoding of opaque data)
  • CoAP BLOCK transfers (for transferring data that does not fit in a single UDP packet):

    • Block1 (sending / receiving requests)
    • Block2 (sending responses)
  • Pre-implemented LwM2M Objects:

    • Access Control
    • Security
    • Server
  • Stream-oriented persistence API

About OMA LwM2M

OMA LwM2M is a remote device management and telemetry protocol designed to conserve network resources. It is especially suitable for constrained wireless devices, where network communication is a major factor affecting battery life. LwM2M features secure (DTLS-encrypted) methods of remote bootstrapping, configuration and notifications over UDP or SMS.

More details about OMA LwM2M: Brief introduction to LwM2M

Quickstart guide

Dependencies

  • C compiler with C99 support,
  • avs_commons - included in the repository as a subproject,
  • If DTLS support is enabled, at least one of:
  • Optional dependencies (required for tests):
  • Optional dependencies (required for building documentation - more information in "Contributing" section):

Ubuntu 16.04 LTS / Raspbian Buster or later

sudo apt-get install git build-essential cmake libmbedtls-dev zlib1g-dev

CentOS 7 or later

# EPEL is required for mbedtls-devel and cmake3
sudo yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum install -y which git make cmake3 mbedtls-devel gcc gcc-c++ zlib-devel

macOS Sierra or later, with Homebrew

brew install cmake mbedtls

Running the demo client

For initial development and testing of LwM2M clients, we recommend using the Try Anjay platform where you can use the basic LwM2M server functionality for free.

After setting up an account and adding the device entry, you can compile Anjay demo client and connect it to the platform by running:

git clone https://github.com/AVSystem/Anjay.git \
    && cd Anjay \
    && git submodule update --init \
    && cmake . \
    && make -j \
    && ./output/bin/demo --endpoint-name $(hostname) --server-uri coap://try-anjay.avsystem.com:5683

NOTE: On some older systems like CentOS 7, you may need to use cmake3 instead of cmake.

NOTE: We strongly recommend replacing $(hostname) with some actual unique hostname. Please see the documentation for information on preferred endpoint name formats. Note that with the Try Anjay platform, you will need to enter the endpoint name into the server UI first.

Detailed compilation guide

First, make sure all necessary submodules are downloaded and up-to-date:

git submodule update --init

After that, you have several options to compile the library.

Building using CMake

The preferred way of building Anjay is to use CMake.

By default demo client compiles with DTLS enabled and uses mbedtls as a DTLS provider, but you may choose other DTLS backends currently supported by setting DTLS_BACKEND in a CMake invocation to one of the following DTLS backends: openssl, mbedtls or tinydtls:

cmake . -DDTLS_BACKEND="mbedtls" && make -j

Or, if a lack of security (not recommended) is what you need for some reason:

cmake . -DDTLS_BACKEND="" && make -j

Compiled executables, including demo client, can be found in output/bin subdirectory.

For a detailed guide on configuring and compiling the project (including cross-compiling), see Compiling client applications.

To start the demo client:

# uses plain CoAP
./output/bin/demo --endpoint-name $(hostname) --server-uri coap://try-anjay.avsystem.com:5683

# uses DTLS in PSK mode, with PSK identity "foo" and secret key "bar" (hex-encoded)
./output/bin/demo --endpoint-name $(hostname) --server-uri coaps://try-anjay.avsystem.com:5684 --security-mode psk --identity 666f6f --key 626172

NOTE: When establishing a DTLS connection, the URI MUST use "coaps://". In NoSec mode (default), the URI MUST use "coap://".

Alternative build systems

Alternatively, you may use any other build system. You will need to:

  • Prepare your avs_commons_config.h, avs_coap_config.h and anjay_config.h files.
  • Configure your build system so that:
    • At least all *.c and *.h files from src, include_public, deps/avs_coap/src, deps/avs_coap/include_public, deps/avs_commons/src and deps/avs_commons/include_public directories are preserved, with the directory structure intact.
      • It is also safe to merge contents of all include_public directories into one. Merging src directories should be safe, too, but is not explicitly supported.
    • All *.c files inside src, deps/avs_coap/src, deps/avs_commons/src, or any of their direct or indirect subdirectories are compiled.
    • deps/avs_commons/src and deps/avs_commons/include_public directories are included in the header search path when compiling avs_commons.
    • deps/avs_coap/src, deps/avs_coap/include_public and deps/avs_commons/include_public directories are included in the header search path when compiling avs_coap.
    • src, include_public, deps/avs_coap/include_public and deps/avs_commons/include_public directories are included in the header search path when compiling Anjay.
    • include_public, deps/avs_coap/include_public and deps/avs_commons/include_public directories, or copies of them (possibly merged into one directory) are included in the header search path when compiling dependent application code.

Below is an example of a simplistic build process, that builds all of avs_commons, avs_coap and Anjay from a Unix-like shell:

# configuration
cp -r example_configs/linux_lwm2m10 config
# you may want to edit the files in the "config" directory before continuing

# compilation
cc -Iconfig -Iinclude_public -Ideps/avs_coap/include_public -Ideps/avs_commons/include_public -Isrc -Ideps/avs_coap/src -Ideps/avs_commons/src -c $(find src deps/avs_coap/src deps/avs_commons/src -name '*.c')
ar rcs libanjay.a *.o

# installation
cp libanjay.a /usr/local/lib/
cp -r include_public/avsystem /usr/local/include/
cp -r deps/avs_coap/include_public/avsystem /usr/local/include/
cp -r deps/avs_commons/include_public/avsystem /usr/local/include/
cp -r config/* /usr/local/include/

Use a Dockerfile

For some cases you may find it comfortable to use Docker image. In this case, the only dependency is Docker, which you can install with your favorite package manager. If Docker is already installed, you can clone the repo and build the Docker image:

git clone --recurse-submodules https://github.com/AVSystem/Anjay.git
cd Anjay
docker build --no-cache --tag anjay .

Then, you can launch the built image and run the demo client:

docker run -it anjay
./output/bin/demo -e $(hostname) -u coap://try-anjay.avsystem.io:5683

Mbed OS port

If you want to use Anjay on Mbed OS, you might be interested in the Anjay-mbedos and Anjay-mbedos-client repositories, which contain basic integration with that system.

Zephyr OS port

If you want to use Anjay on Zephyr OS, you might want to check our example client based on it.

License

See LICENSE file.

Commercial support

Anjay LwM2M library comes with the option of full commercial support, provided by AVSystem.

The commercial version supports the latest LwM2M 1.1 release, including Composite operations, Send method, SenML JSON and CBOR data formats, TCP, SMS and NIDD bindings.

If you're interested in LwM2M Server, be sure to check out the Coiote IoT Device Management platform by AVSystem, which also focuses on LwM2M along with its latest 1.1 specification.

Contributing

Contributions are welcome! See our contributing guide.

Building documentation

Make sure, both Doxygen and Sphinx are installed on your system, then type:

cmake . && make doc

the documentation will be available under output/doc/doxygen and output/doc/sphinx.

You can’t perform that action at this time.