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>
Shifting "timeout <<= conn->zwp_retries" by more then 63 bits results in
undefined behaviour.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
If a socket has DSCP set then the packets from the socket should also be
marked with appropriate priority in case traffic classes are used in
networking stack.
Signed-off-by: Krishna T <krishna.t@nordicsemi.no>
In the FIN_WAIT_1 any incoming data is dropped, but anknowledged. Add a
check to see if the data is already acknowleged to prevent double
acknowledging of the data and bringing the acknowlegde counter out of
sync. When the acknowledge counter gets out of sync, the connection will
never properly terminate any more.
Signed-off-by: Sjors Hettinga <s.a.hettinga@gmail.com>
Provide an extra struct net_if * iface parameter to
net_if_ipv*_maddr_join/leave functions, so that the corresponding
interface context, the mcast address belong to, can be locked for the
operation.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
As `net_if_get_link_addr()` returns a pointer to the link layer
structure, some extra protection is needed to prevent its contents from
being changed while accessed. Using the mutex lock associated with an
interface should do the trick.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Instead of having a single global mutex, covering, in most cases
unrelated, access to all network interfaces, introduce a separate mutex
for each network interface.
Wherever interface function operates on an individual interface context
data, use local mutex protection instead. The global mutex remains only
to protect access to shared resources (IPv4/6 context pool, timer lists
etc.).
Finally, rework the timer expiry handlers, to prevent interface
functions from being called while the global lock is held (the global
mutex has to be held when iterating over the timer list, as lists are
not thread safe). The reason for this is to avoid possible deadlock
scenario. The global mutex is sometimes being locked, while inside
interface function (protected by a local mutex), so if it was allowed
the other way as well, a deadlock could occur.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Fix possible NULL dereference at net_pkt_cursor_operate() and
resolve 'Dereference after null check' warnings from the Coverity
static code analysis.
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
Print new NET_IF_IPV6_NO_ND and NET_IF_IPV6_NO_MLD flags when
the "net iface" command is used.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add new network interface flag, which allows to disable Multicast
Listener Discovery protocol from being used on the interface. This
allows to interfaces that do not support ND (like OpenThread) to
coexist with other IPv6 interfaces.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add new network interface flag, which allows to disable Neighbour
Discovery protocol from being used on the interface. This allows to
interfaces that do not support ND (like OpenThread) to coexist with
other IPv6 interfaces.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Fix dhcpv4_create_message() dereferenced NULL return value from
net_pkt_alloc_with_buffer() in case of no memory available.
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
Fix net_ipv4_send_fragmented_pkt() dereference of NULL return value
from net_pkt_get_data() possible with non contiguous packet data.
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
The arm-clang compiler/linker does not optimize away unused function
symbols and thus will error if symbols that are referenced are not
defined. To fix this add needed ifdef'ry.
Build various network samples that utilize ethernet but don't have
CONFIG_NET_PROMISCUOUS_MODE will get a link error for:
Error: L6218E: Undefined symbol
net_mgmt_NET_REQUEST_ETHERNET_SET_PROMISC_MODE
(referred from ethernet.o).
Fix by adding ifdef protection around promisc code.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Fix tcp_send_zwp() retransmission timeout calculation to avoid sign
extension on bit shift operation: the uint16_t value was implicitly
promoted to 32-bit signed type with sign extension to uint64_t.
Signed-off-by: Dmitrii Golovanov <dmitrii.golovanov@intel.com>
Added a feature of socket connect
being asynchronous. If socket is set
to nonblock with O_NONBLOCK flag,
then connect() is non-blocking aswell.
App can normally poll the socket to
test when the connection is established.
Signed-off-by: Daniel Nejezchleb <dnejezchleb@hwg.cz>
Fixes#56657, incorrect TCP MSS calculation for IPv6.
Previously the supported MSS would incorrectly returned as the MTU if it
was less than the MTU, probably to account for the case where
the network interface MTU check returns 0.
New behaviour is to return the supported MSS as MTU minus header length,
using default MTU for this calculation if network interface MTU check
returns 0.
Signed-off-by: Kenny Johansson <wirehell@gmail.com>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
TCP packet allocation timeout is currently 100ms, but there are cases
where it is not enough and as a side effect, the kernel internals are
printing some errors on the log before retrying again, create a
Kconfig parameter to be able to tune this value.
Signed-off-by: Luca Fancellu <luca.fancellu@arm.com>
