When using Leshan REST API to perform a discover OP on a client, only an
accept field is sent with "application/link-format". Current logic uses
the content-type to determine when a discover OP is indicated. Let's
handle this case as well.
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>
Don't use names like "strlen" for parameters. Try and name buffer
parameters consistently.
NOTE: For several functions I removed "const" flag. This is
intentional and will be needed in upcoming patches.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
".well-known/core" is mainly used with method GET for performing the
resource discovery (RFC 6690). Since we are implementing a LwM2M client
and is not implement a resource directory which allow others to do the
resource registration (POST to .well-known/core). Only GET method is
allowed for the usage. Report 4.5 (Method Not Allowed) if other methods
are requested.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
Modify zoap_options_to_path() to return error when URI contains
character other than digits and return 4.04 NOT FOUND to caller.
PATH such as "/1a/2/3" was treated as "/1/2/3" after parsring
which is incorrect.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
Return 4.05 Method Not Allowed when path is empty ('/') to the
caller for it's only use by bootstrap delete. This change also avoid the
empty path being treated as request targeted at 0/0/0.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
1) Respond NOT FOUND to caller when object doesn't exist
2) Report as internal server error when OP not handled
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
When a packet expires after the pending retries we call
lwm2m_release_message() to free up resources. This includes
cleanup of the pending structure which calls net_pkt_unref on
the pending packet. This would normally free up the packet
memory. However, earlier in the pending processing we add a ref
to the packet so that normal send processing doesn't free up
the memory. This meant we were leaking packet memory every
time we had an expiration due to timeout.
Let's do an unref prior to calling lwm2m_release_message() to
make sure the packet memory is freed correctly.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Create an internal function lwm2m_engine_context_init() which sets
the extra packet pools and initializes retransmit work internal to
the LwM2M engine.
This function will be used by firmware pull support which establishes
a new LwM2M context for downloading firmware.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
In the case of a proxy server translating HTTP -> COAP (known in
the code as "separate reply"), we were leaking lwm2m_message structures.
This was due to pending objects being cleared out during the first ACK,
and no other way of finding a matching message when the follow up packet
was received. Let's add a second match for reply to make sure we can
find our matching message resources.
NOTE: This change renames find_msg_from_pending() to find_msg() and
makes it a static function as it's only used by the lwm2m_engine.
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>
OPAQUE resource type might/might not have data_ptr/data_len setup
depending on the implementation. This introduce an issue that when
OPAQUE resource is written from the server side, the ones w/ none
setup will not be able to get the data at post_write_cb()
Modify to setup data_ptr/data_len as incoming buffer and buffer size
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
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>
Instead of using a magic reference to 8 for token length, let's
establish a define for MAX_TOKEN_LENGTH and then use it for both
variable definitions and to make sure tokens are valid. Also,
Correct the handling of a special token length value (0xFF) which
lets lwm2m_init_message() know to skip token generation. We were
using a -1 value here previously (on a u8_t variable).
Signed-off-by: Michael Scott <michael.scott@linaro.org>
This is the first part of a large refactoring of LwM2M library
message functions and will simplify observer handling later.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
All throughout the LwM2M library we use sockaddr values which are
basically the same as the net_app_ctx's remote addr. There's no
reason to keep these extra sockaddr values around. The net_app
framework client won't accept incoming requests on sockaddr other
than the one we're connected to.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
This is the final stage of moving the LwM2M library internals to
the net_app APIs. This means we can support DTLS and other
built-in features in the future. All of the logic for
establishing the network connection is removed from the sample
app.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
In preparation for the move to net_app APIs, we will need
to pass net_app_ctx structures around to the following
functions:
lwm2m_udp_sendto()
udp_request_handler()
Let's add the parameter as net_context for now so the
transition will be smoother later.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
This allows use to associate easily the replies / pending operations
with a specific network connection.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
The LwM2M library does not use net_app APIs internally. To help
this effort let's establish a user facing structure "lwm2m_ctx"
(similar to http_client_ctx and mqtt_ctx) and start it off by
wrappering the net_context structure.
Future patches will add user setup options to this structure and
eventually remove the net_context structure in favor of a net_app_ctx.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
We did not check the requested object/object instance/resource exists or
not before we adding an observer. Correct it by checking the existence
first.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
We should stop sending out notification to the peer when the
object/object instances requested to be observed is removed
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
We were using sys_slist_remove() to remove object, object instance and
observer w/o passing the previous sys_snode_t to it (NULL).
This will instruct the function to treat the node as the list head and
result in unexpected behavior after the removal.
Correct it by using sys_slist_find_and_remove() or passing the previous
node to the function.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
When a request demands to create a new object instance, it will search
whether the request object instance exists or not. However, current
implementation does not reset the lwm2m_engine_obj_inst at the time it
is deleted. It only removes the object instance from the sys list.
Correct the behavior by resetting both object instance and resource
instances at the time it's deleted. Also, consolidate function
lwm2m_delete_handler() and lwm2m_delete_obj_inst().
To reproduce the issue, try to create light control object instance
(/3301), delete the created instance and create it again. You shall find
following error message dumped.
> [ipso_light_control] [ERR] light_control_create: Can not create
instance - already existing: 0
> [lib/lwm2m_engine] [ERR] lwm2m_create_obj_inst: unable to create obj -
3311 instance 0
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
Per LwM2M spec (7.3.2.4 Operation on Object):
"If the payload (New Value) conveys an Object Instance ID in conflict
with one already present in the LwM2M Client, the complete request
MUST be rejected and a "Bad Request" error code MUST be sent back."
Let's do that.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
Prior to this patch, a CREATE operation was handled as a WRITE operation
after the object instance was created. This becomes problematic when
handling of optional resources differs between these 2 operations.
Let's introduce an actual CREATE operation and use it later to create
these differences.
Signed-off-by: Michael Scott <michael.scott@linaro.org>
POSIX requires struct sockaddr's field to be named "sa_family"
(not just "family"):
http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/socket.h.html
This change allows to port POSIX apps easier (including writing
portable apps using BSD Sockets compatible API).
Signed-off-by: Paul Sokolovsky <paul.sokolovsky@linaro.org>
Per LwM2M specification 5.3.1 Register, report "ct=11543" when JSON is
supported. Also, report the resource type as rt="oma.lwm2m" when "ct="
presents.
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
Per LwM2M specification 5.3.1 Register. When object instances are
available, object ID can be ignored in registration message
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
According to LwM2M specification 5.2.7.3 Bootstrap DISOCVER,
security object is only reported to the bootstrap server.
Correct the behavior to (1) report server object to the server
(2) do not report security object at registration time
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
1. According to the specification 5.3.1, it's a MUST to specify
(1) content format: app link format (2) supported lwm2m version.
Also, we should use text/plain instead of LWM2M's (obsolete).
2. Use LWM2M_FORMAT_OMA_TLV as default accept format when accept option
is not given from the caller for TLV is a MUST have in LwM2M spec and
it can deals w/ multiple resources read
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
Save in observe_node_data so that later on we can select the correct
content format requested by the caller at the first time
Signed-off-by: Robert Chou <robert.ch.chou@acer.com>
sprint_token is only used by SYS_LOG_DBG, so only build it when
CONFIG_SYS_LOG_LWM2M_LEVEL > 3.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Separate response can happen when handling block transfer for firmware
updates, and to avoid duplicating the lwm2m_udp_receive function, create
and additional flag to allow handling CoAP separate response messages.
This is required to avoid removing the reply callback, since a new
message (with a valid token) will be received later from the server.
Signed-off-by: Ricardo Salveti <ricardo.salveti@linaro.org>
Simplifly net_context_sendto calls and also allows to easily debug every
send/receive lwm2m call.
Signed-off-by: Ricardo Salveti <ricardo.salveti@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>
