incubator-nuttx/net/Kconfig

375 lines
10 KiB
Plaintext
Raw Normal View History

#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
config ARCH_HAVE_NET
bool
default n
config ARCH_HAVE_PHY
bool
default n
config ARCH_PHY_INTERRUPT
bool
default n
2020-09-18 20:04:49 +08:00
config ARCH_PHY_POLLED
bool
default n
config ARCH_HAVE_NETDEV_STATISTICS
bool
default n
config NET_WRITE_BUFFERS
bool
default n
select MM_IOB
config NET_READAHEAD
bool
default n
select MM_IOB
config NET_MCASTGROUP
bool
default n
config NET
bool "Networking support"
default n
select ARCH_HAVE_NET
---help---
Enable or disable all network features
if NET
config NET_PROMISCUOUS
bool "Promiscuous mode"
default n
---help---
Force the Ethernet driver to operate in promiscuous mode (if supported
by the Ethernet driver).
menu "Driver buffer configuration"
This commit attempts remove some long standard confusion in naming and some actual problems that result from the naming confusion. The basic problem is the standard MTU does not include the size of the Ethernet header. For clarity, I changed the naming of most things called MTU to PKTSIZE. For example, CONFIG_NET_ETH_MTU is now CONFIG_NET_ETH_PKTSIZE. This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU. The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's. Squashed commit of the following: Trivial update to fix some spacing issues. net/: Rename several macros containing _MTU to _PKTSIZE. net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2018-07-05 04:10:40 +08:00
config NET_ETH_PKTSIZE
int "Ethernet packet buffer size"
default 1294 if NET_IPv6
default 590 if !NET_IPv6
range 1294 1518 if NET_IPv6
range 590 1518 if !NET_IPv6
depends on NET_ETHERNET
---help---
Packet buffer size. This size includes the TCP/UDP payload plus the
size of TCP/UDP header, the IP header, and the Ethernet header.
This commit attempts remove some long standard confusion in naming and some actual problems that result from the naming confusion. The basic problem is the standard MTU does not include the size of the Ethernet header. For clarity, I changed the naming of most things called MTU to PKTSIZE. For example, CONFIG_NET_ETH_MTU is now CONFIG_NET_ETH_PKTSIZE. This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU. The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's. Squashed commit of the following: Trivial update to fix some spacing issues. net/: Rename several macros containing _MTU to _PKTSIZE. net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2018-07-05 04:10:40 +08:00
This value is related to the MTU (Maximum Transmission Unit), except
that it includes the size of the link layer header; the payload is
the MSS (Maximum Segment Size).
IPv4 hosts are required to be able to handle an MSS of at least
536 octets, resulting in a minimum buffer size of 536+20+20+14 =
590.
IPv6 hosts are required to be able to handle an MSS of 1220 octets,
resulting in a minimum buffer size of 1220+20+40+14 = 1294
To get an MTU of 1500, for example, you would need packet buffer of
size 1514.
This commit attempts remove some long standard confusion in naming and some actual problems that result from the naming confusion. The basic problem is the standard MTU does not include the size of the Ethernet header. For clarity, I changed the naming of most things called MTU to PKTSIZE. For example, CONFIG_NET_ETH_MTU is now CONFIG_NET_ETH_PKTSIZE. This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU. The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's. Squashed commit of the following: Trivial update to fix some spacing issues. net/: Rename several macros containing _MTU to _PKTSIZE. net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2018-07-05 04:10:40 +08:00
config NET_SLIP_PKTSIZE
int "SLIP packet buffer size"
default 296
depends on NET_SLIP
range 296 1518
---help---
Provides the size of the SLIP packet buffers. This size includes
the TCP/UDP payload plus the size of TCP/UDP header and the IP header.
This commit attempts remove some long standard confusion in naming and some actual problems that result from the naming confusion. The basic problem is the standard MTU does not include the size of the Ethernet header. For clarity, I changed the naming of most things called MTU to PKTSIZE. For example, CONFIG_NET_ETH_MTU is now CONFIG_NET_ETH_PKTSIZE. This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU. The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's. Squashed commit of the following: Trivial update to fix some spacing issues. net/: Rename several macros containing _MTU to _PKTSIZE. net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2018-07-05 04:10:40 +08:00
This value is related to the MTU (Maximum Transmission Unit), except
that it includes the size of the link layer header; the payload is
the MSS (Maximum Segment Size). SLIP has no link layer header so for
SLIP the MTU is the same as the PKTSIZE.
SLIP is required to support at least 256+20+20 = 296. Values other than
296 are not recommended.
The Linux slip module hard-codes its MTU size to 296 (40 bytes for
the IP+TCP headers plus 256 bytes of data). So you might as well
This commit attempts remove some long standard confusion in naming and some actual problems that result from the naming confusion. The basic problem is the standard MTU does not include the size of the Ethernet header. For clarity, I changed the naming of most things called MTU to PKTSIZE. For example, CONFIG_NET_ETH_MTU is now CONFIG_NET_ETH_PKTSIZE. This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU. The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's. Squashed commit of the following: Trivial update to fix some spacing issues. net/: Rename several macros containing _MTU to _PKTSIZE. net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2018-07-05 04:10:40 +08:00
set CONFIG_NET_SLIP_PKTSIZE to 296 as well.
There may be an issue with this setting, however. I see that Linux
uses a MTU of 296 and window of 256, but actually only sends 168
bytes of data: 40 + 128. I believe that is to allow for the 2x
worst cast packet expansion. Ideally we would like to advertise the
256 MSS, but restrict transfers to 128 bytes (possibly by modifying
the MSS value in the TCP connection structure).
config NET_GUARDSIZE
int "Driver I/O guard size"
default 2
---help---
Network drivers often receive packets with garbage at the end and
are longer than the size of packet in the TCP header. The following
"fudge" factor increases the size of the I/O buffering by a small
amount to allocate slightly oversize packets. After receipt, the
packet size will be chopped down to the size indicated in the TCP
header.
endmenu # Driver buffer configuration
menu "Link layer support"
2014-06-01 23:40:23 +08:00
config NET_ETHERNET
bool "Ethernet support"
default y
2014-06-01 23:40:23 +08:00
---help---
If NET_SLIP is not selected, then Ethernet will be used (there is
no need to define anything special in the configuration file to use
Ethernet -- it is the default).
config NET_LOOPBACK
bool "Local loopback"
select ARCH_HAVE_NETDEV_STATISTICS
default n
---help---
Add support for the local network loopback device, lo.
Network Loopback Driver: A configuration option to control packet size. Historically, the loopback driver used the largest packet size of all enabled link layer protocols. This permitted packets to be forward via the loopbak device with no major loss of performance. However, in experimenting with configurations where no other link layer protocols were enabled, this means the loopback packet size was set to the smallest possible size, to the SLIP minimum of 296 bytes. This resulted in terrible loopback performance. This commit adds an option to increase the loopback packet size with the option CONFIG_NET_LOOPBACK_PACKETSIZE. The loopback driver packet buffer should be quite large. The larger the loopback packet buffer, the better will be TCP performance of the loopback transfers. The Linux loopback device historically used packet buffers of size 16Kb, but that was increased in recent Linux versions to 64Kb. Those sizes may be excessive for resource constrained MCUs, however. The network still enforces the lower limit that is the maximum packet size of all enabled link layer protocols. But this new option permits the loopback packet size to be increased from that. * net/Kconfig: Adds CONFIG_NET_LOOPBACK_PKTSIZE option * include/nuttx/net/netconfig.h: Assures that the packet size that is used is at least as large as the largest packet size of other link layer protocols. * drivers/net/loopback.c: Use that larger packet size. * boards/sim/sim/sim/configs/tcploop/defconfig: Set the loopback packet size to 1500
2020-02-11 08:35:02 +08:00
config NET_LOOPBACK_PKTSIZE
int "Loopback packet buffer size"
default 0
depends on NET_LOOPBACK
range 0 65535
---help---
The loopback driver packet buffer should be quite large. The larger
the loopback packet buffer, the better will be TCP performance of
the loopback transfers. The Linux loopback device historically used
packet buffers of size 16Kb, but that was increased in recent Linux
versions to 64Kb. Those sizes may be excessive for resource
constrained MCUs, however.
The network enforces a lower limit that is the maximum packet size
of all enabled link layer protocols. The default value of
CONFIG_NET_LOOPBACK_PKTSIZE is zero, meaning that this maximum
packet size will be used by loopback driver.
2020-06-15 06:59:38 +08:00
menuconfig NET_MBIM
2020-06-15 08:08:20 +08:00
bool "MBIM modem support"
2020-06-15 06:59:38 +08:00
depends on USBHOST_CDCMBIM
default n
menuconfig NET_SLIP
bool "SLIP support"
select ARCH_HAVE_NETDEV_STATISTICS
default n
---help---
Enables building of the SLIP driver. SLIP requires
at least one IP protocol selected.
SLIP supports point-to-point IP communications over a serial port.
The default link layer for network layer is Ethernet. If NET_SLIP
is defined in the NuttX configuration file, then SLIP will be
supported. The basic differences between the SLIP and Ethernet
configurations is that when SLIP is selected:
* The link level header (that comes before the IP header) is omitted.
* All MAC address processing is suppressed.
* ARP is disabled.
If NET_SLIP is not selected, then Ethernet will be used (there is
no need to define anything special in the configuration file to use
Ethernet -- it is the default).
if NET_SLIP
config SLIP_NINTERFACES
int "Number of SLIP interfaces"
default 1
---help---
Selects the number of physical SLIP
interfaces to support.
Default: 1
config SLIP_STACKSIZE
int "SLIP stack size"
default DEFAULT_TASK_STACKSIZE
---help---
Select the stack size of the SLIP RX and TX tasks.
config SLIP_DEFPRIO
int "SLIP priority"
default 128
---help---
The priority of the SLIP RX and TX tasks. Default: 128
endif # NET_SLIP
2015-03-11 20:52:56 +08:00
menuconfig NET_TUN
2015-03-11 20:52:56 +08:00
bool "TUN Virtual Network Device support"
default n
select ARCH_HAVE_NETDEV_STATISTICS
2015-03-11 20:52:56 +08:00
if NET_TUN
config TUN_NINTERFACES
int "Number of TUN interfaces"
default 1
range 1 8
---help---
Selects the number of TUN
interfaces to support.
Default: 1
This commit attempts remove some long standard confusion in naming and some actual problems that result from the naming confusion. The basic problem is the standard MTU does not include the size of the Ethernet header. For clarity, I changed the naming of most things called MTU to PKTSIZE. For example, CONFIG_NET_ETH_MTU is now CONFIG_NET_ETH_PKTSIZE. This makes the user interface a little hostile. People thing of an MTU of 1500 bytes, but the corresponding packet is really 1514 bytes (including the 14 byte Ethernet header). A more friendly solution would configure the MTU (as before), but then derive the packet buffer size by adding the MAC header length. Instead, we define the packet buffer size then derive the MTU. The MTU is not common currency in networking. On the wire, the only real issue is the MSS which is derived from MTU by subtracting the IP header and TCP header sizes (for the case of TCP). Now it is derived for the PKTSIZE by subtracting the IP header, the TCP header, and the MAC header sizes. So we should be all good and without the recurring 14 byte error in MTU's and MSS's. Squashed commit of the following: Trivial update to fix some spacing issues. net/: Rename several macros containing _MTU to _PKTSIZE. net/: Rename CONFIG_NET_SLIP_MTU to CONFIG_NET_SLIP_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_6LOWPAN_MTU to CONFIG_NET_6LOWPAN_PKTSIZE and similarly for CONFIG_NET_TUN_MTU. These are not the MTU which does not include the size of the link layer header. These are the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename CONFIG_NET_ETH_MTU to CONFIG_NET_ETH_PKTSIZE. This is not the MTU which does not include the size of the link layer header. This is the full size of the packet buffer memory (minus any GUARD bytes). net/: Rename the file d_mtu in the network driver structure to d_pktsize. That value saved there is not the MTU. The packetsize is the memory large enough to hold the maximum packet PLUS the size of the link layer header. The MTU does not include the link layer header.
2018-07-05 04:10:40 +08:00
config NET_TUN_PKTSIZE
int "TUN packet buffer size"
default 296
range 296 1518
---help---
Provides the size of the TUN packet buffers. This size includes
the TCP/UDP payload plus the size of TCP/UDP header and the IP header.
This value is related to the MTU (Maximum Transmission Unit), except
that it includes the size of the link layer header; the payload is
the MSS (Maximum Segment Size). TUN has no link layer header so for
TUN the MTU is the same as the PKTSIZE.
2015-03-11 20:52:56 +08:00
endif # NET_TUN
config NETDEV_LATEINIT
bool "Late driver initialization"
default n
---help---
Normally, networking initialization occur in the later phase of the
boot process in the function up_initialize() when it calls the
2019-08-05 04:50:28 +08:00
driver initialization function, up_netinitialize(). This
initialization occurs after a sufficient about of the OS has been
initialized so that driver registration can be performed, but
before the completion of OS initialization and before the first
application is started.
In a few situations, however, you may want to suppress this early
network driver initialization. As examples:
- If you are using SLIP or PPPD, then there will be no network
driver to be initialized,
- Certain multi-network configurations where a simple call to
up_netinitialize() may be insufficient, and
- Situations where there are other board-level hardware
dependencies so that the hardware is not in an appropriate
state for up_netinitialize() to be called.
Examples of this latter situation includes such things as network
drivers that required some setup via an I2C I/O expander, or network
drivers that depend on USB, SPI, I2C, PCI, serial, or other
2020-03-12 14:04:42 +08:00
interfaces that may not be ready when up_netinitialize() is normally
called.
endmenu # Link layer support
source "net/netdev/Kconfig"
menu "Internet Protocol Selection"
config NET_IPv4
bool "IPv4"
default y
---help---
Build in support for IPv4.
config NET_IPv6
bool "IPv6"
default n
---help---
Build in support for IPv6.
source "net/neighbor/Kconfig"
menuconfig NET_6LOWPAN
bool "6LoWPAN support"
default n
select NETDEV_IOCTL
select NET_HAVE_STAR
depends on NET_IPv6
---help---
Enable support for Low power Wireless Personal Area Networking (6LoWPAN)
for IEEE 802.15.4 or other packet radios.
source "net/sixlowpan/Kconfig"
source "net/ipforward/Kconfig"
endmenu # Internet Protocol Selection
source "net/socket/Kconfig"
source "net/inet/Kconfig"
source "net/pkt/Kconfig"
source "net/local/Kconfig"
source "net/rpmsg/Kconfig"
2020-06-15 16:23:25 +08:00
source "net/can/Kconfig"
source "net/netlink/Kconfig"
source "net/tcp/Kconfig"
source "net/udp/Kconfig"
This comment adds (1) basic support for AF_BLUETOOTH sockets. The logic compiles but is still incomplete. Support for Bluetooth is general is still dependent on CONFIG_EXPERMIMENTAL because it is not yet ready for used. Squashed commit of the following: wireless/bluetooth: Some small changes that gets to a clean compile by just eliminating some incorrect implementations (still with a lot of warnings. The logic is still incomplete but now not so lethal. wireless/bluetooth: Restructuring: Connection interfaces should internal to wireless/bluetooth. include/nuttx/wireless/bt_conn.h removed and merged with wireless/bluetooth/bt_conn.h. Several fix to get closer to bt_netdev.c compiling. Need to design some not interfaces and use some existing interfaces to send and receiv packets. wireless/bluetooth: Some organization with some network device compile errors fixed. Still not even close to compiling. net/bluetooth: Fix numerous compile issues; Still open design issues with regard to the interface with the Bluetooth stack. wireless/bluetooth: Create bt_netdev.c with a crude copy of mac802154_netdev.c. Does not not even compile yet. include/nuttx/net: Add bluetooth.h. Content is not yet correct. net/netpackets: Add bluetooth.h. Update net/bluetooth to use new socket address definition. net/bluetooth: Some fixes for initial build. net/bluetooth: Add initial support for Bluetooth sockets. The initial cut is just the a clone of the IEEE 802.15.4 socket support with name changes. net/ieee802154: Fix some typos noted when cloning to create net/bluetooth.
2018-04-01 04:55:03 +08:00
source "net/bluetooth/Kconfig"
Squashed commit of the following: commit 2a3ab1652a2c95bcfc8be8380fc7cbdcb6472938 Author: Gregory Nutt <gnutt@nuttx.org> Date: Sat Aug 19 08:44:31 2017 -0600 PF_IEEE802154: Finish some missing bind() logic. Add configs/sim configuration for testing. commit 59be4b846a6e3bfe82087a888e3fdac9c3c414e5 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 19:30:04 2017 -0600 PF_IEEE802154: More renaming to decouple 6LoPAN from radios in general. commit 69fabb1aea76e54381bdc13de28a3f1441fb42f4 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 19:21:11 2017 -0600 PF_IEEE802154: Missed a few renamings. commit ff0af1bb25567720934cc1c2a721ccd92cc35f89 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 17:46:58 2017 -0600 PF_IEEE802154: A few bugfixes commit 01c7c84afd00cf907d280d30cfaf0fb2cf90e02e Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 17:01:31 2017 -0600 PF_IEEE802154: A few bugfixes commit dcef4056d1c1488c93151135f3b7106977faa903 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 16:31:05 2017 -0600 PF_IEEE802154: Bring in framework for sendto/recvfrom. Currently just a crude port of functions from net/pkt and do not provide the implemenation needed. commit 68c5b7b6dd3ab7eb2d0c19890abb38e6561b140e Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 15:18:31 2017 -0600 Trivial fix to typo in comment commit fd0af534c089569ccdbd59f13b85453de0a653ad Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 15:07:20 2017 -0600 PF_IEEE802154: Add device lookup logic; Rename some things that used to be used only by 6LoWPAN but now must be shared with PF_IEEE802154 and need more generic naming. commit 4fc80a1659f1c699b050775cefc7f6b631b46114 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 13:49:54 2017 -0600 PF_IEEE802154: Add driver poll logic. commit d83f71992df8764faa93f9425f1a7602a758f730 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 13:28:59 2017 -0600 PF_IEEE802154: Add frame input function. commit 77561b8c4d5d7be1f8d8eb62cf1a07229afe2048 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 12:46:29 2017 -0600 PF_IEEE802154: Socket type should be SOCK_DGRAM. Hook in socket interface. commit c0f90350282e9905d7f26a1b30f04cc6d6794648 Merge: 8b518abfd0 169c55e546 Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 09:36:32 2017 -0600 Merge remote-tracking branch 'origin/master' into pf_ieee802154 commit 8b518abfd07d492f5148f2c5fdf65604de9822da Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 09:35:39 2017 -0600 PF_IEEE802154: Add initialization and connection management logic. commit 98b62620b3cb420041d8ad14204f9410a8aace8c Author: Gregory Nutt <gnutt@nuttx.org> Date: Fri Aug 18 07:52:51 2017 -0600 PF_IEEE802154: Add basic build support and socket interface framework.
2017-08-19 22:48:52 +08:00
source "net/ieee802154/Kconfig"
source "net/icmp/Kconfig"
source "net/icmpv6/Kconfig"
source "net/mld/Kconfig"
source "net/igmp/Kconfig"
source "net/arp/Kconfig"
source "net/procfs/Kconfig"
source "net/usrsock/Kconfig"
source "net/utils/Kconfig"
config NET_STATISTICS
bool "Collect network statistics"
default n
---help---
Network layer statistics on or off
config NET_HAVE_STAR
bool
default n
---help---
Automatically enabled if at least one selected L2 protocol supports
a STAR topology. In order to support the star topology, the L2
protocol must support relaying all packets to a well-known hub node.
menu "Network Topologies"
config NET_STAR
bool "Enable star topology"
default n
depends on NET_HAVE_STAR && NET_IPv6
---help---
Enable support for a star network topology.
NOTE: Currently only supported by 6LoWPAN.
NOTE: L2 forwarding only supported for IPv6.
choice
prompt "Node role"
depends on NET_STAR
default NET_STARPOINT
---help---
Specifies the role of this not in the star configuration.
config NET_STARPOINT
bool "Point node in star"
---help---
The node is a "point" in the star configuration and must send all
packets to the star hub node.
config NET_STARHUB
bool "Hub node of star"
select NET_IPFORWARD
---help---
This is the "hub" node in the star configurations. It will receive
packets packets from all "point" nodes and perform L2 forwarding of
the packets that are not destined for this node.
endchoice # Node role
endmenu # Network Topologies
source "net/route/Kconfig"
endif # NET