Debugging IPv6 Neighbor Discovery issues requires to enable full IPv6
logs, which can get bloated given it provides logs for every single
packet. We should be able to focus on IPv6 ND logs only, hence introduce
a separate log module for IPv6 ND.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When we receive Router Advertisement with life time,
we will add this as default router, like typing command "net iface"
and has show below
IPv6 default router :
fe80:xxxx::xxxx
When this default router is backend A and
we ping backend B with link local address,
we will use default router A and send echo request
to backend A instead of B, which will receive Redirect and no reply.
Fix it by link local address does not check route.
Signed-off-by: Fengming Ye <frank.ye@nxp.com>
This is not used by anyone, and is unlikely to be useful actually.
Helps to save 4 bytes for each instance of struct net_nbr also (removing
a 2 bytes attributes, which was anyway generating a 4bytes loss due to
structure misalignment).
Removing relevant useless functions related to it as well.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Currently, the only thread-safe part of the IPv6 Neighbor processing
implementation are stale_counter related operation.
Fix this, by extending the mutex protection over all of the module, so
that message handlers, timers and API functions do not interfere with
each other.
As IPv6 Neighbor cache is tightly coupled with the Routing module, use
the same mutex to protect both, neighbor and routing tables, to prevent
deadlocks.
Also, replace the semaphore used with a mutex, as it seems more fit for
this particular job.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This commit introduces a new IPv6 API for positive reachability
confirmation, as specified in RFC 4861, Section 7.3.1. This feature aims
to enhance the effectiveness of the Neighbor Discovery mechanism, by
enabling upper-layer protocols to signal that the connection makes a
"forward progress".
The implementation within TCP serves as a reference. Compliance with
RFC 4861, especially Appendix E.1, was ensured by focusing on reliable
handshake and acknowledgment of new data transmissions.
Though initially integrated with TCP, the API is designed for broader
applicability. For example, it might be used by some UDP-based protocols
that can indicate two-way communication progress.
Signed-off-by: Łukasz Duda <lukasz.duda@nordicsemi.no>
Silently drop the IPv6 Neighbor Advertisement if we receive it
for an unknown neighbor or if there some some issue in the packet.
Returning error here would cause the ICMP module to print an
actual error which just pollutes the log without any apparent
benefit.
Fixes#66063
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The net_if_ipv6_set_hop_limit() API was missing the "_if_"
part in it. Fix this so that the network interface API is
consistent. The old function is deprecated and should not
be used. The old function is left to the code and it calls
the new properly named function.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
A minor overlook from the recent ICMP rework, the registered handlers
should no longer unref the processed packet as it's now the
responsibility of the ICMP module.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In net_pkt structure couple of flags are no longer used.
Flag pkt_queued can be removed permanently togeter with setter
and getter functions.
Second flag sent_or_eof has been renamed because it is still
used partially only for indicating EOF. Additionally unused setter
and getter for 'sent_' part of this flag are removed.
Signed-off-by: Marcin Gasiorek <marcin.gasiorek@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>
Handle RA RDNSS and use the first DNS server fetched. This is needed
when building IPv6 only without static DNS server IP addresses.
This implementation does not handle the lifetime, because the current
resolve logic does not have support for a DNS server lifetime.
Signed-off-by: Stig Bjørlykke <stig.bjorlykke@nordicsemi.no>
This mirrors the behaviour of MLD packets, the only other ICMPv6 subtype
that is tracked separately.
Inbound ND packets are already counted as received ICMP packets by way of
going through the ICMP receive path.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
This caused outgoing MAC address lookups to count as one received and two
sent Neighbour Discovery packets, when it's really one sent Neighbour
Solicitation and one received Neighbour Advertisement.
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
Zephyr doesn't seem to allow on adding route to the device from
which it received Router Advertisement without SLLAO field set
(in particular device that doesn't include Link Layer address).
Changes done:
* Added creating new NBR without Link Layer address set on RA
reception (LL is added only if SLLAO option is set, otherwise
NBR doesn't have LL address, but exists in the table and has
valid IPv6 link local address).
* Removed two asserts preventing from adding route to the NBR
that doesn't have Link Layer address set.
Signed-off-by: Kamil Kasperczyk <kamil.kasperczyk@nordicsemi.no>
Logging v1 has been removed and log_strdup wrapper function is no
longer needed. Removing the function and its use in the tree.
Signed-off-by: Krzysztof Chruscinski <krzysztof.chruscinski@nordicsemi.no>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Implement a concept of Route Preference, as specified in RFC 4191. The
Zephyr host will prefer routes with higher preference, if they lead to
the same prefix through different neighbours.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Add support for route lifetime, as defined in RFC 4191. The existing
route adding logic remains the same, if not specified, lifetime is set
to infinite. For routes added with Route Info option from ICMPv6 RA
message, set the expiration timer, according to the route lifetime value
received.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
This commits adds handling of the Route Information option from
the Router Advertisement message. This option allows to add/delete
routes in the host based on the information sent by the router.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Replace unpacked in6_addr structures with raw buffers in packed icmpv6
structs, to prevent compiler warnings about unaligned access.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Replace unpacked in6_addr structures with raw buffers in net_ipv6_hdr
struct, to prevent compiler warnings about unaligned access.
Remove __packed parameter from `struct net_6lo_context` since the
structure isn't really serialized.
Signed-off-by: Robert Lubos <robert.lubos@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>
Replace all existing deprecated API with the recommended alternative.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Add infrastructure to allow user to configure the system so that
all the network packets, that are sent to or received from a specific
network interface, are sent to remote system for analysis.
The captured network packets are placed as a payload in UDP packet,
which is then sent inside a tunnel to a remote host. The host can
then receive the packets and for example show them in wireshark.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Currently there is no way to distinguish between a caller
explicitly asking for a semaphore with a limit that
happens to be `UINT_MAX` and a semaphore that just
has a limit "as large as possible".
Add `K_SEM_MAX_LIMIT`, currently defined to `UINT_MAX`, and akin
to `K_FOREVER` versus just passing some very large wait time.
In addition, the `k_sem_*` APIs were type-confused, where
the internal data structure was `uint32_t`, but the APIs took
and returned `unsigned int`. This changes the underlying data
structure to also use `unsigned int`, as changing the APIs
would be a (potentially) breaking change.
These changes are backwards-compatible, but it is strongly suggested
to take a quick scan for `k_sem_init` and `K_SEM_DEFINE` calls with
`UINT_MAX` (or `UINT32_MAX`) and replace them with `K_SEM_MAX_LIMIT`
where appropriate.
Signed-off-by: James Harris <james.harris@intel.com>
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>
-Wimplicit-fallthrough=2 requires a fallthrough comment or a compiler
to tells gcc that this happens intentionally.
Signed-off-by: Flavio Ceolin <flavio.ceolin@intel.com>
Current implementation of net_ipv6_send_rs() uses
net_ipv6_addr_create_ll_allnodes_mcast() for creating RS packet.
As result we send RS packet to all-nodes destination [FF02::1],
but RFC4291 requires all-routers destination [FF02::2] for RS packets.
Signed-off-by: Eug Krashtan <eug.krashtan@gmail.com>
This change fixes routing for routes when the nexthop is a link-local
address of a connected peer.
The issue was that nexthop was correctly set from the routes, but the
code did not detect that the nexthop address (link local of the pc on
ppp interface) was on the ppp interface, because
net_if_ipv6_addr_onlink() only evaluated the network prefix and not
any other information (like the nbr list).
Signed-off-by: Christian Taedcke <christian.taedcke@lemonbeat.com>
The Router Advertisement can have prefix option. It's length
is 4 but the code did not check that which meant that we could
accept malformed packet. See RFC 4861 chapter 4.6.2 for details.
Fixes#25694
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
When we are about to send a NS, we should not use the destination
address as that is typically the multicast address. We should use
the target address instead.
This fixes the case where a neighbor is in incomplete state, and
we send a neighbor solicitation to find out whether the neighbor
is reachable. In this case the destination address is the solicited
node multicast address which is no use when trying to figure out
the source address.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This commit fixes a problem where our own IP address
is added to the cache instead of the senders.
This bug was due to a swap of the address in the original packet.
The swapping of the address is now removed.
Signed-off-by: Alexander Wachter <alexander@wachter.cloud>
A neighbor solicitation packet for an address that is not ours should
not cause the sender to be added to the neighbor cache. See RFC 4861
section 7.2.3.
Add the neighbor to the cache when we have decided to respond to the
NS packet.
Fixes#21869.
Signed-off-by: Jonas Norling <jonas.norling@greeneggs.se>
Use the same code when parsing source link-layer address option for
both RA and NS packets. It looked like handle_ns_neighbor() could
actually read too much data into lladdr.addr when handling 8-byte
addresses (802.15.4).
Signed-off-by: Jonas Norling <jonas.norling@greeneggs.se>
Setting it to UINT32_MAX, as it is subsequently overwritten with
MIN(oldest, something_else).
Signed-off-by: Piotr Zierhoffer <pzierhoffer@antmicro.com>
This commit changes the Link-Layer Address Option length calculation
from hardcoded values to a numerical rounding up to full 8.
The length is calculated according to rfc4861 section 4.6.1.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
The network to host byte order conversion is actually in place
on the network buffer. This prevents the reuse and forwarding of
RA packets. This commit uses temporary variables instead.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
Take the targer link layer address option link laxer addres lenght
from net packets source addres instead if the interface.
This is usefull for 6LoCAN border translator (6LoCAN to Ethernet).
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
This commit is an implementation of 6LoCAN, a 6Lo adaption layer for
Controller Area Networks. 6LoCAN is not yet standardised.
Signed-off-by: Alexander Wachter <alexander.wachter@student.tugraz.at>
This reduces the size of struct net_if_ipv6 by 24 bytes by moving
the k_delayed_work attribute into net_if core code.
Then each net_if_ipv6 can be added to the timer handler via a slist.
This does not make much gain if the system has only 1 network interface
It starts to be interesting if it has 2+ network interfaces then.
Fixes#8728
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Provide access functions for manipulating network interface flags.
There is no need for the caller of this API to know about the inner
details of the flags.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This patch fixes following issues.
* If IPv6 neighbor table is full, stack can not add any new
neighbors. So stale counter is introduced. Whenever neighbor
enters into STALE state, stale counter will be incremented
by one. When table is full and if stack wants to add new
neighbor, oldest neighbor in STALE state will be removed
and new neighbor will be added.
* When neighbor is in PROBE state and when it exceeds max
number of PROBEs, only neighbor with router is removed.
As per RFC 4861 Appendix C, entry can be discarded. Now
neighbor will be removed from the table.
* Reachability timer has an issue. e.g. if a first entry timer
is 10 seconds, after 3 seconds, a new entry added with
only 3 seconds. But current implementation does not check
whether remaining time of current left over timeout is more
than new entry timeout or not. In this example, when new entry
timeout is 3 seconds, left over timeout from first etnry is
still 7 seconds. If k_delayed_work_remaining_get() returns
some value then new entry time out was not considered.
Which is bad. It fixed now.
* nbr_free is used sometimes to remove the neighbor. Which does
not remove route if that particulat neighbor is route to some
other neighbor. net_ipv6_nbr_rm() should be used in such places.
* Trivial changes which does not affect functionality.
Fixes#14063
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
