When URI is written, we must first set the state to DOWNLOADING
so when any error happens on the initialization phase, the
result written on a callbacks are correctly reflected and the state
changes correctly IDLE -> DOWNLOADING -> IDLE (result written).
Signed-off-by: Seppo Takalo <seppo.takalo@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Previously the object 5 was only single instance object. Provide
backwards compatibility, so it can be continued to use with single
instance.
Signed-off-by: Jarno Lamsa <jarno.lamsa@nordicsemi.no>
This is a proof-of-concept implementation.
A device might have multiple firmware images which needs to be updated
separately. For example a single device might have
* A bootloader image
* An application image
* External firmware image
Instead of pushing all these updates through the object instance 0 -
/5/0 - here a split to multiple has been made possible.
Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
Add a semaphore to control that no collisions occur when multiple
sources want to use the pull_context
Add struct firmware_pull_context *ctx as an argument to the result_cb of
the context. This allows the receiver to do some kind of differentiation
on the source.
Signed-off-by: Michal Ciesielski <michal.m.ciesielski@voiapp.io>
Make it possible to reuse the pull logic from firmware_pull.c by
separating it to a separate file.
The firmware_pull_context is still owned and statically allocated in
firmware_pull.c and is being passed into lwm2m_pull_context.c as a
pointer.
In other words, pull_context, does not keep any state except for a
pointer to the context currently in use.
Signed-off-by: Michal Ciesielski <michal.m.ciesielski@voiapp.io>
net: lwm2m: When mbedtls CONFIG_MBEDTLS_SERVER_NAME_INDICATION is
enabled, a destination hostname must be passed to socket to properly
connect do lwm2m server.
Passing lwm2m context to lwm2m_parse_peerinfo
Signed-off-by: Jair Jack <jack@icatorze.com.br>
If a firmware update is fetched from a server, and no port number is set
in the URI (e.g. coap://example.com/fw_update), the client will try
to connect on the port specified by CONFIG_LWM2M_PEER_PORT.
If a port different from the peer port is to be used for firmware
update, this has to be set explicitly in the URI:
coap://example.com:5683/fw_update.
This fix adds CONFIG_LWM2M_FIRMWARE_PORT, which will be used when
fetching a firmware update without specifying the port number in the
URI.
Signed-off-by: Tjerand Bjornsen <tjerand.bjornsen@nordicsemi.no>
Instead of manually computing payload offset, let the CoAP library do
the work, and use the payload pointer returned by the
`coap_packet_get_payload()` function instead.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This restructures the lwm2m_engine to use a non-blocking socket access
instead of the previously used blocking style, and eliminates any
socket-access from outside of the main work loop.
The main motivation behind this is an issue within nordics
nrf_modem_lib/modem-fw on nrf9160, that leads to socket send() calls to
block indefinitely when the shared memory used for
rpc-communication with the modem is already exhausted because of
incoming data.
This lead to the lwm2m_engine locking up on send calls when there is
also a large amount of incoming data.
This works around this issue, by only issuing send calls when poll
reports the socket to be ready for sending, and (more importantly) by
always receiving all buffered incoming data before sending anything.
There might still be a (perhaps academic) possibility where this
situation might be triggered, when the scheduler interrupts the lwm2m
thread in-between receiving and sending, but for now we have not yet
observed this.
Besides working around the aforementioned issue, this also simplifies
the way resends are handled as they are no longer send from the main
system-workqueue, and limits all interaction with the sockets to a
single thread.
Signed-off-by: Henning Fleddermann <henning.fleddermann@grandcentrix.net>
The LwM2M firmware pull object no longer uses the system workqueue
to execute firmware_transfer(), but directly executes it itself.
Previously, the workqueue would be blocked because firmware_transfer()
indirectly calls a blocking connect(). This would lead to problems
with e.g. modem drivers that use UART to interface with the modem
hardware, as some UART drivers use the workqueue.
Fixes#31053.
Signed-off-by: Maik Vermeulen <maik.vermeulen@innotractor.com>
Currently, when socket errors occur during receive, the LwM2M engine
restarts the state machine and registers again to the server. While this
works in simple use case (only RD client socket open), it's not a valid
approach when more sockets are open (FW update socket).
Fix this by introducing socket fault callback, which is registered by
the LwM2M engine users. This way, a proper socket owner is notified on
error and can pertake appropriate action.
For RD socket errors the behaviour remains the same - the state machine
is reset and the client registers again to the server. For FW update
socket, handle the error by reopening the socket and retransmitting the
last request. This allows to resume the download from the point the
error occured, w/o a need to start from scratch.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The memset on firmware_ctx during PULL FW update initialization will
set the socket descriptor to a valid value of 0. This leads to an error
if parsing of the URI provided by the server fails, and the firware_ctx
is closed - the socket with a descriptor 0 will be accidently closed.
Fix this by invalidating the socket FD after the memset on
initialization.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
It shouldn't be optional to handle separate response, as it's a
mandatory requirement according to the RFC7252:
"The protocol leaves the decision whether to
piggyback a response or not (i.e., send a separate response) to
the server. The client MUST be prepared to receive either."
Therefore, remove the flag as separate responses are handled now
properly.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
So far this function existed as a static function in LwM2M PULL FOTA
module. Since such functionality will be needed in other places, make it
an internal API function.
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>
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>
The FOTA socket was not closed when download finished or an error
occured.
Additionally, fix the socket fd verification (it was assumed 0 is not a
valid fd which is not correct).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This change is to allow access to the firmware block context in order to
give the firmware update callback implementation an indication of when
to reset the flash context. Additionally, it allows for a validity check
between the total expected size downloaded and the actual size
downloaded. A simple implementation can check if the block context's
current downloaded blocks is equal to the expected block size in order
to determine if the flash context needs to be reset. This approach
seemed the simplest, and knowing the firmware block context can have
other purposes. This has been tested by accessing the block context
during the update in the block received callback and confirming that the
callback had information regarding the current downloaded bytes.
Fixes#16122
Signed-off-by: Kyle Sun <yaomon18@yahoo.com>
When the firmware_pull mechansim sends the callback to notify the
sample of a new firmware block, the user supplied buffer can be
smaller than the CoAP BLOCK_SIZE setting. To handle this case,
we loop through the payload and fill the user supplied buffer with
smaller chunks.
Unfortunately, the last_block calculation is done outside this loop
which causes several callbacks (while in this loop) to have
last_block true. Let's fix this by adding a small check to make
sure we're at the end of the current payload block before notifying
the user of a last_block.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/16158
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>
When performing OTA using the LwM2M subsys, several logging errors
regarding log_strdup were noted. Let's fix these.
Signed-off-by: Michael Scott <mike@foundries.io>
In order to support bootstrap mode, we need to store server data
in the security / server objects. Once the connection to the
bootstrap server is made, it will clear these objects and add
new server connection data.
Signed-off-by: Michael Scott <mike@foundries.io>
net_app contexts save the remote address and we use this during
observe notifications and pending handling. If we move to another
network layer such as sockets, then the remote address becomes
harder to reference. Let's save it as a part of the client
context.
Signed-off-by: Michael Scott <mike@foundries.io>
As part of the migration from net_app APIs to socket APIs, let's
stop referencing the net_pkt fragments throughout the LwM2M library.
Establish a msg_data flat buffer inside lwm2m_message and use that
instead.
NOTE: As a part of this change we remove the COAP_NET_PKT setting.
The COAP library reverts to COAP_SOCK behavior.
This doesn't mean we use sockets in LwM2M (yet), it only means we
use the socket-compatible COAP library which parses flat buffers
instead of net_pkt fragments.
Signed-off-by: Michael Scott <mike@foundries.io>
During firmware transmit timeout, we rely on the pending packet data to
reconstitute the token and token length. At this point the pending
structure may be cleared out due to multiple retries. To avoid getting
a zero token, let's use the token data from the original msg structure
instead.
Signed-off-by: Michael Scott <mike@foundries.io>
The return of memset is never checked. This patch explicitly ignore
the return to avoid MISRA-C violations.
The only directory excluded directory was ext/* since it contains
only imported code.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
During normal use, a CoAP packet can be resent due to network congestion
and other causes. During block transfer the LwM2M client checks to make
sure the block received is the one we expect and if not generates a
"duplicate" warning. When this happened, we were releasing the reply
handler and when the correct block was received the client would
generate a "No handler" error.
To avoid releasing the reply handler too early, let's set the coap_reply
"user_data" field to an error condition (1). Then, once the reply
processing is complete we can check the user_data field to be sure that
it's ok to release the reply handler.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
This allows a user to customize the port used for downloading
firmware via the pull method of the LwM2M client. It's default
value of 0 will select a random port during initialization.
NOTE: If set, this value should not be the same port as the
LWM2M_LOCAL_PORT setting.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
commit 2a7546fb5a ("net: lwm2m: add support for coap2coap proxy")
erroneously changed the COAP_OPTION_* used to specify the coap2coap
or coap2http proxy resource used from COAP_OPTION_URI_PATH to
COAP_OPTION_PROXY_SCHEME.
Changing it back to COAP_OPTION_URI_PATH requires us to re-order how
the coap options are appended to the packet as the coap options must
be added in the order specified by the numbers in:
https://tools.ietf.org/html/rfc7252#section-12.2
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Consolidate and standardize error handling throughout
lwm2m_obj_firmware_pull.c. As well as handle previously
unhandled errors returned from transfer_request().
NOTE: in general, unhandled errors will now result in
RESULT_UPDATE_FAILED. Previously, unhandled errors in
transfer_request() would result in RESULT_CONNECTION_LOST
which might or might not be over-written with another
result later.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Currently, LwM2M firmware download only supports coap2http proxy.
Let's add support for coap2coap proxy as well.
This was tested running Californium demo app cf-proxy on the host
machine with the following setting changed in Californum.properties:
MAX_RESOURCE_BODY_SIZE=524288
Add the following to the samples/net/lwm2m_client/prj.conf:
CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_SUPPORT=y
CONFIG_LWM2M_FIRMWARE_UPDATE_PULL_COAP_PROXY_ADDR="coap://[2001:db8::2]:5682"
Build the sample for qemu_x86 as you would normally, but now
you can use a real world coap address to pull firmware using the 5/0/1
resource. The host machine running cf-proxy will pull the remote
resource and then deliver it to the running qemu sample.
Signed-off-by: Michael Scott <michael@opensourcefoundries.com>
Update the firmware update_result accordingly by checking return
value of the firmware data write callback registered by application.
Also, set response code according.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
Now that we can access resource data in the lwm2m subsys, let's use
the user provided firmware push buffer (5/0/0) to also store the
firmware pull data.
This way the size of the firmware pull buffer is completely up to the
application.
NOTE: This patch adds a 64 byte firmware buffer to the lwm2m_client
sample for this purpose.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
No need for 2 different defines to specify URI lengths in the source
for firmware pull method. Let's combine them.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
The existing LwM2M framework expected contiguous buffers and this
was the reason for the 384 byte buffer sizes. This was previously
a limitation of the ZoAP API. The new CoAP API doesn't have this
limitation and the LwM2M library has already been migrated to use
it.
Let's finish the process by replacing any contiguous buffer handling
with the correct net_pkt APIs to parse across multiple fragments.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Let's rename lwm2m_release_message() to lwm2m_reset_message()
and add a parameter to let the function know whether or not to
release the lwm2m_message resource back to the pool.
By adding the optional release parameter, we can keep the
lwm2m_message but reset the underlying net_pkt / net_buf resources.
This allows us to regenerate the net_pkt after determining
an error has occured. In this case, we don't want the previously
added net_pkt contents but we do want to maintain the message id,
token, etc.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
This patch moves from the ZoAP API in subsys/net/lib/zoap to
the CoAP API in subsys/net/lib/coap which handles multiple
fragments for sending / receiving data.
NOTE: This patch moves the LwM2M library over to the CoAP APIs
but there will be a follow-up patch which re-writes the content
formatter reader / writers to use net_pkt APIs for parsing
across multiple net buffers. The current implementation assumes
all of the data will land in 1 buffer.
Samples using the library still need a fairly large NET_BUF_DATA_SIZE
setting. (Example: CONFIG_NET_BUF_DATA_SIZE=384)
Signed-off-by: Michael Scott <michael.scott@linaro.org>
CoAP allows a proxy to be used when transferring data (CoAP-CoAP and/or
CoAP-HTTP) by creating request on a specific URI path and by using the
Proxy URI CoAP option. Create specific Kconfig options for the proxy
server address and port, until a parser gets implemented.
Code tested with Californium acting as CoAP proxy.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
[michael.scott@linaro.org: rebased on net_app + lwm2m_message
refactoring + firmware update changes.]
Signed-off-by: Michael Scott <michael.scott@linaro.org>
During firmware download via block-wise transfer, we can see
packets occaionally get re-transmitted (normal logic in the
pending / retry functions). However, both of these packets
end up coming through the reply handler and we should ignore
any block-wise transfer that has a current value less than
where we expect to be.
NOTE: This fixes K64F ethernet transfers where we were getting
too many packets back in the handler.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
UDP packets can be lost in heavy traffic. Normally we can handle this
with pending packet processing for packets which have not been responded
to with an ACK. However, due to the time it takes for firmware to
download via CoAP, an extra level of retries should be added.
The process works like this:
Normal pending packets will try to send 3 times fairly quickly.
If that fails, then the timeout callback is called for the firmware
download process. A retry counter is incremented and the timeout
callback perform a new packet send of the block-wise transfer
packet that is missing, until the retry counter hits a limit (3)
and then the transfer is aborted.
This allows for a longer "outage" to happen during firmware transfer
and the process can still succeed.
NOTE: This patch does not fix a current bug where the pending process
is not re-sending the packets correctly, it only makes the process
more stable with a better chance to work.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Previously, firmware support wasn't initializing the retransmit work
or the extra network packet pools. Let's fix that.
NOTE: While this fixes the setup of retransmit work, the actual
attempts to re-send packets which are pending is failing. Needs
another follow-up fix.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
1. Add handling block1 option in handle_request(). The basic idea is
to declare structure block_context at compiled time and use "token"
as a key to pick up the on-going block cotext. It should be able to
support multiple blockwise transfer concurrently
2. Use write callback implemented in lwm2m_obj_firmware to deal w/ the
update state transition and than call the callback registered by the
application
3. move default_block_size to lwm2m_engine.c to share between
lwm2m_engine and lwm2m_obj_firmware_pull
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
[michael.scott@linaro.org: rebased on LwM2M net_app changes.]
Signed-off-by: Michael Scott <michael.scott@linaro.org>
1. Parse firmware pull URI
2. Add lwm2m_firmware_get/set_update_cb() for application to register
callback. This is because we want to check the update_state before
we pass to the application
3. Add lwm2m_firmware_get/set_update_result() and
lwm2m_firmware_get/set_update_stat() to manage the state transition
as well as the sanity check
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
[michael.scott@linaro.org: rebased on net_app framework and
lwm2m_message refactoring.]
Signed-off-by: Michael Scott <michael.scott@linaro.org>
