Current 6lo implementation is unable to deal with scattered headers
(which should not happen usually, though it's a valid use case), so
let's just fail uncompressing such packet then.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
When pushing received data to the application, check that app
was able to receive the data. If the application already closed
the socket, then we must free the received net_pkt in order to
avoid memory leak.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If we cannot allocate net_pkt or net_buf, then check this condition
properly and release other resources that were already allocated.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We need to make sure that when listening a connection establishment,
the connection gets cleared if we do not receive final ACK.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This patch brings support for AF_PACKET and SOCK_RAW type of sockets.
In net_conn_input() function the new flag has been introduced -
'raw_pkt_continue' to indicate if there are other than AF_PACKET
connections registered.
If we do not have other connections than AF_PACKET, the packet is
solely handled in net_conn_input() (or to be more specific in its
helper function - conn_raw_socket()).
Otherwise, it is passed back to net_conn_input in IPv4/6 processing.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
The new function - namely conn_raw_socket(); has been introduced to
handle raw sockets processing. Its code, up till now, only was
executed when IS_ENABLED(CONFIG_NET_SOCKETS_PACKET) was defined.
After this change it can be reused when one would like to handle
raw sockets also when CONFIG_NET_{UDP|TCP} are enabled.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Add a check to stop a multicast address to be registered multiple times.
This can happen if the application is using net_if_ipv6_maddr_add()
directly.
Tested on the existing bluetooth/ipsp sample:
<wrn> net_if: Multicast address ff02::1 is is already registered.
Signed-off-by: Fabio Baltieri <fabio.baltieri@gmail.com>
The #if statement used IS_ENABLED to check if it was defined.
IS_ENABLED will only return true if the value is 1, and false otherwise.
If the NET_TCP_MAX_SEND_WINDOW_SIZE value would be e.g. 8, then the
check would fail.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
If we receive data that is out-of-order, queue sequential
TCP segments until we have received earlier segment or a timeout
happens.
Note that we only queue data sequentially in current version i.e.,
there should be no holes in the queue. For example, if we receive
SEQs 5,4,3,6 and are waiting SEQ 2, the data in segments 3,4,5,6 is
queued (in this order), and then given to application when we receive
SEQ 2. But if we receive SEQs 5,4,3,7 then the SEQ 7 is discarded
because the list would not be sequential as number 6 is be missing.
Fixes#30364
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
As the tcp header struct can be cast to unaligned memory, mark
it as packed and access fields using UNALIGNED_GET/PUT when
needed.
Fixes#31145
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Both RS and DAD timeouts are simplified because the delay is a
constant, and by construction the list of timeouts is in increasing
time remaining.
Refactor to avoid repeating the expression that represents the time
until DAD state expires. Uniformly use unsigned operands in deadline
calculation.
Note a case where the racy idiom for retaining an existing timeout is
required in the current work API, but can be replaced with a robust
solution in the proposed new API (the reschedule API replaces any
existing pending update, but the schedule API will leave an existing
scheduled submission in place).
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The existing implementation is inconsistent in that checking for
expired routers when a timeout is processed detects end-of-life
correctly (when the remaining duration exceeds the signed maximum),
but the calculation of time remaining before expiration uses only
unsigned calculation. So when the set of routers is changed the newly
calculated timeout will not recognize routers that have expired, and
so those routers expired late. In the worst case if the only
remaining router had expired the timer may be set for almost two
months in the future.
Refactor to calculate remaining time in one place and as a signed
value. Change a function name to more clearly reflect what it does.
Avoid unnecessary race conditions in k_work API.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The net_timeout structure is documented to exist because of behavior
that is no longer true, i.e. that `k_delayed_work_submit()` supports
only delays up to INT32_MAX milliseconds. Nonetheless, use of 32-bit
timestamps within the work handlers mean the restriction is still
present.
This infrastructure is currently used for two timers with long
durations:
* address for IPv6 addresses
* prefix for IPv6 prefixes
The handling of rollover was subtly different between these: address
wraps reset the start time while prefix wraps did not.
The calculation of remaining time in ipv6_nbr was incorrect when the
original requested time in seconds was a multiple of
NET_TIMEOUT_MAX_VALUE: the remainder value would be zero while the
wrap counter was positive, causing the calculation to indicate no time
remained.
The maximum value was set to allow a 100 ms latency between elapse of
the deadline and assessment of a given timer, but detection of
rollover assumed that the captured time in the work handler was
precisely the expected deadline, which is unlikely to be true. Use of
the shared system work queue also risks observed latency exceeding 100
ms. These calculations could produce delays to next event that
exceeded the maximum delay, which introduced special cases.
Refactor so all operations that use this structure are encapsulated
into API that is documented and has a full-coverage unit test. Switch
to the standard mechanism of detecting completed deadlines by
calculating the signed difference between the deadline and the current
time, which eliminates some special cases.
Uniformly rely on the scanning the set of timers to determine the next
deadline, rather than assuming that the most recent update is always
next.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
If there are multiple interfaces a change to the timeout for one
cannot determine the correct delay until the next timeout event. That
can be determined only by checking for the next event over all
interfaces, which is exactly what's done by the timeout worker.
Refactor interface timeout configuration to just set the start time
and request time, and trigger the worker to calculate the next
scheduled event.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When a renewal occurs the client enters RENEWING, sends a request,
then sets a short timeout (about 4 s) for the response. In the common
case the response will arrive immediately, which will trigger an
attempt to reset the timer with T1 which is generally large.
However the check for updating the timer performs the update only if
the new deadline is closer than the currently set one. Thus the timer
fires at the time the RENEWING request would have been retransmitted,
and only then updates to the correct deadline (T1) for the current
machine state.
Remove the extra timeout by unconditionally setting the timeout to the
new value.
This works when there is one interface; it could be wrong if there
were multiple interfaces one of which had a closer deadline, but
multiple interfaces are mishandled anyway and will be fixed next.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When there is only a single interface the timeout infrastructure can
correctly calculate time to next event, because timeouts only occur
when an event for that interface is due. This is not the case when
multiple interfaces are present: the timeout is scheduled for the next
event calculated over all interfaces.
When calculating the next event for an interface where the timeout is
not due the current code returns the original absolute delay
associated with its current state, without accounting for the time
that has passed since the start time.
For example if interface A's T1 is 3600 s and is due at 3610, but at
3605 a timeout for interface B occurs, the contribution of A to the
delay to the next scheduled event would be 3600 rather than 5,
preventing the renewal from occurring at the scheduled time.
Fix this by replacing the boolean timed-out state with the number of
seconds remaining until the interface event will occur, and
propagating that through the system so the correct delay over all
interfaces can be maintained.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
If send_request() fails it would return UINT32_MAX as the next
timeout. Callers pass the returned value to update_timeout_work
without validating it. This has worked only because
update_timeout_work will not set a timeout if an existing timeout
would fire earlier, and the way the state is currently structured it
is likely there will be an existing timeout. However, if work thread
retransmission from REQUESTING failed the timer would not be
rescheduled, causing the state machine to stop.
A more clean solution, which matches the behavior of send_discover(),
is to return the timeout for the next transmission even in the case
when the send fails. The observed behavior is the same as if the
network, rather than the sender, failed to transport the request.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
A variable named "timeout" is used to represent the current time in
comparisons against timeouts calculated from a start time and an
interval. Since this current time is not the timeout change its name
to "now" to reduce maintainer confusion.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
If assertions are disabled the send operation would continue on to
transmit a message. Stop it from doing so.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The flag value UINT32_MAX is returned from manage_timers() when a send
operation did not succeed. This indicates that the timeout should not
be rescheduled, but because it will never replace the starting update
value UINT32_MAX-1 the check will never pass, and in cases where it
should work will be submitted to run at UINT32_MAX-1 seconds.
Fix the upper bound.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When a connection is lost the client will first attempt to renew, and
then to rebind, and finally to select. Options like gateway may have
been provided by the original connection, but not the new connection,
resulting in an inconsistent configuration for the new network.
Remove the partial state clearing when entering INIT, and expand the
state cleared when entering SELECTING to be more comprehensive.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
The start time is negative only if the interface came up in the the
first milliscond since startup; even then changing the sign of the
start is not appropriate. Presumably a left-over from signed 32-bit
timestamps.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
When needing to lock non-connection related access, use k_mutex
instead of locking irq. There is really no reason to prevent the
system from generating interrupts.
Fixes#30636
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We did not check that user has supplied network interface index
in "net stats iface <idx>" command.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Debug messages used the address of a member of the work_q structure as
an identifier; that field is not public API, so replace it with the
address of the work queue itself.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Set the RX/TX thread priorities so that if cooperative priorities
are used, then lowest priority thread will have priority -1 which
is the lowest cooperative priority. The higest net thread priority
will depend on number of traffic classes but with max value 8,
the highest priority will be -8.
If preemptive priorities are used, then highest priority thread
will have priority 0, which is the highest preemptive priority.
In this case, the lowest thread priority will be 7 if there are
8 traffic classes.
The motivation for this change is that for cooperative priorities
we want to let other cooperative priority threads to run before
networking. But if preemptive priorities are used, we want
networking threads to run reasonably often compared to other
preemptive priority threads.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If networking pre-emptive thread priorities are enabled,
then use the proper macro to enable them.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Let user to decide whether the RX/TX threads are run in either
co-operative or pre-emptive thread priority.
Default is co-operative threading.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
A cast made assumption on how data is stored.
This commit makes the following test pass on qemu_leon3:
- net.udp
Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
A cast made assumption on how data is stored.
This commit makes the following test pass on qemu_leon3:
- net.ipv6.fragment
Signed-off-by: Martin Åberg <martin.aberg@gaisler.com>
If user has enabled TCP debugging, print detailed internal TCP2
information too when user gives "net conn" command. This is useful
to have when debugging.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Comment out TCP1 specific stuff when TCP2 is enabled. This means
shuffling the code around a bit so that common code is placed at
the end. Introduce also net_tcp_foreach() function to TCP2 so that
it can be used from net-shell.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The data length is already calculated in tcp_in() so no need
to do it again in tcp_data_get(). Just pass the length to the
tcp_data_get() function.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This change adds net_context_port_in_use(), which is a simple
wrapper around net_context_check_port() and is used to check
if a particular socket is bound to a given IP address.
Fixes#29649
Signed-off-by: Christopher Friedt <chrisfriedt@gmail.com>
Do not send the original pkt in 6lo based networks as in those
the IPv6 header is mangled and we would not be able to do any
resends of the original pkt. So for 6lo networks, clone the
pkt and send it to peer. The original pkt is kept in sent list
in case we need to resend to peer.
Fixes#29771
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Track the number of dropped TCP data segments and number of dropped
TCP packets in network statistics. It is useful to see these
numbers separately.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
If the peer ACKs data when it closes the connection, update
our sequence number accordinly. The connection would eventually
be terminated but this will avoid extra resends by the peer.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
When a connection is being closed, it is possible that the application
will have a lock to net_context and TCP2 connection lock. If we then
receive a final TCP2 ACK and close the connection, the locking order
get switched and TCP2 will first try to get its own lock and then the
net_context lock. This will lead to deadlock as the locking ordering
is now mixed.
The solution is to unref the TCP connection after releasing the
connection lock. The TCP connection unref function will anyway get the
lock so no need to do double locking.
Fixes#29444
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
