2019-11-01 13:45:29 +01:00
|
|
|
# IP stack config
|
2016-04-29 14:52:09 +02:00
|
|
|
|
|
|
|
# Copyright (c) 2016 Intel Corporation.
|
2021-01-19 07:34:25 +01:00
|
|
|
# Copyright (c) 2021 Nordic Semiconductor
|
2017-01-19 02:01:01 +01:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
2016-05-02 09:02:04 +02:00
|
|
|
|
2016-11-11 23:13:24 +01:00
|
|
|
menu "IP stack"
|
2016-06-14 15:31:30 +02:00
|
|
|
|
2019-08-09 13:49:35 +02:00
|
|
|
config NET_NATIVE
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Native IP stack"
|
2019-08-09 13:49:35 +02:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enables Zephyr native IP stack. If you disable this, then
|
|
|
|
you need to enable the offloading support if you want to
|
|
|
|
have IP connectivity.
|
|
|
|
|
|
|
|
# Hidden options for enabling native IPv6/IPv4. Using these options
|
|
|
|
# avoids having "defined(CONFIG_NET_IPV6) && defined(CONFIG_NET_NATIVE)"
|
|
|
|
# in the code as we can have "defined(CONFIG_NET_NATIVE_IPV6)" instead.
|
|
|
|
config NET_NATIVE_IPV6
|
|
|
|
bool
|
|
|
|
depends on NET_NATIVE
|
|
|
|
default y if NET_IPV6
|
|
|
|
|
|
|
|
config NET_NATIVE_IPV4
|
|
|
|
bool
|
|
|
|
depends on NET_NATIVE
|
|
|
|
default y if NET_IPV4
|
|
|
|
|
|
|
|
config NET_NATIVE_TCP
|
|
|
|
bool
|
|
|
|
depends on NET_NATIVE
|
|
|
|
default y if NET_TCP
|
|
|
|
|
|
|
|
config NET_NATIVE_UDP
|
|
|
|
bool
|
|
|
|
depends on NET_NATIVE
|
|
|
|
default y if NET_UDP
|
|
|
|
|
|
|
|
config NET_OFFLOAD
|
2021-10-15 14:23:18 +02:00
|
|
|
bool "Offload IP stack"
|
2019-08-09 13:49:35 +02:00
|
|
|
help
|
|
|
|
Enables TCP/IP stack to be offload to a co-processor.
|
|
|
|
|
|
|
|
if NET_OFFLOAD
|
|
|
|
module = NET_OFFLOAD
|
|
|
|
module-dep = NET_LOG
|
|
|
|
module-str = Log level for offload layer
|
|
|
|
module-help = Enables offload layer to output debug messages.
|
|
|
|
source "subsys/net/Kconfig.template.log_config.net"
|
|
|
|
endif # NET_OFFLOAD
|
|
|
|
|
2017-11-16 11:11:51 +01:00
|
|
|
config NET_RAW_MODE
|
2016-09-27 14:45:09 +02:00
|
|
|
bool
|
2017-11-16 11:11:51 +01:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
This is a very specific option used to built only the very minimal
|
|
|
|
part of the net stack in order to get network drivers working without
|
|
|
|
any net stack above: core, L2 etc... Basically this will build only
|
|
|
|
net_pkt part. It is currently used only by IEEE 802.15.4 drivers,
|
|
|
|
though any type of net drivers could use it.
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2017-11-16 11:11:51 +01:00
|
|
|
if !NET_RAW_MODE
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2018-10-16 13:27:21 +02:00
|
|
|
choice
|
|
|
|
prompt "Qemu networking"
|
2019-03-26 16:26:25 +01:00
|
|
|
default NET_QEMU_PPP if NET_PPP
|
2018-10-16 13:27:21 +02:00
|
|
|
default NET_QEMU_SLIP
|
|
|
|
depends on QEMU_TARGET
|
|
|
|
help
|
|
|
|
Can be used to select how the network connectivity is established
|
|
|
|
from inside qemu to host system. This can be done either via
|
|
|
|
serial connection (SLIP) or via Qemu ethernet driver.
|
|
|
|
|
|
|
|
config NET_QEMU_SLIP
|
|
|
|
bool "SLIP"
|
|
|
|
help
|
|
|
|
Connect to host or to another Qemu via SLIP.
|
|
|
|
|
2019-03-26 16:26:25 +01:00
|
|
|
config NET_QEMU_PPP
|
|
|
|
bool "PPP"
|
|
|
|
help
|
|
|
|
Connect to host via PPP.
|
|
|
|
|
2018-10-16 13:27:21 +02:00
|
|
|
config NET_QEMU_ETHERNET
|
|
|
|
bool "Ethernet"
|
|
|
|
help
|
|
|
|
Connect to host system via Qemu ethernet driver support. One such
|
|
|
|
driver that Zephyr supports is Intel e1000 ethernet driver.
|
|
|
|
|
2020-05-06 01:56:52 +02:00
|
|
|
config NET_QEMU_USER
|
|
|
|
bool "SLIRP"
|
|
|
|
help
|
|
|
|
Connect to host system via Qemu's built-in User Networking support. This
|
|
|
|
is implemented using "slirp", which provides a full TCP/IP stack within
|
|
|
|
QEMU and uses that stack to implement a virtual NAT'd network.
|
|
|
|
|
2018-10-16 13:27:21 +02:00
|
|
|
endchoice
|
|
|
|
|
2020-05-06 01:56:52 +02:00
|
|
|
config NET_QEMU_USER_EXTRA_ARGS
|
|
|
|
string "Qemu User Networking Args"
|
|
|
|
depends on NET_QEMU_USER
|
|
|
|
default ""
|
|
|
|
help
|
|
|
|
Extra arguments passed to QEMU when User Networking is enabled. This may
|
|
|
|
include host / guest port forwarding, device id, Network address
|
|
|
|
information etc. This string is appended to the QEMU "-net user" option.
|
|
|
|
|
2016-05-09 13:31:12 +02:00
|
|
|
config NET_INIT_PRIO
|
2016-08-24 10:49:14 +02:00
|
|
|
int
|
|
|
|
default 90
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Network initialization priority level. This number tells how
|
|
|
|
early in the boot the network stack is initialized.
|
2016-05-03 07:33:34 +02:00
|
|
|
|
2016-11-11 22:46:28 +01:00
|
|
|
source "subsys/net/ip/Kconfig.ipv6"
|
2016-06-23 15:06:24 +02:00
|
|
|
|
2016-11-11 22:46:28 +01:00
|
|
|
source "subsys/net/ip/Kconfig.ipv4"
|
2016-05-17 13:13:17 +02:00
|
|
|
|
2016-12-30 13:00:55 +01:00
|
|
|
config NET_SHELL
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Network shell utilities"
|
2018-09-04 16:01:48 +02:00
|
|
|
select SHELL
|
2016-12-30 13:00:55 +01:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Activate shell module that provides network commands like
|
|
|
|
ping to the console.
|
2016-12-30 13:00:55 +01:00
|
|
|
|
2018-09-04 16:01:48 +02:00
|
|
|
config NET_SHELL_DYN_CMD_COMPLETION
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Network shell dynamic command completion"
|
2018-09-04 16:01:48 +02:00
|
|
|
depends on NET_SHELL
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Enable various net-shell command to support dynamic command
|
|
|
|
completion. This means that for example the nbr command can
|
|
|
|
automatically complete the neighboring IPv6 address and user
|
|
|
|
does not need to type it manually.
|
|
|
|
Please note that this uses more memory in order to save the
|
|
|
|
dynamic command strings. For example for nbr command the
|
|
|
|
increase is 320 bytes (8 neighbors * 40 bytes for IPv6 address
|
|
|
|
length) by default. Other dynamic completion commands in
|
|
|
|
net-shell require also some smaller amount of memory.
|
|
|
|
|
2018-02-07 14:00:08 +01:00
|
|
|
config NET_TC_TX_COUNT
|
|
|
|
int "How many Tx traffic classes to have for each network device"
|
2021-05-18 10:27:37 +02:00
|
|
|
default 1 if USERSPACE || USB_DEVICE_NETWORK
|
2020-12-01 09:23:20 +01:00
|
|
|
default 0
|
2020-12-01 09:37:56 +01:00
|
|
|
range 1 NET_TC_NUM_PRIORITIES if NET_TC_NUM_PRIORITIES<=8 && USERSPACE
|
2020-12-01 09:23:20 +01:00
|
|
|
range 0 NET_TC_NUM_PRIORITIES if NET_TC_NUM_PRIORITIES<=8
|
2020-12-01 09:37:56 +01:00
|
|
|
range 1 8 if USERSPACE
|
2020-12-01 09:23:20 +01:00
|
|
|
range 0 8
|
2018-02-07 14:00:08 +01:00
|
|
|
help
|
|
|
|
Define how many Tx traffic classes (queues) the system should have
|
|
|
|
when sending a network packet. The network packet priority can then
|
2018-04-06 00:07:00 +02:00
|
|
|
be mapped to this traffic class so that higher prioritized packets
|
|
|
|
can be processed before lower prioritized ones. Each queue is handled
|
2018-02-07 14:00:08 +01:00
|
|
|
by a separate thread which will need RAM for stack space.
|
|
|
|
Only increase the value from 1 if you really need this feature.
|
|
|
|
The default value is 1 which means that all the network traffic is
|
|
|
|
handled equally. In this implementation, the higher traffic class
|
|
|
|
value corresponds to lower thread priority.
|
2020-12-01 09:23:20 +01:00
|
|
|
If you select 0 here, then it means that all the network traffic
|
|
|
|
is pushed to the driver directly without any queues.
|
2020-12-01 09:37:56 +01:00
|
|
|
Note that if USERSPACE support is enabled, then currently we need to
|
|
|
|
enable at least 1 TX thread.
|
2018-02-07 14:00:08 +01:00
|
|
|
|
|
|
|
config NET_TC_RX_COUNT
|
|
|
|
int "How many Rx traffic classes to have for each network device"
|
|
|
|
default 1
|
2020-12-01 09:37:56 +01:00
|
|
|
range 1 NET_TC_NUM_PRIORITIES if NET_TC_NUM_PRIORITIES<=8 && USERSPACE
|
2020-12-01 09:23:20 +01:00
|
|
|
range 0 NET_TC_NUM_PRIORITIES if NET_TC_NUM_PRIORITIES<=8
|
2020-12-01 09:37:56 +01:00
|
|
|
range 1 8 if USERSPACE
|
2020-12-01 09:23:20 +01:00
|
|
|
range 0 8
|
2018-02-07 14:00:08 +01:00
|
|
|
help
|
|
|
|
Define how many Rx traffic classes (queues) the system should have
|
|
|
|
when receiving a network packet. The network packet priority can then
|
2018-04-06 00:07:00 +02:00
|
|
|
be mapped to this traffic class so that higher prioritized packets
|
|
|
|
can be processed before lower prioritized ones. Each queue is handled
|
2018-02-07 14:00:08 +01:00
|
|
|
by a separate thread which will need RAM for stack space.
|
|
|
|
Only increase the value from 1 if you really need this feature.
|
|
|
|
The default value is 1 which means that all the network traffic is
|
|
|
|
handled equally. In this implementation, the higher traffic class
|
|
|
|
value corresponds to lower thread priority.
|
2020-12-01 09:23:20 +01:00
|
|
|
If you select 0 here, then it means that all the network traffic
|
|
|
|
is pushed from the driver to application thread without any
|
|
|
|
intermediate RX queue. There is always a receive socket queue between
|
|
|
|
device driver and application. Disabling RX thread means that the
|
|
|
|
network device driver, that is typically running in IRQ context, will
|
|
|
|
handle the packet all the way to the application. This might cause
|
|
|
|
other incoming packets to be lost if the RX processing takes long
|
|
|
|
time.
|
2020-12-01 09:37:56 +01:00
|
|
|
Note that if USERSPACE support is enabled, then currently we need to
|
|
|
|
enable at least 1 RX thread.
|
2018-02-07 14:00:08 +01:00
|
|
|
|
2020-05-18 12:40:18 +02:00
|
|
|
config NET_TC_SKIP_FOR_HIGH_PRIO
|
|
|
|
bool "Push high priority packets directly to network driver"
|
|
|
|
help
|
|
|
|
If this is set, then high priority (NET_PRIORITY_CA) net_pkt will be
|
|
|
|
pushed directly to network driver and will skip the traffic class
|
|
|
|
queues. This is currently not enabled by default.
|
|
|
|
|
2020-10-06 19:22:25 +02:00
|
|
|
choice NET_TC_THREAD_TYPE
|
|
|
|
prompt "How the network RX/TX threads should work"
|
|
|
|
help
|
|
|
|
Please select the RX/TX threads to be either pre-emptive or
|
|
|
|
co-operative.
|
|
|
|
|
|
|
|
config NET_TC_THREAD_COOPERATIVE
|
|
|
|
bool "Use co-operative TX/RX threads"
|
|
|
|
depends on COOP_ENABLED
|
|
|
|
help
|
|
|
|
With co-operative threads, the thread cannot be pre-empted.
|
|
|
|
|
|
|
|
config NET_TC_THREAD_PREEMPTIVE
|
|
|
|
bool "Use pre-emptive TX/RX threads [EXPERIMENTAL]"
|
|
|
|
depends on PREEMPT_ENABLED
|
2021-10-15 14:23:18 +02:00
|
|
|
select EXPERIMENTAL
|
2020-10-06 19:22:25 +02:00
|
|
|
help
|
|
|
|
With pre-emptive threads, the thread can be pre-empted.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
2020-10-22 14:06:01 +02:00
|
|
|
config NET_TC_NUM_PRIORITIES
|
|
|
|
int
|
|
|
|
default NUM_COOP_PRIORITIES if NET_TC_THREAD_COOPERATIVE
|
|
|
|
default NUM_PREEMPT_PRIORITIES if NET_TC_THREAD_PREEMPTIVE
|
|
|
|
|
2018-08-02 13:41:24 +02:00
|
|
|
choice
|
|
|
|
prompt "Priority to traffic class mapping"
|
|
|
|
help
|
|
|
|
Select mapping to use to map network packet priorities to traffic
|
|
|
|
classes.
|
|
|
|
|
|
|
|
config NET_TC_MAPPING_STRICT
|
|
|
|
bool "Strict priority mapping"
|
|
|
|
help
|
|
|
|
This is the recommended default priority to traffic class mapping.
|
|
|
|
Use it for implementations that do not support the credit-based
|
2018-08-07 15:42:31 +02:00
|
|
|
shaper transmission selection algorithm.
|
2018-08-02 13:41:24 +02:00
|
|
|
See 802.1Q, chapter 8.6.6 for more information.
|
|
|
|
|
|
|
|
config NET_TC_MAPPING_SR_CLASS_A_AND_B
|
|
|
|
bool "SR class A and class B mapping"
|
|
|
|
depends on NET_TC_TX_COUNT >= 2
|
|
|
|
depends on NET_TC_RX_COUNT >= 2
|
|
|
|
help
|
|
|
|
This is the recommended priority to traffic class mapping for a
|
|
|
|
system that supports SR (Stream Reservation) class A and SR class B.
|
|
|
|
See 802.1Q, chapter 34.5 for more information.
|
|
|
|
|
|
|
|
config NET_TC_MAPPING_SR_CLASS_B_ONLY
|
|
|
|
bool "SR class B only mapping"
|
|
|
|
depends on NET_TC_TX_COUNT >= 2
|
|
|
|
depends on NET_TC_RX_COUNT >= 2
|
|
|
|
help
|
|
|
|
This is the recommended priority to traffic class mapping for a
|
|
|
|
system that supports SR (Stream Reservation) class B only.
|
|
|
|
See 802.1Q, chapter 34.5 for more information.
|
|
|
|
endchoice
|
|
|
|
|
2018-02-07 14:00:08 +01:00
|
|
|
config NET_TX_DEFAULT_PRIORITY
|
2019-10-08 13:58:13 +02:00
|
|
|
int "Default network TX packet priority if none have been set"
|
2018-02-07 14:00:08 +01:00
|
|
|
default 1
|
|
|
|
range 0 7
|
|
|
|
help
|
|
|
|
What is the default network packet priority if user has not specified
|
|
|
|
one. The value 0 means lowest priority and 7 is the highest.
|
|
|
|
|
2019-10-08 13:58:13 +02:00
|
|
|
config NET_RX_DEFAULT_PRIORITY
|
|
|
|
int "Default network RX packet priority if none have been set"
|
|
|
|
default 0
|
|
|
|
range 0 7
|
|
|
|
help
|
|
|
|
What is the default network RX packet priority if user has not set
|
|
|
|
one. The value 0 means lowest priority and 7 is the highest.
|
|
|
|
|
2016-11-12 12:02:27 +01:00
|
|
|
config NET_IP_ADDR_CHECK
|
|
|
|
bool "Check IP address validity before sending IP packet"
|
|
|
|
default y
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Check that either the source or destination address is
|
|
|
|
correct before sending either IPv4 or IPv6 network packet.
|
2016-11-12 12:02:27 +01:00
|
|
|
|
2016-06-10 09:31:21 +02:00
|
|
|
config NET_MAX_ROUTERS
|
2016-08-24 10:11:58 +02:00
|
|
|
int "How many routers are supported"
|
|
|
|
default 2 if NET_IPV4 && NET_IPV6
|
|
|
|
default 1 if NET_IPV4 && !NET_IPV6
|
|
|
|
default 1 if !NET_IPV4 && NET_IPV6
|
|
|
|
range 1 254
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
The value depends on your network needs.
|
2016-06-10 09:31:21 +02:00
|
|
|
|
2017-03-17 11:36:55 +01:00
|
|
|
# Normally the route support is enabled by RPL or similar technology
|
|
|
|
# that needs to use the routing infrastructure.
|
2016-09-19 14:09:37 +02:00
|
|
|
config NET_ROUTE
|
|
|
|
bool
|
2017-03-17 11:36:55 +01:00
|
|
|
depends on NET_IPV6_NBR_CACHE
|
|
|
|
default y if NET_IPV6_NBR_CACHE
|
2016-09-19 14:09:37 +02:00
|
|
|
|
2019-09-20 15:15:45 +02:00
|
|
|
# Temporarily hide the routing option as we do not have RPL in the system
|
|
|
|
# that used to populate the routing table.
|
2017-08-16 16:13:47 +02:00
|
|
|
config NET_ROUTING
|
2019-09-20 15:15:45 +02:00
|
|
|
bool
|
2017-08-16 16:13:47 +02:00
|
|
|
depends on NET_ROUTE
|
|
|
|
help
|
2018-02-15 14:36:16 +01:00
|
|
|
Allow IPv6 routing between different network interfaces and
|
2019-09-20 15:15:45 +02:00
|
|
|
technologies. Currently this has limited use as some entity
|
|
|
|
would need to populate the routing table. RPL used to do that
|
|
|
|
earlier but currently there is no RPL support in Zephyr.
|
2017-08-16 16:13:47 +02:00
|
|
|
|
2019-11-01 10:24:07 +01:00
|
|
|
config NET_MAX_ROUTES
|
2016-09-19 14:09:37 +02:00
|
|
|
int "Max number of routing entries stored."
|
|
|
|
default NET_IPV6_MAX_NEIGHBORS
|
|
|
|
depends on NET_ROUTE
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
This determines how many entries can be stored in routing table.
|
2016-09-19 14:09:37 +02:00
|
|
|
|
2019-11-01 10:24:07 +01:00
|
|
|
config NET_MAX_NEXTHOPS
|
2016-09-19 14:09:37 +02:00
|
|
|
int "Max number of next hop entries stored."
|
|
|
|
default NET_MAX_ROUTES
|
|
|
|
depends on NET_ROUTE
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
This determines how many entries can be stored in nexthop table.
|
2016-10-04 11:10:23 +02:00
|
|
|
|
|
|
|
config NET_ROUTE_MCAST
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Multicast Routing / Forwarding"
|
2016-10-04 11:10:23 +02:00
|
|
|
depends on NET_ROUTE
|
2020-08-17 15:24:46 +02:00
|
|
|
help
|
|
|
|
Activates multicast routing/forwarding
|
2016-10-04 11:10:23 +02:00
|
|
|
|
2019-11-01 10:24:07 +01:00
|
|
|
config NET_MAX_MCAST_ROUTES
|
2016-10-04 11:10:23 +02:00
|
|
|
int "Max number of multicast routing entries stored."
|
|
|
|
default 1
|
|
|
|
depends on NET_ROUTE_MCAST
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
This determines how many entries can be stored in multicast
|
|
|
|
routing table.
|
2016-09-19 14:09:37 +02:00
|
|
|
|
2016-08-24 10:49:14 +02:00
|
|
|
config NET_TCP
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "TCP"
|
2016-08-18 09:08:04 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
The value depends on your network needs.
|
2016-08-18 09:08:04 +02:00
|
|
|
|
2017-05-17 09:43:18 +02:00
|
|
|
config NET_TCP_CHECKSUM
|
|
|
|
bool "Check TCP checksum"
|
|
|
|
default y
|
|
|
|
depends on NET_TCP
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Enables TCP handler to check TCP checksum. If the checksum is invalid,
|
|
|
|
then the packet is discarded.
|
2017-05-17 09:43:18 +02:00
|
|
|
|
2018-07-06 10:35:07 +02:00
|
|
|
if NET_TCP
|
|
|
|
module = NET_TCP
|
|
|
|
module-dep = NET_LOG
|
|
|
|
module-str = Log level for TCP
|
|
|
|
module-help = Enables TCP handler output debug messages
|
|
|
|
source "subsys/net/Kconfig.template.log_config.net"
|
|
|
|
endif # NET_TCP
|
2016-08-24 10:49:14 +02:00
|
|
|
|
2017-06-28 16:33:34 +02:00
|
|
|
config NET_TCP_BACKLOG_SIZE
|
|
|
|
int "Number of simultaneous incoming TCP connections"
|
|
|
|
depends on NET_TCP
|
|
|
|
default 1
|
|
|
|
range 1 128
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
The number of simultaneous TCP connection attempts, i.e. outstanding
|
|
|
|
TCP connections waiting for initial ACK.
|
2017-06-28 16:33:34 +02:00
|
|
|
|
2018-05-11 13:17:48 +02:00
|
|
|
config NET_TCP_TIME_WAIT_DELAY
|
|
|
|
int "How long to wait in TIME_WAIT state (in milliseconds)"
|
2017-03-27 14:38:50 +02:00
|
|
|
depends on NET_TCP
|
2018-05-11 13:17:48 +02:00
|
|
|
default 250
|
|
|
|
help
|
|
|
|
To avoid a (low-probability) issue when delayed packets from
|
|
|
|
previous connection get delivered to next connection reusing
|
|
|
|
the same local/remote ports, RFC 793 (TCP) suggests to keep
|
|
|
|
an old, closed connection in a special "TIME_WAIT" state for
|
|
|
|
the duration of 2*MSL (Maximum Segment Lifetime). The RFC
|
|
|
|
suggests to use MSL of 2 minutes, but notes "This is an
|
|
|
|
engineering choice, and may be changed if experience indicates
|
|
|
|
it is desirable to do so." For low-resource systems, having
|
|
|
|
large MSL may lead to quick resource exhaustion (and related
|
2018-05-23 20:53:20 +02:00
|
|
|
DoS attacks). At the same time, the issue of packet misdelivery
|
2018-05-11 13:17:48 +02:00
|
|
|
is largely alleviated in the modern TCP stacks by using random,
|
|
|
|
non-repeating port numbers and initial sequence numbers. Due
|
|
|
|
to this, Zephyr uses much lower value of 250ms by default.
|
|
|
|
Value of 0 disables TIME_WAIT state completely.
|
2017-03-27 14:38:50 +02:00
|
|
|
|
2017-05-18 10:27:30 +02:00
|
|
|
config NET_TCP_ACK_TIMEOUT
|
|
|
|
int "How long to wait for ACK (in milliseconds)"
|
|
|
|
depends on NET_TCP
|
|
|
|
default 1000
|
|
|
|
range 1 2147483647
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
This value affects the timeout when waiting ACK to arrive in
|
|
|
|
various TCP states. The value is in milliseconds. Note that
|
|
|
|
having a very low value here could prevent connectivity.
|
2017-05-18 10:27:30 +02:00
|
|
|
|
2017-10-26 10:44:21 +02:00
|
|
|
config NET_TCP_INIT_RETRANSMISSION_TIMEOUT
|
|
|
|
int "Initial value of Retransmission Timeout (RTO) (in milliseconds)"
|
|
|
|
depends on NET_TCP
|
|
|
|
default 200
|
2017-10-31 14:57:56 +01:00
|
|
|
range 100 60000
|
2017-10-26 10:44:21 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
This value affects the timeout between initial retransmission
|
|
|
|
of TCP data packets. The value is in milliseconds.
|
2017-10-26 10:44:21 +02:00
|
|
|
|
2017-05-31 23:32:53 +02:00
|
|
|
config NET_TCP_RETRY_COUNT
|
|
|
|
int "Maximum number of TCP segment retransmissions"
|
|
|
|
depends on NET_TCP
|
|
|
|
default 9
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
The following formula can be used to determine the time (in ms)
|
|
|
|
that a segment will be be buffered awaiting retransmission:
|
|
|
|
n=NET_TCP_RETRY_COUNT
|
|
|
|
Sum((1<<n) * NET_TCP_INIT_RETRANSMISSION_TIMEOUT)
|
|
|
|
n=0
|
|
|
|
With the default value of 9, the IP stack will try to
|
|
|
|
retransmit for up to 1:42 minutes. This is as close as possible
|
|
|
|
to the minimum value recommended by RFC1122 (1:40 minutes).
|
|
|
|
Only 5 bits are dedicated for the retransmission count, so accepted
|
|
|
|
values are in the 0-31 range. It's highly recommended to not go
|
|
|
|
below 9, though.
|
|
|
|
Should a retransmission timeout occur, the receive callback is
|
|
|
|
called with -ECONNRESET error code and the context is dereferenced.
|
2017-05-31 23:32:53 +02:00
|
|
|
|
2020-09-16 16:47:26 +02:00
|
|
|
config NET_TCP_MAX_SEND_WINDOW_SIZE
|
|
|
|
int "Maximum sending window size to use"
|
2021-11-10 14:39:42 +01:00
|
|
|
depends on NET_TCP
|
2020-09-16 16:47:26 +02:00
|
|
|
default 0
|
|
|
|
range 0 65535
|
|
|
|
help
|
|
|
|
This value affects how the TCP selects the maximum sending window
|
|
|
|
size. The default value 0 lets the TCP stack select the value
|
|
|
|
according to amount of network buffers configured in the system.
|
|
|
|
|
2022-02-18 16:29:11 +01:00
|
|
|
config NET_TCP_MAX_RECV_WINDOW_SIZE
|
|
|
|
int "Maximum receive window size to use"
|
|
|
|
depends on NET_TCP
|
|
|
|
default 0
|
|
|
|
range 0 65535
|
|
|
|
help
|
|
|
|
This value defines the maximum TCP receive window size. Increasing
|
|
|
|
this value can improve connection throughput, but requires more
|
2022-03-16 22:07:43 +01:00
|
|
|
receive buffers available in the system for efficient operation.
|
2022-02-18 16:29:11 +01:00
|
|
|
The default value 0 lets the TCP stack select the value
|
|
|
|
according to amount of network buffers configured in the system.
|
|
|
|
|
net: tcp2: Queue received out-of-order data
If we receive data that is out-of-order, queue sequential
TCP segments until we have received earlier segment or a timeout
happens.
Note that we only queue data sequentially in current version i.e.,
there should be no holes in the queue. For example, if we receive
SEQs 5,4,3,6 and are waiting SEQ 2, the data in segments 3,4,5,6 is
queued (in this order), and then given to application when we receive
SEQ 2. But if we receive SEQs 5,4,3,7 then the SEQ 7 is discarded
because the list would not be sequential as number 6 is be missing.
Fixes #30364
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2020-12-22 15:14:10 +01:00
|
|
|
config NET_TCP_RECV_QUEUE_TIMEOUT
|
|
|
|
int "How long to queue received data (in ms)"
|
2021-11-10 14:39:42 +01:00
|
|
|
depends on NET_TCP
|
net: tcp2: Queue received out-of-order data
If we receive data that is out-of-order, queue sequential
TCP segments until we have received earlier segment or a timeout
happens.
Note that we only queue data sequentially in current version i.e.,
there should be no holes in the queue. For example, if we receive
SEQs 5,4,3,6 and are waiting SEQ 2, the data in segments 3,4,5,6 is
queued (in this order), and then given to application when we receive
SEQ 2. But if we receive SEQs 5,4,3,7 then the SEQ 7 is discarded
because the list would not be sequential as number 6 is be missing.
Fixes #30364
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2020-12-22 15:14:10 +01:00
|
|
|
default 100
|
|
|
|
range 0 10000
|
|
|
|
help
|
|
|
|
If we receive out-of-order TCP data, we queue it. This value tells
|
|
|
|
how long the data is kept before it is discarded if we have not been
|
|
|
|
able to pass the data to the application. If set to 0, then receive
|
2022-03-16 22:07:43 +01:00
|
|
|
queueing is not enabled. The value is in milliseconds.
|
net: tcp2: Queue received out-of-order data
If we receive data that is out-of-order, queue sequential
TCP segments until we have received earlier segment or a timeout
happens.
Note that we only queue data sequentially in current version i.e.,
there should be no holes in the queue. For example, if we receive
SEQs 5,4,3,6 and are waiting SEQ 2, the data in segments 3,4,5,6 is
queued (in this order), and then given to application when we receive
SEQ 2. But if we receive SEQs 5,4,3,7 then the SEQ 7 is discarded
because the list would not be sequential as number 6 is be missing.
Fixes #30364
Signed-off-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
2020-12-22 15:14:10 +01:00
|
|
|
Note that we only queue data sequentially in current version i.e.,
|
|
|
|
there should be no holes in the queue. For example, if we receive
|
|
|
|
SEQs 5,4,3,6 and are waiting SEQ 2, the data in segments 3,4,5,6 is
|
|
|
|
queued (in this order), and then given to application when we receive
|
|
|
|
SEQ 2. But if we receive SEQs 5,4,3,7 then the SEQ 7 is discarded
|
|
|
|
because the list would not be sequential as number 6 is be missing.
|
|
|
|
|
2021-02-15 19:43:59 +01:00
|
|
|
config NET_TCP_WORKQ_STACK_SIZE
|
|
|
|
int "TCP work queue thread stack size"
|
|
|
|
default 1024
|
|
|
|
depends on NET_TCP
|
|
|
|
help
|
|
|
|
Set the TCP work queue thread stack size in bytes.
|
|
|
|
|
2021-02-24 18:33:46 +01:00
|
|
|
config NET_TCP_ISN_RFC6528
|
|
|
|
bool "Use ISN algorithm from RFC 6528"
|
|
|
|
default y
|
|
|
|
depends on NET_TCP
|
|
|
|
select MBEDTLS
|
2021-05-09 20:48:36 +02:00
|
|
|
select MBEDTLS_MD
|
|
|
|
select MBEDTLS_MAC_MD5_ENABLED
|
2021-02-24 18:33:46 +01:00
|
|
|
help
|
|
|
|
Implement Initial Sequence Number calculation as described in
|
|
|
|
RFC 6528 chapter 3. https://tools.ietf.org/html/rfc6528
|
|
|
|
If this is not set, then sys_rand32_get() is used for ISN value.
|
|
|
|
|
2019-10-16 07:37:48 +02:00
|
|
|
config NET_TEST_PROTOCOL
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "JSON based test protocol (UDP)"
|
2019-10-16 07:37:48 +02:00
|
|
|
help
|
|
|
|
Enable JSON based test protocol (UDP).
|
|
|
|
|
2016-06-14 09:00:55 +02:00
|
|
|
config NET_UDP
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "UDP"
|
2016-08-24 10:49:14 +02:00
|
|
|
default y
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
The value depends on your network needs.
|
2016-06-14 09:00:55 +02:00
|
|
|
|
2017-05-17 09:43:18 +02:00
|
|
|
config NET_UDP_CHECKSUM
|
|
|
|
bool "Check UDP checksum"
|
|
|
|
default y
|
|
|
|
depends on NET_UDP
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Enables UDP handler to check UDP checksum. If the checksum is invalid,
|
|
|
|
then the packet is discarded.
|
2017-05-17 09:43:18 +02:00
|
|
|
|
2019-05-27 10:54:01 +02:00
|
|
|
config NET_UDP_MISSING_CHECKSUM
|
|
|
|
bool "Accept missing checksum (IPv4 only)"
|
|
|
|
depends on NET_UDP && NET_IPV4
|
|
|
|
help
|
|
|
|
RFC 768 states the possibility to have a missing checksum, for
|
|
|
|
debugging purposes for instance. That feature is however valid only
|
|
|
|
for IPv4 and on reception only, since Zephyr will always compute the
|
|
|
|
UDP checksum in transmission path.
|
|
|
|
|
2018-07-06 10:35:07 +02:00
|
|
|
if NET_UDP
|
|
|
|
module = NET_UDP
|
|
|
|
module-dep = NET_LOG
|
|
|
|
module-str = Log level for UDP
|
|
|
|
module-help = Enables UDP handler output debug messages
|
|
|
|
source "subsys/net/Kconfig.template.log_config.net"
|
|
|
|
endif # NET_UDP
|
2016-09-07 15:03:10 +02:00
|
|
|
|
2016-06-14 08:56:50 +02:00
|
|
|
config NET_MAX_CONN
|
2016-08-24 10:49:14 +02:00
|
|
|
int "How many network connections are supported"
|
2019-02-08 12:45:54 +01:00
|
|
|
depends on NET_UDP || NET_TCP || NET_SOCKETS_PACKET || NET_SOCKETS_CAN
|
2016-11-23 09:36:40 +01:00
|
|
|
default 8 if NET_IPV6 && NET_IPV4
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 4
|
2016-08-24 10:49:14 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
The value depends on your network needs. The value
|
|
|
|
should include both UDP and TCP connections.
|
2016-06-14 08:56:50 +02:00
|
|
|
|
2016-06-22 15:44:55 +02:00
|
|
|
config NET_MAX_CONTEXTS
|
2016-05-09 14:49:48 +02:00
|
|
|
int "Number of network contexts to allocate"
|
2017-01-30 09:57:55 +01:00
|
|
|
default 6
|
2016-05-09 14:49:48 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Each network context is used to describe a network 5-tuple that
|
|
|
|
is used when listening or sending network traffic. This is very
|
|
|
|
similar as one could call a network socket in some other systems.
|
2016-06-22 15:44:55 +02:00
|
|
|
|
2017-04-03 17:14:35 +02:00
|
|
|
config NET_CONTEXT_NET_PKT_POOL
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Net_buf TX pool / context"
|
2017-04-07 11:30:52 +02:00
|
|
|
default y if NET_TCP && NET_6LO
|
2017-02-15 20:41:44 +01:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
If enabled, then it is possible to fine-tune network packet pool
|
|
|
|
for each context when sending network data. If this setting is
|
|
|
|
enabled, then you should define the context pools in your application
|
|
|
|
using NET_PKT_TX_POOL_DEFINE() and NET_PKT_DATA_POOL_DEFINE()
|
|
|
|
macros and tie these pools to desired context using the
|
|
|
|
net_context_setup_pools() function.
|
2017-02-15 20:41:44 +01:00
|
|
|
|
2016-06-22 15:44:55 +02:00
|
|
|
config NET_CONTEXT_SYNC_RECV
|
|
|
|
bool "Support synchronous functionality in net_context_recv() API"
|
|
|
|
default y
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
You can disable sync support to save some memory if you are calling
|
|
|
|
net_context_recv() in async way only when timeout is set to 0.
|
2016-06-22 15:44:55 +02:00
|
|
|
|
|
|
|
config NET_CONTEXT_CHECK
|
|
|
|
bool "Check options when calling various net_context functions"
|
|
|
|
default y
|
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
If you know that the options passed to net_context...() functions
|
|
|
|
are ok, then you can disable the checks to save some memory.
|
2016-05-09 14:49:48 +02:00
|
|
|
|
2018-02-07 13:44:04 +01:00
|
|
|
config NET_CONTEXT_PRIORITY
|
|
|
|
bool "Add priority support to net_context"
|
|
|
|
help
|
|
|
|
It is possible to prioritize network traffic. This requires
|
|
|
|
also traffic class support to work as expected.
|
|
|
|
|
2019-06-27 16:57:01 +02:00
|
|
|
config NET_CONTEXT_TXTIME
|
|
|
|
bool "Add TXTIME support to net_context"
|
|
|
|
select NET_PKT_TXTIME
|
|
|
|
help
|
|
|
|
It is possible to add information when the outgoing network packet
|
|
|
|
should be sent. The TX time information should be placed into
|
|
|
|
ancillary data field in sendmsg call.
|
|
|
|
|
2021-01-19 07:34:25 +01:00
|
|
|
config NET_CONTEXT_RCVTIMEO
|
|
|
|
bool "Add RCVTIMEO support to net_context"
|
|
|
|
help
|
|
|
|
It is possible to time out receiving a network packet. The timeout
|
|
|
|
time is configurable run-time in the application code. For network
|
|
|
|
sockets timeout is configured per socket with
|
|
|
|
setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, ...) function.
|
|
|
|
|
2021-01-19 07:50:06 +01:00
|
|
|
config NET_CONTEXT_SNDTIMEO
|
|
|
|
bool "Add SNDTIMEO support to net_context"
|
|
|
|
help
|
|
|
|
It is possible to time out sending a network packet. The timeout
|
|
|
|
time is configurable run-time in the application code. For network
|
|
|
|
sockets timeout is configured per socket with
|
|
|
|
setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, ...) function.
|
|
|
|
|
2022-03-30 21:59:13 +02:00
|
|
|
config NET_CONTEXT_RCVBUF
|
|
|
|
bool "Add RCVBUF support to net_context"
|
|
|
|
help
|
|
|
|
If is possible to define the maximum socket receive buffer per socket.
|
|
|
|
The default value is set by CONFIG_NET_TCP_MAX_RECV_WINDOW_SIZE. For
|
|
|
|
TCP sockets, the rcvbuf will determine the receive window size.
|
|
|
|
|
2017-07-26 14:45:13 +02:00
|
|
|
config NET_TEST
|
|
|
|
bool "Network Testing"
|
2016-08-31 21:38:06 +02:00
|
|
|
help
|
2017-07-26 14:45:13 +02:00
|
|
|
Used for self-contained networking tests that do not require a
|
|
|
|
network device.
|
2017-06-30 14:36:19 +02:00
|
|
|
|
2016-08-31 21:38:06 +02:00
|
|
|
config NET_SLIP_TAP
|
|
|
|
bool "TAP SLIP driver"
|
2018-10-16 13:27:21 +02:00
|
|
|
depends on NET_QEMU_SLIP
|
2019-08-09 13:49:35 +02:00
|
|
|
depends on NET_NATIVE
|
2016-08-31 21:38:06 +02:00
|
|
|
select SLIP
|
|
|
|
select UART_PIPE
|
|
|
|
select UART_INTERRUPT_DRIVEN
|
|
|
|
select SLIP_TAP
|
2017-08-09 08:21:11 +02:00
|
|
|
default y if (QEMU_TARGET && !NET_TEST && !NET_L2_BT)
|
2016-08-31 21:38:06 +02:00
|
|
|
help
|
2017-07-27 13:09:11 +02:00
|
|
|
SLIP TAP support is necessary when testing with QEMU. The host
|
|
|
|
needs to have tunslip6 with TAP support running in order to
|
|
|
|
communicate via the SLIP driver. See net-tools project at
|
|
|
|
https://github.com/zephyrproject-rtos/net-tools for more details.
|
2016-05-09 16:39:09 +02:00
|
|
|
|
2016-08-05 14:13:33 +02:00
|
|
|
config NET_TRICKLE
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Trickle library"
|
2016-08-05 14:13:33 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Normally this is enabled automatically if needed,
|
|
|
|
so say 'n' if unsure.
|
2016-08-05 14:13:33 +02:00
|
|
|
|
2018-07-06 10:35:07 +02:00
|
|
|
if NET_TRICKLE
|
|
|
|
module = NET_TRICKLE
|
|
|
|
module-dep = NET_LOG
|
|
|
|
module-str = Log level for Trickle algorithm
|
|
|
|
module-help = Enables Trickle library output debug messages
|
|
|
|
source "subsys/net/Kconfig.template.log_config.net"
|
|
|
|
endif # NET_TRICKLE
|
2016-06-14 15:31:30 +02:00
|
|
|
|
2017-11-16 11:11:51 +01:00
|
|
|
endif # NET_RAW_MODE
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2017-04-03 17:14:35 +02:00
|
|
|
config NET_PKT_RX_COUNT
|
|
|
|
int "How many packet receives can be pending at the same time"
|
2018-03-29 13:33:49 +02:00
|
|
|
default 14 if NET_L2_ETHERNET
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 4
|
2016-09-27 14:45:09 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Each RX buffer will occupy smallish amount of memory.
|
|
|
|
See include/net/net_pkt.h and the sizeof(struct net_pkt)
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2017-04-03 17:14:35 +02:00
|
|
|
config NET_PKT_TX_COUNT
|
|
|
|
int "How many packet sends can be pending at the same time"
|
2018-03-29 13:33:49 +02:00
|
|
|
default 14 if NET_L2_ETHERNET
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 4
|
2016-09-27 14:45:09 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Each TX buffer will occupy smallish amount of memory.
|
|
|
|
See include/net/net_pkt.h and the sizeof(struct net_pkt)
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2017-04-03 17:14:35 +02:00
|
|
|
config NET_BUF_RX_COUNT
|
|
|
|
int "How many network buffers are allocated for receiving data"
|
2018-03-29 13:33:49 +02:00
|
|
|
default 36 if NET_L2_ETHERNET
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 16
|
2017-02-23 22:53:59 +01:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Each data buffer will occupy CONFIG_NET_BUF_DATA_SIZE + smallish
|
|
|
|
header (sizeof(struct net_buf)) amount of data.
|
2017-02-23 22:53:59 +01:00
|
|
|
|
2017-04-03 17:14:35 +02:00
|
|
|
config NET_BUF_TX_COUNT
|
|
|
|
int "How many network buffers are allocated for sending data"
|
2018-03-29 13:33:49 +02:00
|
|
|
default 36 if NET_L2_ETHERNET
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 16
|
2016-09-27 14:45:09 +02:00
|
|
|
help
|
2017-12-13 16:08:21 +01:00
|
|
|
Each data buffer will occupy CONFIG_NET_BUF_DATA_SIZE + smallish
|
|
|
|
header (sizeof(struct net_buf)) amount of data.
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2018-11-23 16:23:14 +01:00
|
|
|
choice
|
|
|
|
prompt "Network packet data allocator type"
|
|
|
|
default NET_BUF_FIXED_DATA_SIZE
|
|
|
|
help
|
|
|
|
Select the memory allocator for the network buffers that hold the
|
|
|
|
packet data.
|
|
|
|
|
|
|
|
config NET_BUF_FIXED_DATA_SIZE
|
|
|
|
bool "Fixed data size buffer"
|
|
|
|
help
|
|
|
|
Each buffer comes with a built time configured size. If runtime
|
|
|
|
requested is bigger than that, it will allocate as many net_buf
|
|
|
|
as necessary to reach that request.
|
|
|
|
|
|
|
|
config NET_BUF_VARIABLE_DATA_SIZE
|
|
|
|
bool "Variable data size buffer [EXPERIMENTAL]"
|
2021-10-15 14:23:18 +02:00
|
|
|
select EXPERIMENTAL
|
2018-11-23 16:23:14 +01:00
|
|
|
help
|
|
|
|
The buffer is dynamically allocated from runtime requested size.
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
2017-04-03 17:14:35 +02:00
|
|
|
config NET_BUF_DATA_SIZE
|
2016-09-27 14:45:09 +02:00
|
|
|
int "Size of each network data fragment"
|
Kconfig: Use the first default with a satisfied condition
Up until now, Zephyr has patched Kconfig to use the last 'default' with
a satisfied condition, instead of the first one. I'm not sure why the
patch was added (it predates Kconfiglib), but I suspect it's related to
Kconfig.defconfig files.
There are at least three problems with the patch:
1. It's inconsistent with how Kconfig works in other projects, which
might confuse newcomers.
2. Due to oversights, earlier 'range' properties are still preferred,
as well as earlier 'default' properties on choices.
In addition to being inconsistent, this makes it impossible to
override 'range' properties and choice 'default' properties if the
base definition of the symbol/choice already has 'range'/'default'
properties.
I've seen errors caused by the inconsistency, and I suspect there
are more.
3. A fork of Kconfiglib that adds the patch needs to be maintained.
Get rid of the patch and go back to standard Kconfig behavior, as
follows:
1. Include the Kconfig.defconfig files first instead of last in
Kconfig.zephyr.
2. Include boards/Kconfig and arch/<arch>/Kconfig first instead of
last in arch/Kconfig.
3. Include arch/<arch>/soc/*/Kconfig first instead of last in
arch/<arch>/Kconfig.
4. Swap a few other 'source's to preserve behavior for some scattered
symbols with multiple definitions.
Swap 'source's in some no-op cases too, where it might match the
intent.
5. Reverse the defaults on symbol definitions that have more than one
default.
Skip defaults that are mutually exclusive, e.g. where each default
has an 'if <some board>' condition. They are already safe.
6. Remove the prefer-later-defaults patch from Kconfiglib.
Testing was done with a Python script that lists all Kconfig
symbols/choices with multiple defaults, along with a whitelist of fixed
symbols. The script also verifies that there are no "unreachable"
defaults hidden by defaults without conditions
As an additional test, zephyr/.config was generated before and after the
change for several samples and checked to be identical (after sorting).
This commit includes some default-related cleanups as well:
- Simplify some symbol definitions, e.g. where a default has 'if FOO'
when the symbol already has 'depends on FOO'.
- Remove some redundant 'default ""' for string symbols. This is the
implicit default.
Piggyback fixes for swapped ranges on BT_L2CAP_RX_MTU and
BT_L2CAP_TX_MTU (caused by confusing inconsistency).
Piggyback some fixes for style nits too, e.g. unindented help texts.
Signed-off-by: Ulf Magnusson <Ulf.Magnusson@nordicsemi.no>
2018-07-30 10:57:47 +02:00
|
|
|
default 128
|
2018-11-23 16:23:14 +01:00
|
|
|
depends on NET_BUF_FIXED_DATA_SIZE
|
|
|
|
help
|
|
|
|
This value tells what is the fixed size of each network buffer.
|
|
|
|
|
|
|
|
config NET_BUF_DATA_POOL_SIZE
|
|
|
|
int "Size of the memory pool where buffers are allocated from"
|
|
|
|
default 4096 if NET_L2_ETHERNET
|
|
|
|
default 2048
|
|
|
|
depends on NET_BUF_VARIABLE_DATA_SIZE
|
2016-09-27 14:45:09 +02:00
|
|
|
help
|
2019-11-01 10:24:07 +01:00
|
|
|
This value tell what is the size of the memory pool where each
|
|
|
|
network buffer is allocated from.
|
2016-09-27 14:45:09 +02:00
|
|
|
|
2018-11-27 08:49:50 +01:00
|
|
|
config NET_HEADERS_ALWAYS_CONTIGUOUS
|
|
|
|
bool
|
|
|
|
help
|
|
|
|
This a hidden option, which one should use with a lot of care.
|
|
|
|
NO bug reports will be accepted if that option is enabled!
|
|
|
|
You are warned.
|
2019-02-27 22:55:32 +01:00
|
|
|
If you are 100% sure the headers memory space is always in a
|
2018-11-27 08:49:50 +01:00
|
|
|
contiguous space, this will save stack usage and ROM in net core.
|
|
|
|
This is a possible case when using IPv4 only, with
|
|
|
|
NET_BUF_FIXED_DATA_SIZE enabled and NET_BUF_DATA_SIZE of 128 for
|
|
|
|
instance.
|
|
|
|
|
2018-01-23 12:47:03 +01:00
|
|
|
choice
|
|
|
|
prompt "Default Network Interface"
|
|
|
|
default NET_DEFAULT_IF_FIRST
|
|
|
|
help
|
|
|
|
If system has multiple interfaces enabled, then user shall be able
|
|
|
|
to choose default interface. Otherwise first interface will be the
|
|
|
|
default interface.
|
|
|
|
|
|
|
|
config NET_DEFAULT_IF_FIRST
|
|
|
|
bool "First available interface"
|
|
|
|
|
2022-03-08 11:43:59 +01:00
|
|
|
config NET_DEFAULT_IF_UP
|
|
|
|
bool "First interface which is up"
|
|
|
|
|
2018-01-23 12:47:03 +01:00
|
|
|
config NET_DEFAULT_IF_ETHERNET
|
|
|
|
bool "Ethernet"
|
|
|
|
depends on NET_L2_ETHERNET
|
|
|
|
|
|
|
|
config NET_DEFAULT_IF_BLUETOOTH
|
|
|
|
bool "Bluetooth"
|
|
|
|
depends on NET_L2_BT
|
|
|
|
|
|
|
|
config NET_DEFAULT_IF_IEEE802154
|
|
|
|
bool "IEEE 802.15.4"
|
|
|
|
depends on NET_L2_IEEE802154
|
|
|
|
|
|
|
|
config NET_DEFAULT_IF_OFFLOAD
|
|
|
|
bool "Offloaded interface"
|
2018-05-24 09:16:43 +02:00
|
|
|
depends on NET_OFFLOAD
|
2018-01-23 12:47:03 +01:00
|
|
|
|
|
|
|
config NET_DEFAULT_IF_DUMMY
|
|
|
|
bool "Dummy testing interface"
|
|
|
|
depends on NET_L2_DUMMY
|
|
|
|
|
2019-08-06 16:12:24 +02:00
|
|
|
config NET_DEFAULT_IF_CANBUS_RAW
|
|
|
|
bool "Socket CAN interface"
|
|
|
|
depends on NET_L2_CANBUS_RAW
|
|
|
|
|
2020-01-17 09:57:31 +01:00
|
|
|
config NET_DEFAULT_IF_PPP
|
|
|
|
bool "PPP interface"
|
|
|
|
depends on NET_L2_PPP
|
2019-08-06 16:12:24 +02:00
|
|
|
|
2018-01-23 12:47:03 +01:00
|
|
|
endchoice
|
|
|
|
|
2018-01-24 14:20:21 +01:00
|
|
|
config NET_PKT_TIMESTAMP
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Network packet timestamp support"
|
2018-01-24 14:20:21 +01:00
|
|
|
help
|
|
|
|
Enable network packet timestamp support. This is needed for
|
|
|
|
example in gPTP which needs to know how long it takes to send
|
|
|
|
a network packet.
|
|
|
|
|
2019-05-30 12:32:07 +02:00
|
|
|
config NET_PKT_TIMESTAMP_THREAD
|
|
|
|
bool "Create TX timestamp thread"
|
2021-09-09 05:28:27 +02:00
|
|
|
default y if NET_L2_PTP
|
2019-05-30 12:32:07 +02:00
|
|
|
depends on NET_PKT_TIMESTAMP
|
|
|
|
help
|
|
|
|
Create a TX timestamp thread that will pass the timestamped network
|
|
|
|
packets to some other module like gPTP for further processing.
|
|
|
|
If you just want to timestamp network packets and get information
|
|
|
|
how long the network packets flow in the system, you can disable
|
|
|
|
the thread support.
|
|
|
|
|
2018-01-24 14:20:21 +01:00
|
|
|
config NET_PKT_TIMESTAMP_STACK_SIZE
|
|
|
|
int "Timestamp thread stack size"
|
|
|
|
default 1024
|
2019-05-30 12:32:07 +02:00
|
|
|
depends on NET_PKT_TIMESTAMP_THREAD
|
2018-01-24 14:20:21 +01:00
|
|
|
help
|
|
|
|
Set the timestamp thread stack size in bytes. The timestamp
|
|
|
|
thread waits for timestamped TX frames and calls registered
|
|
|
|
callbacks.
|
|
|
|
|
2019-06-27 16:57:01 +02:00
|
|
|
config NET_PKT_TXTIME
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Network packet TX time support"
|
2019-06-27 16:57:01 +02:00
|
|
|
help
|
|
|
|
Enable network packet TX time support. This is needed for
|
|
|
|
when the application wants to set the exact time when the network
|
|
|
|
packet should be sent.
|
|
|
|
|
2019-10-08 13:58:13 +02:00
|
|
|
config NET_PKT_RXTIME_STATS
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Network packet RX time statistics"
|
2019-10-08 13:58:13 +02:00
|
|
|
select NET_PKT_TIMESTAMP
|
|
|
|
select NET_STATISTICS
|
2020-05-13 10:20:30 +02:00
|
|
|
depends on (NET_UDP || NET_TCP || NET_SOCKETS_PACKET) && NET_NATIVE
|
2019-10-08 13:58:13 +02:00
|
|
|
help
|
|
|
|
Enable network packet RX time statistics support. This is used to
|
|
|
|
calculate how long on average it takes for a packet to travel from
|
|
|
|
device driver to just before it is given to application. The RX
|
|
|
|
timing information can then be seen in network interface statistics
|
|
|
|
in net-shell.
|
|
|
|
The RX statistics are only calculated for UDP and TCP packets.
|
|
|
|
|
2020-05-13 10:20:30 +02:00
|
|
|
config NET_PKT_RXTIME_STATS_DETAIL
|
|
|
|
bool "Get extra receive detail statistics in RX path"
|
|
|
|
depends on NET_PKT_RXTIME_STATS
|
|
|
|
help
|
|
|
|
Store receive statistics detail information in certain key points
|
|
|
|
in RX path. This is very special configuration and will increase
|
|
|
|
the size of net_pkt so in typical cases you should not enable it.
|
|
|
|
The extra statistics can be seen in net-shell using "net stats"
|
|
|
|
command.
|
|
|
|
|
2019-10-08 15:00:37 +02:00
|
|
|
config NET_PKT_TXTIME_STATS
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Network packet TX time statistics"
|
2019-10-08 15:00:37 +02:00
|
|
|
select NET_PKT_TIMESTAMP
|
|
|
|
select NET_STATISTICS
|
2020-05-15 13:55:33 +02:00
|
|
|
depends on (NET_UDP || NET_TCP || NET_SOCKETS_PACKET) && NET_NATIVE
|
2019-10-08 15:00:37 +02:00
|
|
|
help
|
|
|
|
Enable network packet TX time statistics support. This is used to
|
|
|
|
calculate how long on average it takes for a packet to travel from
|
|
|
|
application to just before it is sent to network. The TX timing
|
|
|
|
information can then be seen in network interface statistics in
|
|
|
|
net-shell.
|
2020-05-15 13:55:33 +02:00
|
|
|
The RX calculation is done only for UDP, TCP or RAW packets,
|
|
|
|
but for TX we do not know the protocol so the TX packet timing is
|
|
|
|
done for all network protocol packets.
|
2019-10-08 15:00:37 +02:00
|
|
|
|
2020-05-13 10:09:10 +02:00
|
|
|
config NET_PKT_TXTIME_STATS_DETAIL
|
|
|
|
bool "Get extra transmit detail statistics in TX path"
|
|
|
|
depends on NET_PKT_TXTIME_STATS
|
|
|
|
help
|
|
|
|
Store receive statistics detail information in certain key points
|
|
|
|
in TX path. This is very special configuration and will increase
|
|
|
|
the size of net_pkt so in typical cases you should not enable it.
|
|
|
|
The extra statistics can be seen in net-shell using "net stats"
|
|
|
|
command.
|
|
|
|
|
2018-07-23 13:03:11 +02:00
|
|
|
config NET_PROMISCUOUS_MODE
|
2022-03-09 12:05:12 +01:00
|
|
|
bool "Promiscuous mode support"
|
2018-07-23 13:03:11 +02:00
|
|
|
select NET_MGMT
|
|
|
|
select NET_MGMT_EVENT
|
|
|
|
select NET_L2_ETHERNET_MGMT if NET_L2_ETHERNET
|
|
|
|
help
|
|
|
|
Enable promiscuous mode support. This only works if the network
|
|
|
|
device driver supports promiscuous mode. The user application
|
|
|
|
also needs to read the promiscuous mode data.
|
|
|
|
|
2018-11-02 15:17:09 +01:00
|
|
|
if NET_PROMISCUOUS_MODE
|
|
|
|
module = NET_PROMISC
|
|
|
|
module-dep = NET_LOG
|
|
|
|
module-str = Log level for promiscuous mode
|
|
|
|
module-help = Enables promiscuous mode to output debug messages.
|
|
|
|
source "subsys/net/Kconfig.template.log_config.net"
|
|
|
|
endif # NET_PROMISCUOUS_MODE
|
|
|
|
|
2021-07-30 21:21:08 +02:00
|
|
|
config NET_DISABLE_ICMP_DESTINATION_UNREACHABLE
|
|
|
|
bool "Disable destination unreachable ICMP errors"
|
|
|
|
help
|
|
|
|
Suppress the generation of ICMP destination unreachable errors
|
|
|
|
when ports that are not in a listening state receive packets.
|
|
|
|
|
2016-11-11 22:46:28 +01:00
|
|
|
source "subsys/net/ip/Kconfig.stack"
|
2016-11-18 11:56:43 +01:00
|
|
|
|
2016-11-11 22:46:28 +01:00
|
|
|
source "subsys/net/ip/Kconfig.mgmt"
|
2016-09-21 11:11:47 +02:00
|
|
|
|
2016-12-13 15:19:28 +01:00
|
|
|
source "subsys/net/ip/Kconfig.stats"
|
|
|
|
|
2018-12-21 12:49:31 +01:00
|
|
|
source "subsys/net/ip/Kconfig.debug"
|
|
|
|
|
2016-06-14 15:31:30 +02:00
|
|
|
endmenu
|