Modify the signature of the k_mem_slab_free() function with a new one,
replacing the old void **mem with void *mem as a parameter.
The following function:
void k_mem_slab_free(struct k_mem_slab *slab, void **mem);
has the wrong signature. mem is only used as a regular pointer, so there
is no need to use a double-pointer. The correct signature should be:
void k_mem_slab_free(struct k_mem_slab *slab, void *mem);
The issue with the current signature, although functional, is that it is
extremely confusing. I myself, a veteran Zephyr developer, was confused
by this parameter when looking at it recently.
All in-tree uses of the function have been adapted.
Fixes#61888.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
If network interface name support is enabled, print the name
when showing network interface data.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
If CONFIG_NET_INTERFACE_NAME is enabled (default is y), then
system will automatically set a user friendly name to the network
interface like eth0, wlan0 etc.
Application can change the interface name if needed.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Fix few mismatched CONTAINER_OF, few missing k_work_delayable_from_work
and a missing reference to the array first element.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
This change allows to register additional handlers for ICMPv6 so the
user can handle some of the messages between they are handled by the
ICMPv6 module in Zephyr by returning NET_CONTINUE.
Signed-off-by: Konrad Derda <konrad.derda@nordicsemi.no>
There was a corner case which was not handled well in a scenario, when
listening socket was closed during an active handshake with a new
client.
When a listening socket is closed, the accept callback is cleared on the
TCP context. If this happened during a handshake with a new client, i.
e. before final ACK from the client was processed, this lead to a
context leak, as application did not take ownership of the connection
(i. e. had no means to close it).
Fix this, by proactively closing the connection at the TCP level when no
accept_cb is available. Instead of ignoring the fact that no accept_cb
is available, the TCP stack will now enter TCP_FIN_WAIT_1 state and
proceed with a graceful teardown of the connection.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
net_iface_status is larger than scan_result, causing
net_iface events to be dropped due to info exceeding
NET_EVENT_INFO_MAX_SIZE.
Signed-off-by: Noah Luskey <LuskeyNoah@gmail.com>
ICMPv6 messages with type < 128 are error messages, where we should not
send back another error. The meaning of the code depends on the type.
Signed-off-by: Andreas Müller <andreas.mueller@husqvarnagroup.com>
When the application closes the connection, it enters the FIN1 state.
Restructure this sequence to RST on data received after the application
has closed the socket.
Next to that deal with packets that contain both data and a FIN flag.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
In case a TCP connection should be established with a specific source
IP address (e.g., by calling bind() prior to connect() on the socket),
we have to actually place the address in the outgoing packet.
Signed-off-by: Tobias Frauenschläger <t.frauenschlaeger@me.com>
Remove the shadowing ret variable and fix a bug that was related to
its existence - the shadowing ret variable was assigned with -ETIMEDOUT
which was supposed to be retuned by the function, but was not because
the ret variable at the function scope was left intact.
Also remove the unneded goto unlock; jump (assigning the error code is
the last operation before unlocking the mutex anyway).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
At the moment, NET_EVENT_IPV6_PREFIX_ADD and NET_EVENT_IPV6_PREFIX_DEL
events provide provide information about an address without its length
and lifetime.
Signed-off-by: Konrad Derda <konrad.derda@nordicsemi.no>
To allow insighed into the correct functioning of the collision avoidance,
log the internal values and function calls.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
To avoid a TCP connection from collapsing a link, implement a collision
avoidance algorithm. Initially TCP new Reno is implemented for its
simplicity.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
The TCP work queue is handles all TCP transmission and maintenance tasks.
Make it's priority configurable, so it can be configured to a lower
priority than the lower level network layers to avoid it consuming all
net_bufs before handing over execution to the lower layer network layers.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
Likely this trigger of the send_data_timer was an alternative for the
function that has been filled in by the ZWP transmission.
At the moment this timer has the potential to cause spurious
retransmissions that can degrade the throughput of the network stack.
Second to that it can accelerate the retransmission process, quickly
running to the number of retransmissions, causing a connection failure.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
At any ack, the retransmission timer was cancelled. This means when an ACK
is only partially acknowledging pending data, followed by a packet loss,
the connection ended in a deadlock eventually timing out.
By checking if there is any pending data for transmission before canceling
the retransmission timer, there is no risk of this lock-up any more.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
The IEEE 802.15.4 API and networking subsystem were using several
inconsistent timestamp resolutions and types. This change defines all
timestamps with nanosecond resolution and reduces the number of
available types to represent timestamps to two:
* `struct net_ptp_time` for PTP timestamps
* `net_time_t` for all other high resolution timestamps
All timestamps (including PTP timestamps) are now referred to a
"virtual" local network subsystem clock source based on the well-defined
types above. It is the responsibility of network subsystem L2/driver
implementations (notably Ethernet and IEEE 802.15.4 L2 stacks) to ensure
consistency of all timestamps and radio timer values exposed by the
driver API to such a network subsystem uptime reference clock
independent of internal implementation details.
The "virtual" network clock source may be implemented based on arbitrary
hardware peripherals (e.g. a coarse low power RTC counter during sleep
time plus a high resolution/high precision radio timer while receiving
or sending). Such implementation details must be hidden from API
clients, as if the driver used a single high resolution clock source
instead.
For IEEE 802.15.4, whenever timestamps refer to packet send or receive
times, they are measured when the end of the IEEE 802.15.4 SFD (message
timestamp point) is present at the local antenna (reference plane).
Due to its limited range of ~290 years, net_time_t timestamps (and
therefore net_pkt timestamps and times) must not be used to represent
absolute points in time referred to an external epoch independent of
system uptime (e.g. UTC, TAI, PTP, NTP, ...).
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
Add new net_if API functions which allow to loop over all valid
IPv4/IPv6 addresses assigned to the interface and execute a callback
function on them.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Some DHCPv4 servers do not respect BROADCAST flag set on DHCP Discover,
replying with unicast packet, making it impossible to obtain DHCP
address by Zephyr in such cases.
RFC1542 chapter 3.1.1 makes the following statement about the BROADCAST
flag:
This addition to the protocol is a workaround for old host
implementations. Such implementations SHOULD be modified so
that they may receive unicast BOOTREPLY messages, thus making
use of this workaround unnecessary. In general, the use of
this mechanism is discouraged.
Making it clear that being able to process unicast replies from the DHCP
server is not only an optional behavior, but a recommended solution.
Therefore, introduce a support for unicast DHCPv4 in Zephyr. To achieve
this, add additional filtering rule at the IPv4 level - in case DHCPv4
is enabled, there is an active query and the packet is destined for the
DHCPv4 module, let it through for the DHCPv4 module to process,
regardless of the destination IP address.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This is meant as a substitute for sys_clock_timeout_end_calc()
Current sys_clock_timeout_end_calc() usage opens up many bug
possibilities due to the actual timeout evaluation's open-coded nature.
Issue ##50611 is one example.
- Some users store the returned value in a signed variable, others in
an unsigned one, making the comparison with UINT64_MAX (corresponding
to K_FOREVER) wrong in the signed case.
- Some users compute the difference and store that in a signed variable
to compare against 0 which still doesn't work with K_FOREVER. And when
this difference is used as a timeout argument then the K_FOREVER
nature of the timeout is lost.
- Some users complexify their code by special-casing K_NO_WAIT and
K_FOREVER inline which is bad for both code readability and binary
size.
Let's introduce a better abstraction to deal with absolute timepoints
with an opaque type to be used with a well-defined API.
The word "timeout" was avoided in the naming on purpose as the timeout
namespace is quite crowded already and it is preferable to make a
distinction between relative time periods (timeouts) and absolute time
values (timepoints).
A few stacks are also adjusted as they were too tight on X86.
Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
net_if_lock() should be called only after iface pointer is verified not
to be NULL, otherwise we can end up dereferencing NULL pointer in
certain corner cases.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The management thread *barely* fits in 768 bytes of stack; when thread
local storage is in use and TLS variables are also allocated from the same
region, this stack can overflow.
Increase to 800 bytes to leave plenty of room for TLS variables.
Signed-off-by: Keith Packard <keithp@keithp.com>
The additional hooks provide infrastructure to construct
rules on another network stack levels. Main benefit of this
approach is packets are pre-parsed and e.g. IP filter is
easier to implement. These hooks are equivalent of prerouting
and local_in in linux's netfilter.
Signed-off-by: Marcin Gasiorek <marcin.gasiorek@nordicsemi.no>
Set default offloaded interface during net_context_get() call, so that
net_context_recv() can be called before net_context_connect(). There is
already an assumption about using default network interface, so this should
not be harmful.
Fixes: 2c75070360 ("net: sockets: tcp: Fix possible race between
connect/recv")
Signed-off-by: Marcin Niestroj <m.niestroj@emb.dev>
Two different IPv6 addresses can have the same solicited node multicast
address, for example when they are derived from the same EUI-64
interface identifier during the auto-configuration process. For example,
an interface with a physical address 70:07:12:34:56:78 can have the
following:
- link-local address FE80::7207:12FF:FE34:5678
- global unicast address 2001🔢::7207:12FF:FE34:5678
Both addresses will have the same solicited-node multicast address
FF02::1:FF34:5678. Currently, if one removes the global unicast address,
the solicited-node multicast address is also removed, leaving the
link-local address out of the solicited-node multicast group. This
breaks some protocols like Neighbour Discovery.
Count how many times the solicited-node multicast address is used and
remove it only if it is not shared by any other unicast address.
Fixes#59683
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
First search for a match, then perform the removal outside the loop.
There is no functional change but this prepares for some future changes.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Move the creation of the multicast solicited node address outside the
loop. There is no functional change but it prepares for some future
changes.
Signed-off-by: Florian Vaussard <florian.vaussard@gmail.com>
Add a configuration option to set Wi-Fi as default interface and also
add an API to get first available Wi-Fi interface.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Identify the Wi-Fi capability to the networking stack and also the type
of Wi-Fi (Native vs Offloaded), this helps identifying Wi-Fi interfaces
that can be used by applications.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Wi-Fi is based on L2 Ethernet, so, all drivers are registered as
Ethernet L2, but in order to distinguish true Ethernet and Wi-Fi
devices, add a L2 type within Ethernet.
Also, handle offloaded net devices that also offload Wi-Fi.
This approach is better than adding a new Wi-Fi L2 as that would mean
invasive changes which are unnecessary.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
If the address was removed immediately after being added (e.g. because the
interface MAC address is changed on boot), it would remain in the DAD timer
list.
In one scenario, the DAD timeout would eventually fire, causing the
now-removed address to be modified, potentially causing issues that way.
In another scenario, if the interface was immediately brought back up
again with a different link-local address, this new address would reuse the
first address slot on the interface. Starting the DAD process for this new
address would lead to the same address slot being added to the DAD timer
list a second time, causing an infinite list and associated lockup during
iteration.
Always remove the address from the DAD timer list when it is removed from
the interface, not just when DAD fails.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
The `net_if` layer should not be forcing `NET_IF_LOWER_UP` to be set on
all interfaces at runtime. Because `net_init` runs relatively late by
default, this is overriding any control the driver itself may have
performed using `net_if_carrier_on/off`.
Initialise this bit at compile-time instead. As the structure is already
being initialised, this doesn't increase any footprints.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
This adds a few line use zephyr_syscall_header() to include
headers containing syscall function prototypes.
Signed-off-by: Daniel Leung <daniel.leung@intel.com>
The RSSI value in net_pkt (net_pkt_cb_ieee802154.rssi) was used
inconsistently across drivers. Some drivers did cast a signed dBm value
directly to net_pkt's unsigned byte value. Others were assigning the
negative value of the signed dBm value and again others were offsetting
and stretching the signed dBm value linearly onto the full unsigned byte
range.
This change standardizes net_pkt's rssi attribute to represent RSSI on
the RX path as an unsigned integer ranging from 0 (–174 dBm) to 254 (80
dBm) and lets 255 represent an "unknown RSSI" (IEEE 802.15.4-2020,
section 6.16.2.8). On the TX path the rssi attribute will always be
zero. Out-of-range values will be truncated to max/min values.
The change also introduces conversion functions to and from signed dBm
values and introduces these consistently to all existing call sites. The
"unknown RSSI" value is represented as INT16_MIN in this case.
In some cases drivers had to be changed to calculate dBm values from
internal hardware specific representations.
The conversion functions are fully covered by unit tests.
Fixes: #58494
Signed-off-by: Florian Grandel <fgrandel@code-for-humans.de>
In previous patch fixing this issue, I've missed the fact that offloaded
drivers would not set the context->local address, which resulted in a
regression, where the previously introduced assert would hit in
offloaded cases. Not setting laddr is not a problem in case of
offloading, as it's only used in net_tcp_connect() which would not be
reached in this case.
Therefore I propose to remove previous patch to get rid of regression.
As an alternative fix, verify the laddr just before use, so that it is
only checked when native net stack is in use.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Coverity reported, that laddr pointer used in net_context_connect()
could be passed as NULL to net_tcp_connect() where it could be
dereferenced. This is because the actual setting of laddr to a valid
address structure was only done after
net_sin/sin6_ptr(&context->local)->sin/sin6_addr verification.
In practice though, the aforementioned pointer verification would always
pass, as the bind_default() guarantee that the context->local address is
set to an unspecified address (if it hasn't been set earlier).
Therefore refactor the code a bit: replace the pointer verification
with NET_ASSERT - only to assure that we can catch regression in case
for any reason the behavior of bind_default() changes. This should also
ensure that Coverity no longer reports that laddr is NULL when reaching
net_tcp_connect().
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case TCP connection is being closed from the TCP stack, due to for
instance retransmission timeout, the stack should also switch the TCP
state to CLOSED. Otherwise, there was a risk of dereferencing the TCP
context twice, for example if the application was in active socket
send(), and tried to reschedule data transmission.
Additionally, make sure that the TCP_CLOSED state handling is a no-op
state - otherwise, there is a risk that if packets keep incoming before
the application dereferences the TCP context on its side, TCP stack
will incorrectly dereference the context for the second time from
within due to current TCP_CLOSED state logic.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
`local_addr` would only be initialized if `context->local->sin*_addr` was
non-null. However, since `context` is a fresh context object, `local_addr`
always remains at its initial value of `INADDR_ANY`, which is propagated to
the context by `net_context_bind()`.
By populating `local_addr` using the TCP endpoint, `getsockname()` now
returns the correct local address.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
Installing recv callback with net_context_recv() after
net_context_connect() left an opening for a possible race - in case the
server send some data immediately after establishing TCP connection, and
Zephyr did not manage to install the callback on time, the data would be
lost, corrupting the stream.
This can be avoided, by installing the recv callback before the
connection is triggered. As net_context_recv() called w/o timeout only
registers the callback function, it should have no negative impact. The
only change on the TCP side is when the connection is closed - in case
TCP is in connect stage, do not call the recv callback (before this
change it'd be NULL at that point).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
According to RFC768 UDP packets with zero checksum are allowed with IPv4.
Enable this by default.
For example, some routers use zero checksum in DHCP packets.
Signed-off-by: Nils Ruf <nils.ruf@endress.com>
In certain scenarios, it may be necessary to get values of additional
options from the application layer. With this patch, this can be
accomplished by registering a callback with the DHCP client.
This change has been tested using the posix build in qemu.
Signed-off-by: Matthias Breithaupt <m.breithaupt@vogl-electronic.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
