The event NET_EVENT_CAPTURE_STARTED is generated when the
capture is enabled, and NET_EVENT_CAPTURE_STOPPED when capture
is disabled.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The net_capture_pkt() does not return information what happened
to the net_pkt because the packet was always cloned. With cooked
capture we can avoid the cloning in which case we need to know
the capture status in order to unref the packet if needed.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Add support for capturing arbitrary data via the cooked mode (sll)
capture API. The actual packet capture is done using net_capture_data()
function, the packet capture infrastructure does not need any changes.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Instead of having a single config specifying the memory pool size for
variable-sized net buffers, have a separate one for TX and RX for better
configuration granularity when optimizing memory usage of the
application.
Deprecate the old configuration but use its value as a default (for now)
for the new configs. This will need to change when the config is
deleted.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The netmask should be tied to the IPv4 address instead of being
global for the network interface.
If there is only one IPv4 address specified to the network interface,
nothing changes from user point of view. But if there are more than
one IPv4 address / network interface, the netmask must be specified
to each address separately.
This means that net_if_ipv4_get_netmask() and net_if_ipv4_set_netmask()
functions should not be used as they only work reliably if there is
only one IPv4 address in the network interface.
The new net_if_ipv4_get_netmask_by_addr() and
net_if_ipv4_set_netmask_by_addr() functions should be used as they make
sure that the netmask is tied to correct IPv4 address in the network
interface.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@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>
Stop using redundant DEV_DATA/DEV_CFG macros and use dev->data and
dev->config instead.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Update the macro prototype to explicitly require the length of the
desired user data. Update all in-tree usage of this macro.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Update the macro prototype to explicitly require the length of the
desired user data. Update all in-tree usage of this macro.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
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>
