diff options
Diffstat (limited to 'Documentation/networking')
22 files changed, 452 insertions, 173 deletions
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index 8a8d3d96f6c6..ccf94677b240 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt @@ -32,7 +32,7 @@ compatible interfaces. Once found, it will create subfolders in the /sys directories of each supported interface, e.g. # ls /sys/class/net/eth0/batman_adv/ -# iface_status mesh_iface +# elp_interval iface_status mesh_iface throughput_override If an interface does not have the "batman_adv" subfolder it prob- ably is not supported. Not supported interfaces are: loopback, @@ -71,17 +71,19 @@ All mesh wide settings can be found in batman's own interface folder: # ls /sys/class/net/bat0/mesh/ -#aggregated_ogms distributed_arp_table gw_sel_class orig_interval -#ap_isolation fragmentation hop_penalty routing_algo -#bonding gw_bandwidth isolation_mark vlan0 -#bridge_loop_avoidance gw_mode log_level +# aggregated_ogms fragmentation isolation_mark routing_algo +# ap_isolation gw_bandwidth log_level vlan0 +# bonding gw_mode multicast_mode +# bridge_loop_avoidance gw_sel_class network_coding +# distributed_arp_table hop_penalty orig_interval There is a special folder for debugging information: # ls /sys/kernel/debug/batman_adv/bat0/ -# bla_backbone_table log transtable_global -# bla_claim_table originators transtable_local -# gateways socket +# bla_backbone_table log neighbors transtable_local +# bla_claim_table mcast_flags originators +# dat_cache nc socket +# gateways nc_nodes transtable_global Some of the files contain all sort of status information regard- ing the mesh network. For example, you can view the table of @@ -159,13 +161,16 @@ file in debugfs The additional debug output is by default disabled. It can be en- abled during run time. Following log_levels are defined: -0 - All debug output disabled -1 - Enable messages related to routing / flooding / broadcasting -2 - Enable messages related to route added / changed / deleted -4 - Enable messages related to translation table operations -8 - Enable messages related to bridge loop avoidance -16 - Enable messaged related to DAT, ARP snooping and parsing -31 - Enable all messages + 0 - All debug output disabled + 1 - Enable messages related to routing / flooding / broadcasting + 2 - Enable messages related to route added / changed / deleted + 4 - Enable messages related to translation table operations + 8 - Enable messages related to bridge loop avoidance + 16 - Enable messages related to DAT, ARP snooping and parsing + 32 - Enable messages related to network coding + 64 - Enable messages related to multicast +128 - Enable messages related to throughput meter +255 - Enable all messages The debug output can be changed at runtime using the file /sys/class/net/bat0/mesh/log_level. e.g. diff --git a/Documentation/networking/cdc_mbim.txt b/Documentation/networking/cdc_mbim.txt index a15ea602aa52..b9482ca10254 100644 --- a/Documentation/networking/cdc_mbim.txt +++ b/Documentation/networking/cdc_mbim.txt @@ -38,7 +38,7 @@ Basic usage =========== MBIM functions are inactive when unmanaged. The cdc_mbim driver only -provides an userspace interface to the MBIM control channel, and will +provides a userspace interface to the MBIM control channel, and will not participate in the management of the function. This implies that a userspace MBIM management application always is required to enable a MBIM function. @@ -200,7 +200,7 @@ structure described in section 10.5.29 of [1]. The DSS VLAN subdevices are used as a practical interface between the shared MBIM data channel and a MBIM DSS aware userspace application. It is not intended to be presented as-is to an end user. The -assumption is that an userspace application initiating a DSS session +assumption is that a userspace application initiating a DSS session also takes care of the necessary framing of the DSS data, presenting the stream to the end user in an appropriate way for the stream type. diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt index 63912ef34606..b8b40753133e 100644 --- a/Documentation/networking/dsa/dsa.txt +++ b/Documentation/networking/dsa/dsa.txt @@ -295,7 +295,6 @@ DSA currently leverages the following subsystems: - MDIO/PHY library: drivers/net/phy/phy.c, mdio_bus.c - Switchdev: net/switchdev/* - Device Tree for various of_* functions -- HWMON: drivers/hwmon/* MDIO/PHY library ---------------- @@ -349,12 +348,6 @@ Documentation/devicetree/bindings/net/dsa/dsa.txt. PHY/MDIO library helper functions such as of_get_phy_mode(), of_phy_connect() are also used to query per-port PHY specific details: interface connection, MDIO bus location etc.. -HWMON ------ - -Some switch drivers feature internal temperature sensors which are exposed as -regular HWMON devices in /sys/class/hwmon/. - Driver development ================== @@ -495,23 +488,6 @@ Power management BR_STATE_DISABLED and propagating changes to the hardware if this port is disabled while being a bridge member -Hardware monitoring -------------------- - -These callbacks are only available if CONFIG_NET_DSA_HWMON is enabled: - -- get_temp: this function queries the given switch for its temperature - -- get_temp_limit: this function returns the switch current maximum temperature - limit - -- set_temp_limit: this function configures the maximum temperature limit allowed - -- get_temp_alarm: this function returns the critical temperature threshold - returning an alarm notification - -See Documentation/hwmon/sysfs-interface for details. - Bridge layer ------------ diff --git a/Documentation/networking/gtp.txt b/Documentation/networking/gtp.txt new file mode 100644 index 000000000000..93e96750f103 --- /dev/null +++ b/Documentation/networking/gtp.txt @@ -0,0 +1,135 @@ +The Linux kernel GTP tunneling module +====================================================================== +Documentation by Harald Welte <laforge@gnumonks.org> + +In 'drivers/net/gtp.c' you are finding a kernel-level implementation +of a GTP tunnel endpoint. + +== What is GTP == + +GTP is the Generic Tunnel Protocol, which is a 3GPP protocol used for +tunneling User-IP payload between a mobile station (phone, modem) +and the interconnection between an external packet data network (such +as the internet). + +So when you start a 'data connection' from your mobile phone, the +phone will use the control plane to signal for the establishment of +such a tunnel between that external data network and the phone. The +tunnel endpoints thus reside on the phone and in the gateway. All +intermediate nodes just transport the encapsulated packet. + +The phone itself does not implement GTP but uses some other +technology-dependent protocol stack for transmitting the user IP +payload, such as LLC/SNDCP/RLC/MAC. + +At some network element inside the cellular operator infrastructure +(SGSN in case of GPRS/EGPRS or classic UMTS, hNodeB in case of a 3G +femtocell, eNodeB in case of 4G/LTE), the cellular protocol stacking +is translated into GTP *without breaking the end-to-end tunnel*. So +intermediate nodes just perform some specific relay function. + +At some point the GTP packet ends up on the so-called GGSN (GSM/UMTS) +or P-GW (LTE), which terminates the tunnel, decapsulates the packet +and forwards it onto an external packet data network. This can be +public internet, but can also be any private IP network (or even +theoretically some non-IP network like X.25). + +You can find the protocol specification in 3GPP TS 29.060, available +publicly via the 3GPP website at http://www.3gpp.org/DynaReport/29060.htm + +A direct PDF link to v13.6.0 is provided for convenience below: +http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/13.06.00_60/ts_129060v130600p.pdf + +== The Linux GTP tunnelling module == + +The module implements the function of a tunnel endpoint, i.e. it is +able to decapsulate tunneled IP packets in the uplink originated by +the phone, and encapsulate raw IP packets received from the external +packet network in downlink towards the phone. + +It *only* implements the so-called 'user plane', carrying the User-IP +payload, called GTP-U. It does not implement the 'control plane', +which is a signaling protocol used for establishment and teardown of +GTP tunnels (GTP-C). + +So in order to have a working GGSN/P-GW setup, you will need a +userspace program that implements the GTP-C protocol and which then +uses the netlink interface provided by the GTP-U module in the kernel +to configure the kernel module. + +This split architecture follows the tunneling modules of other +protocols, e.g. PPPoE or L2TP, where you also run a userspace daemon +to handle the tunnel establishment, authentication etc. and only the +data plane is accelerated inside the kernel. + +Don't be confused by terminology: The GTP User Plane goes through +kernel accelerated path, while the GTP Control Plane goes to +Userspace :) + +The official homepge of the module is at +https://osmocom.org/projects/linux-kernel-gtp-u/wiki + +== Userspace Programs with Linux Kernel GTP-U support == + +At the time of this writing, there are at least two Free Software +implementations that implement GTP-C and can use the netlink interface +to make use of the Linux kernel GTP-U support: + +* OpenGGSN (classic 2G/3G GGSN in C): + https://osmocom.org/projects/openggsn/wiki/OpenGGSN + +* ergw (GGSN + P-GW in Erlang): + https://github.com/travelping/ergw + +== Userspace Library / Command Line Utilities == + +There is a userspace library called 'libgtpnl' which is based on +libmnl and which implements a C-language API towards the netlink +interface provided by the Kernel GTP module: + +http://git.osmocom.org/libgtpnl/ + +== Protocol Versions == + +There are two different versions of GTP-U: v0 and v1. Both are +implemented in the Kernel GTP module. Version 0 is a legacy version, +and deprecated from recent 3GPP specifications. + +There are three versions of GTP-C: v0, v1, and v2. As the kernel +doesn't implement GTP-C, we don't have to worry about this. It's the +responsibility of the control plane implementation in userspace to +implement that. + +== IPv6 == + +The 3GPP specifications indicate either IPv4 or IPv6 can be used both +on the inner (user) IP layer, or on the outer (transport) layer. + +Unfortunately, the Kernel module currently supports IPv6 neither for +the User IP payload, nor for the outer IP layer. Patches or other +Contributions to fix this are most welcome! + +== Mailing List == + +If yo have questions regarding how to use the Kernel GTP module from +your own software, or want to contribute to the code, please use the +osmocom-net-grps mailing list for related discussion. The list can be +reached at osmocom-net-gprs@lists.osmocom.org and the mailman +interface for managign your subscription is at +https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs + +== Issue Tracker == + +The Osmocom project maintains an issue tracker for the Kernel GTP-U +module at +https://osmocom.org/projects/linux-kernel-gtp-u/issues + +== History / Acknowledgements == + +The Module was originally created in 2012 by Harald Welte, but never +completed. Pablo came in to finish the mess Harald left behind. But +doe to a lack of user interest, it never got merged. + +In 2015, Andreas Schultz came to the rescue and fixed lots more bugs, +extended it with new features and finally pushed all of us to get it +mainline, where it was merged in 4.7.0. diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index aa69ccc481db..c4114346f054 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -4,20 +4,20 @@ Introduction ============ -The IEEE 802.15.4 working group focuses on standardization of bottom -two layers: Medium Access Control (MAC) and Physical (PHY). And there +The IEEE 802.15.4 working group focuses on standardization of the bottom +two layers: Medium Access Control (MAC) and Physical access (PHY). And there are mainly two options available for upper layers: - ZigBee - proprietary protocol from the ZigBee Alliance - 6LoWPAN - IPv6 networking over low rate personal area networks -The linux-wpan project goal is to provide a complete implementation +The goal of the Linux-wpan is to provide a complete implementation of the IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack of protocols for organizing Low-Rate Wireless Personal Area Networks. The stack is composed of three main parts: - IEEE 802.15.4 layer; We have chosen to use plain Berkeley socket API, - the generic Linux networking stack to transfer IEEE 802.15.4 messages - and a special protocol over genetlink for configuration/management + the generic Linux networking stack to transfer IEEE 802.15.4 data + messages and a special protocol over netlink for configuration/management - MAC - provides access to shared channel and reliable data delivery - PHY - represents device drivers @@ -33,15 +33,13 @@ include/net/af_ieee802154.h header or in the special header in the userspace package (see either http://wpan.cakelab.org/ or the git tree at https://github.com/linux-wpan/wpan-tools). -One can use SOCK_RAW for passing raw data towards device xmit function. YMMV. - Kernel side ============= Like with WiFi, there are several types of devices implementing IEEE 802.15.4. 1) 'HardMAC'. The MAC layer is implemented in the device itself, the device - exports MLME and data API. + exports a management (e.g. MLME) and data API. 2) 'SoftMAC' or just radio. These types of devices are just radio transceivers possibly with some kinds of acceleration like automatic CRC computation and comparation, automagic ACK handling, address matching, etc. @@ -106,7 +104,7 @@ Fake drivers In addition there is a driver available which simulates a real device with SoftMAC (fakelb - IEEE 802.15.4 loopback driver) interface. This option -provides possibility to test and debug stack without usage of real hardware. +provides a possibility to test and debug the stack without usage of real hardware. See sources in drivers/net/ieee802154 folder for more details. @@ -125,17 +123,15 @@ to support the IPv6 minimum MTU requirement [RFC2460], and stateless header compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down to (in the best case) several bytes. -In Semptember 2011 the standard update was published - [RFC6282]. +In September 2011 the standard update was published - [RFC6282]. It deprecates HC1 and HC2 compression and defines IPHC encoding format which is used in this Linux implementation. All the code related to 6lowpan you may find in files: net/6lowpan/* and net/ieee802154/6lowpan/* -To setup 6lowpan interface you need (busybox release > 1.17.0): -1. Add IEEE802.15.4 interface and initialize PANid; +To setup a 6LoWPAN interface you need: +1. Add IEEE802.15.4 interface and set channel and PAN ID; 2. Add 6lowpan interface by command like: # ip link add link wpan0 name lowpan0 type lowpan -3. Set MAC (if needs): - # ip link set lowpan0 address de:ad:be:ef:ca:fe:ba:be -4. Bring up 'lowpan0' interface +3. Bring up 'lowpan0' interface diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 3db8c67d2c8d..fc73eeb7b3b8 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -246,21 +246,12 @@ tcp_dsack - BOOLEAN Allows TCP to send "duplicate" SACKs. tcp_early_retrans - INTEGER - Enable Early Retransmit (ER), per RFC 5827. ER lowers the threshold - for triggering fast retransmit when the amount of outstanding data is - small and when no previously unsent data can be transmitted (such - that limited transmit could be used). Also controls the use of - Tail loss probe (TLP) that converts RTOs occurring due to tail - losses into fast recovery (draft-dukkipati-tcpm-tcp-loss-probe-01). + Tail loss probe (TLP) converts RTOs occurring due to tail + losses into fast recovery (draft-ietf-tcpm-rack). Note that + TLP requires RACK to function properly (see tcp_recovery below) Possible values: - 0 disables ER - 1 enables ER - 2 enables ER but delays fast recovery and fast retransmit - by a fourth of RTT. This mitigates connection falsely - recovers when network has a small degree of reordering - (less than 3 packets). - 3 enables delayed ER and TLP. - 4 enables TLP only. + 0 disables TLP + 3 or 4 enables TLP Default: 3 tcp_ecn - INTEGER @@ -610,8 +601,13 @@ tcp_syn_retries - INTEGER with the current initial RTO of 1second. With this the final timeout for an active TCP connection attempt will happen after 127seconds. -tcp_timestamps - BOOLEAN - Enable timestamps as defined in RFC1323. +tcp_timestamps - INTEGER +Enable timestamps as defined in RFC1323. + 0: Disabled. + 1: Enable timestamps as defined in RFC1323 and use random offset for + each connection rather than only using the current time. + 2: Like 1, but without random offsets. + Default: 1 tcp_min_tso_segs - INTEGER Minimal number of segments per TSO frame. @@ -707,18 +703,6 @@ tcp_thin_linear_timeouts - BOOLEAN Documentation/networking/tcp-thin.txt Default: 0 -tcp_thin_dupack - BOOLEAN - Enable dynamic triggering of retransmissions after one dupACK - for thin streams. If set, a check is performed upon reception - of a dupACK to determine if the stream is thin (less than 4 - packets in flight). As long as the stream is found to be thin, - data is retransmitted on the first received dupACK. This - improves retransmission latency for non-aggressive thin - streams, often found to be time-dependent. - For more information on thin streams, see - Documentation/networking/tcp-thin.txt - Default: 0 - tcp_limit_output_bytes - INTEGER Controls TCP Small Queue limit per tcp socket. TCP bulk sender tends to increase packets in flight until it @@ -737,6 +721,13 @@ tcp_challenge_ack_limit - INTEGER UDP variables: +udp_l3mdev_accept - BOOLEAN + Enabling this option allows a "global" bound socket to work + across L3 master domains (e.g., VRFs) with packets capable of + being received regardless of the L3 domain in which they + originated. Only valid when the kernel was compiled with + CONFIG_NET_L3_MASTER_DEV. + udp_mem - vector of 3 INTEGERs: min, pressure, max Number of pages allowed for queueing by all UDP sockets. @@ -838,6 +829,15 @@ ip_local_reserved_ports - list of comma separated ranges Default: Empty +ip_unprivileged_port_start - INTEGER + This is a per-namespace sysctl. It defines the first + unprivileged port in the network namespace. Privileged ports + require root or CAP_NET_BIND_SERVICE in order to bind to them. + To disable all privileged ports, set this to 0. It may not + overlap with the ip_local_reserved_ports range. + + Default: 1024 + ip_nonlocal_bind - BOOLEAN If set, allows processes to bind() to non-local IP addresses, which can be quite useful - but may break some applications. @@ -967,6 +967,21 @@ igmp_qrv - INTEGER Default: 2 (as specified by RFC2236 8.1) Minimum: 1 (as specified by RFC6636 4.5) +force_igmp_version - INTEGER + 0 - (default) No enforcement of a IGMP version, IGMPv1/v2 fallback + allowed. Will back to IGMPv3 mode again if all IGMPv1/v2 Querier + Present timer expires. + 1 - Enforce to use IGMP version 1. Will also reply IGMPv1 report if + receive IGMPv2/v3 query. + 2 - Enforce to use IGMP version 2. Will fallback to IGMPv1 if receive + IGMPv1 query message. Will reply report if receive IGMPv3 query. + 3 - Enforce to use IGMP version 3. The same react with default 0. + + Note: this is not the same with force_mld_version because IGMPv3 RFC3376 + Security Considerations does not have clear description that we could + ignore other version messages completely as MLDv2 RFC3810. So make + this value as default 0 is recommended. + conf/interface/* changes special settings per interface (where "interface" is the name of your network interface) @@ -1714,6 +1729,15 @@ drop_unsolicited_na - BOOLEAN By default this is turned off. +enhanced_dad - BOOLEAN + Include a nonce option in the IPv6 neighbor solicitation messages used for + duplicate address detection per RFC7527. A received DAD NS will only signal + a duplicate address if the nonce is different. This avoids any false + detection of duplicates due to loopback of the NS messages that we send. + The nonce option will be sent on an interface unless both of + conf/{all,interface}/enhanced_dad are set to FALSE. + Default: TRUE + icmp/*: ratelimit - INTEGER Limit the maximal rates for sending ICMPv6 packets. diff --git a/Documentation/networking/kcm.txt b/Documentation/networking/kcm.txt index 3476ede5bc2c..9a513295b07c 100644 --- a/Documentation/networking/kcm.txt +++ b/Documentation/networking/kcm.txt @@ -272,7 +272,7 @@ on the socket thus waking up the application thread. When the application sees the error (which may just be a disconnect) it should unattach the socket from KCM and then close it. It is assumed that once an error is posted on the TCP socket the data stream is unrecoverable (i.e. an error -may have occurred in in the middle of receiving a messssge). +may have occurred in the middle of receiving a messssge). TCP connection monitoring ------------------------- diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt index 4650a00ed012..9bc271cdc9a8 100644 --- a/Documentation/networking/l2tp.txt +++ b/Documentation/networking/l2tp.txt @@ -177,10 +177,10 @@ setsockopt on the PPPoX socket to set a debug mask. The following debug mask bits are available: -PPPOL2TP_MSG_DEBUG verbose debug (if compiled in) -PPPOL2TP_MSG_CONTROL userspace - kernel interface -PPPOL2TP_MSG_SEQ sequence numbers handling -PPPOL2TP_MSG_DATA data packets +L2TP_MSG_DEBUG verbose debug (if compiled in) +L2TP_MSG_CONTROL userspace - kernel interface +L2TP_MSG_SEQ sequence numbers handling +L2TP_MSG_DATA data packets If enabled, files under a l2tp debugfs directory can be used to dump kernel state about L2TP tunnels and sessions. To access it, the diff --git a/Documentation/networking/mac80211_hwsim/README b/Documentation/networking/mac80211_hwsim/README index 24ac91d56698..3566a725d19c 100644 --- a/Documentation/networking/mac80211_hwsim/README +++ b/Documentation/networking/mac80211_hwsim/README @@ -60,7 +60,7 @@ modprobe mac80211_hwsim hostapd hostapd.conf # Run wpa_supplicant (station) for wlan1 -wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf +wpa_supplicant -Dnl80211 -iwlan1 -c wpa_supplicant.conf More test cases are available in hostap.git: diff --git a/Documentation/networking/mpls-sysctl.txt b/Documentation/networking/mpls-sysctl.txt index 9ed15f86c17c..15d8d16934fd 100644 --- a/Documentation/networking/mpls-sysctl.txt +++ b/Documentation/networking/mpls-sysctl.txt @@ -5,8 +5,8 @@ platform_labels - INTEGER possible to configure forwarding for label values equal to or greater than the number of platform labels. - A dense utliziation of the entries in the platform label table - is possible and expected aas the platform labels are locally + A dense utilization of the entries in the platform label table + is possible and expected as the platform labels are locally allocated. If the number of platform label table entries is set to 0 no diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt index 30409a36e95d..296ea00fd3eb 100644 --- a/Documentation/networking/netconsole.txt +++ b/Documentation/networking/netconsole.txt @@ -200,7 +200,7 @@ priority messages to the console. You can change this at runtime using: or by specifying "debug" on the kernel command line at boot, to send all kernel messages to the console. A specific value for this parameter can also be set using the "loglevel" kernel boot option. See the -dmesg(8) man page and Documentation/kernel-parameters.txt for details. +dmesg(8) man page and Documentation/admin-guide/kernel-parameters.rst for details. Netconsole was designed to be as instantaneous as possible, to enable the logging of even the most critical kernel bugs. It works diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt index a20b2fae942b..247a30ba8e17 100644 --- a/Documentation/networking/netdev-FAQ.txt +++ b/Documentation/networking/netdev-FAQ.txt @@ -136,14 +136,14 @@ A: Normally Greg Kroah-Hartman collects stable commits himself, but Q: I see a network patch and I think it should be backported to stable. Should I request it via "stable@vger.kernel.org" like the references in - the kernel's Documentation/stable_kernel_rules.txt file say? + the kernel's Documentation/process/stable-kernel-rules.rst file say? A: No, not for networking. Check the stable queues as per above 1st to see if it is already queued. If not, then send a mail to netdev, listing the upstream commit ID and why you think it should be a stable candidate. Before you jump to go do the above, do note that the normal stable rules - in Documentation/stable_kernel_rules.txt still apply. So you need to + in Documentation/process/stable-kernel-rules.rst still apply. So you need to explicitly indicate why it is a critical fix and exactly what users are impacted. In addition, you need to convince yourself that you _really_ think it has been overlooked, vs. having been considered and rejected. @@ -165,7 +165,7 @@ A: No. See above answer. In short, if you think it really belongs in If you think there is some valid information relating to it being in stable that does _not_ belong in the commit log, then use the three - dash marker line as described in Documentation/SubmittingPatches to + dash marker line as described in Documentation/process/submitting-patches.rst to temporarily embed that information into the patch that you send. Q: Someone said that the comment style and coding convention is different @@ -220,5 +220,5 @@ A: Attention to detail. Re-read your own work as if you were the If it is your first patch, mail it to yourself so you can test apply it to an unpatched tree to confirm infrastructure didn't mangle it. - Finally, go back and read Documentation/SubmittingPatches to be + Finally, go back and read Documentation/process/submitting-patches.rst to be sure you are not repeating some common mistake documented there. diff --git a/Documentation/networking/netfilter-sysctl.txt b/Documentation/networking/netfilter-sysctl.txt new file mode 100644 index 000000000000..55791e50e169 --- /dev/null +++ b/Documentation/networking/netfilter-sysctl.txt @@ -0,0 +1,10 @@ +/proc/sys/net/netfilter/* Variables: + +nf_log_all_netns - BOOLEAN + 0 - disabled (default) + not 0 - enabled + + By default, only init_net namespace can log packets into kernel log + with LOG target; this aims to prevent containers from flooding host + kernel log. If enabled, this target also works in other network + namespaces. This variable is only accessible from init_net. diff --git a/Documentation/networking/nf_conntrack-sysctl.txt b/Documentation/networking/nf_conntrack-sysctl.txt index 433b6724797a..497d668288f9 100644 --- a/Documentation/networking/nf_conntrack-sysctl.txt +++ b/Documentation/networking/nf_conntrack-sysctl.txt @@ -96,6 +96,17 @@ nf_conntrack_max - INTEGER Size of connection tracking table. Default value is nf_conntrack_buckets value * 4. +nf_conntrack_default_on - BOOLEAN + 0 - don't register conntrack in new net namespaces + 1 - register conntrack in new net namespaces (default) + + This controls wheter newly created network namespaces have connection + tracking enabled by default. It will be enabled automatically + regardless of this setting if the new net namespace requires + connection tracking, e.g. when NAT rules are created. + This setting is only visible in initial user namespace, it has no + effect on existing namespaces. + nf_conntrack_tcp_be_liberal - BOOLEAN 0 - disabled (default) not 0 - enabled diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index daa015af16a0..f3b9e507ab05 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -565,7 +565,7 @@ TPACKET_V1 --> TPACKET_V2: (void *)hdr + TPACKET_ALIGN(sizeof(struct tpacket_hdr)) TPACKET_V2 --> TPACKET_V3: - - Flexible buffer implementation: + - Flexible buffer implementation for RX_RING: 1. Blocks can be configured with non-static frame-size 2. Read/poll is at a block-level (as opposed to packet-level) 3. Added poll timeout to avoid indefinite user-space wait @@ -574,7 +574,12 @@ TPACKET_V2 --> TPACKET_V3: 4.1 block::timeout 4.2 tpkt_hdr::sk_rxhash - RX Hash data available in user space - - Currently only RX_RING available + - TX_RING semantics are conceptually similar to TPACKET_V2; + use tpacket3_hdr instead of tpacket2_hdr, and TPACKET3_HDRLEN + instead of TPACKET2_HDRLEN. In the current implementation, + the tp_next_offset field in the tpacket3_hdr MUST be set to + zero, indicating that the ring does not hold variable sized frames. + Packets with non-zero values of tp_next_offset will be dropped. ------------------------------------------------------------------------------- + AF_PACKET fanout mode diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index 7ab9404a8412..16f90d817224 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -65,6 +65,83 @@ The MDIO bus drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/") +(RG)MII/electrical interface considerations + + The Reduced Gigabit Medium Independent Interface (RGMII) is a 12-pin + electrical signal interface using a synchronous 125Mhz clock signal and several + data lines. Due to this design decision, a 1.5ns to 2ns delay must be added + between the clock line (RXC or TXC) and the data lines to let the PHY (clock + sink) have enough setup and hold times to sample the data lines correctly. The + PHY library offers different types of PHY_INTERFACE_MODE_RGMII* values to let + the PHY driver and optionally the MAC driver, implement the required delay. The + values of phy_interface_t must be understood from the perspective of the PHY + device itself, leading to the following: + + * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any + internal delay by itself, it assumes that either the Ethernet MAC (if capable + or the PCB traces) insert the correct 1.5-2ns delay + + * PHY_INTERFACE_MODE_RGMII_TXID: the PHY should insert an internal delay + for the transmit data lines (TXD[3:0]) processed by the PHY device + + * PHY_INTERFACE_MODE_RGMII_RXID: the PHY should insert an internal delay + for the receive data lines (RXD[3:0]) processed by the PHY device + + * PHY_INTERFACE_MODE_RGMII_ID: the PHY should insert internal delays for + both transmit AND receive data lines from/to the PHY device + + Whenever possible, use the PHY side RGMII delay for these reasons: + + * PHY devices may offer sub-nanosecond granularity in how they allow a + receiver/transmitter side delay (e.g: 0.5, 1.0, 1.5ns) to be specified. Such + precision may be required to account for differences in PCB trace lengths + + * PHY devices are typically qualified for a large range of applications + (industrial, medical, automotive...), and they provide a constant and + reliable delay across temperature/pressure/voltage ranges + + * PHY device drivers in PHYLIB being reusable by nature, being able to + configure correctly a specified delay enables more designs with similar delay + requirements to be operate correctly + + For cases where the PHY is not capable of providing this delay, but the + Ethernet MAC driver is capable of doing so, the correct phy_interface_t value + should be PHY_INTERFACE_MODE_RGMII, and the Ethernet MAC driver should be + configured correctly in order to provide the required transmit and/or receive + side delay from the perspective of the PHY device. Conversely, if the Ethernet + MAC driver looks at the phy_interface_t value, for any other mode but + PHY_INTERFACE_MODE_RGMII, it should make sure that the MAC-level delays are + disabled. + + In case neither the Ethernet MAC, nor the PHY are capable of providing the + required delays, as defined per the RGMII standard, several options may be + available: + + * Some SoCs may offer a pin pad/mux/controller capable of configuring a given + set of pins'strength, delays, and voltage; and it may be a suitable + option to insert the expected 2ns RGMII delay. + + * Modifying the PCB design to include a fixed delay (e.g: using a specifically + designed serpentine), which may not require software configuration at all. + +Common problems with RGMII delay mismatch + + When there is a RGMII delay mismatch between the Ethernet MAC and the PHY, this + will most likely result in the clock and data line signals to be unstable when + the PHY or MAC take a snapshot of these signals to translate them into logical + 1 or 0 states and reconstruct the data being transmitted/received. Typical + symptoms include: + + * Transmission/reception partially works, and there is frequent or occasional + packet loss observed + + * Ethernet MAC may report some or all packets ingressing with a FCS/CRC error, + or just discard them all + + * Switching to lower speeds such as 10/100Mbits/sec makes the problem go away + (since there is enough setup/hold time in that case) + + Connecting to a PHY Sometime during startup, the network driver needs to establish a connection @@ -127,8 +204,9 @@ Letting the PHY Abstraction Layer do Everything values pruned from them which don't make sense for your controller (a 10/100 controller may be connected to a gigabit capable PHY, so you would need to mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions - for these bitfields. Note that you should not SET any bits, or the PHY may - get put into an unsupported state. + for these bitfields. Note that you should not SET any bits, except the + SUPPORTED_Pause and SUPPORTED_AsymPause bits (see below), or the PHY may get + put into an unsupported state. Lastly, once the controller is ready to handle network traffic, you call phy_start(phydev). This tells the PAL that you are ready, and configures the @@ -139,6 +217,19 @@ Letting the PHY Abstraction Layer do Everything When you want to disconnect from the network (even if just briefly), you call phy_stop(phydev). +Pause frames / flow control + + The PHY does not participate directly in flow control/pause frames except by + making sure that the SUPPORTED_Pause and SUPPORTED_AsymPause bits are set in + MII_ADVERTISE to indicate towards the link partner that the Ethernet MAC + controller supports such a thing. Since flow control/pause frames generation + involves the Ethernet MAC driver, it is recommended that this driver takes care + of properly indicating advertisement and support for such features by setting + the SUPPORTED_Pause and SUPPORTED_AsymPause bits accordingly. This can be done + either before or after phy_connect() and/or as a result of implementing the + ethtool::set_pauseparam feature. + + Keeping Close Tabs on the PAL It is possible that the PAL's built-in state machine needs a little help to @@ -251,39 +342,8 @@ Writing a PHY driver PHY_BASIC_FEATURES, but you can look in include/mii.h for other features. - Each driver consists of a number of function pointers: - - soft_reset: perform a PHY software reset - config_init: configures PHY into a sane state after a reset. - For instance, a Davicom PHY requires descrambling disabled. - probe: Allocate phy->priv, optionally refuse to bind. - PHY may not have been reset or had fixups run yet. - suspend/resume: power management - config_aneg: Changes the speed/duplex/negotiation settings - aneg_done: Determines the auto-negotiation result - read_status: Reads the current speed/duplex/negotiation settings - ack_interrupt: Clear a pending interrupt - did_interrupt: Checks if the PHY generated an interrupt - config_intr: Enable or disable interrupts - remove: Does any driver take-down - ts_info: Queries about the HW timestamping status - match_phy_device: used for Clause 45 capable PHYs to match devices - in package and ensure they are compatible - hwtstamp: Set the PHY HW timestamping configuration - rxtstamp: Requests a receive timestamp at the PHY level for a 'skb' - txtsamp: Requests a transmit timestamp at the PHY level for a 'skb' - set_wol: Enable Wake-on-LAN at the PHY level - get_wol: Get the Wake-on-LAN status at the PHY level - link_change_notify: called to inform the core is about to change the - link state, can be used to work around bogus PHY between state changes - read_mmd_indirect: Read PHY MMD indirect register - write_mmd_indirect: Write PHY MMD indirect register - module_info: Get the size and type of an EEPROM contained in an plug-in - module - module_eeprom: Get EEPROM information of a plug-in module - get_sset_count: Get number of strings sets that get_strings will count - get_strings: Get strings from requested objects (statistics) - get_stats: Get the extended statistics from the PHY device + Each driver consists of a number of function pointers, documented + in include/linux/phy.h under the phy_driver structure. Of these, only config_aneg and read_status are required to be assigned by the driver code. The rest are optional. Also, it is @@ -347,3 +407,22 @@ Board Fixups The stubs set one of the two matching criteria, and set the other one to match anything. + When phy_register_fixup() or *_for_uid()/*_for_id() is called at module, + unregister fixup and free allocate memory are required. + + Call one of following function before unloading module. + + int phy_unregister_fixup(const char *phy_id, u32 phy_uid, u32 phy_uid_mask); + int phy_unregister_fixup_for_uid(u32 phy_uid, u32 phy_uid_mask); + int phy_register_fixup_for_id(const char *phy_id); + +Standards + + IEEE Standard 802.3: CSMA/CD Access Method and Physical Layer Specifications, Section Two: + http://standards.ieee.org/getieee802/download/802.3-2008_section2.pdf + + RGMII v1.3: + http://web.archive.org/web/20160303212629/http://www.hp.com/rnd/pdfs/RGMIIv1_3.pdf + + RGMII v2.0: + http://web.archive.org/web/20160303171328/http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt index 356f791af574..7818b5fe448b 100644 --- a/Documentation/networking/regulatory.txt +++ b/Documentation/networking/regulatory.txt @@ -156,12 +156,12 @@ struct ieee80211_regdomain mydriver_jp_regdom = { //.alpha2 = "99", /* If I have no alpha2 to map it to */ .reg_rules = { /* IEEE 802.11b/g, channels 1..14 */ - REG_RULE(2412-20, 2484+20, 40, 6, 20, 0), + REG_RULE(2412-10, 2484+10, 40, 6, 20, 0), /* IEEE 802.11a, channels 34..48 */ - REG_RULE(5170-20, 5240+20, 40, 6, 20, + REG_RULE(5170-10, 5240+10, 40, 6, 20, NL80211_RRF_NO_IR), /* IEEE 802.11a, channels 52..64 */ - REG_RULE(5260-20, 5320+20, 40, 6, 20, + REG_RULE(5260-10, 5320+10, 40, 6, 20, NL80211_RRF_NO_IR| NL80211_RRF_DFS), } @@ -205,7 +205,7 @@ the data in regdb.c as an alternative to using CRDA. The file net/wireless/db.txt should be kept up-to-date with the db.txt file available in the git repository here: - git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-regdb.git + git://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git Again, most users in most situations should be using the CRDA package provided with their distribution, and in most other situations users diff --git a/Documentation/networking/seg6-sysctl.txt b/Documentation/networking/seg6-sysctl.txt new file mode 100644 index 000000000000..bdbde23b19cb --- /dev/null +++ b/Documentation/networking/seg6-sysctl.txt @@ -0,0 +1,18 @@ +/proc/sys/net/conf/<iface>/seg6_* variables: + +seg6_enabled - BOOL + Accept or drop SR-enabled IPv6 packets on this interface. + + Relevant packets are those with SRH present and DA = local. + + 0 - disabled (default) + not 0 - enabled + +seg6_require_hmac - INTEGER + Define HMAC policy for ingress SR-enabled packets on this interface. + + -1 - Ignore HMAC field + 0 - Accept SR packets without HMAC, validate SR packets with HMAC + 1 - Drop SR packets without HMAC, validate SR packets with HMAC + + Default is 0. diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt index e226f8925c9e..2bb07078f535 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -28,8 +28,6 @@ CONFIG_STMMAC_PCI: is to enable the pci driver. 2) Driver parameters list: debug: message level (0: no output, 16: all); phyaddr: to manually provide the physical address to the PHY device; - dma_rxsize: DMA rx ring size; - dma_txsize: DMA tx ring size; buf_sz: DMA buffer size; tc: control the HW FIFO threshold; watchdog: transmit timeout (in milliseconds); @@ -40,31 +38,31 @@ CONFIG_STMMAC_PCI: is to enable the pci driver. 3) Command line options Driver parameters can be also passed in command line by using: - stmmaceth=dma_rxsize:128,dma_txsize:512 + stmmaceth=watchdog:100,chain_mode=1 4) Driver information and notes 4.1) Transmit process The xmit method is invoked when the kernel needs to transmit a packet; it sets -the descriptors in the ring and informs the DMA engine that there is a packet +the descriptors in the ring and informs the DMA engine, that there is a packet ready to be transmitted. By default, the driver sets the NETIF_F_SG bit in the features field of the -net_device structure enabling the scatter-gather feature. This is true on +net_device structure, enabling the scatter-gather feature. This is true on chips and configurations where the checksum can be done in hardware. -Once the controller has finished transmitting the packet, napi will be +Once the controller has finished transmitting the packet, timer will be scheduled to release the transmit resources. 4.2) Receive process When one or more packets are received, an interrupt happens. The interrupts -are not queued so the driver has to scan all the descriptors in the ring during +are not queued, so the driver has to scan all the descriptors in the ring during the receive process. -This is based on NAPI so the interrupt handler signals only if there is work +This is based on NAPI, so the interrupt handler signals only if there is work to be done, and it exits. Then the poll method will be scheduled at some future point. The incoming packets are stored, by the DMA, in a list of pre-allocated socket buffers in order to avoid the memcpy (zero-copy). -4.3) Interrupt Mitigation +4.3) Interrupt mitigation The driver is able to mitigate the number of its DMA interrupts using NAPI for the reception on chips older than the 3.50. New chips have an HW RX-Watchdog used for this mitigation. @@ -88,19 +86,20 @@ the list, hence creating the explicit chaining in the descriptor itself, whereas such explicit chaining is not possible in RING mode. 4.5.1) Extended descriptors - The extended descriptors give us information about the Ethernet payload - when it is carrying PTP packets or TCP/UDP/ICMP over IP. - These are not available on GMAC Synopsys chips older than the 3.50. - At probe time the driver will decide if these can be actually used. - This support also is mandatory for PTPv2 because the extra descriptors - are used for saving the hardware timestamps and Extended Status. +The extended descriptors give us information about the Ethernet payload +when it is carrying PTP packets or TCP/UDP/ICMP over IP. +These are not available on GMAC Synopsys chips older than the 3.50. +At probe time the driver will decide if these can be actually used. +This support also is mandatory for PTPv2 because the extra descriptors +are used for saving the hardware timestamps and Extended Status. 4.6) Ethtool support Ethtool is supported. For example, driver statistics (including RMON), internal errors can be taken using: - # ethtool -S ethX command + # ethtool -S ethX +command 4.7) Jumbo and Segmentation Offloading Jumbo frames are supported and tested for the GMAC. @@ -153,8 +152,10 @@ Where: o dma_cfg: internal DMA parameters o pbl: the Programmable Burst Length is maximum number of beats to be transferred in one DMA transaction. - GMAC also enables the 4xPBL by default. - o fixed_burst/mixed_burst/burst_len + GMAC also enables the 4xPBL by default. (8xPBL for GMAC 3.50 and newer) + o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx. + o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default. + o fixed_burst/mixed_burst/aal o clk_csr: fixed CSR Clock range selection. o has_gmac: uses the GMAC core. o enh_desc: if sets the MAC will use the enhanced descriptor structure. @@ -206,16 +207,24 @@ tuned according to the HW capabilities. struct stmmac_dma_cfg { int pbl; + int txpbl; + int rxpbl; + bool pblx8; int fixed_burst; - int burst_len_supported; + int mixed_burst; + bool aal; }; Where: - o pbl: Programmable Burst Length + o pbl: Programmable Burst Length (tx and rx) + o txpbl: Transmit Programmable Burst Length. Only for GMAC and newer. + If set, DMA tx will use this value rather than pbl. + o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer. + If set, DMA rx will use this value rather than pbl. + o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default. o fixed_burst: program the DMA to use the fixed burst mode - o burst_len: this is the value we put in the register - supported values are provided as macros in - linux/stmmac.h header file. + o mixed_burst: program the DMA to use the mixed burst mode + o aal: Address-Aligned Beats --- @@ -275,11 +284,11 @@ Please see the following document: Documentation/devicetree/bindings/net/stmmac.txt 4.11) This is a summary of the content of some relevant files: - o stmmac_main.c: to implement the main network device driver; - o stmmac_mdio.c: to provide mdio functions; - o stmmac_pci: this the PCI driver; - o stmmac_platform.c: this the platform driver (OF supported) - o stmmac_ethtool.c: to implement the ethtool support; + o stmmac_main.c: implements the main network device driver; + o stmmac_mdio.c: provides MDIO functions; + o stmmac_pci: this is the PCI driver; + o stmmac_platform.c: this the platform driver (OF supported); + o stmmac_ethtool.c: implements the ethtool support; o stmmac.h: private driver structure; o common.h: common definitions and VFTs; o mmc_core.c/mmc.h: Management MAC Counters; @@ -381,12 +390,12 @@ In addition to the basic timestamp features mentioned in IEEE 1588-2002 Timestamps, new GMAC cores support the advanced timestamp features. IEEE 1588-2008 that can be enabled when configure the Kernel. -8) SGMII/RGMII supports +8) SGMII/RGMII support New GMAC devices provide own way to manage RGMII/SGMII. This information is available at run-time by looking at the HW capability register. This means that the stmmac can manage -auto-negotiation and link status w/o using the PHYLIB stuff +auto-negotiation and link status w/o using the PHYLIB stuff. In fact, the HW provides a subset of extended registers to restart the ANE, verify Full/Half duplex mode and Speed. -Also thanks to these registers it is possible to look at the +Thanks to these registers, it is possible to look at the Auto-negotiated Link Parter Ability. diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index 671cccf0dcd2..96f50694a748 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt @@ -182,6 +182,16 @@ SOF_TIMESTAMPING_OPT_TSONLY: the timestamp even if sysctl net.core.tstamp_allow_data is 0. This option disables SOF_TIMESTAMPING_OPT_CMSG. +SOF_TIMESTAMPING_OPT_STATS: + + Optional stats that are obtained along with the transmit timestamps. + It must be used together with SOF_TIMESTAMPING_OPT_TSONLY. When the + transmit timestamp is available, the stats are available in a + separate control message of type SCM_TIMESTAMPING_OPT_STATS, as a + list of TLVs (struct nlattr) of types. These stats allow the + application to associate various transport layer stats with + the transmit timestamps, such as how long a certain block of + data was limited by peer's receiver window. New applications are encouraged to pass SOF_TIMESTAMPING_OPT_ID to disambiguate timestamps and SOF_TIMESTAMPING_OPT_TSONLY to operate diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index 97282da82b75..ad3dead052a4 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -364,7 +364,7 @@ steps you should take: - The contents of your report will vary a lot depending upon the problem. If it's a kernel crash then you should refer to the - REPORTING-BUGS file. + admin-guide/reporting-bugs.rst file. But for most problems it is useful to provide the following: diff --git a/Documentation/networking/vrf.txt b/Documentation/networking/vrf.txt index 755dab856392..3918dae964d4 100644 --- a/Documentation/networking/vrf.txt +++ b/Documentation/networking/vrf.txt @@ -98,10 +98,11 @@ VRF device: or to specify the output device using cmsg and IP_PKTINFO. -TCP services running in the default VRF context (ie., not bound to any VRF -device) can work across all VRF domains by enabling the tcp_l3mdev_accept -sysctl option: +TCP & UDP services running in the default VRF context (ie., not bound +to any VRF device) can work across all VRF domains by enabling the +tcp_l3mdev_accept and udp_l3mdev_accept sysctl options: sysctl -w net.ipv4.tcp_l3mdev_accept=1 + sysctl -w net.ipv4.udp_l3mdev_accept=1 netfilter rules on the VRF device can be used to limit access to services running in the default VRF context as well. |