When moving to the new CoAP API, I thought we would need to parse
incoming option values longer than 12 characters.
This hasn't proven to be true, so let's remove the auto-selection of
this config. If needed user can set this option later.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Remove the RD client's stack in favor of using the engine's periodic
service to trigger RD client events. This saves 5K RAM of stack based
memory.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Let's use conservative defaults for the LwM2M library to enable
hardware with constrained resources. Users can increase where
necessary.
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>
The stack of rd client is exhausted while running lwm2m client w/ IPv6
and network log global enabled. Increase the stack size to 1536 when
NET_LOG_GLOBAL is enabled.
Detail described at #4424
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
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>
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>
With future patches we will need to parse URLs in the registration
client and firmware object. Enable it by default when LWM2M is
enabled.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Due to timeout checking the minimum lifetime must be 15 seconds,
and we're storing the lifetime as an unsigned short so set the
maximum to 65535.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Sending an lwm2m message is too difficult. It requires pending / reply
and other structures to be configured and set by various portions of
the library. There is also no way to know if a pending message ever
encounters a timeout.
Let's fix this by simplifying the internal LwM2M engine APIs for
handling lwm2m messages:
1. A user calls lwm2m_get_message(lwm2m_ctx) which returns the first
available lwm2m message from an array of messages
(total # of messages is set via CONFIG_LWM2M_ENGINE_MAX_MESSAGES).
2. Next the user sets all of the fields in the message that are
required (type, code message id, token, etc)
3. Then the user calls lwm2m_init_message(msg). This initializes the
underlying zoap_packet, pending and reply structures.
4. Once initialized, the user creates their payload in msg->zpkt.
5. When the user is ready to send, the call lwm2m_send_message(msg).
6. And if for some reason an error occurs at any point, they can free
up the entire set of structures with: lwm2m_release_message(msg).
Included in the refactoring is a timeout_cb field which can be set in
the LwM2M messages. If a pending structure ever expires the engine
will call the timeout_cb passing in the msg structure before it's
automatically released.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
IPSO Smart Objects are a set of template objects based on the LwM2M
object framework which are designed to represent standard hardware
such as temperature and humidity sensors or light controls.
Let's add a place for these objects to live as well as an initial
temperature sensor object.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Origin: SICS-IoT / Contiki OS
URL: https://github.com/sics-iot/lwm2m-contiki/tree/lwm2m-standalone-dtls
commit: d07b0bcd77ec7e8b93787669507f3d86cfbea64a
Purpose: Introduction of LwM2M client library.
Maintained-by: Zephyr
Lightweight Machine-to-Machine (LwM2M) is a protocol stack extension
of the Constrained Application Protocol (CoAP) which uses UDP
transmission packets.
This library was based on source worked on by Joakim Eriksson,
Niclas Finne and Joel Hoglund which was adopted by Contiki and then
later revamped to work as a stand-alone library.
A VERY high level summary of the changes made:
- [ALL] sources were re-formatted to Zephyr coding standards
- [engine] The engine portion was re-written due to the heavy reliance
on ER-CoAP APIs which are not compatible to the Zephyr CoAP APIs as
well as other Zephyr specific needs.
- [engine] All LWM2M/IPSO object data is now abstracted into resource
data which stores information like the data type, length, callbacks
to help with read/write. The engine modifies this data directly (or
makes callbacks) instead of all of the logic for this living in each
object's code. (This wasn't scaling well as I was implementing
changes).
- [engine] Related to the above change, I also added a generic set of
getter/setter functions that user applications can call to change
the object data instead of having to add getter/setting methods in
each object.
- [engine] The original sources shared the engine's context structure
quite extensively causing a problem with portability. I broke up the
context into it's individual parts: LWM2M path data, input data and
output data and pass only the needed data into each set of APIs.
- [content format read/writer] sources were re-organized into single
.c/h files per content formatter.
- [content format read/writer] sources were re-written where necessary
to remove the sharing of the lwm2m engine's context and instead only
requires the path and input or output data specific to it's
function.
- [LwM2M objects] re-written using the new engine's abstractions
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Michael Scott