LwM2M engine did not set response code for the Bootstrap-finish message,
hence it replied with the code copied from the request which is not
correct. Fix this by setting correct code for the Bootstrap-finish
reply.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
"Public Key or Identity" resource is of opaque data type, therefore it's
not correct to assume it will be a NULL terminated string (the existing
servers, for instance Leshan, does not include NULL terminator). Use the
actual size associated with the resource instead.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
So far, the resource instance structure kept only the information about
the buffer length provided to the resource (in the `data_len` field).
While this approach might be enough for integer resources, where the
actual data size is fixed, it did not work for opaque resources. It is
impossible to determine the actual opaque resource length after it's
been written into.
Fix this, by replacing the current `data_len` field of the
`lwm2m_engine_res_inst` with `max_data_len`, indicating the buffer
size, and making the `data_len` field to hold the actual data size of
the resource.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This commit fixes PUSH FOTA when opaque content-format is used.
This consists of the following fixes:
* Moved `struct block_context` to a private header, so that it can be a
part of `struct lwm2m_input_context`. This allows content decoders to
make use of the block context data.
* Removed faulty `get_length_left` function from the plain text
decoder, and replace it with coap_packet_get_payload() to obtain the
actual payload size.
* Introduce `struct lwm2m_opaque_context` as a part of block context,
which allows to keep track of opaque data download progress.
* Simplify `lwm2m_write_handler_opaque()` function. It will now only
make calls to `engine_get_opaque` - it's the decoder responsibility
to update the opaque context according to it's content format (for
instance TLV decoder should only update it with the actual opaque
data size, not the whole TLV).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Change so that the caller of lwm2m_init_message is
responsible for generating a message id and remove message id generation
from lwm2m_init_message. Prevents generating a new id when the caller's
intent is to init a message with id 0.
Fixes#28283
Signed-off-by: Pascal Brogle <pascal.brogle@husqvarnagroup.com>
message id 0 and token 0 have special semantics in the lwm2m engine,
they are used to request generation of new id, mark them as such.
Signed-off-by: Pascal Brogle <pascal.brogle@husqvarnagroup.com>
Now that device_api attribute is unmodified at runtime, as well as all
the other attributes, it is possible to switch all device driver
instance to be constant.
A coccinelle rule is used for this:
@r_const_dev_1
disable optional_qualifier
@
@@
-struct device *
+const struct device *
@r_const_dev_2
disable optional_qualifier
@
@@
-struct device * const
+const struct device *
Fixes#27399
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
A proper way to match a Security object instance with a Server object
instance is via Short Server ID resource. Both coupled object instances
should carry the same value of this resource in order to me considered
matched.
This was not implemented in the LwM2M library and it was incorrectly
assumed that the Security object instance index corresponds to the
Server object instance index. While such apporach works is simple
scenario, it might yield incorrect results when bootstrap is used.
Fix this, by verifyng the Short Server ID resource in the Secuirty
instance used, and finding a matching Server instance. The server object
instance is stored for future use in the engine.
Additionally, remove an extra Server object instance that was created
when the bootstrap procedure was used. Since the boostrap Security
object instance does not have the corresponding Server object, it's
enough to have a single Server instance.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Currently, functions for poll sock_fds array management are buggy, in
case there is another socket open (for instance the socket for firmware
update download), it could get overwritten, if the LwM2M socket was
closed and re-opened in a meantime (e. g. on registration timeout).
Fix this, by appending new entries to the sock_fds in continuous manner.
In case of removal, the deleted entry is overwritten by the last one,
and the last one is cleared.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
During FW update, the application expects a consecutive data stream.
Therefore retransmitted blocks shall not be forwarded to the
application, but ignored. In case blocks are received out of order,
return an error and do not handle this block.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When FW update in PUSH mode is used, the firmware is encapsulated in the
TLV as an opaque data, according to the LMWM2M satandard, and then
sliced into blocks and transferred block by block in several
transactions. Therefore, the TLV header is only present in the initial
message.
Current implementation did not handle this case well, reporting errors
on consecutive blocks, therefore making the FW update in PUSH mode
broken.
This commit fixes this issue with following changes:
* The TLV is only assumed to be present in the initial block, while
consecutive blocks will be processed directly into the appropriate
handler,
* 32-bit variables shall be used whenever dealing with the opaque data
length, since the firmware size can easily exceed the 16-bit range,
* Additional information, required for the FW block transfer to work
properly were added to the block context structure,
* The application shall only be notified of the actual data length, and
not the total block size (the total TLV size including header).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
During the bootstrap procedure, when Boostrap Finish was received, the
response message was not initialized properly, resulting in a socket
error (NULL pointer porovided) and the response not being sent.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
`addrlen` parameter is updated on each `recvfrom` call, indicating the
actual address length returned. In case both, IPv4 and IPv6 are used on
different sockets (i. e. on regular LWM2M socket and FOTA socket), the
returned address length will differ.
In case `from_addr_len` is not reinitialized on each iteration, the
value stored in the `from_addr_len` variable will eventually indicate
the smaller IPv4 address size, therefore resulting in a failure in a
consecutive call on an IPv6 socket.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Although LwM2M engine uses cooperative threads, the internal `send()`
implementation might trigger context switch when it calls a kernel
function, therefore resulting in `send()` call being entered from both
the LwM2M thread and the retransmit work.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The context should only clear messages it owns, not all of them. Since
both context (LwM2M and FOTA) share common message pool, they might
interrupt their operation otherwise (i. e. cancel retransmissions).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
So far socket errors reported by poll/recvfrom were ignored, which could
lead to an unexpected behavior when socket was left in an undefined
state.
Fix this, by requesting a re-registration in the LWM2M state machine,
which will close the faulty socket and open a new one. Note, that simply
closing and re-opening a socket in the lwm2m engine would not work,
since this would silently invalidate any open observations on the
lwm2m server side (due to port number change). Triggering a fresh
registration will notify the server to update its observations.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
On OT network with poor coverage, very often request/observe packets
doesn't get it's ACK and consumes from pendings/replies/message stacks.
In such cases when LWM2M engine tries to recover by resetting its state,
it fails because of lack of free messages.
Signed-off-by: Kiril Petrov <retfie@gmail.com>
In networks with high latencies (like NB-IoT), it's quite common to
recieve duplicated response. It's not an error condition, a correct way
to handle it is to simply ignore the duplicate. Lower the log level for
this event, not to disturb users.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The retaransmission logic was not correct in the lwm2m_engine, and could
lead to faulty behavior in case multiple messages were pending for
retransmission in the queue.
1. Since there is a singe delayed work item for entire retransmission
queue, `coap_pending_next_to_expire` should be called before
scheduling next timeout, to identify which message is going to expire
next (and when). Currently, the engine always set next timeout, based
on timeout from the message being currently re-transmitted.
2. In case the message was re-transmitted several times, and is removed
from the retansmission queue due to a timeout, next retransmission
should be scheduled, in case there are other messages on the queue.
3. Verify the timeout of the earliest message to expire in the
retransmission handler. In case messages from the beginning of the
queue were removed, we might need to schedule the retransmission
again, instead of sending message rightaway.
4. `lwm2m_send_message` is not handling retransmissions anyway, so
there's no need to check send attempts. Instead, verify
retransmission work item is already pending, and update its timeout
if needed.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The LwM2M stack would previously ignore all OPAQUE resources when
reading them. This meant that it was impossible to read them, even if
there was a custom read callback.
Signed-off-by: Göran Weinholt <goran.weinholt@endian.se>
According to LWM2M specification, when Queue Mode is used, the LWM2M
client should keep the reciever on for specified time after sending A
CoAP message. This commit adds a new LWM2M event,
`LWM2M_RD_CLIENT_EVENT_QUEUE_MODE_RX_OFF`, to facilitate the process by
notifying the application when it's safe to turn the receiver off.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add Kconfig option to enable Queue Mode binding. With this option
enabled, the LWM2M client will register with `UQ` binding, instead of
`U`.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
With `CONFIG_NET_NATIVE`, offloaded drivers can specify capabilites with
`NET_IPV4/6` configs, so there is no longer need to handle socket
offloading separately.
Also, initialize hints structure with zeros, as according to man pages
unused fields should be set to 0:
`All the other fields in the structure pointed to by hints must contain
either 0 or a NULL pointer, as appropriate.`
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add new config option `LWM2M_DNS_SUPPORT` to the LWM2M library, instead
of relying on `DNS_RESOLVER` which is only compatible with native
network stack. This allows to use DNS with offloaded interfaces
seamlessly.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The LwM2M implementation for DNS resolving has checks which
configure hints based on whether IPv4 or IPv6 are enabled.
Neither of them need enabled if using NET_SOCKETS_OFFLOAD,
which then causes an error to be returned to due to
"hints.ai_family" not being set.
Also the offload API need to know when to free the allocated
"struct addrinfo" instead of calling free() generically,
thus let's use the freeaddrinfo() API for sockets which will
call into the offload API if needed.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/18765
Signed-off-by: Jun Qing Zou <jun.qing.zou@nordicsemi.no>
When the bootstrap support was added, it looks like I somehow missed
the handling block in the engine.
Let's add it now to fix boostrap support.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/18080
Signed-off-by: Michael Scott <mike@foundries.io>
When presenting errors in lwm2m_engine_set() let's include the related
LwM2M path for easier debugging.
Signed-off-by: Michael Scott <mike@foundries.io>
LwM2M allows for multiple instance resources such the power source
resources in the device object. These types of resources have
always been very hard to work with, and frankly were poorly
implemented.
This led to other issues where it was very hard to have
non-sequential resource instances, and each resource of this type
needed special getter / setter methods such as:
lwm2m_device_add_pwrsrc()
lwm2m_device_set_pwrsrc_voltage_mv()
Going forward, as more LwM2M objects are implemented this just
doesn't scale well.
To fix this:
- split the resource instance data out from the resource data.
This includes the data pointer information and resource
instance id.
- add resource id and resource instance id to the event callback
functions so user's can see in more detail what resources and
resource instances are being handled.
- allow generic functions like lwm2m_engine_get_*() and
lwm2m_engine_set_*() to access resource instance data.
- adjust object resource initialization macros to map resource
instances to resources at the time of object instance
creation.
- fix up the lwm2m_client as a reflection of all of these changes.
Signed-off-by: Michael Scott <mike@foundries.io>
Due to work combining data into the lwm2m_message structure, we no
longer need to pass the lwm2m_engine_obj parameter between
formatters and most of the operation handlers.
So, let's remove it.
Signed-off-by: Michael Scott <mike@foundries.io>
Server records contain the default PMIN and PMAX settings for how
often we can send observe notifications. We are currently using
arbitrary defaults which cannot be changed when compiled or
during runtime.
Let's add Kconfig settings for the default settings to use and
also lookup the current values in the active server record when
an observe is added.
The actual PMIN/PMAX values can still be set via WRITE_ATTRIBUTE
operation.
Signed-off-by: Michael Scott <mike@foundries.io>
Currently the retransmit_work is not cancelled when closing a context,
making it operate on an invalid context.
LwM2M RD client also closes the context and initializes it again when
registration with the server fails, overwriting the active timeout and
breaking the timeout dlist.
Signed-off-by: Pieterjan Camerlynck <pieterjan.camerlynck@gmail.com>
Current implementation of LwM2M engine doesn't allow users a way
of overriding TLS credential load with custom function. This
would be needed by an offloaded TLS stack where we don't want
to use standard Zephyr functions.
Let's add a load_credential function pointer to the LwM2M client
context which will be called when it's available.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17408
Signed-off-by: Michael Scott <mike@foundries.io>
CONFIG_NET_IPV* checks are not needed in lwm2m_parse_peerinfo().
The functions used are always available. Worse, having these checks
forces the need to enable CONFIG_NET_IPV4 or IPV6 when it's not really
needed (LwM2M could be using an offloaded IP stack).
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17401
Signed-off-by: Michael Scott <mike@foundries.io>
CONFIG_NET_IPV* checks are not needed in lwm2m_sprint_ip_addr(). The
functions used are always available. Worse, having these checks
forces the need to enable CONFIG_NET_IPV4 or IPV6 when it's not really
needed (LwM2M could be using an offloaded IP stack).
NOTE: Also fixes an issue where a NULL is returned when the IP address
is unknown. This usually ends up with a crash/abort in the logging
code.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/17401
Signed-off-by: Michael Scott <mike@foundries.io>
This fixes the issue where observations are automatically reported using
the minimum period instead of the maximum. This causes notifications to
be sent more frequently than configured when the resource does not
change.
Signed-off-by: Pieterjan Camerlynck <pieterjan.camerlynck@gmail.com>
move misc/printk.h to sys/printk.h and
create a shim for backward-compatibility.
No functional changes to the headers.
A warning in the shim can be controlled with CONFIG_COMPAT_INCLUDES.
Related to #16539
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Found a few annoying typos and figured I better run script and
fix anything it can find, here are the results...
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Due to commit a211afb0 ("logging: Add option to detect missed
transient string duplication"), the logs for LwM2M subsystem
is now spamming missing log_strdup() calls.
Let's add log_strdup() where needed.
Signed-off-by: Michael Scott <mike@foundries.io>
This fixes an issue where if timestamp == service_due_timestamp,
we don't call the periodic service. Then the following call to
engine_next_service_timeout_ms() returns 0 because the service
is still due and lwm2m_engine_service() is called again.
This process repeats several times until the value of
k_uptime_get() changes and then the work is finally handled.
Previously, the resolution of k_uptime_get() was in ms. A recent
change to this API defaults Zephyr so that the resolution is
set via CONFIG_SYS_CLOCK_TICKS_PER_SEC (default 100).
This means the value of k_uptime_get() only changes every 10ms.
Reported-by: Github User pieterjanc
Signed-off-by: Michael Scott <mike@foundries.io>
"It's a Trap!" -- Admiral Ackbar
When moving to the BSD-socket APIs, the original thread running LwM2M
periodic services such as observes and lifetime updates, was replaced
with a re-occuring workqueue job. To save the overhead of creating a
new thread, I used the system workqueue for these jobs.
This was a mistake. If these jobs hit a semaphore or wait for some
reason, it cannot be prempted due to the priority of the system work
queue.
Let's instead add this service handling to the thread that we already
use for polling sockets. This also removes a configuration issue where
the system workqueue stack size needed to be increased. This can now
be adjusted via the LWM2M_ENGINE_STACK_SIZE knob.
Directly fixes semaphore usage in the socket-based DNS code.
This was introduced as a bugfix for non-responsive DNS server hanging
the Zephyr device forever. However, this probably fixes randomly
seeming hangs on the device.
Signed-off-by: Michael Scott <mike@foundries.io>
Normally, this bug wasn't apparent as the value is type-casted
to a float32/64 type. However, once we start persisting these
values they need the correct length.
Signed-off-by: Michael Scott <mike@foundries.io>
