2005-04-17 02:20:36 +04:00
#
# Network configuration
#
2008-07-30 14:14:01 +04:00
menuconfig NET
2005-04-17 02:20:36 +04:00
bool "Networking support"
2009-03-04 09:53:30 +03:00
select NLATTR
2013-06-04 20:46:26 +04:00
select GENERIC_NET_UTILS
2014-10-24 05:41:08 +04:00
select BPF
2005-04-17 02:20:36 +04:00
---help---
Unless you really know what you are doing, you should say Y here.
The reason is that some programs need kernel networking support even
when running on a stand-alone machine that isn't connected to any
2005-07-12 08:03:49 +04:00
other computer.
If you are upgrading from an older kernel, you
2005-04-17 02:20:36 +04:00
should consider updating your networking tools too because changes
in the kernel and the tools often go hand in hand. The tools are
contained in the package net-tools, the location and version number
of which are given in <file:Documentation/Changes>.
For a general introduction to Linux networking, it is highly
recommended to read the NET-HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
2005-07-12 08:13:56 +04:00
if NET
2005-04-17 02:20:36 +04:00
net/compat/wext: send different messages to compat tasks
Wireless extensions have the unfortunate problem that events
are multicast netlink messages, and are not independent of
pointer size. Thus, currently 32-bit tasks on 64-bit platforms
cannot properly receive events and fail with all kinds of
strange problems, for instance wpa_supplicant never notices
disassociations, due to the way the 64-bit event looks (to a
32-bit process), the fact that the address is all zeroes is
lost, it thinks instead it is 00:00:00:00:01:00.
The same problem existed with the ioctls, until David Miller
fixed those some time ago in an heroic effort.
A different problem caused by this is that we cannot send the
ASSOCREQIE/ASSOCRESPIE events because sending them causes a
32-bit wpa_supplicant on a 64-bit system to overwrite its
internal information, which is worse than it not getting the
information at all -- so we currently resort to sending a
custom string event that it then parses. This, however, has a
severe size limitation we are frequently hitting with modern
access points; this limitation would can be lifted after this
patch by sending the correct binary, not custom, event.
A similar problem apparently happens for some other netlink
users on x86_64 with 32-bit tasks due to the alignment for
64-bit quantities.
In order to fix these problems, I have implemented a way to
send compat messages to tasks. When sending an event, we send
the non-compat event data together with a compat event data in
skb_shinfo(main_skb)->frag_list. Then, when the event is read
from the socket, the netlink code makes sure to pass out only
the skb that is compatible with the task. This approach was
suggested by David Miller, my original approach required
always sending two skbs but that had various small problems.
To determine whether compat is needed or not, I have used the
MSG_CMSG_COMPAT flag, and adjusted the call path for recv and
recvfrom to include it, even if those calls do not have a cmsg
parameter.
I have not solved one small part of the problem, and I don't
think it is necessary to: if a 32-bit application uses read()
rather than any form of recvmsg() it will still get the wrong
(64-bit) event. However, neither do applications actually do
this, nor would it be a regression.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-01 15:26:02 +04:00
config WANT_COMPAT_NETLINK_MESSAGES
bool
help
This option can be selected by other options that need compat
netlink messages.
config COMPAT_NETLINK_MESSAGES
def_bool y
depends on COMPAT
2010-07-27 00:13:49 +04:00
depends on WEXT_CORE || WANT_COMPAT_NETLINK_MESSAGES
net/compat/wext: send different messages to compat tasks
Wireless extensions have the unfortunate problem that events
are multicast netlink messages, and are not independent of
pointer size. Thus, currently 32-bit tasks on 64-bit platforms
cannot properly receive events and fail with all kinds of
strange problems, for instance wpa_supplicant never notices
disassociations, due to the way the 64-bit event looks (to a
32-bit process), the fact that the address is all zeroes is
lost, it thinks instead it is 00:00:00:00:01:00.
The same problem existed with the ioctls, until David Miller
fixed those some time ago in an heroic effort.
A different problem caused by this is that we cannot send the
ASSOCREQIE/ASSOCRESPIE events because sending them causes a
32-bit wpa_supplicant on a 64-bit system to overwrite its
internal information, which is worse than it not getting the
information at all -- so we currently resort to sending a
custom string event that it then parses. This, however, has a
severe size limitation we are frequently hitting with modern
access points; this limitation would can be lifted after this
patch by sending the correct binary, not custom, event.
A similar problem apparently happens for some other netlink
users on x86_64 with 32-bit tasks due to the alignment for
64-bit quantities.
In order to fix these problems, I have implemented a way to
send compat messages to tasks. When sending an event, we send
the non-compat event data together with a compat event data in
skb_shinfo(main_skb)->frag_list. Then, when the event is read
from the socket, the netlink code makes sure to pass out only
the skb that is compatible with the task. This approach was
suggested by David Miller, my original approach required
always sending two skbs but that had various small problems.
To determine whether compat is needed or not, I have used the
MSG_CMSG_COMPAT flag, and adjusted the call path for recv and
recvfrom to include it, even if those calls do not have a cmsg
parameter.
I have not solved one small part of the problem, and I don't
think it is necessary to: if a 32-bit application uses read()
rather than any form of recvmsg() it will still get the wrong
(64-bit) event. However, neither do applications actually do
this, nor would it be a regression.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-07-01 15:26:02 +04:00
help
This option makes it possible to send different netlink messages
to tasks depending on whether the task is a compat task or not. To
achieve this, you need to set skb_shinfo(skb)->frag_list to the
compat skb before sending the skb, the netlink code will sort out
which message to actually pass to the task.
Newly written code should NEVER need this option but do
compat-independent messages instead!
2005-07-12 08:13:56 +04:00
menu "Networking options"
2005-04-17 02:20:36 +04:00
2005-07-12 08:13:56 +04:00
source "net/packet/Kconfig"
source "net/unix/Kconfig"
source "net/xfrm/Kconfig"
2007-02-09 00:37:42 +03:00
source "net/iucv/Kconfig"
2005-04-17 02:20:36 +04:00
config INET
bool "TCP/IP networking"
2012-09-04 22:20:14 +04:00
select CRYPTO
select CRYPTO_AES
2005-04-17 02:20:36 +04:00
---help---
These are the protocols used on the Internet and on most local
Ethernets. It is highly recommended to say Y here (this will enlarge
2008-02-12 11:35:16 +03:00
your kernel by about 400 KB), since some programs (e.g. the X window
2005-04-17 02:20:36 +04:00
system) use TCP/IP even if your machine is not connected to any
other computer. You will get the so-called loopback device which
allows you to ping yourself (great fun, that!).
For an excellent introduction to Linux networking, please read the
Linux Networking HOWTO, available from
<http://www.tldp.org/docs.html#howto>.
If you say Y here and also to "/proc file system support" and
"Sysctl support" below, you can change various aspects of the
behavior of the TCP/IP code by writing to the (virtual) files in
/proc/sys/net/ipv4/*; the options are explained in the file
<file:Documentation/networking/ip-sysctl.txt>.
Short answer: say Y.
2005-07-12 08:13:56 +04:00
if INET
2005-04-17 02:20:36 +04:00
source "net/ipv4/Kconfig"
source "net/ipv6/Kconfig"
2006-11-06 03:44:06 +03:00
source "net/netlabel/Kconfig"
2005-04-17 02:20:36 +04:00
2005-07-12 08:13:56 +04:00
endif # if INET
2006-06-09 11:29:17 +04:00
config NETWORK_SECMARK
bool "Security Marking"
help
This enables security marking of network packets, similar
to nfmark, but designated for security purposes.
If you are unsure how to answer this question, answer N.
2014-04-01 18:20:23 +04:00
config NET_PTP_CLASSIFY
def_bool n
2010-07-17 12:49:36 +04:00
config NETWORK_PHY_TIMESTAMPING
bool "Timestamping in PHY devices"
2014-04-01 18:20:23 +04:00
select NET_PTP_CLASSIFY
2010-07-17 12:49:36 +04:00
help
This allows timestamping of network packets by PHYs with
hardware timestamping capabilities. This option adds some
overhead in the transmit and receive paths.
If you are unsure how to answer this question, answer N.
2005-04-17 02:20:36 +04:00
menuconfig NETFILTER
2006-11-29 04:35:43 +03:00
bool "Network packet filtering framework (Netfilter)"
2005-04-17 02:20:36 +04:00
---help---
Netfilter is a framework for filtering and mangling network packets
that pass through your Linux box.
The most common use of packet filtering is to run your Linux box as
a firewall protecting a local network from the Internet. The type of
firewall provided by this kernel support is called a "packet
filter", which means that it can reject individual network packets
based on type, source, destination etc. The other kind of firewall,
a "proxy-based" one, is more secure but more intrusive and more
bothersome to set up; it inspects the network traffic much more
closely, modifies it and has knowledge about the higher level
protocols, which a packet filter lacks. Moreover, proxy-based
firewalls often require changes to the programs running on the local
clients. Proxy-based firewalls don't need support by the kernel, but
they are often combined with a packet filter, which only works if
you say Y here.
You should also say Y here if you intend to use your Linux box as
the gateway to the Internet for a local network of machines without
globally valid IP addresses. This is called "masquerading": if one
of the computers on your local network wants to send something to
the outside, your box can "masquerade" as that computer, i.e. it
forwards the traffic to the intended outside destination, but
modifies the packets to make it look like they came from the
firewall box itself. It works both ways: if the outside host
replies, the Linux box will silently forward the traffic to the
correct local computer. This way, the computers on your local net
are completely invisible to the outside world, even though they can
reach the outside and can receive replies. It is even possible to
run globally visible servers from within a masqueraded local network
using a mechanism called portforwarding. Masquerading is also often
called NAT (Network Address Translation).
Another use of Netfilter is in transparent proxying: if a machine on
the local network tries to connect to an outside host, your Linux
box can transparently forward the traffic to a local server,
typically a caching proxy server.
Yet another use of Netfilter is building a bridging firewall. Using
a bridge with Network packet filtering enabled makes iptables "see"
the bridged traffic. For filtering on the lower network and Ethernet
protocols over the bridge, use ebtables (under bridge netfilter
configuration).
Various modules exist for netfilter which replace the previous
masquerading (ipmasqadm), packet filtering (ipchains), transparent
proxying, and portforwarding mechanisms. Please see
<file:Documentation/Changes> under "iptables" for the location of
these packages.
if NETFILTER
config NETFILTER_DEBUG
bool "Network packet filtering debugging"
depends on NETFILTER
help
You can say Y here if you want to get additional messages useful in
debugging the netfilter code.
2007-12-18 09:47:05 +03:00
config NETFILTER_ADVANCED
bool "Advanced netfilter configuration"
depends on NETFILTER
default y
help
If you say Y here you can select between all the netfilter modules.
2009-01-26 13:12:25 +03:00
If you say N the more unusual ones will not be shown and the
2007-12-18 09:47:05 +03:00
basic ones needed by most people will default to 'M'.
If unsure, say Y.
2005-04-17 02:20:36 +04:00
config BRIDGE_NETFILTER
2014-09-18 13:29:03 +04:00
tristate "Bridged IP/ARP packets filtering"
2014-09-30 12:59:18 +04:00
depends on BRIDGE
2014-09-18 13:29:03 +04:00
depends on NETFILTER && INET
2007-12-18 09:47:05 +03:00
depends on NETFILTER_ADVANCED
2014-09-18 13:29:03 +04:00
default m
2005-04-17 02:20:36 +04:00
---help---
Enabling this option will let arptables resp. iptables see bridged
ARP resp. IP traffic. If you want a bridging firewall, you probably
want this option enabled.
Enabling or disabling this option doesn't enable or disable
ebtables.
If unsure, say N.
2005-09-17 11:41:21 +04:00
source "net/netfilter/Kconfig"
2005-04-17 02:20:36 +04:00
source "net/ipv4/netfilter/Kconfig"
source "net/ipv6/netfilter/Kconfig"
source "net/decnet/netfilter/Kconfig"
source "net/bridge/netfilter/Kconfig"
endif
2005-08-10 07:14:34 +04:00
source "net/dccp/Kconfig"
2005-04-17 02:20:36 +04:00
source "net/sctp/Kconfig"
2009-02-24 18:30:39 +03:00
source "net/rds/Kconfig"
2006-01-16 18:39:13 +03:00
source "net/tipc/Kconfig"
2005-07-12 08:13:56 +04:00
source "net/atm/Kconfig"
2010-04-02 10:18:33 +04:00
source "net/l2tp/Kconfig"
2008-07-06 08:25:39 +04:00
source "net/802/Kconfig"
2005-07-12 08:13:56 +04:00
source "net/bridge/Kconfig"
net: Distributed Switch Architecture protocol support
Distributed Switch Architecture is a protocol for managing hardware
switch chips. It consists of a set of MII management registers and
commands to configure the switch, and an ethernet header format to
signal which of the ports of the switch a packet was received from
or is intended to be sent to.
The switches that this driver supports are typically embedded in
access points and routers, and a typical setup with a DSA switch
looks something like this:
+-----------+ +-----------+
| | RGMII | |
| +-------+ +------ 1000baseT MDI ("WAN")
| | | 6-port +------ 1000baseT MDI ("LAN1")
| CPU | | ethernet +------ 1000baseT MDI ("LAN2")
| |MIImgmt| switch +------ 1000baseT MDI ("LAN3")
| +-------+ w/5 PHYs +------ 1000baseT MDI ("LAN4")
| | | |
+-----------+ +-----------+
The switch driver presents each port on the switch as a separate
network interface to Linux, polls the switch to maintain software
link state of those ports, forwards MII management interface
accesses to those network interfaces (e.g. as done by ethtool) to
the switch, and exposes the switch's hardware statistics counters
via the appropriate Linux kernel interfaces.
This initial patch supports the MII management interface register
layout of the Marvell 88E6123, 88E6161 and 88E6165 switch chips, and
supports the "Ethertype DSA" packet tagging format.
(There is no officially registered ethertype for the Ethertype DSA
packet format, so we just grab a random one. The ethertype to use
is programmed into the switch, and the switch driver uses the value
of ETH_P_EDSA for this, so this define can be changed at any time in
the future if the one we chose is allocated to another protocol or
if Ethertype DSA gets its own officially registered ethertype, and
everything will continue to work.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tested-by: Nicolas Pitre <nico@marvell.com>
Tested-by: Byron Bradley <byron.bbradley@gmail.com>
Tested-by: Tim Ellis <tim.ellis@mac.com>
Tested-by: Peter van Valderen <linux@ddcrew.com>
Tested-by: Dirk Teurlings <dirk@upexia.nl>
Signed-off-by: David S. Miller <davem@davemloft.net>
2008-10-07 17:44:02 +04:00
source "net/dsa/Kconfig"
2005-07-12 08:13:56 +04:00
source "net/8021q/Kconfig"
2005-04-17 02:20:36 +04:00
source "net/decnet/Kconfig"
source "net/llc/Kconfig"
source "net/ipx/Kconfig"
source "drivers/net/appletalk/Kconfig"
2005-07-12 08:13:56 +04:00
source "net/x25/Kconfig"
source "net/lapb/Kconfig"
2009-01-23 06:00:25 +03:00
source "net/phonet/Kconfig"
2014-07-11 12:24:18 +04:00
source "net/6lowpan/Kconfig"
2009-06-08 16:18:48 +04:00
source "net/ieee802154/Kconfig"
2012-05-16 00:50:20 +04:00
source "net/mac802154/Kconfig"
2005-04-17 02:20:36 +04:00
source "net/sched/Kconfig"
2008-11-21 07:52:10 +03:00
source "net/dcb/Kconfig"
2010-08-04 18:16:33 +04:00
source "net/dns_resolver/Kconfig"
2010-12-13 14:19:28 +03:00
source "net/batman-adv/Kconfig"
2011-10-26 06:26:31 +04:00
source "net/openvswitch/Kconfig"
VSOCK: Introduce VM Sockets
VM Sockets allows communication between virtual machines and the hypervisor.
User level applications both in a virtual machine and on the host can use the
VM Sockets API, which facilitates fast and efficient communication between
guest virtual machines and their host. A socket address family, designed to be
compatible with UDP and TCP at the interface level, is provided.
Today, VM Sockets is used by various VMware Tools components inside the guest
for zero-config, network-less access to VMware host services. In addition to
this, VMware's users are using VM Sockets for various applications, where
network access of the virtual machine is restricted or non-existent. Examples
of this are VMs communicating with device proxies for proprietary hardware
running as host applications and automated testing of applications running
within virtual machines.
The VMware VM Sockets are similar to other socket types, like Berkeley UNIX
socket interface. The VM Sockets module supports both connection-oriented
stream sockets like TCP, and connectionless datagram sockets like UDP. The VM
Sockets protocol family is defined as "AF_VSOCK" and the socket operations
split for SOCK_DGRAM and SOCK_STREAM.
For additional information about the use of VM Sockets, please refer to the
VM Sockets Programming Guide available at:
https://www.vmware.com/support/developer/vmci-sdk/
Signed-off-by: George Zhang <georgezhang@vmware.com>
Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Andy king <acking@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-02-06 18:23:56 +04:00
source "net/vmw_vsock/Kconfig"
2013-03-21 20:33:48 +04:00
source "net/netlink/Kconfig"
2013-05-24 01:02:52 +04:00
source "net/mpls/Kconfig"
2013-10-31 00:10:47 +04:00
source "net/hsr/Kconfig"
2014-11-28 16:34:17 +03:00
source "net/switchdev/Kconfig"
2005-04-17 02:20:36 +04:00
2010-03-24 22:13:54 +03:00
config RPS
2014-12-20 23:41:11 +03:00
bool
2013-11-22 02:32:01 +04:00
depends on SMP && SYSFS
2010-03-24 22:13:54 +03:00
default y
2011-01-19 14:03:53 +03:00
config RFS_ACCEL
2014-12-20 23:41:11 +03:00
bool
2013-08-30 11:39:53 +04:00
depends on RPS
2011-01-19 14:03:53 +03:00
select CPU_RMAP
default y
2010-11-26 11:36:09 +03:00
config XPS
2014-12-20 23:41:11 +03:00
bool
2013-11-22 02:32:01 +04:00
depends on SMP
2010-11-26 11:36:09 +03:00
default y
2013-12-29 20:27:11 +04:00
config CGROUP_NET_PRIO
2014-02-08 19:36:58 +04:00
bool "Network priority cgroup"
2011-11-22 09:10:51 +04:00
depends on CGROUPS
---help---
Cgroup subsystem for use in assigning processes to network priorities on
2013-12-29 20:27:11 +04:00
a per-interface basis.
2011-11-22 09:10:51 +04:00
2013-12-29 21:27:10 +04:00
config CGROUP_NET_CLASSID
2014-12-20 23:41:11 +03:00
bool "Network classid cgroup"
2013-12-29 21:27:10 +04:00
depends on CGROUPS
---help---
Cgroup subsystem for use as general purpose socket classid marker that is
being used in cls_cgroup and for netfilter matching.
2013-08-01 07:10:25 +04:00
config NET_RX_BUSY_POLL
2014-12-20 23:41:11 +03:00
bool
2013-06-14 17:33:46 +04:00
default y
2013-06-10 12:39:50 +04:00
2011-11-28 20:33:09 +04:00
config BQL
2014-12-20 23:41:11 +03:00
bool
2011-11-28 20:33:09 +04:00
depends on SYSFS
select DQL
default y
2011-04-20 13:27:32 +04:00
config BPF_JIT
bool "enable BPF Just In Time compiler"
depends on HAVE_BPF_JIT
2011-04-29 21:20:53 +04:00
depends on MODULES
2011-04-20 13:27:32 +04:00
---help---
Berkeley Packet Filter filtering capabilities are normally handled
by an interpreter. This option allows kernel to generate a native
code when filter is loaded in memory. This should speedup
packet sniffing (libpcap/tcpdump). Note : Admin should enable
this feature changing /proc/sys/net/core/bpf_jit_enable
2013-05-20 08:02:32 +04:00
config NET_FLOW_LIMIT
2014-12-20 23:41:11 +03:00
bool
2013-05-20 08:02:32 +04:00
depends on RPS
default y
---help---
The network stack has to drop packets when a receive processing CPU's
backlog reaches netdev_max_backlog. If a few out of many active flows
generate the vast majority of load, drop their traffic earlier to
maintain capacity for the other flows. This feature provides servers
with many clients some protection against DoS by a single (spoofed)
flow that greatly exceeds average workload.
2005-04-17 02:20:36 +04:00
menu "Network testing"
config NET_PKTGEN
tristate "Packet Generator (USE WITH CAUTION)"
2013-07-29 15:44:15 +04:00
depends on INET && PROC_FS
2005-04-17 02:20:36 +04:00
---help---
This module will inject preconfigured packets, at a configurable
rate, out of a given interface. It is used for network interface
stress testing and performance analysis. If you don't understand
what was just said, you don't need it: say N.
Documentation on how to use the packet generator can be found
at <file:Documentation/networking/pktgen.txt>.
To compile this code as a module, choose M here: the
module will be called pktgen.
2006-06-06 04:30:32 +04:00
config NET_TCPPROBE
tristate "TCP connection probing"
2012-10-02 22:19:40 +04:00
depends on INET && PROC_FS && KPROBES
2006-06-06 04:30:32 +04:00
---help---
This module allows for capturing the changes to TCP connection
2006-06-09 10:42:09 +04:00
state in response to incoming packets. It is used for debugging
2006-06-06 04:30:32 +04:00
TCP congestion avoidance modules. If you don't understand
what was just said, you don't need it: say N.
2006-09-26 10:47:14 +04:00
Documentation on how to use TCP connection probing can be found
2010-11-15 22:55:34 +03:00
at:
http://www.linuxfoundation.org/collaborate/workgroups/networking/tcpprobe
2006-06-06 04:30:32 +04:00
To compile this code as a module, choose M here: the
module will be called tcp_probe.
2009-03-11 12:53:16 +03:00
config NET_DROP_MONITOR
2012-05-17 14:04:00 +04:00
tristate "Network packet drop alerting service"
2012-10-02 22:19:40 +04:00
depends on INET && TRACEPOINTS
2009-03-11 12:53:16 +03:00
---help---
This feature provides an alerting service to userspace in the
event that packets are discarded in the network stack. Alerts
are broadcast via netlink socket to any listening user space
process. If you don't need network drop alerts, or if you are ok
just checking the various proc files and other utilities for
drop statistics, say N here.
2005-04-17 02:20:36 +04:00
endmenu
endmenu
source "net/ax25/Kconfig"
2007-11-17 02:52:17 +03:00
source "net/can/Kconfig"
2005-04-17 02:20:36 +04:00
source "net/irda/Kconfig"
source "net/bluetooth/Kconfig"
2007-04-27 02:48:28 +04:00
source "net/rxrpc/Kconfig"
2006-01-21 02:46:55 +03:00
2006-08-04 14:38:38 +04:00
config FIB_RULES
bool
2008-07-24 20:20:09 +04:00
menuconfig WIRELESS
bool "Wireless"
2007-05-10 17:46:01 +04:00
depends on !S390
2008-07-24 20:20:09 +04:00
default y
if WIRELESS
2007-04-23 23:19:12 +04:00
source "net/wireless/Kconfig"
2007-05-05 22:45:53 +04:00
source "net/mac80211/Kconfig"
2007-04-23 23:19:12 +04:00
2008-07-24 20:20:09 +04:00
endif # WIRELESS
2007-04-23 23:19:12 +04:00
2008-12-24 03:18:24 +03:00
source "net/wimax/Kconfig"
2007-05-07 11:34:20 +04:00
source "net/rfkill/Kconfig"
2007-07-11 02:57:28 +04:00
source "net/9p/Kconfig"
2010-03-30 17:56:28 +04:00
source "net/caif/Kconfig"
2010-04-07 02:14:15 +04:00
source "net/ceph/Kconfig"
2011-07-02 02:31:33 +04:00
source "net/nfc/Kconfig"
2010-03-30 17:56:28 +04:00
2007-05-07 11:34:20 +04:00
2005-07-12 08:13:56 +04:00
endif # if NET
2012-05-21 22:45:37 +04:00
# Used by archs to tell that they support BPF_JIT
config HAVE_BPF_JIT
bool