Such state needs to be set _from_ the PM API functions and not the other
way round. So if a network device driver does not support such API, it
will not be able to set the core net_if on PM state, obviously.
Currently, these functions only set/unset NET_IF_SUSPENDED flag.
More logic will be added later, to decide whether the net_if can be
actually set to suspend mode or not and also to take care of all timers
related to the interface.
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This function can be used for example by network power management
to check if the network interface can be suspended or not.
If there are network packets in transmit queue, then the network
interface cannot be suspended yet.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
We need to know whether the net_pkt was successfully placed
to transmit queue. It is possible in TX side, that the net_pkt
is already in TX queue when for example TCP packet is
re-transmitted, in which case the queue submit will fail.
This cannot happen in RX side as there are no timers involved.
It is required to check about such pending flag before trying to submit
it into the queue. Indeed, the work queue could be scheduled right after
such queuing, thus checking for the pending flag afterwards would
provide a false information.
It is unfortunate k_work_submit_to_queue() does not return anything as
it would simplify the code then.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This reverts commit 8739517107.
Pull Request #23437 was merged by mistake with an invalid manifest.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Replace all occurences of BUILD_ASSERT_MSG() with BUILD_ASSERT()
as a result of merging BUILD_ASSERT() and BUILD_ASSERT_MSG().
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
It is possible that net_pkt will disappear while we are sending
it, so save link address if we need that information.
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The code was leaking memory in TX side when there was lot of
incoming packets. The reason was that the net_pkt_sent() flag
was manipulated in two threads which caused races. The solution
is to move the sent flag check only to tcp.c.
Fixes#23246
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
The current design of the network-specific stack dumping APIs
is fundamentally unsafe. You cannot properly dump stack data
without information which is only available in the thread object.
In addition, this infrastructure is unnecessary. There is already
a core shell command which dumps stack information for all
active threads.
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
This commit updates the the IPv4 ping command to handle the ENETUNREACH
error number returned by `net_icmpv4_send_echo_request` function when
IPv4 is unavailable.
The `net_icmpv4_send_echo_request` function previously returned EINVAL
when IPv4 is unavailable and this caused the shell command to report
"Invalid IP address" even when the provided IP address is correct; this
problem was corrected by returning ENETUNREACH instead of EINVAL in the
aforementioned function.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
net_icmpv4_send_echo_request currently returns EINVAL (invalid
argument) when IPv4 is unavailable.
Since the availability of IPv4 has nothing to do with the arguments
provided to this function and the meaning of EINVAL in this case is
ambiguous, return the ENETUNREACH (network is unreachable) error
number instead.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
The TCP connection might be concurrently modified from the
TR/TX threads, so add a mutex to protect from the concurrent
modification.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
After removing the test windows, update test protocol
functions for the TTCN-3 sanity check.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
These test receive windows were used by TTCN-3 sanity check,
but it's possible to do without them.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
In order to drop dependency on a heap, drop the
test send window.
Use net_tcp_queue_data() to receive the outgoing data
from the socket layer.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
In order to drop dependency on a heap, drop the test
receive window.
The receive window was needed for TTCN-3 sanity check,
but it's possible to do without it.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
On incoming SYN+ACK, use the existing TCP connection.
This problem was overlooked earlier and was found while
testing TCP2 client side.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
In SYN_SENT check the ack number of the incoming TCP message
against our sequence number.
This problem was overlooked earlier and was found while
testing TCP2 client side.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Don't erroneously instantiate an extra TCP connection
on TCP connect.
This problem was overlooked earlier and found while testing
TCP2 client side.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
k_timer callback is executed from ISR context, which isn't
currenty compatible with Zephyr's shell implementation.
This problem was found while testing TCP2 client side.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
In order to support TTCN-3 based TCP2 sanity check,
register test inputs with net_conn_register() and adjust
test functions to account for this.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
In order to support IPv4/IPv6, work with packet through
net_pkt_ip_hdr_len(), net_pkt_ip_opts_len() which account
for IPv4/IPv6, IPv4 options and IPv6 extension headers.
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Remove temporary interception of TCP, UDP for TTCN-3 based
TCP2 sanity check.
As a part of adding IPv6 support, TCP2 will register test
callbacks/inputs with net_conn_register().
Signed-off-by: Oleg Zhurakivskyy <oleg.zhurakivskyy@intel.com>
Allocate tcp2.c endpoints before storing port numbers or addresses.
Select the IPv4 source address since net_context_create_ipv4_new()
is not currently called on packet output.
Signed-off-by: Patrik Flykt <patrik.flykt@intel.com>
NET_OFFLOAD interfaces do not handle ICMP request. Request to send ICMP
packet resulted in NULL pointer dereference in net_if_tx() later
on. Prevent that by detecting NET_OFFLOAD interfaces early in icmpv4
module.
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
If the system has more than one network interface, then it should
be possible to bind a AF_PACKET socket to each interface if the
network interface index is set when bind() is called. This was
not possible earlier as the code was always using default network
interface with AF_PACKET socket bind().
Fixes#23153
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
This option specifies the name of the client.
See https://tools.ietf.org/html/rfc2132#section-3.14
This is useful for identification when looking in DHCP lease table.
Signed-off-by: Luuk Bosma <l.bosma@interay.com>
opts_len renamed to total_opts_len in previous changes.
But it's not replaced at one place.
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
If IPv4 header options has wrong options length
(e.g. options length is more that actual data),
then parser decrements opts_len without checking
actual data length. Which crashes the network stack.
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
net_pkt_clone() initializes the original packet cursor
and clone the packet. But it doesn't restore the cursor
back to original position.
Issue noticed when mDNS resolving fails when mdns responder
is also enabled.
net_conn_input(), in case of multicast packet, connection
handler clone the packet and deliver to matching handler.
Example case: dns_resolver and mdns_responder both register
handlers for 5353 port. After first clone original packet
cursor moved back to starting position. But first cloned
packet cursor is set properly. Second time cloning makes
cursor position to set to zero. Which makes second packet
handler header unpacking goes wrong.
Fixes#21970.
Signed-off-by: Ravi kumar Veeramally <ravikumar.veeramally@linux.intel.com>
Same deal as in commit eddd98f811 ("kconfig: Replace some single-symbol
'if's with 'depends on'"), for the remaining cases outside defconfig
files. See that commit for an explanation.
Will do the defconfigs separately in case there are any complaints
there.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
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>
A memory corruption could happen in `uncompress_IPHC_header` function,
when data was moved to make place in the net buffer for the uncompressed
IPv6/UDP header.
The size of data being moved should only contain the original data size,
not incremented by the amount of space needed to expand the header,
which was already added to the net buffer size. In result, the `memmove`
operation could exceed the allocated net buffer and cause memory
corruption.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
