Add an option to force close the LwM2M connection
instead of always trying to deregister.
If on a cellular connection and the connection is dropped,
deregistering will never complete and take a long time
before retries fail. This option allows the app to close the
socket and quickly re-establish the connection when the
network connection is available again.
Signed-off-by: Ryan Erickson <ryan.erickson@lairdconnect.com>
If blockwise transfer is not in use it must be possible to send bigger
CoAP messages than what is the block size used with blockwise transfers.
To compensate for the increased memory usage number of in-flight packets
allowed could be decreased.
Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
...range for LWM2M_COAP_BLOCK_SIZE.
The range has been set to start from 64 bytes and now the help text has
been brought up to date.
Signed-off-by: Veijo Pesonen <veijo.pesonen@nordicsemi.no>
Support DNS-SD Service Type Enumeration in the dns_sd library
and mdns_responder sample application.
For more information, please see Section 9, "Service Type
Enumeration" in RFC 6763.
https://datatracker.ietf.org/doc/html/rfc6763Fixes#38673
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
According to `sendmsg()` man pages, the `struct msghdr` can contain
empty records (iov_len equal to 0). Ignore them in TLS `sendmsg()`
implementation to avoid unnecessary calls to mbed TLS.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case zsock_sendmsg did not send all of the data requested, update the
`struct msghdr` content and retry.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
If data for `context_sendto()` was provided in a form of
`struct msghdr` (for instance via `sendmsg()`), it was not verified that
the provided data would actually fit into allocated net_pkt. In result,
and error could be returned in case the provided data was larger than
net_pkt allows.
Fix this, by verifying the remaining buffer length when iterating over
`struct msghdr`. Once the buffer is filled up, break the loop. In
result, functions like `sendmsg()` will return the actual length of data
sent instead of an error.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When creating a socket, all of the registered socket implementation are
processed in a sequence, allowing to find appropriate socket
implementation for specified family/type/protocol. So far however,
the order of processing was not clearly defined, leaving ambiguity if
multiple implmentations supported the same set of parameters.
Fix this, by registering socket priority along with implementation. This
makes the processing order of particular socket implementations
explicit, giving more flexibility to the user, for example when it's
neeed to prioritze one implementation over another if they support the
same set of parameters.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
As with IPv6, the mdns and llmnr responders should join their multicast
groups for IPv4 instead of just adding the multicast address to the
interface.
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
As per #38352, we would like to start building out PTP (IEEE 1588)
support for superset of gPTP functionality in Zephyr. This is the first
step to abstract away some key interfaces from NET_GPTP umbrella to
NET_L2_PTP.
Signed-off-by: Alex Sergeev <asergeev@carbonrobotics.com>
RFC 2460 Sec. 5 requires that a ICMPv6 Time Exceeded message is sent
upon reassembly timeout, if we received the first fragment (i.e. the one
with a Fragment Offset of zero).
Implement this requirement.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The purpose of shift_packets() is to make room to insert one fragment in
the list. This is not what it does currently, potentially leading to
-ENOMEM even if there is enough free room.
To see the current behaviour, let's assume that we receive 3 fragments
in reverse order:
- Frag3(offset = 0x40, M=0)
- Frag2(offset = 0x20, M=1)
- Frag1(offset = 0x00, M=1)
After receiving Frag3 and Frag2, pkt[] will look like:
.-------.-------.-------.
| Frag2 | Frag3 | NULL |
| 0x20 | 0x40 | |
'-------'-------'-------'
pkt[0] pkt[1] pkt[2]
When receiving Frag1, shift_packets(pos = 0) is called to make some room
at position 0. It will iterate up to i = 2 where there is a free
element. The current algorithm will try to shift pkt[0] to pkt[2], which
is indeed impossible but also unnecessary. It is only required to shift
pkt[0] and pkt[1] by one element in order to free pkt[0] to insert
Frag1.
Update the algorithm in order to shift the memory only by one element.
As a result, the ENOMEM test is only simpler: as long as we encounter
one free element, we are guaranteed that we can shift by one element.
Also assign a NULL value to the newly freed element since memmove() only
copy bytes.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently net_ipv6_handle_fragment_hdr() performs 2 distinct tests: it
checks the M-bit of the most recent fragment to decide if we can proceed
with the reassembly. Then it performs some sanity checks which can lead
to dropping the whole packet if not successful.
The test on the M-bit assumes that fragments arrive in order. But this
will fail if packets arrive out-of-order, since the last fragment can
arrive before some other fragments. In that case, we proceed with the
reassembly but it will fail because not all the fragments have been
received.
We need a more complete check before proceeding with the reassembly:
- We received the first fragment (offset = 0)
- All intermediate fragments are contiguous
- The More bit of the last fragment is 0
Since these conditions can also detect a malformed fragmented packet, we
can replace the existing sanity check that is performed before
reassembly. As a bonus, we can now detect and rejected overlapping
fragments, since this can have some security issues (see RFC 5722).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently we only store the fragment offset. But in some cases it might
be necessary to also inspect the M-bit (More Fragment) of all received
fragments.
Modify the semantics of the field to store all the flags, rename the
setter to account for this change, and add a getter for the M-bit.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The special handling of the 1st fragment in unnecessary, since it will
be correctly handled even without it. Moreover it causes some corner
cases, like a single packet with a fragment header (M=0), to be
incorrectly handled since the reassembly code is skipped.
Remove the special handling of the 1st fragment to fix these problems.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently the requirement of the length being a multiple of 8 is not
tested for the first fragment, since the first fragment takes a
different path due to the goto.
Move the test earlier in the process, so that it is performed on all
fragments, including the first one.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
If we have less fragments than what can be stored in the reassembly
array, some loops will blindly dereference NULL pointers.
Add checks for NULL pointers when necessary and exit the loop.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently the stack is limited to a maximum of 2 incoming fragments per
packet. While this can be enough in most cases, it might not be enough
in other cases.
Make this value configurable at build time.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently prev_hdr_offset always equals 6, which is the offset of
the nexthdr field in the IPv6 header. This value is used to overwrite it
when removing an IPv6 Fragment header, so it will work as long as there
is no other Extension header between the IPv6 header and the Fragment
header.
However this does not work in the other cases: the nexthdr field of the
IPv6 header will be overwritten instead of the nexthdr field of the last
Extension header before the Fragment, leading to unwanted results.
Update prev_hdr_offset so that it always point to the nexthdr field of
the previous header, either the IPv6 header or an Extension header.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The current validation code waits to process the header before rejecting
it, while some checks can be already enforced when reading the nexthdr
field of the previous header.
The main problem is a wrong pointer field in the resulting ICMPv6 error
message: the pointer should have the offset of the invalid nexthdr
field, while currently it will the offset the invalid header.
To solve that problem, reorganize the loop in two parts: the first
switch validates nexthdr, while the second switch processes the current
header. This allows to reject invalid nexthdr earlier.
The check for duplicated headers is also generalized, so that we can
catch other kind of headers (like the Fragment header).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
By definition, NET_IPV6_NEXTHDR_NONE is void. So we must stop processing
before trying to read any data, since we will start reading values that
are outside the Extension Header (likely the payload, if any).
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
When an unknown option is encountered, an ICMPv6 error message must be
sent in some cases. The message contains a pointer field, which must be
the offset to the unknown option. Currently the offset is computed from
the beginning of the option list, while it should be computed with
respect to the beginning of the IPv6 header.
Record the offset when reading the option type and pass it later to
ipv6_drop_on_unknown_option() to correctly set the pointer field. Also
rename the argument in ipv6_drop_on_unknown_option() to make the
purpose more clear.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Currently PADN data are not skipped, which results in the stack to think
that the next header starts in the middle of the padding. We have to
skip the bytes before going on.
Also clarify the PAD1 does not have any length field.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
The current names are confusing. Indeed "nexthdr" if the type of the
header currently processed, while "next_nexthdr" is the nexthdr field of
the current header.
Rename them to improve readability and make it less error-prone.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
ICMPv6 error messages are not sent (on native_posix) because the first
net_pkt_write() returns an error.
pkt has just been allocated using net_pkt_alloc_with_buffer(). Trying to
write an empty packet in overwrite mode will result in an error. There
is no need to be in overwrite mode, since we want to write the LL
src/dst addresses at the beginning.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Refactor IPv4 multicast address to MAC multicast address conversion
into its own function, so it can be reused by drivers as it is already
possible for IPv6 multicast addresses.
Signed-off-by: Markus Fuchs <markus.fuchs@ch.sauter-bc.com>
In case LwM2M server or bootstrap server rejected
Registration/Registration Update/Deregsitration attempt, there were no
reasonable notification to the application. Fix this by reporting
LWM2M_RD_CLIENT_EVENT_*_FAILURE in such case.
Addtitionaly, remove pointless ENGINE_DEREGISTER_FAILED event, which
have no use in the state machine.
Finally, simplify the response code logging to prevent code duplication.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The Counter resource in the IPSO Push Button object was incremented
silently by the post write handler of the State resource. This prevented
the resource from being marked as updated, effectively preventing
the engine from sending notifications to observers.
Fix this, by setting the new counter value with `lwm2m_engine_set_u64()`
instead. This will update the resource value, and trigger the engine to
send notifications if needed.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
HTTP_DATA_FINAL was incorrectly notified in case Content Length field
was present in the HTTP respone - in such case it was set for every
response fragment, not only the last one.
Fix this by relying on `message_complete` flag instead of
`http_should_keep_alive()` function to determine whether to notify
HTTP_DATA_FINAL or not. As the HTTP parser calls the
`on_message_complete()` callback in either case (response is chunked or
not), this seems to be a more reasonable apporach to determine whether
the fragment is final or not.
Additinally, instead of calling response callback for
`on_body`/`on_message_complete` separately, call it directly from
`http_wait_data()` function, after the parsing round. This fixes the
case when headers were not reported correctly when the provided buffer
was smaller than the total headers length, resulting in corrupted data
being reported to the user.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The helper function to conver 32-bit binary float value to
float32_value_t incorrectly identified the "hidden" bit, resulting in
invalid conversion when TLV encoding was used to write a resource
(the output value was divided by 2).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
There were several issues preventing JSON format writes to work
correctly:
1. The formatter wrongly assumed that Base Name and Relative Name values
read from the message are NULL terminated, which in result could give
invalid results when combining them.
2. The formatter wrongly assumed that Relative Name is always present,
which is not always the case. In result, it failed to parse messages,
which contained full path in their Base Name Field
3. There were no boundaries check when reading JSON variable name/value,
which could lead to buffer overflow in case malformed data was
received.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Just like plain text, JSON parser ignored leading zeros after decimal
point, giving invalid results. Fix this in a similar way as for the
plain text.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Floating point parser for plain text format was parsing floats wrongly,
ignoring leading zeros after decimal points.
Fix this, by reusing atof32() function, already avaialbe in a different
part of the engine, which did the parsing correctly.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
According to the specificaion, resources are not predefined to use 32 or
64 bit floating point numbers, but should rather accept any of them (as
indicated by the size of the TLV in the message). This lead to issues
for instance with Eclipse Leshan LWM2M server, where Leshan sent 64-bit
value, while Zephyr expected 32-bit, making it impossible to write
the resource.
Therefore, unify the float usage to 32-bit float representation and fix
the TLV parsing functions, to accept values sent as either 32 or 64 bit
float.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The `poll()` function did not report POLLHUP if the peer ended the DTLS
session, making it impossible to detect such event on the application
side.
On the other hand, TLS erroneusely reported POLLHUP along with each
POLLIN event, as the 0 returned by the `recv()` socket call was
wrongly interpreted (it was expected to get 0 in return as 0 bytes were
requested).
Fix this by introducing a helper function to process the mbedtls context
and verify if new application data is pendingi or session has ended.
Use this new function in the poll handler, instead of a socket `recv()`
call, to remove any ambiguity in the usage, for both TLS and DTLS.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Notify the application when DTLS client session ends by returning
ENOTCONN on such event. Additionally, reset the mbed TLS session
structures, allowing to reinstante the session on the next send() call.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
ECONNABORTED was returned in case tls_mbedtls_reset() function for
resetting session failed, which can be caused by memory shortage. Return
ENOMEM instead.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
net_packet_socket_input() was changed to hardcode the return of
NET_CONTINUE and that caused a segmentation fault/crash in
net_core/process_data(), in cases when pkt was unreferred and
NET_OK was returned from net_conn_input()
This happened with socket combo of: AF_PACKET+SOCK_RAW+IPPROTO_RAW.
Signed-off-by: Jani Hirsimäki <jani.hirsimaki@nordicsemi.no>
The nbr_lock var actually depends on CONFIG_NET_IPV6_NBR_CACHE
(not CONFIG_NET_IPV6_ND), so move its initialization call.
Signed-off-by: Stancu Florin <niflostancu@gmail.com>
BT_SECURITY_LOW and etc. were previously renamed and are no longer
valid.
The original rename is in the following commits:
1c48757d94 (New names, deprecate old)
5f2a9ba8e4 (Remove deprecated names)
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemiconductor.no>
Since it's not possible to encode full range of 64-bit unsigned integer,
remove this type from the LwM2M implementation, and replace its uses
with 64-bit signed integer.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
As the resource values represented by the unsigned integers were casted
to integers of a corresponding size in the read handler, they were not
ecoded properly if the unsigned value was larger than the maximum
integer value of the corresponding size (i.e. they were encoded as
negative values).
Fix this by casting the unsinged value to a wider integer type, to
prevent incorrect interpratetion of the data provided. The TLV encoding
functions take care of the optimization (i. e. encoding integers on the
minimum number of bytes needed), so it should prevent bandwith waste if
the unsigned value would actually fit into the integer of the
corresponding size.
Similar case is for the write hander, where unsigned integers encoded at
8 bytes were not processed correctly. Fix this by using wider decoder as
well.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Listing a neighbour table with "net nbr" command, when a neighbour w/o
assigned link address was present, resulted in an assert condition. Add
additional check to prevent this.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
TCP state machine gets stuck in TCP_FIN_WAIT_2 state
when server responds with [ FIN, PSH, ACK ]
Fixes#37842
Signed-off-by: Nicolas Marty <nicolas.marty@zuehlke.com>
Using zsock_ in http_client instead of the POSIX API versions of the
functions allows the usage of http_client in combination with
CONFIG_POSIX_API.
Signed-off-by: Benedikt Schmidt <benedikt.schmidt@embedded-solutions.at>
