Skip to content

L
linux
Commit 07f81727 authored by David S. Miller's avatar David S. Miller
Browse files
Options

Merge branch 'net-ReST-part-two' 

Mauro Carvalho Chehab says:

====================
net: manually convert files to ReST format - part 2

That's the second part of my work to convert the networking
text files into ReST. it is based on today's linux-next (next-20200430).

The full series (including those ones) are at:

	https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs

I should be sending the remaining patches (another /38 series)
after getting those merged at -next.

The documents, converted to HTML via the building system are at:

	https://www.infradead.org/~mchehab/kernel_docs/networking/
====================
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents 9f049606 4ac0b122
Expand all Show whitespace changes
Inline Side-by-side
Showing with 2889 additions and 1200 deletions
Documentation/admin-guide/kernel-parameters.txt
View file @ 07f81727
......@@ -638,7 +638,7 @@
See Documentation/admin-guide/serial-console.rst for more
information. See
Documentation/networking/netconsole.txt for an
Documentation/networking/netconsole.rst for an
alternative.
uart[8250],io,<addr>[,options]
......
Documentation/admin-guide/serial-console.rst
View file @ 07f81727
......@@ -54,7 +54,7 @@ You will need to create a new device to use ``/dev/console``. The official
``/dev/console`` is now character device 5,1.
(You can also use a network device as a console. See
``Documentation/networking/netconsole.txt`` for information on that.)
``Documentation/networking/netconsole.rst`` for information on that.)
Here's an example that will use ``/dev/ttyS1`` (COM2) as the console.
Replace the sample values as needed.
......
Documentation/filesystems/afs.rst
View file @ 07f81727
......@@ -70,7 +70,7 @@ list of volume location server IP addresses::
The first module is the AF_RXRPC network protocol driver. This provides the
RxRPC remote operation protocol and may also be accessed from userspace. See:
Documentation/networking/rxrpc.txt
Documentation/networking/rxrpc.rst
The second module is the kerberos RxRPC security driver, and the third module
is the actual filesystem driver for the AFS filesystem.
......
Documentation/networking/bonding.rst
View file @ 07f81727
......@@ -1639,7 +1639,7 @@ can safely be sent over either interface. Such configurations may be achieved
using the traffic control utilities inherent in linux.
By default the bonding driver is multiqueue aware and 16 queues are created
when the driver initializes (see Documentation/networking/multiqueue.txt
when the driver initializes (see Documentation/networking/multiqueue.rst
for details). If more or less queues are desired the module parameter
tx_queues can be used to change this value. There is no sysfs parameter
available as the allocation is done at module init time.
......
Documentation/networking/can.rst
View file @ 07f81727
......@@ -1058,7 +1058,7 @@ drivers you mainly have to deal with:
- TX: Put the CAN frame from the socket buffer to the CAN controller.
- RX: Put the CAN frame from the CAN controller to the socket buffer.
See e.g. at Documentation/networking/netdevices.txt . The differences
See e.g. at Documentation/networking/netdevices.rst . The differences
for writing CAN network device driver are described below:
......
Documentation/networking/checksum-offloads.rst
View file @ 07f81727
......@@ -59,7 +59,7 @@ recomputed for each resulting segment. See the skbuff.h comment (section 'E')
for more details.
A driver declares its offload capabilities in netdev->hw_features; see
Documentation/networking/netdev-features.txt for more. Note that a device
Documentation/networking/netdev-features.rst for more. Note that a device
which only advertises NETIF_F_IP[V6]_CSUM must still obey the csum_start and
csum_offset given in the SKB; if it tries to deduce these itself in hardware
(as some NICs do) the driver should check that the values in the SKB match
......
Documentation/networking/index.rst
View file @ 07f81727
......@@ -74,6 +74,43 @@ Contents:
ipvlan
ipvs-sysctl
kcm
l2tp
lapb-module
ltpc
mac80211-injection
mpls-sysctl
multiqueue
netconsole
netdev-features
netdevices
netfilter-sysctl
netif-msg
nf_conntrack-sysctl
nf_flowtable
openvswitch
operstates
packet_mmap
phonet
pktgen
plip
ppp_generic
proc_net_tcp
radiotap-headers
ray_cs
rds
regulatory
rxrpc
sctp
secid
seg6-sysctl
skfp
strparser
switchdev
tc-actions-env-rules
tcp-thin
team
timestamping
tproxy
.. only:: subproject and html
......
Documentation/networking/ip-sysctl.rst
View file @ 07f81727
......@@ -886,7 +886,7 @@ tcp_thin_linear_timeouts - BOOLEAN
initiated. 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
Documentation/networking/tcp-thin.rst
Default: 0
......
Documentation/networking/l2tp.txt → Documentation/networking/l2tp.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
====
L2TP
====
This document describes how to use the kernel's L2TP drivers to
provide L2TP functionality. L2TP is a protocol that tunnels one or
more sessions over an IP tunnel. It is commonly used for VPNs
......@@ -121,14 +127,16 @@ Userspace may control behavior of the tunnel or session using
setsockopt and ioctl on the PPPoX socket. The following socket
options are supported:-
DEBUG - bitmask of debug message categories. See below.
========= ===========================================================
DEBUG bitmask of debug message categories. See below.
SENDSEQ - 0 => don't send packets with sequence numbers
1 => send packets with sequence numbers
- 1 => send packets with sequence numbers
RECVSEQ - 0 => receive packet sequence numbers are optional
1 => drop receive packets without sequence numbers
- 1 => drop receive packets without sequence numbers
LNSMODE - 0 => act as LAC.
1 => act as LNS.
REORDERTO - reorder timeout (in millisecs). If 0, don't try to reorder.
- 1 => act as LNS.
REORDERTO reorder timeout (in millisecs). If 0, don't try to reorder.
========= ===========================================================
Only the DEBUG option is supported by the special tunnel management
PPPoX socket.
......@@ -177,20 +185,22 @@ setsockopt on the PPPoX socket to set a debug mask.
The following debug mask bits are available:
================ ==============================
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
debugfs filesystem must first be mounted.
debugfs filesystem must first be mounted::
# mount -t debugfs debugfs /debug
# mount -t debugfs debugfs /debug
Files under the l2tp directory can then be accessed.
Files under the l2tp directory can then be accessed::
# cat /debug/l2tp/tunnels
# cat /debug/l2tp/tunnels
The debugfs files should not be used by applications to obtain L2TP
state information because the file format is subject to change. It is
......@@ -211,14 +221,14 @@ iproute2's ip utility to support this.
To create an L2TPv3 ethernet pseudowire between local host 192.168.1.1
and peer 192.168.1.2, using IP addresses 10.5.1.1 and 10.5.1.2 for the
tunnel endpoints:-
tunnel endpoints::
# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \
# ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \
udp_dport 5000 encap udp local 192.168.1.1 remote 192.168.1.2
# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
# ip -s -d show dev l2tpeth0
# ip addr add 10.5.1.2/32 peer 10.5.1.1/32 dev l2tpeth0
# ip li set dev l2tpeth0 up
# ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1
# ip -s -d show dev l2tpeth0
# ip addr add 10.5.1.2/32 peer 10.5.1.1/32 dev l2tpeth0
# ip li set dev l2tpeth0 up
Choose IP addresses to be the address of a local IP interface and that
of the remote system. The IP addresses of the l2tpeth0 interface can be
......@@ -228,24 +238,27 @@ Repeat the above at the peer, with ports, tunnel/session ids and IP
addresses reversed. The tunnel and session IDs can be any non-zero
32-bit number, but the values must be reversed at the peer.
======================== ===================
Host 1 Host2
======================== ===================
udp_sport=5000 udp_sport=5001
udp_dport=5001 udp_dport=5000
tunnel_id=42 tunnel_id=45
peer_tunnel_id=45 peer_tunnel_id=42
session_id=128 session_id=5196755
peer_session_id=5196755 peer_session_id=128
======================== ===================
When done at both ends of the tunnel, it should be possible to send
data over the network. e.g.
data over the network. e.g.::
# ping 10.5.1.1
# ping 10.5.1.1
Sample Userspace Code
=====================
1. Create tunnel management PPPoX socket
1. Create tunnel management PPPoX socket::
kernel_fd = socket(AF_PPPOX, SOCK_DGRAM, PX_PROTO_OL2TP);
if (kernel_fd >= 0) {
......@@ -272,7 +285,7 @@ Sample Userspace Code
}
}
2. Create session PPPoX data socket
2. Create session PPPoX data socket::
struct sockaddr_pppol2tp sax;
int fd;
......
Documentation/networking/ltpc.txt → Documentation/networking/ltpc.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
===========
LTPC Driver
===========
This is the ALPHA version of the ltpc driver.
In order to use it, you will need at least version 1.3.3 of the
......@@ -15,7 +21,7 @@ yourself. (see "Card Configuration" below for how to determine or
change the settings on your card)
When the driver is compiled into the kernel, you can add a line such
as the following to your /etc/lilo.conf:
as the following to your /etc/lilo.conf::
append="ltpc=0x240,9,1"
......@@ -25,13 +31,13 @@ the driver will try to determine them itself.
If you load the driver as a module, you can pass the parameters "io=",
"irq=", and "dma=" on the command line with insmod or modprobe, or add
them as options in a configuration file in /etc/modprobe.d/ directory:
them as options in a configuration file in /etc/modprobe.d/ directory::
alias lt0 ltpc # autoload the module when the interface is configured
options ltpc io=0x240 irq=9 dma=1
Before starting up the netatalk demons (perhaps in rc.local), you
need to add a line such as:
need to add a line such as::
/sbin/ifconfig lt0 127.0.0.42
......@@ -42,7 +48,7 @@ The appropriate netatalk configuration depends on whether you are
attached to a network that includes AppleTalk routers or not. If,
like me, you are simply connecting to your home Macintoshes and
printers, you need to set up netatalk to "seed". The way I do this
is to have the lines
is to have the lines::
dummy -seed -phase 2 -net 2000 -addr 2000.26 -zone "1033"
lt0 -seed -phase 1 -net 1033 -addr 1033.27 -zone "1033"
......@@ -57,13 +63,13 @@ such.
If you are attached to an extended AppleTalk network, with routers on
it, then you don't need to fool around with this -- the appropriate
line in atalkd.conf is
line in atalkd.conf is::
lt0 -phase 1
--------------------------------------
Card Configuration:
Card Configuration
==================
The interrupts and so forth are configured via the dipswitch on the
board. Set the switches so as not to conflict with other hardware.
......@@ -73,26 +79,32 @@ board. Set the switches so as not to conflict with other hardware.
original documentation refers to IRQ2. Since you'll be running
this on an AT (or later) class machine, that really means IRQ9.
=== ===========================================================
SW1 IRQ 4
SW2 IRQ 3
SW3 IRQ 9 (2 in original card documentation only applies to XT)
=== ===========================================================
DMA -- choose DMA 1 or 3, and set both corresponding switches.
=== =====
SW4 DMA 3
SW5 DMA 1
SW6 DMA 3
SW7 DMA 1
=== =====
I/O address -- choose one.
=== =========
SW8 220 / 240
=== =========
--------------------------------------
IP:
IP
==
Yes, it is possible to do IP over LocalTalk. However, you can't just
treat the LocalTalk device like an ordinary Ethernet device, even if
......@@ -102,9 +114,9 @@ Instead, you follow the same procedure as for doing IP in EtherTalk.
See Documentation/networking/ipddp.rst for more information about the
kernel driver and userspace tools needed.
--------------------------------------
BUGS:
Bugs
====
IRQ autoprobing often doesn't work on a cold boot. To get around
this, either compile the driver as a module, or pass the parameters
......@@ -120,12 +132,13 @@ It may theoretically be possible to use two LTPC cards in the same
machine, but this is unsupported, so if you really want to do this,
you'll probably have to hack the initialization code a bit.
______________________________________
THANKS:
Thanks to Alan Cox for helpful discussions early on in this
Thanks
======
Thanks to Alan Cox for helpful discussions early on in this
work, and to Denis Hainsworth for doing the bleeding-edge testing.
-- Bradford Johnson <bradford@math.umn.edu>
Bradford Johnson <bradford@math.umn.edu>
-- Updated 11/09/1998 by David Huggins-Daines <dhd@debian.org>
Updated 11/09/1998 by David Huggins-Daines <dhd@debian.org>
Documentation/networking/mac80211-injection.txt → Documentation/networking/mac80211-injection.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=========================================
How to use packet injection with mac80211
=========================================
mac80211 now allows arbitrary packets to be injected down any Monitor Mode
interface from userland. The packet you inject needs to be composed in the
following format:
following format::
[ radiotap header ]
[ ieee80211 header ]
[ payload ]
The radiotap format is discussed in
./Documentation/networking/radiotap-headers.txt.
./Documentation/networking/radiotap-headers.rst.
Despite many radiotap parameters being currently defined, most only make sense
to appear on received packets. The following information is parsed from the
......@@ -18,15 +21,19 @@ radiotap headers and used to control injection:
* IEEE80211_RADIOTAP_FLAGS
IEEE80211_RADIOTAP_F_FCS: FCS will be removed and recalculated
IEEE80211_RADIOTAP_F_WEP: frame will be encrypted if key available
IEEE80211_RADIOTAP_F_FRAG: frame will be fragmented if longer than the
========================= ===========================================
IEEE80211_RADIOTAP_F_FCS FCS will be removed and recalculated
IEEE80211_RADIOTAP_F_WEP frame will be encrypted if key available
IEEE80211_RADIOTAP_F_FRAG frame will be fragmented if longer than the
current fragmentation threshold.
========================= ===========================================
* IEEE80211_RADIOTAP_TX_FLAGS
IEEE80211_RADIOTAP_F_TX_NOACK: frame should be sent without waiting for
============================= ========================================
IEEE80211_RADIOTAP_F_TX_NOACK frame should be sent without waiting for
an ACK even if it is a unicast frame
============================= ========================================
* IEEE80211_RADIOTAP_RATE
......@@ -37,8 +44,10 @@ radiotap headers and used to control injection:
HT rate for the transmission (only for devices without own rate control).
Also some flags are parsed
IEEE80211_RADIOTAP_MCS_SGI: use short guard interval
IEEE80211_RADIOTAP_MCS_BW_40: send in HT40 mode
============================ ========================
IEEE80211_RADIOTAP_MCS_SGI use short guard interval
IEEE80211_RADIOTAP_MCS_BW_40 send in HT40 mode
============================ ========================
* IEEE80211_RADIOTAP_DATA_RETRIES
......@@ -54,14 +63,14 @@ radiotap headers and used to control injection:
IEEE80211_RADIOTAP_VHT_FLAG_SGI: use short guard interval
bandwidth field
1: send using 40MHz channel width
4: send using 80MHz channel width
11: send using 160MHz channel width
* 1: send using 40MHz channel width
* 4: send using 80MHz channel width
* 11: send using 160MHz channel width
The injection code can also skip all other currently defined radiotap fields
facilitating replay of captured radiotap headers directly.
Here is an example valid radiotap header defining some parameters
Here is an example valid radiotap header defining some parameters::
0x00, 0x00, // <-- radiotap version
0x0b, 0x00, // <- radiotap header length
......@@ -71,7 +80,7 @@ Here is an example valid radiotap header defining some parameters
0x01 //<-- antenna
The ieee80211 header follows immediately afterwards, looking for example like
this:
this::
0x08, 0x01, 0x00, 0x00,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
......@@ -84,10 +93,10 @@ Then lastly there is the payload.
After composing the packet contents, it is sent by send()-ing it to a logical
mac80211 interface that is in Monitor mode. Libpcap can also be used,
(which is easier than doing the work to bind the socket to the right
interface), along the following lines:
interface), along the following lines:::
ppcap = pcap_open_live(szInterfaceName, 800, 1, 20, szErrbuf);
...
...
r = pcap_inject(ppcap, u8aSendBuffer, nLength);
You can also find a link to a complete inject application here:
......
Documentation/networking/mpls-sysctl.txt → Documentation/networking/mpls-sysctl.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
====================
MPLS Sysfs variables
====================
/proc/sys/net/mpls/* Variables:
===============================
platform_labels - INTEGER
Number of entries in the platform label table. It is not
......@@ -17,6 +24,7 @@ platform_labels - INTEGER
no longer fit in the table.
Possible values: 0 - 1048575
Default: 0
ip_ttl_propagate - BOOL
......@@ -27,8 +35,8 @@ ip_ttl_propagate - BOOL
If disabled, the MPLS transport network will appear as a
single hop to transit traffic.
0 - disabled / RFC 3443 [Short] Pipe Model
1 - enabled / RFC 3443 Uniform Model (default)
* 0 - disabled / RFC 3443 [Short] Pipe Model
* 1 - enabled / RFC 3443 Uniform Model (default)
default_ttl - INTEGER
Default TTL value to use for MPLS packets where it cannot be
......@@ -36,6 +44,7 @@ default_ttl - INTEGER
or ip_ttl_propagate has been disabled.
Possible values: 1 - 255
Default: 255
conf/<interface>/input - BOOL
......@@ -44,5 +53,5 @@ conf/<interface>/input - BOOL
If disabled, packets will be discarded without further
processing.
0 - disabled (default)
not 0 - enabled
* 0 - disabled (default)
* not 0 - enabled
Documentation/networking/multiqueue.txt → Documentation/networking/multiqueue.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
HOWTO for multiqueue network device support
===========================================
===========================================
HOWTO for multiqueue network device support
===========================================
Section 1: Base driver requirements for implementing multiqueue support
=======================================================================
Intro: Kernel support for multiqueue devices
---------------------------------------------------------
Kernel support for multiqueue devices is always present.
Section 1: Base driver requirements for implementing multiqueue support
-----------------------------------------------------------------------
Base drivers are required to use the new alloc_etherdev_mq() or
alloc_netdev_mq() functions to allocate the subqueues for the device. The
underlying kernel API will take care of the allocation and deallocation of
......@@ -26,8 +26,7 @@ comes online or when it's completely shut down (unregister_netdev(), etc.).
Section 2: Qdisc support for multiqueue devices
-----------------------------------------------
===============================================
Currently two qdiscs are optimized for multiqueue devices. The first is the
default pfifo_fast qdisc. This qdisc supports one qdisc per hardware queue.
......@@ -46,22 +45,22 @@ will be queued to the band associated with the hardware queue.
Section 3: Brief howto using MULTIQ for multiqueue devices
---------------------------------------------------------------
==========================================================
The userspace command 'tc,' part of the iproute2 package, is used to configure
qdiscs. To add the MULTIQ qdisc to your network device, assuming the device
is called eth0, run the following command:
is called eth0, run the following command::
# tc qdisc add dev eth0 root handle 1: multiq
# tc qdisc add dev eth0 root handle 1: multiq
The qdisc will allocate the number of bands to equal the number of queues that
the device reports, and bring the qdisc online. Assuming eth0 has 4 Tx
queues, the band mapping would look like:
queues, the band mapping would look like::
band 0 => queue 0
band 1 => queue 1
band 2 => queue 2
band 3 => queue 3
band 0 => queue 0
band 1 => queue 1
band 2 => queue 2
band 3 => queue 3
Traffic will begin flowing through each queue based on either the simple_tx_hash
function or based on netdev->select_queue() if you have it defined.
......@@ -69,11 +68,11 @@ function or based on netdev->select_queue() if you have it defined.
The behavior of tc filters remains the same. However a new tc action,
skbedit, has been added. Assuming you wanted to route all traffic to a
specific host, for example 192.168.0.3, through a specific queue you could use
this action and establish a filter such as:
this action and establish a filter such as::
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
match ip dst 192.168.0.3 \
action skbedit queue_mapping 3
Author: Alexander Duyck <alexander.h.duyck@intel.com>
Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
:Author: Alexander Duyck <alexander.h.duyck@intel.com>
:Original Author: Peter P. Waskiewicz Jr. <peter.p.waskiewicz.jr@intel.com>
Documentation/networking/netconsole.txt → Documentation/networking/netconsole.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
==========
Netconsole
==========
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013
Extended console support by Tejun Heo <tj@kernel.org>, May 1 2015
Please send bug reports to Matt Mackall <mpm@selenic.com>
......@@ -23,7 +32,7 @@ Sender and receiver configuration:
==================================
It takes a string configuration parameter "netconsole" in the
following format:
following format::
netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
......@@ -36,21 +45,21 @@ following format:
tgt-ip IP address for logging agent
tgt-macaddr ethernet MAC address for logging agent (broadcast)
Examples:
Examples::
linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
or
or::
insmod netconsole netconsole=@/,@10.0.0.2/
or using IPv6
or using IPv6::
insmod netconsole netconsole=@/,@fd00:1:2:3::1/
It also supports logging to multiple remote agents by specifying
parameters for the multiple agents separated by semicolons and the
complete string enclosed in "quotes", thusly:
complete string enclosed in "quotes", thusly::
modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/"
......@@ -67,14 +76,19 @@ for example:
On distributions using a BSD-based netcat version (e.g. Fedora,
openSUSE and Ubuntu) the listening port must be specified without
the -p switch:
the -p switch::
nc -u -l -p <port>' / 'nc -u -l <port>
or::
'nc -u -l -p <port>' / 'nc -u -l <port>' or
'netcat -u -l -p <port>' / 'netcat -u -l <port>'
netcat -u -l -p <port>' / 'netcat -u -l <port>
3) socat
'socat udp-recv:<port> -'
::
socat udp-recv:<port> -
Dynamic reconfiguration:
========================
......@@ -92,7 +106,7 @@ netconsole module (or kernel, if netconsole is built-in).
Some examples follow (where configfs is mounted at the /sys/kernel/config
mountpoint).
To add a remote logging target (target names can be arbitrary):
To add a remote logging target (target names can be arbitrary)::
cd /sys/kernel/config/netconsole/
mkdir target1
......@@ -102,12 +116,13 @@ above) and are disabled by default -- they must first be enabled by writing
"1" to the "enabled" attribute (usually after setting parameters accordingly)
as described below.
To remove a target:
To remove a target::
rmdir /sys/kernel/config/netconsole/othertarget/
The interface exposes these parameters of a netconsole target to userspace:
============== ================================= ============
enabled Is this target currently enabled? (read-write)
extended Extended mode enabled (read-write)
dev_name Local network interface name (read-write)
......@@ -117,12 +132,13 @@ The interface exposes these parameters of a netconsole target to userspace:
remote_ip Remote agent's IP address (read-write)
local_mac Local interface's MAC address (read-only)
remote_mac Remote agent's MAC address (read-write)
============== ================================= ============
The "enabled" attribute is also used to control whether the parameters of
a target can be updated or not -- you can modify the parameters of only
disabled targets (i.e. if "enabled" is 0).
To update a target's parameters:
To update a target's parameters::
cat enabled # check if enabled is 1
echo 0 > enabled # disable the target (if required)
......@@ -140,12 +156,12 @@ Extended console:
If '+' is prefixed to the configuration line or "extended" config file
is set to 1, extended console support is enabled. An example boot
param follows.
param follows::
linux netconsole=+4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
Log messages are transmitted with extended metadata header in the
following format which is the same as /dev/kmsg.
following format which is the same as /dev/kmsg::
<level>,<sequnum>,<timestamp>,<contflag>;<message text>
......@@ -155,12 +171,12 @@ newline is used as the delimeter.
If a message doesn't fit in certain number of bytes (currently 1000),
the message is split into multiple fragments by netconsole. These
fragments are transmitted with "ncfrag" header field added.
fragments are transmitted with "ncfrag" header field added::
ncfrag=<byte-offset>/<total-bytes>
For example, assuming a lot smaller chunk size, a message "the first
chunk, the 2nd chunk." may be split as follows.
chunk, the 2nd chunk." may be split as follows::
6,416,1758426,-,ncfrag=0/31;the first chunk,
6,416,1758426,-,ncfrag=16/31; the 2nd chunk.
......@@ -168,39 +184,52 @@ chunk, the 2nd chunk." may be split as follows.
Miscellaneous notes:
====================
WARNING: the default target ethernet setting uses the broadcast
ethernet address to send packets, which can cause increased load on
other systems on the same ethernet segment.
.. Warning::
the default target ethernet setting uses the broadcast
ethernet address to send packets, which can cause increased load on
other systems on the same ethernet segment.
.. Tip::
some LAN switches may be configured to suppress ethernet broadcasts
so it is advised to explicitly specify the remote agents' MAC addresses
from the config parameters passed to netconsole.
TIP: some LAN switches may be configured to suppress ethernet broadcasts
so it is advised to explicitly specify the remote agents' MAC addresses
from the config parameters passed to netconsole.
.. Tip::
TIP: to find out the MAC address of, say, 10.0.0.2, you may try using:
to find out the MAC address of, say, 10.0.0.2, you may try using::
ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2
TIP: in case the remote logging agent is on a separate LAN subnet than
the sender, it is suggested to try specifying the MAC address of the
default gateway (you may use /sbin/route -n to find it out) as the
remote MAC address instead.
.. Tip::
in case the remote logging agent is on a separate LAN subnet than
the sender, it is suggested to try specifying the MAC address of the
default gateway (you may use /sbin/route -n to find it out) as the
remote MAC address instead.
.. note::
the network device (eth1 in the above case) can run any kind
of other network traffic, netconsole is not intrusive. Netconsole
might cause slight delays in other traffic if the volume of kernel
messages is high, but should have no other impact.
NOTE: the network device (eth1 in the above case) can run any kind
of other network traffic, netconsole is not intrusive. Netconsole
might cause slight delays in other traffic if the volume of kernel
messages is high, but should have no other impact.
.. note::
NOTE: if you find that the remote logging agent is not receiving or
printing all messages from the sender, it is likely that you have set
the "console_loglevel" parameter (on the sender) to only send high
priority messages to the console. You can change this at runtime using:
if you find that the remote logging agent is not receiving or
printing all messages from the sender, it is likely that you have set
the "console_loglevel" parameter (on the sender) to only send high
priority messages to the console. You can change this at runtime using::
dmesg -n 8
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/admin-guide/kernel-parameters.rst for details.
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/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
......
Documentation/networking/netdev-features.txt → Documentation/networking/netdev-features.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=====================================================
Netdev features mess and how to get out from it alive
=====================================================
......@@ -6,8 +9,8 @@ Author:
Part I: Feature sets
======================
Part I: Feature sets
====================
Long gone are the days when a network card would just take and give packets
verbatim. Today's devices add multiple features and bugs (read: offloads)
......@@ -39,8 +42,8 @@ one used internally by network core:
Part II: Controlling enabled features
=======================================
Part II: Controlling enabled features
=====================================
When current feature set (netdev->features) is to be changed, new set
is calculated and filtered by calling ndo_fix_features callback
......@@ -65,8 +68,8 @@ driver except by means of ndo_fix_features callback.
Part III: Implementation hints
================================
Part III: Implementation hints
==============================
* ndo_fix_features:
......@@ -94,8 +97,8 @@ Errors returned are not (and cannot be) propagated anywhere except dmesg.
Part IV: Features
===================
Part IV: Features
=================
For current list of features, see include/linux/netdev_features.h.
This section describes semantics of some of them.
......
Documentation/networking/netdevices.txt → Documentation/networking/netdevices.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=====================================
Network Devices, the Kernel, and You!
=====================================
Introduction
......@@ -78,8 +81,9 @@ ndo_start_xmit:
will be called with interrupts disabled by netconsole.
Return codes:
o NETDEV_TX_OK everything ok.
o NETDEV_TX_BUSY Cannot transmit packet, try later
* NETDEV_TX_OK everything ok.
* NETDEV_TX_BUSY Cannot transmit packet, try later
Usually a bug, means queue start/stop flow control is broken in
the driver. Note: the driver must NOT put the skb in its DMA ring.
......@@ -95,10 +99,13 @@ ndo_set_rx_mode:
struct napi_struct synchronization rules
========================================
napi->poll:
Synchronization: NAPI_STATE_SCHED bit in napi->state. Device
Synchronization:
NAPI_STATE_SCHED bit in napi->state. Device
driver's ndo_stop method will invoke napi_disable() on
all NAPI instances which will do a sleeping poll on the
NAPI_STATE_SCHED napi->state bit, waiting for all pending
NAPI activity to cease.
Context: softirq
Context:
softirq
will be called with interrupts disabled by netconsole.
Documentation/networking/netfilter-sysctl.txt → Documentation/networking/netfilter-sysctl.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=========================
Netfilter Sysfs variables
=========================
/proc/sys/net/netfilter/* Variables:
====================================
nf_log_all_netns - BOOLEAN
0 - disabled (default)
not 0 - enabled
- 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
......
Documentation/networking/netif-msg.txt → Documentation/networking/netif-msg.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
________________
===============
NETIF Msg Level
===============
The design of the network interface message level setting.
History
-------
The design of the debugging message interface was guided and
constrained by backwards compatibility previous practice. It is useful
......@@ -18,14 +21,15 @@ History
The message level was not precisely defined past level 3, but were
always implemented within +-1 of the specified level. Drivers tended
to shed the more verbose level messages as they matured.
0 Minimal messages, only essential information on fatal errors.
1 Standard messages, initialization status. No run-time messages
2 Special media selection messages, generally timer-driver.
3 Interface starts and stops, including normal status messages
4 Tx and Rx frame error messages, and abnormal driver operation
5 Tx packet queue information, interrupt events.
6 Status on each completed Tx packet and received Rx packets
7 Initial contents of Tx and Rx packets
- 0 Minimal messages, only essential information on fatal errors.
- 1 Standard messages, initialization status. No run-time messages
- 2 Special media selection messages, generally timer-driver.
- 3 Interface starts and stops, including normal status messages
- 4 Tx and Rx frame error messages, and abnormal driver operation
- 5 Tx packet queue information, interrupt events.
- 6 Status on each completed Tx packet and received Rx packets
- 7 Initial contents of Tx and Rx packets
Initially this message level variable was uniquely named in each driver
e.g. "lance_debug", so that a kernel symbolic debugger could locate and
......@@ -36,33 +40,45 @@ History
This approach worked well. However there is always a demand for
additional features. Over the years the following emerged as
reasonable and easily implemented enhancements
Using an ioctl() call to modify the level.
Per-interface rather than per-driver message level setting.
More selective control over the type of messages emitted.
- Using an ioctl() call to modify the level.
- Per-interface rather than per-driver message level setting.
- More selective control over the type of messages emitted.
The netif_msg recommendation adds these features with only a minor
complexity and code size increase.
The recommendation is the following points
Retaining the per-driver integer variable "debug" as a module
- Retaining the per-driver integer variable "debug" as a module
parameter with a default level of '1'.
Adding a per-interface private variable named "msg_enable". The
variable is a bit map rather than a level, and is initialized as
- Adding a per-interface private variable named "msg_enable". The
variable is a bit map rather than a level, and is initialized as::
1 << debug
Or more precisely
Or more precisely::
debug < 0 ? 0 : 1 << min(sizeof(int)-1, debug)
Messages should changes from
Messages should changes from::
if (debug > 1)
printk(MSG_DEBUG "%s: ...
to
to::
if (np->msg_enable & NETIF_MSG_LINK)
printk(MSG_DEBUG "%s: ...
The set of message levels is named
========= =================== ============
Old level Name Bit position
========= =================== ============
0 NETIF_MSG_DRV 0x0001
1 NETIF_MSG_PROBE 0x0002
2 NETIF_MSG_LINK 0x0004
......@@ -76,4 +92,4 @@ The set of message levels is named
6 NETIF_MSG_TX_DONE 0x0040
6 NETIF_MSG_RX_STATUS 0x0040
7 NETIF_MSG_PKTDATA 0x0080
========= =================== ============
Documentation/networking/nf_conntrack-sysctl.txt → Documentation/networking/nf_conntrack-sysctl.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
===================================
Netfilter Conntrack Sysfs variables
===================================
/proc/sys/net/netfilter/nf_conntrack_* Variables:
=================================================
nf_conntrack_acct - BOOLEAN
0 - disabled (default)
not 0 - enabled
- 0 - disabled (default)
- not 0 - enabled
Enable connection tracking flow accounting. 64-bit byte and packet
counters per flow are added.
......@@ -16,8 +23,8 @@ nf_conntrack_buckets - INTEGER
This sysctl is only writeable in the initial net namespace.
nf_conntrack_checksum - BOOLEAN
0 - disabled
not 0 - enabled (default)
- 0 - disabled
- not 0 - enabled (default)
Verify checksum of incoming packets. Packets with bad checksums are
in INVALID state. If this is enabled, such packets will not be
......@@ -27,8 +34,8 @@ nf_conntrack_count - INTEGER (read-only)
Number of currently allocated flow entries.
nf_conntrack_events - BOOLEAN
0 - disabled
not 0 - enabled (default)
- 0 - disabled
- not 0 - enabled (default)
If this option is enabled, the connection tracking code will
provide userspace with connection tracking events via ctnetlink.
......@@ -62,8 +69,8 @@ nf_conntrack_generic_timeout - INTEGER (seconds)
protocols.
nf_conntrack_helper - BOOLEAN
0 - disabled (default)
not 0 - enabled
- 0 - disabled (default)
- not 0 - enabled
Enable automatic conntrack helper assignment.
If disabled it is required to set up iptables rules to assign
......@@ -81,14 +88,14 @@ nf_conntrack_icmpv6_timeout - INTEGER (seconds)
Default for ICMP6 timeout.
nf_conntrack_log_invalid - INTEGER
0 - disable (default)
1 - log ICMP packets
6 - log TCP packets
17 - log UDP packets
33 - log DCCP packets
41 - log ICMPv6 packets
136 - log UDPLITE packets
255 - log packets of any protocol
- 0 - disable (default)
- 1 - log ICMP packets
- 6 - log TCP packets
- 17 - log UDP packets
- 33 - log DCCP packets
- 41 - log ICMPv6 packets
- 136 - log UDPLITE packets
- 255 - log packets of any protocol
Log invalid packets of a type specified by value.
......@@ -97,15 +104,15 @@ nf_conntrack_max - INTEGER
nf_conntrack_buckets value * 4.
nf_conntrack_tcp_be_liberal - BOOLEAN
0 - disabled (default)
not 0 - enabled
- 0 - disabled (default)
- not 0 - enabled
Be conservative in what you do, be liberal in what you accept from others.
If it's non-zero, we mark only out of window RST segments as INVALID.
nf_conntrack_tcp_loose - BOOLEAN
0 - disabled
not 0 - enabled (default)
- 0 - disabled
- not 0 - enabled (default)
If it is set to zero, we disable picking up already established
connections.
......@@ -148,8 +155,8 @@ nf_conntrack_tcp_timeout_unacknowledged - INTEGER (seconds)
default 300
nf_conntrack_timestamp - BOOLEAN
0 - disabled (default)
not 0 - enabled
- 0 - disabled (default)
- not 0 - enabled
Enable connection tracking flow timestamping.
......
Documentation/networking/nf_flowtable.txt → Documentation/networking/nf_flowtable.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
====================================
Netfilter's flowtable infrastructure
====================================
......@@ -31,6 +34,8 @@ to use this new alternative forwarding path via nftables policy.
This is represented in Fig.1, which describes the classic forwarding path
including the Netfilter hooks and the flowtable fastpath bypass.
::
userspace process
^ |
| |
......@@ -72,7 +77,7 @@ Example configuration
---------------------
Enabling the flowtable bypass is relatively easy, you only need to create a
flowtable and add one rule to your forward chain.
flowtable and add one rule to your forward chain::
table inet x {
flowtable f {
......@@ -101,12 +106,12 @@ forwarding bypass.
More reading
------------
This documentation is based on the LWN.net articles [1][2]. Rafal Milecki also
made a very complete and comprehensive summary called "A state of network
This documentation is based on the LWN.net articles [1]_\ [2]_. Rafal Milecki
also made a very complete and comprehensive summary called "A state of network
acceleration" that describes how things were before this infrastructure was
mailined [3] and it also makes a rough summary of this work [4].
mailined [3]_ and it also makes a rough summary of this work [4]_.
[1] https://lwn.net/Articles/738214/
[2] https://lwn.net/Articles/742164/
[3] http://lists.infradead.org/pipermail/lede-dev/2018-January/010830.html
[4] http://lists.infradead.org/pipermail/lede-dev/2018-January/010829.html
.. [1] https://lwn.net/Articles/738214/
.. [2] https://lwn.net/Articles/742164/
.. [3] http://lists.infradead.org/pipermail/lede-dev/2018-January/010830.html
.. [4] http://lists.infradead.org/pipermail/lede-dev/2018-January/010829.html
Documentation/networking/openvswitch.txt → Documentation/networking/openvswitch.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=============================================
Open vSwitch datapath developer documentation
=============================================
......@@ -80,13 +83,13 @@ The <linux/openvswitch.h> header file defines the exact format of the
flow key attributes. For informal explanatory purposes here, we write
them as comma-separated strings, with parentheses indicating arguments
and nesting. For example, the following could represent a flow key
corresponding to a TCP packet that arrived on vport 1:
corresponding to a TCP packet that arrived on vport 1::
in_port(1), eth(src=e0:91:f5:21:d0:b2, dst=00:02:e3:0f:80:a4),
eth_type(0x0800), ipv4(src=172.16.0.20, dst=172.18.0.52, proto=17, tos=0,
frag=no), tcp(src=49163, dst=80)
Often we ellipsize arguments not important to the discussion, e.g.:
Often we ellipsize arguments not important to the discussion, e.g.::
in_port(1), eth(...), eth_type(0x0800), ipv4(...), tcp(...)
......@@ -151,20 +154,20 @@ Some care is needed to really maintain forward and backward
compatibility for applications that follow the rules listed under
"Flow key compatibility" above.
The basic rule is obvious:
The basic rule is obvious::
------------------------------------------------------------------
==================================================================
New network protocol support must only supplement existing flow
key attributes. It must not change the meaning of already defined
flow key attributes.
------------------------------------------------------------------
==================================================================
This rule does have less-obvious consequences so it is worth working
through a few examples. Suppose, for example, that the kernel module
did not already implement VLAN parsing. Instead, it just interpreted
the 802.1Q TPID (0x8100) as the Ethertype then stopped parsing the
packet. The flow key for any packet with an 802.1Q header would look
essentially like this, ignoring metadata:
essentially like this, ignoring metadata::
eth(...), eth_type(0x8100)
......@@ -172,7 +175,7 @@ Naively, to add VLAN support, it makes sense to add a new "vlan" flow
key attribute to contain the VLAN tag, then continue to decode the
encapsulated headers beyond the VLAN tag using the existing field
definitions. With this change, a TCP packet in VLAN 10 would have a
flow key much like this:
flow key much like this::
eth(...), vlan(vid=10, pcp=0), eth_type(0x0800), ip(proto=6, ...), tcp(...)
......@@ -187,7 +190,7 @@ across kernel versions even though it follows the compatibility rules.
The solution is to use a set of nested attributes. This is, for
example, why 802.1Q support uses nested attributes. A TCP packet in
VLAN 10 is actually expressed as:
VLAN 10 is actually expressed as::
eth(...), eth_type(0x8100), vlan(vid=10, pcp=0), encap(eth_type(0x0800),
ip(proto=6, ...), tcp(...)))
......@@ -215,14 +218,14 @@ For example, consider a packet that contains an IP header that
indicates protocol 6 for TCP, but which is truncated just after the IP
header, so that the TCP header is missing. The flow key for this
packet would include a tcp attribute with all-zero src and dst, like
this:
this::
eth(...), eth_type(0x0800), ip(proto=6, ...), tcp(src=0, dst=0)
As another example, consider a packet with an Ethernet type of 0x8100,
indicating that a VLAN TCI should follow, but which is truncated just
after the Ethernet type. The flow key for this packet would include
an all-zero-bits vlan and an empty encap attribute, like this:
an all-zero-bits vlan and an empty encap attribute, like this::
eth(...), eth_type(0x8100), vlan(0), encap()
......
Documentation/networking/operstates.txt → Documentation/networking/operstates.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
==================
Operational States
==================
1. Introduction
===============
Linux distinguishes between administrative and operational state of an
interface. Administrative state is the result of "ip link set dev
......@@ -20,6 +27,7 @@ and changeable from userspace under certain rules.
2. Querying from userspace
==========================
Both admin and operational state can be queried via the netlink
operation RTM_GETLINK. It is also possible to subscribe to RTNLGRP_LINK
......@@ -30,16 +38,20 @@ These values contain interface state:
ifinfomsg::if_flags & IFF_UP:
Interface is admin up
ifinfomsg::if_flags & IFF_RUNNING:
Interface is in RFC2863 operational state UP or UNKNOWN. This is for
backward compatibility, routing daemons, dhcp clients can use this
flag to determine whether they should use the interface.
ifinfomsg::if_flags & IFF_LOWER_UP:
Driver has signaled netif_carrier_on()
ifinfomsg::if_flags & IFF_DORMANT:
Driver has signaled netif_dormant_on()
TLV IFLA_OPERSTATE
------------------
contains RFC2863 state of the interface in numeric representation:
......@@ -47,26 +59,33 @@ IF_OPER_UNKNOWN (0):
Interface is in unknown state, neither driver nor userspace has set
operational state. Interface must be considered for user data as
setting operational state has not been implemented in every driver.
IF_OPER_NOTPRESENT (1):
Unused in current kernel (notpresent interfaces normally disappear),
just a numerical placeholder.
IF_OPER_DOWN (2):
Interface is unable to transfer data on L1, f.e. ethernet is not
plugged or interface is ADMIN down.
IF_OPER_LOWERLAYERDOWN (3):
Interfaces stacked on an interface that is IF_OPER_DOWN show this
state (f.e. VLAN).
IF_OPER_TESTING (4):
Unused in current kernel.
IF_OPER_DORMANT (5):
Interface is L1 up, but waiting for an external event, f.e. for a
protocol to establish. (802.1X)
IF_OPER_UP (6):
Interface is operational up and can be used.
This TLV can also be queried via sysfs.
TLV IFLA_LINKMODE
-----------------
contains link policy. This is needed for userspace interaction
described below.
......@@ -75,6 +94,7 @@ This TLV can also be queried via sysfs.
3. Kernel driver API
====================
Kernel drivers have access to two flags that map to IFF_LOWER_UP and
IFF_DORMANT. These flags can be set from everywhere, even from
......@@ -126,6 +146,7 @@ netif_carrier_ok() && !netif_dormant():
4. Setting from userspace
=========================
Applications have to use the netlink interface to influence the
RFC2863 operational state of an interface. Setting IFLA_LINKMODE to 1
......@@ -139,18 +160,18 @@ are multicasted on the netlink group RTNLGRP_LINK.
So basically a 802.1X supplicant interacts with the kernel like this:
-subscribe to RTNLGRP_LINK
-set IFLA_LINKMODE to 1 via RTM_SETLINK
-query RTM_GETLINK once to get initial state
-if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until
- subscribe to RTNLGRP_LINK
- set IFLA_LINKMODE to 1 via RTM_SETLINK
- query RTM_GETLINK once to get initial state
- if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until
netlink multicast signals this state
-do 802.1X, eventually abort if flags go down again
-send RTM_SETLINK to set operstate to IF_OPER_UP if authentication
- do 802.1X, eventually abort if flags go down again
- send RTM_SETLINK to set operstate to IF_OPER_UP if authentication
succeeds, IF_OPER_DORMANT otherwise
-see how operstate and IFF_RUNNING is echoed via netlink multicast
-set interface back to IF_OPER_DORMANT if 802.1X reauthentication
- see how operstate and IFF_RUNNING is echoed via netlink multicast
- set interface back to IF_OPER_DORMANT if 802.1X reauthentication
fails
-restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag
- restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag
if supplicant goes down, bring back IFLA_LINKMODE to 0 and
IFLA_OPERSTATE to a sane value.
......
Documentation/networking/phonet.txt → Documentation/networking/phonet.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
============================
Linux Phonet protocol family
============================
......@@ -11,6 +15,7 @@ device attached to the modem. The modem takes care of routing.
Phonet packets can be exchanged through various hardware connections
depending on the device, such as:
- USB with the CDC Phonet interface,
- infrared,
- Bluetooth,
......@@ -21,7 +26,7 @@ depending on the device, such as:
Packets format
--------------
Phonet packets have a common header as follows:
Phonet packets have a common header as follows::
struct phonethdr {
uint8_t pn_media; /* Media type (link-layer identifier) */
......@@ -72,7 +77,7 @@ only the (default) Linux FIFO qdisc should be used with them.
Network layer
-------------
The Phonet socket address family maps the Phonet packet header:
The Phonet socket address family maps the Phonet packet header::
struct sockaddr_pn {
sa_family_t spn_family; /* AF_PHONET */
......@@ -94,6 +99,8 @@ protocol from the PF_PHONET family. Each socket is bound to one of the
2^10 object IDs available, and can send and receive packets with any
other peer.
::
struct sockaddr_pn addr = { .spn_family = AF_PHONET, };
ssize_t len;
socklen_t addrlen = sizeof(addr);
......@@ -116,7 +123,7 @@ Resource subscription
---------------------
A Phonet datagram socket can be subscribed to any number of 8-bits
Phonet resources, as follow:
Phonet resources, as follow::
uint32_t res = 0xXX;
ioctl(fd, SIOCPNADDRESOURCE, &res);
......@@ -137,6 +144,8 @@ socket paradigm. The listening socket is bound to an unique free object
ID. Each listening socket can handle up to 255 simultaneous
connections, one per accept()'d socket.
::
int lfd, cfd;
lfd = socket(PF_PHONET, SOCK_SEQPACKET, PN_PROTO_PIPE);
......@@ -161,7 +170,7 @@ Connections are traditionally established between two endpoints by a
As of Linux kernel version 2.6.39, it is also possible to connect
two endpoints directly, using connect() on the active side. This is
intended to support the newer Nokia Wireless Modem API, as found in
e.g. the Nokia Slim Modem in the ST-Ericsson U8500 platform:
e.g. the Nokia Slim Modem in the ST-Ericsson U8500 platform::
struct sockaddr_spn spn;
int fd;
......@@ -177,30 +186,35 @@ e.g. the Nokia Slim Modem in the ST-Ericsson U8500 platform:
close(fd);
WARNING:
When polling a connected pipe socket for writability, there is an
intrinsic race condition whereby writability might be lost between the
polling and the writing system calls. In this case, the socket will
block until write becomes possible again, unless non-blocking mode
is enabled.
.. Warning:
When polling a connected pipe socket for writability, there is an
intrinsic race condition whereby writability might be lost between the
polling and the writing system calls. In this case, the socket will
block until write becomes possible again, unless non-blocking mode
is enabled.
The pipe protocol provides two socket options at the SOL_PNPIPE level:
PNPIPE_ENCAP accepts one integer value (int) of:
PNPIPE_ENCAP_NONE: The socket operates normally (default).
PNPIPE_ENCAP_NONE:
The socket operates normally (default).
PNPIPE_ENCAP_IP: The socket is used as a backend for a virtual IP
PNPIPE_ENCAP_IP:
The socket is used as a backend for a virtual IP
interface. This requires CAP_NET_ADMIN capability. GPRS data
support on Nokia modems can use this. Note that the socket cannot
be reliably poll()'d or read() from while in this mode.
PNPIPE_IFINDEX is a read-only integer value. It contains the
PNPIPE_IFINDEX
is a read-only integer value. It contains the
interface index of the network interface created by PNPIPE_ENCAP,
or zero if encapsulation is off.
PNPIPE_HANDLE is a read-only integer value. It contains the underlying
PNPIPE_HANDLE
is a read-only integer value. It contains the underlying
identifier ("pipe handle") of the pipe. This is only defined for
socket descriptors that are already connected or being connected.
......@@ -209,6 +223,8 @@ Authors
-------
Linux Phonet was initially written by Sakari Ailus.
Other contributors include Mikä Liljeberg, Andras Domokos,
Carlos Chinea and Rémi Denis-Courmont.
Copyright (C) 2008 Nokia Corporation.
Copyright |copy| 2008 Nokia Corporation.
Documentation/networking/pktgen.txt → Documentation/networking/pktgen.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
HOWTO for the linux packet generator
------------------------------------
====================================
HOWTO for the linux packet generator
====================================
Enable CONFIG_NET_PKTGEN to compile and build pktgen either in-kernel
or as a module. A module is preferred; modprobe pktgen if needed. Once
......@@ -9,14 +10,15 @@ running, pktgen creates a thread for each CPU with affinity to that CPU.
Monitoring and controlling is done via /proc. It is easiest to select a
suitable sample script and configure that.
On a dual CPU:
On a dual CPU::
ps aux | grep pkt
root 129 0.3 0.0 0 0 ? SW 2003 523:20 [kpktgend_0]
root 130 0.3 0.0 0 0 ? SW 2003 509:50 [kpktgend_1]
ps aux | grep pkt
root 129 0.3 0.0 0 0 ? SW 2003 523:20 [kpktgend_0]
root 130 0.3 0.0 0 0 ? SW 2003 509:50 [kpktgend_1]
For monitoring and control pktgen creates::
For monitoring and control pktgen creates:
/proc/net/pktgen/pgctrl
/proc/net/pktgen/kpktgend_X
/proc/net/pktgen/ethX
......@@ -28,7 +30,8 @@ Tuning NIC for max performance
The default NIC settings are (likely) not tuned for pktgen's artificial
overload type of benchmarking, as this could hurt the normal use-case.
Specifically increasing the TX ring buffer in the NIC:
Specifically increasing the TX ring buffer in the NIC::
# ethtool -G ethX tx 1024
A larger TX ring can improve pktgen's performance, while it can hurt
......@@ -46,7 +49,8 @@ This cleanup issue is specifically the case for the driver ixgbe
and the cleanup interval is affected by the ethtool --coalesce setting
of parameter "rx-usecs".
For ixgbe use e.g. "30" resulting in approx 33K interrupts/sec (1/30*10^6):
For ixgbe use e.g. "30" resulting in approx 33K interrupts/sec (1/30*10^6)::
# ethtool -C ethX rx-usecs 30
......@@ -55,7 +59,7 @@ Kernel threads
Pktgen creates a thread for each CPU with affinity to that CPU.
Which is controlled through procfile /proc/net/pktgen/kpktgend_X.
Example: /proc/net/pktgen/kpktgend_0
Example: /proc/net/pktgen/kpktgend_0::
Running:
Stopped: eth4@0
......@@ -64,6 +68,7 @@ Example: /proc/net/pktgen/kpktgend_0
Most important are the devices assigned to the thread.
The two basic thread commands are:
* add_device DEVICE@NAME -- adds a single device
* rem_device_all -- remove all associated devices
......@@ -73,7 +78,7 @@ be unique.
To support adding the same device to multiple threads, which is useful
with multi queue NICs, the device naming scheme is extended with "@":
device@something
device@something
The part after "@" can be anything, but it is custom to use the thread
number.
......@@ -83,9 +88,9 @@ Viewing devices
The Params section holds configured information. The Current section
holds running statistics. The Result is printed after a run or after
interruption. Example:
interruption. Example::
/proc/net/pktgen/eth4@0
/proc/net/pktgen/eth4@0
Params: count 100000 min_pkt_size: 60 max_pkt_size: 60
frags: 0 delay: 0 clone_skb: 64 ifname: eth4@0
......@@ -114,11 +119,12 @@ Configuring devices
This is done via the /proc interface, and most easily done via pgset
as defined in the sample scripts.
You need to specify PGDEV environment variable to use functions from sample
scripts, i.e.:
export PGDEV=/proc/net/pktgen/eth4@0
source samples/pktgen/functions.sh
scripts, i.e.::
export PGDEV=/proc/net/pktgen/eth4@0
source samples/pktgen/functions.sh
Examples:
Examples::
pg_ctrl start starts injection.
pg_ctrl stop aborts injection. Also, ^C aborts generator.
......@@ -232,10 +238,14 @@ A collection of tutorial scripts and helpers for pktgen is in the
samples/pktgen directory. The helper parameters.sh file support easy
and consistent parameter parsing across the sample scripts.
Usage example and help:
Usage example and help::
./pktgen_sample01_simple.sh -i eth4 -m 00:1B:21:3C:9D:F8 -d 192.168.8.2
Usage: ./pktgen_sample01_simple.sh [-vx] -i ethX
Usage:::
./pktgen_sample01_simple.sh [-vx] -i ethX
-i : ($DEV) output interface/device (required)
-s : ($PKT_SIZE) packet size
-d : ($DEST_IP) destination IP
......@@ -250,13 +260,13 @@ The global variables being set are also listed. E.g. the required
interface/device parameter "-i" sets variable $DEV. Copy the
pktgen_sampleXX scripts and modify them to fit your own needs.
The old scripts:
The old scripts::
pktgen.conf-1-2 # 1 CPU 2 dev
pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS
pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6
pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS
pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows.
pktgen.conf-1-2 # 1 CPU 2 dev
pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS
pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6
pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS
pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows.
Interrupt affinity
......@@ -271,10 +281,10 @@ to the running threads CPU (directly from smp_processor_id()).
Enable IPsec
============
Default IPsec transformation with ESP encapsulation plus transport mode
can be enabled by simply setting:
can be enabled by simply setting::
pgset "flag IPSEC"
pgset "flows 1"
pgset "flag IPSEC"
pgset "flows 1"
To avoid breaking existing testbed scripts for using AH type and tunnel mode,
you can use "pgset spi SPI_VALUE" to specify which transformation mode
......@@ -284,53 +294,53 @@ to employ.
Current commands and configuration options
==========================================
** Pgcontrol commands:
**Pgcontrol commands**::
start
stop
reset
start
stop
reset
** Thread commands:
**Thread commands**::
add_device
rem_device_all
add_device
rem_device_all
** Device commands:
**Device commands**::
count
clone_skb
burst
debug
count
clone_skb
burst
debug
frags
delay
frags
delay
src_mac_count
dst_mac_count
src_mac_count
dst_mac_count
pkt_size
min_pkt_size
max_pkt_size
pkt_size
min_pkt_size
max_pkt_size
queue_map_min
queue_map_max
skb_priority
queue_map_min
queue_map_max
skb_priority
tos (ipv4)
traffic_class (ipv6)
tos (ipv4)
traffic_class (ipv6)
mpls
mpls
udp_src_min
udp_src_max
udp_src_min
udp_src_max
udp_dst_min
udp_dst_max
udp_dst_min
udp_dst_max
node
node
flag
flag
IPSRC_RND
IPDST_RND
UDPSRC_RND
......@@ -350,49 +360,51 @@ flag
NODE_ALLOC
NO_TIMESTAMP
spi (ipsec)
spi (ipsec)
dst_min
dst_max
dst_min
dst_max
src_min
src_max
src_min
src_max
dst_mac
src_mac
dst_mac
src_mac
clear_counters
clear_counters
src6
dst6
dst6_max
dst6_min
src6
dst6
dst6_max
dst6_min
flows
flowlen
flows
flowlen
rate
ratep
rate
ratep
xmit_mode <start_xmit|netif_receive>
xmit_mode <start_xmit|netif_receive>
vlan_cfi
vlan_id
vlan_p
vlan_cfi
vlan_id
vlan_p
svlan_cfi
svlan_id
svlan_p
svlan_cfi
svlan_id
svlan_p
References:
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
- tp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
Paper from Linux-Kongress in Erlangen 2004.
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf
- ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf
Thanks to:
Grant Grundler for testing on IA-64 and parisc, Harald Welte, Lennert Buytenhek
Stephen Hemminger, Andi Kleen, Dave Miller and many others.
......
Documentation/networking/PLIP.txt → Documentation/networking/plip.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
================================================
PLIP: The Parallel Line Internet Protocol Device
================================================
Donald Becker (becker@super.org)
I.D.A. Supercomputing Research Center, Bowie MD 20715
......@@ -115,7 +119,7 @@ printer "null" cable to transfer data four bits at a time using
data bit outputs connected to status bit inputs.
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer''
bi-directional parallel ports, rather than output-only ``printer``
ports. This allows byte-wide transfers and avoids reconstructing
nibbles into bytes, leading to much faster transfers.
......@@ -132,7 +136,7 @@ bits with standard status register implementation.
A cable that implements this protocol is available commercially as a
"Null Printer" or "Turbo Laplink" cable. It can be constructed with
two DB-25 male connectors symmetrically connected as follows:
two DB-25 male connectors symmetrically connected as follows::
STROBE output 1*
D0->ERROR 2 - 15 15 - 2
......@@ -146,7 +150,8 @@ two DB-25 male connectors symmetrically connected as follows:
SLCTIN 17 - 17
extra grounds are 18*,19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
* Do not connect these pins on either end
If the cable you are using has a metallic shield it should be
connected to the metallic DB-25 shell at one end only.
......@@ -155,14 +160,14 @@ Parallel Transfer Mode 1
========================
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer''
bi-directional parallel ports, rather than output-only ``printer``
ports. This allows byte-wide transfers, and avoids reconstructing
nibbles into bytes. This cable should not be used on unidirectional
``printer'' (as opposed to ``parallel'') ports or when the machine
``printer`` (as opposed to ``parallel``) ports or when the machine
isn't configured for PLIP, as it will result in output driver
conflicts and the (unlikely) possibility of damage.
The cable for this transfer mode should be constructed as follows:
The cable for this transfer mode should be constructed as follows::
STROBE->BUSY 1 - 11
D0->D0 2 - 2
......@@ -179,7 +184,8 @@ The cable for this transfer mode should be constructed as follows:
GND->ERROR 18 - 15
extra grounds are 19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
* Do not connect these pins on either end
Once again, if the cable you are using has a metallic shield it should
be connected to the metallic DB-25 shell at one end only.
......@@ -188,7 +194,7 @@ PLIP Mode 0 transfer protocol
=============================
The PLIP driver is compatible with the "Crynwr" parallel port transfer
standard in Mode 0. That standard specifies the following protocol:
standard in Mode 0. That standard specifies the following protocol::
send header nibble '0x8'
count-low octet
......@@ -196,7 +202,8 @@ standard in Mode 0. That standard specifies the following protocol:
... data octets
checksum octet
Each octet is sent as
Each octet is sent as::
<wait for rx. '0x1?'> <send 0x10+(octet&0x0F)>
<wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)>
......@@ -205,10 +212,10 @@ That raises the ACK line, triggering an interrupt in the receiving
machine. The receiving machine disables interrupts and raises its own ACK
line.
Restated:
Restated::
(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
Send_Byte:
(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
Send_Byte:
OUT := low nibble, OUT.4 := 1
WAIT FOR IN.4 = 1
OUT := high nibble, OUT.4 := 0
......
Documentation/networking/ppp_generic.txt → Documentation/networking/ppp_generic.rst
View file @ 07f81727
PPP Generic Driver and Channel Interface
----------------------------------------
.. SPDX-License-Identifier: GPL-2.0
========================================
PPP Generic Driver and Channel Interface
========================================
Paul Mackerras
paulus@samba.org
7 Feb 2002
The generic PPP driver in linux-2.4 provides an implementation of the
......@@ -19,7 +23,7 @@ functionality which is of use in any PPP implementation, including:
* simple packet filtering
For sending and receiving PPP frames, the generic PPP driver calls on
the services of PPP `channels'. A PPP channel encapsulates a
the services of PPP ``channels``. A PPP channel encapsulates a
mechanism for transporting PPP frames from one machine to another. A
PPP channel implementation can be arbitrarily complex internally but
has a very simple interface with the generic PPP code: it merely has
......@@ -102,7 +106,7 @@ communications medium and prepare it to do PPP. For example, with an
async tty, this can involve setting the tty speed and modes, issuing
modem commands, and then going through some sort of dialog with the
remote system to invoke PPP service there. We refer to this process
as `discovery'. Then the user-level process tells the medium to
as ``discovery``. Then the user-level process tells the medium to
become a PPP channel and register itself with the generic PPP layer.
The channel then has to report the channel number assigned to it back
to the user-level process. From that point, the PPP negotiation code
......@@ -111,8 +115,8 @@ negotiation, accessing the channel through the /dev/ppp interface.
At the interface to the PPP generic layer, PPP frames are stored in
skbuff structures and start with the two-byte PPP protocol number.
The frame does *not* include the 0xff `address' byte or the 0x03
`control' byte that are optionally used in async PPP. Nor is there
The frame does *not* include the 0xff ``address`` byte or the 0x03
``control`` byte that are optionally used in async PPP. Nor is there
any escaping of control characters, nor are there any FCS or framing
characters included. That is all the responsibility of the channel
code, if it is needed for the particular medium. That is, the skbuffs
......@@ -121,16 +125,16 @@ protocol number and the data, and the skbuffs presented to ppp_input()
must be in the same format.
The channel must provide an instance of a ppp_channel struct to
represent the channel. The channel is free to use the `private' field
however it wishes. The channel should initialize the `mtu' and
`hdrlen' fields before calling ppp_register_channel() and not change
them until after ppp_unregister_channel() returns. The `mtu' field
represent the channel. The channel is free to use the ``private`` field
however it wishes. The channel should initialize the ``mtu`` and
``hdrlen`` fields before calling ppp_register_channel() and not change
them until after ppp_unregister_channel() returns. The ``mtu`` field
represents the maximum size of the data part of the PPP frames, that
is, it does not include the 2-byte protocol number.
If the channel needs some headroom in the skbuffs presented to it for
transmission (i.e., some space free in the skbuff data area before the
start of the PPP frame), it should set the `hdrlen' field of the
start of the PPP frame), it should set the ``hdrlen`` field of the
ppp_channel struct to the amount of headroom required. The generic
PPP layer will attempt to provide that much headroom but the channel
should still check if there is sufficient headroom and copy the skbuff
......@@ -322,6 +326,8 @@ an interface unit are:
interface. The argument should be a pointer to an int containing
the new flags value. The bits in the flags value that can be set
are:
================ ========================================
SC_COMP_TCP enable transmit TCP header compression
SC_NO_TCP_CCID disable connection-id compression for
TCP header compression
......@@ -335,6 +341,7 @@ an interface unit are:
SC_MP_SHORTSEQ expect short multilink sequence
numbers on received multilink fragments
SC_MP_XSHORTSEQ transmit short multilink sequence nos.
================ ========================================
The values of these flags are defined in <linux/ppp-ioctl.h>. Note
that the values of the SC_MULTILINK, SC_MP_SHORTSEQ and
......@@ -345,17 +352,20 @@ an interface unit are:
interface unit. The argument should point to an int where the ioctl
will store the flags value. As well as the values listed above for
PPPIOCSFLAGS, the following bits may be set in the returned value:
================ =========================================
SC_COMP_RUN CCP compressor is running
SC_DECOMP_RUN CCP decompressor is running
SC_DC_ERROR CCP decompressor detected non-fatal error
SC_DC_FERROR CCP decompressor detected fatal error
================ =========================================
* PPPIOCSCOMPRESS sets the parameters for packet compression or
decompression. The argument should point to a ppp_option_data
structure (defined in <linux/ppp-ioctl.h>), which contains a
pointer/length pair which should describe a block of memory
containing a CCP option specifying a compression method and its
parameters. The ppp_option_data struct also contains a `transmit'
parameters. The ppp_option_data struct also contains a ``transmit``
field. If this is 0, the ioctl will affect the receive path,
otherwise the transmit path.
......@@ -377,7 +387,7 @@ an interface unit are:
ppp_idle structure (defined in <linux/ppp_defs.h>). If the
CONFIG_PPP_FILTER option is enabled, the set of packets which reset
the transmit and receive idle timers is restricted to those which
pass the `active' packet filter.
pass the ``active`` packet filter.
Two versions of this command exist, to deal with user space
expecting times as either 32-bit or 64-bit time_t seconds.
......@@ -391,31 +401,33 @@ an interface unit are:
* PPPIOCSNPMODE sets the network-protocol mode for a given network
protocol. The argument should point to an npioctl struct (defined
in <linux/ppp-ioctl.h>). The `protocol' field gives the PPP protocol
number for the protocol to be affected, and the `mode' field
in <linux/ppp-ioctl.h>). The ``protocol`` field gives the PPP protocol
number for the protocol to be affected, and the ``mode`` field
specifies what to do with packets for that protocol:
============= ==============================================
NPMODE_PASS normal operation, transmit and receive packets
NPMODE_DROP silently drop packets for this protocol
NPMODE_ERROR drop packets and return an error on transmit
NPMODE_QUEUE queue up packets for transmit, drop received
packets
============= ==============================================
At present NPMODE_ERROR and NPMODE_QUEUE have the same effect as
NPMODE_DROP.
* PPPIOCGNPMODE returns the network-protocol mode for a given
protocol. The argument should point to an npioctl struct with the
`protocol' field set to the PPP protocol number for the protocol of
interest. On return the `mode' field will be set to the network-
``protocol`` field set to the PPP protocol number for the protocol of
interest. On return the ``mode`` field will be set to the network-
protocol mode for that protocol.
* PPPIOCSPASS and PPPIOCSACTIVE set the `pass' and `active' packet
* PPPIOCSPASS and PPPIOCSACTIVE set the ``pass`` and ``active`` packet
filters. These ioctls are only available if the CONFIG_PPP_FILTER
option is selected. The argument should point to a sock_fprog
structure (defined in <linux/filter.h>) containing the compiled BPF
instructions for the filter. Packets are dropped if they fail the
`pass' filter; otherwise, if they fail the `active' filter they are
``pass`` filter; otherwise, if they fail the ``active`` filter they are
passed but they do not reset the transmit or receive idle timer.
* PPPIOCSMRRU enables or disables multilink processing for received
......
Documentation/networking/proc_net_tcp.txt → Documentation/networking/proc_net_tcp.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
============================================
The proc/net/tcp and proc/net/tcp6 variables
============================================
This document describes the interfaces /proc/net/tcp and /proc/net/tcp6.
Note that these interfaces are deprecated in favor of tcp_diag.
......@@ -7,7 +13,7 @@ and tcp6_seq_show() in net/ipv6/tcp_ipv6.c, respectively.
It will first list all listening TCP sockets, and next list all established
TCP connections. A typical entry of /proc/net/tcp would look like this (split
up into 3 parts because of the length of the line):
up into 3 parts because of the length of the line)::
46: 010310AC:9C4C 030310AC:1770 01
| | | | | |--> connection state
......@@ -40,9 +46,12 @@ up into 3 parts because of the length of the line):
|---------------------------------------------> uid
timer_active:
== ================================================================
0 no timer is pending
1 retransmit-timer is pending
2 another timer (e.g. delayed ack or keepalive) is pending
3 this is a socket in TIME_WAIT state. Not all fields will contain
data (or even exist)
4 zero window probe timer is pending
== ================================================================
Documentation/networking/radiotap-headers.txt → Documentation/networking/radiotap-headers.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
===========================
How to use radiotap headers
===========================
......@@ -5,9 +8,9 @@ Pointer to the radiotap include file
------------------------------------
Radiotap headers are variable-length and extensible, you can get most of the
information you need to know on them from:
information you need to know on them from::
./include/net/ieee80211_radiotap.h
./include/net/ieee80211_radiotap.h
This document gives an overview and warns on some corner cases.
......@@ -21,6 +24,8 @@ of the it_present member of ieee80211_radiotap_header is set, it means that
the header for argument index 0 (IEEE80211_RADIOTAP_TSFT) is present in the
argument area.
::
< 8-byte ieee80211_radiotap_header >
[ <possible argument bitmap extensions ... > ]
[ <argument> ... ]
......@@ -76,6 +81,8 @@ ieee80211_radiotap_header.
Example valid radiotap header
-----------------------------
::
0x00, 0x00, // <-- radiotap version + pad byte
0x0b, 0x00, // <- radiotap header length
0x04, 0x0c, 0x00, 0x00, // <-- bitmap
......@@ -89,14 +96,14 @@ Using the Radiotap Parser
If you are having to parse a radiotap struct, you can radically simplify the
job by using the radiotap parser that lives in net/wireless/radiotap.c and has
its prototypes available in include/net/cfg80211.h. You use it like this:
its prototypes available in include/net/cfg80211.h. You use it like this::
#include <net/cfg80211.h>
#include <net/cfg80211.h>
/* buf points to the start of the radiotap header part */
/* buf points to the start of the radiotap header part */
int MyFunction(u8 * buf, int buflen)
{
int MyFunction(u8 * buf, int buflen)
{
int pkt_rate_100kHz = 0, antenna = 0, pwr = 0;
struct ieee80211_radiotap_iterator iterator;
int ret = ieee80211_radiotap_iterator_init(&iterator, buf, buflen);
......@@ -147,6 +154,6 @@ int MyFunction(u8 * buf, int buflen)
...
}
}
Andy Green <andy@warmcat.com>
Documentation/networking/ray_cs.txt → Documentation/networking/ray_cs.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
=========================
Raylink wireless LAN card
=========================
September 21, 1999
Copyright (c) 1998 Corey Thomas (corey@world.std.com)
Copyright |copy| 1998 Corey Thomas (corey@world.std.com)
This file is the documentation for the Raylink Wireless LAN card driver for
Linux. The Raylink wireless LAN card is a PCMCIA card which provides IEEE
......@@ -29,6 +37,7 @@ with nondefault parameters, they can be edited in
will find them all.
Information on card services is available at:
http://pcmcia-cs.sourceforge.net/
......@@ -43,19 +52,19 @@ At the end of the /etc/pcmcia/config.opts file, add the line:
source ./ray_cs.opts
This will make card services read the ray_cs.opts file
when starting. Create the file /etc/pcmcia/ray_cs.opts containing the
following:
following::
#### start of /etc/pcmcia/ray_cs.opts ###################
# Configuration options for Raylink Wireless LAN PCMCIA card
device "ray_cs"
#### start of /etc/pcmcia/ray_cs.opts ###################
# Configuration options for Raylink Wireless LAN PCMCIA card
device "ray_cs"
class "network" module "misc/ray_cs"
card "RayLink PC Card WLAN Adapter"
card "RayLink PC Card WLAN Adapter"
manfid 0x01a6, 0x0000
bind "ray_cs"
module "misc/ray_cs" opts ""
#### end of /etc/pcmcia/ray_cs.opts #####################
module "misc/ray_cs" opts ""
#### end of /etc/pcmcia/ray_cs.opts #####################
To join an existing network with
......@@ -65,33 +74,39 @@ Add the parameters below between the empty quotes.
Parameters for ray_cs driver which may be specified in ray_cs.opts:
bc integer 0 = normal mode (802.11 timing)
=============== =============== =============================================
bc integer 0 = normal mode (802.11 timing),
1 = slow down inter frame timing to allow
operation with older breezecom access
points.
beacon_period integer beacon period in Kilo-microseconds
beacon_period integer beacon period in Kilo-microseconds,
legal values = must be integer multiple
of hop dwell
default = 256
country integer 1 = USA (default)
2 = Europe
3 = Japan
4 = Korea
5 = Spain
6 = France
7 = Israel
country integer 1 = USA (default),
2 = Europe,
3 = Japan,
4 = Korea,
5 = Spain,
6 = France,
7 = Israel,
8 = Australia
essid string ESS ID - network name to join
string with maximum length of 32 chars
default value = "ADHOC_ESSID"
hop_dwell integer hop dwell time in Kilo-microseconds
legal values = 16,32,64,128(default),256
irq_mask integer linux standard 16 bit value 1bit/IRQ
lsb is IRQ 0, bit 1 is IRQ 1 etc.
Used to restrict choice of IRQ's to use.
Recommended method for controlling
......@@ -104,7 +119,7 @@ phy_addr string string containing new MAC address in
hex, must start with x eg
x00008f123456
psm integer 0 = continuously active
psm integer 0 = continuously active,
1 = power save mode (not useful yet)
pc_debug integer (0-5) larger values for more verbose
......@@ -114,14 +129,14 @@ ray_debug integer Replaced with pc_debug
ray_mem_speed integer defaults to 500
sniffer integer 0 = not sniffer (default)
sniffer integer 0 = not sniffer (default),
1 = sniffer which can be used to record all
network traffic using tcpdump or similar,
but no normal network use is allowed.
translate integer 0 = no translation (encapsulate frames)
translate integer 0 = no translation (encapsulate frames),
1 = translation (RFC1042/802.1)
=============== =============== =============================================
More on sniffer mode:
......
Documentation/networking/rds.txt → Documentation/networking/rds.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
==
RDS
===
Overview
========
......@@ -24,6 +29,7 @@ as IB.
The high-level semantics of RDS from the application's point of view are
* Addressing
RDS uses IPv4 addresses and 16bit port numbers to identify
the end point of a connection. All socket operations that involve
passing addresses between kernel and user space generally
......@@ -38,6 +44,7 @@ The high-level semantics of RDS from the application's point of view are
protocol.
* Socket interface
RDS sockets work *mostly* as you would expect from a BSD
socket. The next section will cover the details. At any rate,
all I/O is performed through the standard BSD socket API.
......@@ -53,6 +60,7 @@ The high-level semantics of RDS from the application's point of view are
doesn't move to a different transport.
* sysctls
RDS supports a number of sysctls in /proc/sys/net/rds
......@@ -147,8 +155,7 @@ Socket Interface
operation. In this case, it would use RDS_CANCEL_SENT_TO to
nuke any pending messages.
setsockopt(fd, SOL_RDS, SO_RDS_TRANSPORT, (int *)&transport ..)
getsockopt(fd, SOL_RDS, SO_RDS_TRANSPORT, (int *)&transport ..)
``setsockopt(fd, SOL_RDS, SO_RDS_TRANSPORT, (int *)&transport ..), getsockopt(fd, SOL_RDS, SO_RDS_TRANSPORT, (int *)&transport ..)``
Set or read an integer defining the underlying
encapsulating transport to be used for RDS packets on the
socket. When setting the option, integer argument may be
......@@ -180,7 +187,9 @@ RDS Protocol
Message header
The message header is a 'struct rds_header' (see rds.h):
Fields:
h_sequence:
per-packet sequence number
h_ack:
......@@ -192,9 +201,14 @@ RDS Protocol
h_dport:
destination port
h_flags:
CONG_BITMAP - this is a congestion update bitmap
ACK_REQUIRED - receiver must ack this packet
RETRANSMITTED - packet has previously been sent
Can be:
============= ==================================
CONG_BITMAP this is a congestion update bitmap
ACK_REQUIRED receiver must ack this packet
RETRANSMITTED packet has previously been sent
============= ==================================
h_credit:
indicate to other end of connection that
it has more credits available (i.e. there is
......@@ -260,7 +274,7 @@ RDS Protocol
RDS Transport Layer
==================
===================
As mentioned above, RDS is not IB-specific. Its code is divided
into a general RDS layer and a transport layer.
......@@ -281,19 +295,25 @@ RDS Kernel Structures
be sent and sets header fields as needed, based on the socket API.
This is then queued for the individual connection and sent by the
connection's transport.
struct rds_incoming
a generic struct referring to incoming data that can be handed from
the transport to the general code and queued by the general code
while the socket is awoken. It is then passed back to the transport
code to handle the actual copy-to-user.
struct rds_socket
per-socket information
struct rds_connection
per-connection information
struct rds_transport
pointers to transport-specific functions
struct rds_statistics
non-transport-specific statistics
struct rds_cong_map
wraps the raw congestion bitmap, contains rbnode, waitq, etc.
......@@ -317,53 +337,58 @@ The send path
=============
rds_sendmsg()
struct rds_message built from incoming data
CMSGs parsed (e.g. RDMA ops)
transport connection alloced and connected if not already
rds_message placed on send queue
send worker awoken
- struct rds_message built from incoming data
- CMSGs parsed (e.g. RDMA ops)
- transport connection alloced and connected if not already
- rds_message placed on send queue
- send worker awoken
rds_send_worker()
calls rds_send_xmit() until queue is empty
- calls rds_send_xmit() until queue is empty
rds_send_xmit()
transmits congestion map if one is pending
may set ACK_REQUIRED
calls transport to send either non-RDMA or RDMA message
- transmits congestion map if one is pending
- may set ACK_REQUIRED
- calls transport to send either non-RDMA or RDMA message
(RDMA ops never retransmitted)
rds_ib_xmit()
allocs work requests from send ring
adds any new send credits available to peer (h_credits)
maps the rds_message's sg list
piggybacks ack
populates work requests
post send to connection's queue pair
- allocs work requests from send ring
- adds any new send credits available to peer (h_credits)
- maps the rds_message's sg list
- piggybacks ack
- populates work requests
- post send to connection's queue pair
The recv path
=============
rds_ib_recv_cq_comp_handler()
looks at write completions
unmaps recv buffer from device
no errors, call rds_ib_process_recv()
refill recv ring
- looks at write completions
- unmaps recv buffer from device
- no errors, call rds_ib_process_recv()
- refill recv ring
rds_ib_process_recv()
validate header checksum
copy header to rds_ib_incoming struct if start of a new datagram
add to ibinc's fraglist
if competed datagram:
update cong map if datagram was cong update
call rds_recv_incoming() otherwise
note if ack is required
- validate header checksum
- copy header to rds_ib_incoming struct if start of a new datagram
- add to ibinc's fraglist
- if competed datagram:
- update cong map if datagram was cong update
- call rds_recv_incoming() otherwise
- note if ack is required
rds_recv_incoming()
drop duplicate packets
respond to pings
find the sock associated with this datagram
add to sock queue
wake up sock
do some congestion calculations
- drop duplicate packets
- respond to pings
- find the sock associated with this datagram
- add to sock queue
- wake up sock
- do some congestion calculations
rds_recvmsg
copy data into user iovec
handle CMSGs
return to application
- copy data into user iovec
- handle CMSGs
- return to application
Multipath RDS (mprds)
=====================
......
Documentation/networking/regulatory.txt → Documentation/networking/regulatory.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=======================================
Linux wireless regulatory documentation
---------------------------------------
=======================================
This document gives a brief review over how the Linux wireless
regulatory infrastructure works.
......@@ -57,7 +60,7 @@ Users can use iw:
http://wireless.kernel.org/en/users/Documentation/iw
An example:
An example::
# set regulatory domain to "Costa Rica"
iw reg set CR
......@@ -104,9 +107,9 @@ Example code - drivers hinting an alpha2:
This example comes from the zd1211rw device driver. You can start
by having a mapping of your device's EEPROM country/regulatory
domain value to a specific alpha2 as follows:
domain value to a specific alpha2 as follows::
static struct zd_reg_alpha2_map reg_alpha2_map[] = {
static struct zd_reg_alpha2_map reg_alpha2_map[] = {
{ ZD_REGDOMAIN_FCC, "US" },
{ ZD_REGDOMAIN_IC, "CA" },
{ ZD_REGDOMAIN_ETSI, "DE" }, /* Generic ETSI, use most restrictive */
......@@ -116,10 +119,10 @@ static struct zd_reg_alpha2_map reg_alpha2_map[] = {
{ ZD_REGDOMAIN_FRANCE, "FR" },
Then you can define a routine to map your read EEPROM value to an alpha2,
as follows:
as follows::
static int zd_reg2alpha2(u8 regdomain, char *alpha2)
{
static int zd_reg2alpha2(u8 regdomain, char *alpha2)
{
unsigned int i;
struct zd_reg_alpha2_map *reg_map;
for (i = 0; i < ARRAY_SIZE(reg_alpha2_map); i++) {
......@@ -131,12 +134,14 @@ static int zd_reg2alpha2(u8 regdomain, char *alpha2)
}
}
return 1;
}
}
Lastly, you can then hint to the core of your discovered alpha2, if a match
was found. You need to do this after you have registered your wiphy. You
are expected to do this during initialization.
::
r = zd_reg2alpha2(mac->regdomain, alpha2);
if (!r)
regulatory_hint(hw->wiphy, alpha2);
......@@ -156,9 +161,9 @@ call regulatory_hint() with the regulatory domain structure in it.
Bellow is a simple example, with a regulatory domain cached using the stack.
Your implementation may vary (read EEPROM cache instead, for example).
Example cache of some regulatory domain
Example cache of some regulatory domain::
struct ieee80211_regdomain mydriver_jp_regdom = {
struct ieee80211_regdomain mydriver_jp_regdom = {
.n_reg_rules = 3,
.alpha2 = "JP",
//.alpha2 = "99", /* If I have no alpha2 to map it to */
......@@ -173,9 +178,9 @@ struct ieee80211_regdomain mydriver_jp_regdom = {
NL80211_RRF_NO_IR|
NL80211_RRF_DFS),
}
};
};
Then in some part of your code after your wiphy has been registered:
Then in some part of your code after your wiphy has been registered::
struct ieee80211_regdomain *rd;
int size_of_regd;
......
Documentation/networking/sctp.txt → Documentation/networking/sctp.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=================
Linux Kernel SCTP
=================
This is the current BETA release of the Linux Kernel SCTP reference
implementation.
......@@ -19,17 +23,20 @@ of SCTP that is RFC 2960 compliant and provides an programming interface
referred to as the UDP-style API of the Sockets Extensions for SCTP, as
proposed in IETF Internet-Drafts.
Caveats:
Caveats
=======
-lksctp can be built as statically or as a module. However, be aware that
module removal of lksctp is not yet a safe activity.
- lksctp can be built as statically or as a module. However, be aware that
module removal of lksctp is not yet a safe activity.
-There is tentative support for IPv6, but most work has gone towards
implementation and testing lksctp on IPv4.
- There is tentative support for IPv6, but most work has gone towards
implementation and testing lksctp on IPv4.
For more information, please visit the lksctp project website:
http://www.sf.net/projects/lksctp
Or contact the lksctp developers through the mailing list:
<linux-sctp@vger.kernel.org>
Documentation/networking/secid.txt → Documentation/networking/secid.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=================
LSM/SeLinux secid
=================
flowi structure:
The secid member in the flow structure is used in LSMs (e.g. SELinux) to indicate
......
Documentation/networking/seg6-sysctl.txt → Documentation/networking/seg6-sysctl.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
====================
Seg6 Sysfs variables
====================
/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
* 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
* -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.
Documentation/networking/skfp.txt → Documentation/networking/skfp.rst
View file @ 07f81727
(C)Copyright 1998-2000 SysKonnect,
===========================================================================
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
========================
SysKonnect driver - SKFP
========================
|copy| Copyright 1998-2000 SysKonnect,
skfp.txt created 11-May-2000
Readme File for skfp.o v2.06
This file contains
(1) OVERVIEW
(2) SUPPORTED ADAPTERS
(3) GENERAL INFORMATION
(4) INSTALLATION
(5) INCLUSION OF THE ADAPTER IN SYSTEM START
(6) TROUBLESHOOTING
(7) FUNCTION OF THE ADAPTER LEDS
(8) HISTORY
.. This file contains
===========================================================================
(1) OVERVIEW
(2) SUPPORTED ADAPTERS
(3) GENERAL INFORMATION
(4) INSTALLATION
(5) INCLUSION OF THE ADAPTER IN SYSTEM START
(6) TROUBLESHOOTING
(7) FUNCTION OF THE ADAPTER LEDS
(8) HISTORY
(1) OVERVIEW
============
1. Overview
===========
This README explains how to use the driver 'skfp' for Linux with your
network adapter.
Chapter 2: Contains a list of all network adapters that are supported by
this driver.
this driver.
Chapter 3: Gives some general information.
Chapter 3:
Gives some general information.
Chapter 4: Describes common problems and solutions.
......@@ -37,14 +43,13 @@ Chapter 5: Shows the changed functionality of the adapter LEDs.
Chapter 6: History of development.
***
(2) SUPPORTED ADAPTERS
======================
2. Supported adapters
=====================
The network driver 'skfp' supports the following network adapters:
SysKonnect adapters:
- SK-5521 (SK-NET FDDI-UP)
- SK-5522 (SK-NET FDDI-UP DAS)
- SK-5541 (SK-NET FDDI-FP)
......@@ -55,72 +60,85 @@ SysKonnect adapters:
- SK-5841 (SK-NET FDDI-FP64)
- SK-5843 (SK-NET FDDI-LP64)
- SK-5844 (SK-NET FDDI-LP64 DAS)
Compaq adapters (not tested):
- Netelligent 100 FDDI DAS Fibre SC
- Netelligent 100 FDDI SAS Fibre SC
- Netelligent 100 FDDI DAS UTP
- Netelligent 100 FDDI SAS UTP
- Netelligent 100 FDDI SAS Fibre MIC
***
(3) GENERAL INFORMATION
=======================
3. General Information
======================
From v2.01 on, the driver is integrated in the linux kernel sources.
Therefore, the installation is the same as for any other adapter
supported by the kernel.
Refer to the manual of your distribution about the installation
of network adapters.
Makes my life much easier :-)
***
Makes my life much easier :-)
(4) TROUBLESHOOTING
===================
4. Troubleshooting
==================
If you run into problems during installation, check those items:
Problem: The FDDI adapter cannot be found by the driver.
Reason: Look in /proc/pci for the following entry:
Problem:
The FDDI adapter cannot be found by the driver.
Reason:
Look in /proc/pci for the following entry:
'FDDI network controller: SysKonnect SK-FDDI-PCI ...'
If this entry exists, then the FDDI adapter has been
found by the system and should be able to be used.
If this entry does not exist or if the file '/proc/pci'
is not there, then you may have a hardware problem or PCI
support may not be enabled in your kernel.
The adapter can be checked using the diagnostic program
which is available from the SysKonnect web site:
www.syskonnect.de
Some COMPAQ machines have a problem with PCI under
Linux. This is described in the 'PCI howto' document
(included in some distributions or available from the
www, e.g. at 'www.linux.org') and no workaround is available.
Problem: You want to use your computer as a router between
Problem:
You want to use your computer as a router between
multiple IP subnetworks (using multiple adapters), but
you cannot reach computers in other subnetworks.
Reason: Either the router's kernel is not configured for IP
Reason:
Either the router's kernel is not configured for IP
forwarding or there is a problem with the routing table
and gateway configuration in at least one of the
computers.
If your problem is not listed here, please contact our
technical support for help.
You can send email to:
linux@syskonnect.de
You can send email to: linux@syskonnect.de
When contacting our technical support,
please ensure that the following information is available:
- System Manufacturer and Model
- Boards in your system
- Distribution
- Kernel version
***
(5) FUNCTION OF THE ADAPTER LEDS
================================
5. Function of the Adapter LEDs
===============================
The functionality of the LED's on the FDDI network adapters was
changed in SMT version v2.82. With this new SMT version, the yellow
......@@ -137,74 +155,91 @@ please ensure that the following information is available:
All implementations indicate that a driver is not loaded if
all LEDs are off.
***
(6) HISTORY
===========
6. History
==========
v2.06 (20000511) (In-Kernel version)
New features:
- 64 bit support
- new pci dma interface
- in kernel 2.3.99
v2.05 (20000217) (In-Kernel version)
New features:
- Changes for 2.3.45 kernel
v2.04 (20000207) (Standalone version)
New features:
- Added rx/tx byte counter
v2.03 (20000111) (Standalone version)
Problems fixed:
- Fixed printk statements from v2.02
v2.02 (991215) (Standalone version)
Problems fixed:
- Removed unnecessary output
- Fixed path for "printver.sh" in makefile
v2.01 (991122) (In-Kernel version)
New features:
- Integration in Linux kernel sources
- Support for memory mapped I/O.
v2.00 (991112)
New features:
- Full source released under GPL
v1.05 (991023)
Problems fixed:
- Compilation with kernel version 2.2.13 failed
v1.04 (990427)
Changes:
- New SMT module included, changing LED functionality
Problems fixed:
- Synchronization on SMP machines was buggy
v1.03 (990325)
Problems fixed:
- Interrupt routing on SMP machines could be incorrect
v1.02 (990310)
New features:
- Support for kernel versions 2.2.x added
- Kernel patch instead of private duplicate of kernel functions
v1.01 (980812)
Problems fixed:
Connection hangup with telnet
Slow telnet connection
v1.00 beta 01 (980507)
New features:
None.
Problems fixed:
None.
Known limitations:
- tar archive instead of standard package format (rpm).
- FDDI statistic is empty.
- not tested with 2.1.xx kernels
......@@ -216,5 +251,3 @@ v1.00 beta 01 (980507)
- does not work on some COMPAQ machines. See the PCI howto
document for details about this problem.
- data corruption with kernel versions below 2.0.33.
*** End of information file ***
Documentation/networking/strparser.txt → Documentation/networking/strparser.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
=========================
Stream Parser (strparser)
=========================
Introduction
============
......@@ -34,7 +38,9 @@ that is called when a full message has been completed.
Functions
=========
strp_init(struct strparser *strp, struct sock *sk,
::
strp_init(struct strparser *strp, struct sock *sk,
const struct strp_callbacks *cb)
Called to initialize a stream parser. strp is a struct of type
......@@ -43,29 +49,39 @@ strp_init(struct strparser *strp, struct sock *sk,
callback mode; in general mode this is set to NULL. Callbacks
are called by the stream parser (the callbacks are listed below).
void strp_pause(struct strparser *strp)
::
void strp_pause(struct strparser *strp)
Temporarily pause a stream parser. Message parsing is suspended
and no new messages are delivered to the upper layer.
void strp_unpause(struct strparser *strp)
::
void strp_unpause(struct strparser *strp)
Unpause a paused stream parser.
void strp_stop(struct strparser *strp);
::
void strp_stop(struct strparser *strp);
strp_stop is called to completely stop stream parser operations.
This is called internally when the stream parser encounters an
error, and it is called from the upper layer to stop parsing
operations.
void strp_done(struct strparser *strp);
::
void strp_done(struct strparser *strp);
strp_done is called to release any resources held by the stream
parser instance. This must be called after the stream processor
has been stopped.
int strp_process(struct strparser *strp, struct sk_buff *orig_skb,
::
int strp_process(struct strparser *strp, struct sk_buff *orig_skb,
unsigned int orig_offset, size_t orig_len,
size_t max_msg_size, long timeo)
......@@ -75,7 +91,9 @@ int strp_process(struct strparser *strp, struct sk_buff *orig_skb,
consume the sk_buff. max_msg_size is maximum size the stream
parser will parse. timeo is timeout for completing a message.
void strp_data_ready(struct strparser *strp);
::
void strp_data_ready(struct strparser *strp);
The upper layer calls strp_tcp_data_ready when data is ready on
the lower socket for strparser to process. This should be called
......@@ -83,7 +101,9 @@ void strp_data_ready(struct strparser *strp);
maximum messages size is the limit of the receive socket
buffer and message timeout is the receive timeout for the socket.
void strp_check_rcv(struct strparser *strp);
::
void strp_check_rcv(struct strparser *strp);
strp_check_rcv is called to check for new messages on the socket.
This is normally called at initialization of a stream parser
......@@ -94,7 +114,9 @@ Callbacks
There are six callbacks:
int (*parse_msg)(struct strparser *strp, struct sk_buff *skb);
::
int (*parse_msg)(struct strparser *strp, struct sk_buff *skb);
parse_msg is called to determine the length of the next message
in the stream. The upper layer must implement this function. It
......@@ -107,14 +129,16 @@ int (*parse_msg)(struct strparser *strp, struct sk_buff *skb);
The return values of this function are:
>0 : indicates length of successfully parsed message
0 : indicates more data must be received to parse the message
-ESTRPIPE : current message should not be processed by the
========= ===========================================================
>0 indicates length of successfully parsed message
0 indicates more data must be received to parse the message
-ESTRPIPE current message should not be processed by the
kernel, return control of the socket to userspace which
can proceed to read the messages itself
other < 0 : Error in parsing, give control back to userspace
other < 0 Error in parsing, give control back to userspace
assuming that synchronization is lost and the stream
is unrecoverable (application expected to close TCP socket)
========= ===========================================================
In the case that an error is returned (return value is less than
zero) and the parser is in receive callback mode, then it will set
......@@ -123,7 +147,9 @@ int (*parse_msg)(struct strparser *strp, struct sk_buff *skb);
the current message, then the error set on the attached socket is
ENODATA since the stream is unrecoverable in that case.
void (*lock)(struct strparser *strp)
::
void (*lock)(struct strparser *strp)
The lock callback is called to lock the strp structure when
the strparser is performing an asynchronous operation (such as
......@@ -131,14 +157,18 @@ void (*lock)(struct strparser *strp)
function is to lock_sock for the associated socket. In general
mode the callback must be set appropriately.
void (*unlock)(struct strparser *strp)
::
void (*unlock)(struct strparser *strp)
The unlock callback is called to release the lock obtained
by the lock callback. In receive callback mode the default
function is release_sock for the associated socket. In general
mode the callback must be set appropriately.
void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb);
::
void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb);
rcv_msg is called when a full message has been received and
is queued. The callee must consume the sk_buff; it can
......@@ -152,7 +182,9 @@ void (*rcv_msg)(struct strparser *strp, struct sk_buff *skb);
the length of the message. skb->len - offset may be greater
then full_len since strparser does not trim the skb.
int (*read_sock_done)(struct strparser *strp, int err);
::
int (*read_sock_done)(struct strparser *strp, int err);
read_sock_done is called when the stream parser is done reading
the TCP socket in receive callback mode. The stream parser may
......@@ -160,7 +192,9 @@ int (*read_sock_done)(struct strparser *strp, int err);
to occur when exiting the loop. If the callback is not set (NULL
in strp_init) a default function is used.
void (*abort_parser)(struct strparser *strp, int err);
::
void (*abort_parser)(struct strparser *strp, int err);
This function is called when stream parser encounters an error
in parsing. The default function stops the stream parser and
......@@ -204,4 +238,3 @@ Author
======
Tom Herbert (tom@quantonium.net)
Documentation/networking/tcp-thin.txt → Documentation/networking/tcp-thin.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
====================
Thin-streams and TCP
====================
A wide range of Internet-based services that use reliable transport
protocols display what we call thin-stream properties. This means
that the application sends data with such a low rate that the
......@@ -42,6 +46,7 @@ References
==========
More information on the modifications, as well as a wide range of
experimental data can be found here:
"Improving latency for interactive, thin-stream applications over
reliable transport"
http://simula.no/research/nd/publications/Simula.nd.477/simula_pdf_file
Documentation/networking/team.txt → Documentation/networking/team.rst
View file @ 07f81727
.. SPDX-License-Identifier: GPL-2.0
====
Team
====
Team devices are driven from userspace via libteam library which is here:
https://github.com/jpirko/libteam
MAINTAINERS
View file @ 07f81727
This diff is collapsed.
drivers/net/Kconfig
View file @ 07f81727
This diff is collapsed.
drivers/net/appletalk/Kconfig
View file @ 07f81727
This diff is collapsed.
drivers/net/ethernet/toshiba/spider_net.c
View file @ 07f81727
This diff is collapsed.
drivers/net/fddi/Kconfig
View file @ 07f81727
This diff is collapsed.
drivers/net/plip/Kconfig
View file @ 07f81727
This diff is collapsed.
drivers/net/wireless/Kconfig
View file @ 07f81727
This diff is collapsed.
drivers/staging/fsl-dpaa2/ethsw/README
View file @ 07f81727
This diff is collapsed.
include/linux/netdev_features.h
View file @ 07f81727
This diff is collapsed.
include/net/cfg80211.h
View file @ 07f81727
This diff is collapsed.
include/uapi/linux/errqueue.h
View file @ 07f81727
This diff is collapsed.
net/Kconfig
View file @ 07f81727
This diff is collapsed.
net/core/pktgen.c
View file @ 07f81727
This diff is collapsed.
net/lapb/Kconfig
View file @ 07f81727
This diff is collapsed.
net/mac80211/tx.c
View file @ 07f81727
This diff is collapsed.
net/netfilter/Kconfig
View file @ 07f81727
This diff is collapsed.
net/rxrpc/Kconfig
View file @ 07f81727
This diff is collapsed.
net/rxrpc/sysctl.c
View file @ 07f81727
This diff is collapsed.
net/wireless/radiotap.c
View file @ 07f81727
This diff is collapsed.
samples/pktgen/README.rst
View file @ 07f81727
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7