Merge branch 'net-ReST-convert'
Mauro Carvalho Chehab says: ==================== net: manually convert files to ReST format - part 1 There are very few documents upstream that aren't converted upstream. This series convert part of the networking text files into ReST. It is part of a bigger set of patches, which were split on parts, in order to make reviewing task easier. The full series (including those ones) are at: https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs And the documents, converted to HTML via the building system are at: https://www.infradead.org/~mchehab/kernel_docs/networking/ ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
commit
c76c223016
|
@ -356,7 +356,7 @@
|
|||
shot down by NMI
|
||||
|
||||
autoconf= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
See Documentation/networking/ipv6.rst.
|
||||
|
||||
show_lapic= [APIC,X86] Advanced Programmable Interrupt Controller
|
||||
Limit apic dumping. The parameter defines the maximal
|
||||
|
@ -831,7 +831,7 @@
|
|||
|
||||
decnet.addr= [HW,NET]
|
||||
Format: <area>[,<node>]
|
||||
See also Documentation/networking/decnet.txt.
|
||||
See also Documentation/networking/decnet.rst.
|
||||
|
||||
default_hugepagesz=
|
||||
[same as hugepagesz=] The size of the default
|
||||
|
@ -872,7 +872,7 @@
|
|||
miss to occur.
|
||||
|
||||
disable= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
See Documentation/networking/ipv6.rst.
|
||||
|
||||
hardened_usercopy=
|
||||
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
|
||||
|
@ -912,7 +912,7 @@
|
|||
to workaround buggy firmware.
|
||||
|
||||
disable_ipv6= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
See Documentation/networking/ipv6.rst.
|
||||
|
||||
disable_mtrr_cleanup [X86]
|
||||
The kernel tries to adjust MTRR layout from continuous
|
||||
|
@ -4910,7 +4910,7 @@
|
|||
Set the number of tcp_metrics_hash slots.
|
||||
Default value is 8192 or 16384 depending on total
|
||||
ram pages. This is used to specify the TCP metrics
|
||||
cache size. See Documentation/networking/ip-sysctl.txt
|
||||
cache size. See Documentation/networking/ip-sysctl.rst
|
||||
"tcp_no_metrics_save" section for more details.
|
||||
|
||||
tdfx= [HW,DRM]
|
||||
|
|
|
@ -353,8 +353,8 @@ socket's buffer. It will not take effect unless PF_UNIX flag is specified.
|
|||
|
||||
3. /proc/sys/net/ipv4 - IPV4 settings
|
||||
-------------------------------------
|
||||
Please see: Documentation/networking/ip-sysctl.txt and ipvs-sysctl.txt for
|
||||
descriptions of these entries.
|
||||
Please see: Documentation/networking/ip-sysctl.rst and
|
||||
Documentation/admin-guide/sysctl/net.rst for descriptions of these entries.
|
||||
|
||||
|
||||
4. Appletalk
|
||||
|
|
|
@ -7,7 +7,7 @@ Filter) facility, with a focus on the extended BPF version (eBPF).
|
|||
|
||||
This kernel side documentation is still work in progress. The main
|
||||
textual documentation is (for historical reasons) described in
|
||||
`Documentation/networking/filter.txt`_, which describe both classical
|
||||
`Documentation/networking/filter.rst`_, which describe both classical
|
||||
and extended BPF instruction-set.
|
||||
The Cilium project also maintains a `BPF and XDP Reference Guide`_
|
||||
that goes into great technical depth about the BPF Architecture.
|
||||
|
@ -59,7 +59,7 @@ Testing and debugging BPF
|
|||
|
||||
|
||||
.. Links:
|
||||
.. _Documentation/networking/filter.txt: ../networking/filter.txt
|
||||
.. _Documentation/networking/filter.rst: ../networking/filter.txt
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
.. _BPF and XDP Reference Guide: http://cilium.readthedocs.io/en/latest/bpf/
|
||||
|
|
|
@ -1,27 +1,36 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==============
|
||||
6pack Protocol
|
||||
==============
|
||||
|
||||
This is the 6pack-mini-HOWTO, written by
|
||||
|
||||
Andreas Könsgen DG3KQ
|
||||
Internet: ajk@comnets.uni-bremen.de
|
||||
AMPR-net: dg3kq@db0pra.ampr.org
|
||||
AX.25: dg3kq@db0ach.#nrw.deu.eu
|
||||
|
||||
:Internet: ajk@comnets.uni-bremen.de
|
||||
:AMPR-net: dg3kq@db0pra.ampr.org
|
||||
:AX.25: dg3kq@db0ach.#nrw.deu.eu
|
||||
|
||||
Last update: April 7, 1998
|
||||
|
||||
1. What is 6pack, and what are the advantages to KISS?
|
||||
======================================================
|
||||
|
||||
6pack is a transmission protocol for data exchange between the PC and
|
||||
the TNC over a serial line. It can be used as an alternative to KISS.
|
||||
|
||||
6pack has two major advantages:
|
||||
|
||||
- The PC is given full control over the radio
|
||||
channel. Special control data is exchanged between the PC and the TNC so
|
||||
that the PC knows at any time if the TNC is receiving data, if a TNC
|
||||
buffer underrun or overrun has occurred, if the PTT is
|
||||
set and so on. This control data is processed at a higher priority than
|
||||
normal data, so a data stream can be interrupted at any time to issue an
|
||||
important event. This helps to improve the channel access and timing
|
||||
algorithms as everything is computed in the PC. It would even be possible
|
||||
to experiment with something completely different from the known CSMA and
|
||||
important event. This helps to improve the channel access and timing
|
||||
algorithms as everything is computed in the PC. It would even be possible
|
||||
to experiment with something completely different from the known CSMA and
|
||||
DAMA channel access methods.
|
||||
This kind of real-time control is especially important to supply several
|
||||
TNCs that are connected between each other and the PC by a daisy chain
|
||||
|
@ -36,6 +45,7 @@ More details about 6pack are described in the file 6pack.ps that is located
|
|||
in the doc directory of the AX.25 utilities package.
|
||||
|
||||
2. Who has developed the 6pack protocol?
|
||||
========================================
|
||||
|
||||
The 6pack protocol has been developed by Ekki Plicht DF4OR, Henning Rech
|
||||
DF9IC and Gunter Jost DK7WJ. A driver for 6pack, written by Gunter Jost and
|
||||
|
@ -44,12 +54,14 @@ They have also written a firmware for TNCs to perform the 6pack
|
|||
protocol (see section 4 below).
|
||||
|
||||
3. Where can I get the latest version of 6pack for LinuX?
|
||||
=========================================================
|
||||
|
||||
At the moment, the 6pack stuff can obtained via anonymous ftp from
|
||||
db0bm.automation.fh-aachen.de. In the directory /incoming/dg3kq,
|
||||
there is a file named 6pack.tgz.
|
||||
|
||||
4. Preparing the TNC for 6pack operation
|
||||
========================================
|
||||
|
||||
To be able to use 6pack, a special firmware for the TNC is needed. The EPROM
|
||||
of a newly bought TNC does not contain 6pack, so you will have to
|
||||
|
@ -75,12 +87,14 @@ and the status LED are lit for about a second if the firmware initialises
|
|||
the TNC correctly.
|
||||
|
||||
5. Building and installing the 6pack driver
|
||||
===========================================
|
||||
|
||||
The driver has been tested with kernel version 2.1.90. Use with older
|
||||
kernels may lead to a compilation error because the interface to a kernel
|
||||
function has been changed in the 2.1.8x kernels.
|
||||
|
||||
How to turn on 6pack support:
|
||||
=============================
|
||||
|
||||
- In the linux kernel configuration program, select the code maturity level
|
||||
options menu and turn on the prompting for development drivers.
|
||||
|
@ -94,27 +108,28 @@ To use the driver, the kissattach program delivered with the AX.25 utilities
|
|||
has to be modified.
|
||||
|
||||
- Do a cd to the directory that holds the kissattach sources. Edit the
|
||||
kissattach.c file. At the top, insert the following lines:
|
||||
kissattach.c file. At the top, insert the following lines::
|
||||
|
||||
#ifndef N_6PACK
|
||||
#define N_6PACK (N_AX25+1)
|
||||
#endif
|
||||
#ifndef N_6PACK
|
||||
#define N_6PACK (N_AX25+1)
|
||||
#endif
|
||||
|
||||
Then find the line
|
||||
|
||||
int disc = N_AX25;
|
||||
Then find the line:
|
||||
|
||||
int disc = N_AX25;
|
||||
|
||||
and replace N_AX25 by N_6PACK.
|
||||
|
||||
- Recompile kissattach. Rename it to spattach to avoid confusions.
|
||||
|
||||
Installing the driver:
|
||||
----------------------
|
||||
|
||||
- Do an insmod 6pack. Look at your /var/log/messages file to check if the
|
||||
- Do an insmod 6pack. Look at your /var/log/messages file to check if the
|
||||
module has printed its initialization message.
|
||||
|
||||
- Do a spattach as you would launch kissattach when starting a KISS port.
|
||||
Check if the kernel prints the message '6pack: TNC found'.
|
||||
Check if the kernel prints the message '6pack: TNC found'.
|
||||
|
||||
- From here, everything should work as if you were setting up a KISS port.
|
||||
The only difference is that the network device that represents
|
||||
|
@ -138,6 +153,7 @@ from the PC to the TNC over the serial line, the status LED if data is
|
|||
sent to the PC.
|
||||
|
||||
6. Known problems
|
||||
=================
|
||||
|
||||
When testing the driver with 2.0.3x kernels and
|
||||
operating with data rates on the radio channel of 9600 Baud or higher,
|
|
@ -1,6 +1,12 @@
|
|||
Altera Triple-Speed Ethernet MAC driver
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Copyright (C) 2008-2014 Altera Corporation
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
=======================================
|
||||
Altera Triple-Speed Ethernet MAC driver
|
||||
=======================================
|
||||
|
||||
Copyright |copy| 2008-2014 Altera Corporation
|
||||
|
||||
This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers
|
||||
using the SGDMA and MSGDMA soft DMA IP components. The driver uses the
|
||||
|
@ -46,23 +52,33 @@ Jumbo frames are not supported at this time.
|
|||
The driver limits PHY operations to 10/100Mbps, and has not yet been fully
|
||||
tested for 1Gbps. This support will be added in a future maintenance update.
|
||||
|
||||
1) Kernel Configuration
|
||||
1. Kernel Configuration
|
||||
=======================
|
||||
|
||||
The kernel configuration option is ALTERA_TSE:
|
||||
|
||||
Device Drivers ---> Network device support ---> Ethernet driver support --->
|
||||
Altera Triple-Speed Ethernet MAC support (ALTERA_TSE)
|
||||
|
||||
2) Driver parameters list:
|
||||
debug: message level (0: no output, 16: all);
|
||||
dma_rx_num: Number of descriptors in the RX list (default is 64);
|
||||
dma_tx_num: Number of descriptors in the TX list (default is 64).
|
||||
2. Driver parameters list
|
||||
=========================
|
||||
|
||||
- debug: message level (0: no output, 16: all);
|
||||
- dma_rx_num: Number of descriptors in the RX list (default is 64);
|
||||
- dma_tx_num: Number of descriptors in the TX list (default is 64).
|
||||
|
||||
3. Command line options
|
||||
=======================
|
||||
|
||||
Driver parameters can be also passed in command line by using::
|
||||
|
||||
3) Command line options
|
||||
Driver parameters can be also passed in command line by using:
|
||||
altera_tse=dma_rx_num:128,dma_tx_num:512
|
||||
|
||||
4) Driver information and notes
|
||||
4. Driver information and notes
|
||||
===============================
|
||||
|
||||
4.1) Transmit process
|
||||
4.1. Transmit process
|
||||
---------------------
|
||||
When the driver's transmit routine is called by the kernel, it sets up a
|
||||
transmit descriptor by calling the underlying DMA transmit routine (SGDMA or
|
||||
MSGDMA), and initiates a transmit operation. Once the transmit is complete, an
|
||||
|
@ -70,7 +86,8 @@ interrupt is driven by the transmit DMA logic. The driver handles the transmit
|
|||
completion in the context of the interrupt handling chain by recycling
|
||||
resource required to send and track the requested transmit operation.
|
||||
|
||||
4.2) Receive process
|
||||
4.2. Receive process
|
||||
--------------------
|
||||
The driver will post receive buffers to the receive DMA logic during driver
|
||||
initialization. Receive buffers may or may not be queued depending upon the
|
||||
underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able
|
||||
|
@ -79,34 +96,39 @@ received, the DMA logic generates an interrupt. The driver handles a receive
|
|||
interrupt by obtaining the DMA receive logic status, reaping receive
|
||||
completions until no more receive completions are available.
|
||||
|
||||
4.3) Interrupt Mitigation
|
||||
4.3. Interrupt Mitigation
|
||||
-------------------------
|
||||
The driver is able to mitigate the number of its DMA interrupts
|
||||
using NAPI for receive operations. Interrupt mitigation is not yet supported
|
||||
for transmit operations, but will be added in a future maintenance release.
|
||||
|
||||
4.4) Ethtool support
|
||||
--------------------
|
||||
Ethtool is supported. Driver statistics and internal errors can be taken using:
|
||||
ethtool -S ethX command. It is possible to dump registers etc.
|
||||
|
||||
4.5) PHY Support
|
||||
----------------
|
||||
The driver is compatible with PAL to work with PHY and GPHY devices.
|
||||
|
||||
4.7) List of source files:
|
||||
o Kconfig
|
||||
o Makefile
|
||||
o altera_tse_main.c: main network device driver
|
||||
o altera_tse_ethtool.c: ethtool support
|
||||
o altera_tse.h: private driver structure and common definitions
|
||||
o altera_msgdma.h: MSGDMA implementation function definitions
|
||||
o altera_sgdma.h: SGDMA implementation function definitions
|
||||
o altera_msgdma.c: MSGDMA implementation
|
||||
o altera_sgdma.c: SGDMA implementation
|
||||
o altera_sgdmahw.h: SGDMA register and descriptor definitions
|
||||
o altera_msgdmahw.h: MSGDMA register and descriptor definitions
|
||||
o altera_utils.c: Driver utility functions
|
||||
o altera_utils.h: Driver utility function definitions
|
||||
--------------------------
|
||||
- Kconfig
|
||||
- Makefile
|
||||
- altera_tse_main.c: main network device driver
|
||||
- altera_tse_ethtool.c: ethtool support
|
||||
- altera_tse.h: private driver structure and common definitions
|
||||
- altera_msgdma.h: MSGDMA implementation function definitions
|
||||
- altera_sgdma.h: SGDMA implementation function definitions
|
||||
- altera_msgdma.c: MSGDMA implementation
|
||||
- altera_sgdma.c: SGDMA implementation
|
||||
- altera_sgdmahw.h: SGDMA register and descriptor definitions
|
||||
- altera_msgdmahw.h: MSGDMA register and descriptor definitions
|
||||
- altera_utils.c: Driver utility functions
|
||||
- altera_utils.h: Driver utility function definitions
|
||||
|
||||
5) Debug Information
|
||||
5. Debug Information
|
||||
====================
|
||||
|
||||
The driver exports debug information such as internal statistics,
|
||||
debug information, MAC and DMA registers etc.
|
||||
|
@ -118,17 +140,18 @@ or sees the MAC registers: e.g. using: ethtool -d ethX
|
|||
The developer can also use the "debug" module parameter to get
|
||||
further debug information.
|
||||
|
||||
6) Statistics Support
|
||||
6. Statistics Support
|
||||
=====================
|
||||
|
||||
The controller and driver support a mix of IEEE standard defined statistics,
|
||||
RFC defined statistics, and driver or Altera defined statistics. The four
|
||||
specifications containing the standard definitions for these statistics are
|
||||
as follows:
|
||||
|
||||
o IEEE 802.3-2012 - IEEE Standard for Ethernet.
|
||||
o RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt.
|
||||
o RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt.
|
||||
o Altera Triple Speed Ethernet User Guide, found at http://www.altera.com
|
||||
- IEEE 802.3-2012 - IEEE Standard for Ethernet.
|
||||
- RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt.
|
||||
- RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt.
|
||||
- Altera Triple Speed Ethernet User Guide, found at http://www.altera.com
|
||||
|
||||
The statistics supported by the TSE and the device driver are as follows:
|
||||
|
File diff suppressed because it is too large
Load diff
|
@ -1,11 +1,18 @@
|
|||
----------------------------------------------------------------------------
|
||||
NOTE: See also arcnet-hardware.txt in this directory for jumper-setting
|
||||
and cabling information if you're like many of us and didn't happen to get a
|
||||
manual with your ARCnet card.
|
||||
----------------------------------------------------------------------------
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======
|
||||
ARCnet
|
||||
======
|
||||
|
||||
.. note::
|
||||
|
||||
See also arcnet-hardware.txt in this directory for jumper-setting
|
||||
and cabling information if you're like many of us and didn't happen to get a
|
||||
manual with your ARCnet card.
|
||||
|
||||
Since no one seems to listen to me otherwise, perhaps a poem will get your
|
||||
attention:
|
||||
attention::
|
||||
|
||||
This driver's getting fat and beefy,
|
||||
But my cat is still named Fifi.
|
||||
|
||||
|
@ -24,28 +31,21 @@ Come on, be a sport! Send me a success report!
|
|||
(hey, that was even better than my original poem... this is getting bad!)
|
||||
|
||||
|
||||
--------
|
||||
WARNING:
|
||||
--------
|
||||
.. warning::
|
||||
|
||||
If you don't e-mail me about your success/failure soon, I may be forced to
|
||||
start SINGING. And we don't want that, do we?
|
||||
If you don't e-mail me about your success/failure soon, I may be forced to
|
||||
start SINGING. And we don't want that, do we?
|
||||
|
||||
(You know, it might be argued that I'm pushing this point a little too much.
|
||||
If you think so, why not flame me in a quick little e-mail? Please also
|
||||
include the type of card(s) you're using, software, size of network, and
|
||||
whether it's working or not.)
|
||||
(You know, it might be argued that I'm pushing this point a little too much.
|
||||
If you think so, why not flame me in a quick little e-mail? Please also
|
||||
include the type of card(s) you're using, software, size of network, and
|
||||
whether it's working or not.)
|
||||
|
||||
My e-mail address is: apenwarr@worldvisions.ca
|
||||
My e-mail address is: apenwarr@worldvisions.ca
|
||||
|
||||
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
|
||||
These are the ARCnet drivers for Linux.
|
||||
|
||||
|
||||
This new release (2.91) has been put together by David Woodhouse
|
||||
This new release (2.91) has been put together by David Woodhouse
|
||||
<dwmw2@infradead.org>, in an attempt to tidy up the driver after adding support
|
||||
for yet another chipset. Now the generic support has been separated from the
|
||||
individual chipset drivers, and the source files aren't quite so packed with
|
||||
|
@ -62,12 +62,13 @@ included and seems to be working fine!
|
|||
Where do I discuss these drivers?
|
||||
---------------------------------
|
||||
|
||||
Tomasz has been so kind as to set up a new and improved mailing list.
|
||||
Tomasz has been so kind as to set up a new and improved mailing list.
|
||||
Subscribe by sending a message with the BODY "subscribe linux-arcnet YOUR
|
||||
REAL NAME" to listserv@tichy.ch.uj.edu.pl. Then, to submit messages to the
|
||||
list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
|
||||
|
||||
There are archives of the mailing list at:
|
||||
|
||||
http://epistolary.org/mailman/listinfo.cgi/arcnet
|
||||
|
||||
The people on linux-net@vger.kernel.org (now defunct, replaced by
|
||||
|
@ -80,17 +81,20 @@ Other Drivers and Info
|
|||
----------------------
|
||||
|
||||
You can try my ARCNET page on the World Wide Web at:
|
||||
http://www.qis.net/~jschmitz/arcnet/
|
||||
|
||||
http://www.qis.net/~jschmitz/arcnet/
|
||||
|
||||
Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you
|
||||
might be interested in, which includes several drivers for various cards
|
||||
including ARCnet. Try:
|
||||
|
||||
http://www.smc.com/
|
||||
|
||||
|
||||
Performance Technologies makes various network software that supports
|
||||
ARCnet:
|
||||
|
||||
http://www.perftech.com/ or ftp to ftp.perftech.com.
|
||||
|
||||
|
||||
Novell makes a networking stack for DOS which includes ARCnet drivers. Try
|
||||
FTPing to ftp.novell.com.
|
||||
|
||||
|
@ -99,19 +103,20 @@ one you'll want to use with ARCnet cards) from
|
|||
oak.oakland.edu:/simtel/msdos/pktdrvr. It won't work perfectly on a 386+
|
||||
without patches, though, and also doesn't like several cards. Fixed
|
||||
versions are available on my WWW page, or via e-mail if you don't have WWW
|
||||
access.
|
||||
access.
|
||||
|
||||
|
||||
Installing the Driver
|
||||
---------------------
|
||||
|
||||
All you will need to do in order to install the driver is:
|
||||
All you will need to do in order to install the driver is::
|
||||
|
||||
make config
|
||||
(be sure to choose ARCnet in the network devices
|
||||
(be sure to choose ARCnet in the network devices
|
||||
and at least one chipset driver.)
|
||||
make clean
|
||||
make zImage
|
||||
|
||||
|
||||
If you obtained this ARCnet package as an upgrade to the ARCnet driver in
|
||||
your current kernel, you will need to first copy arcnet.c over the one in
|
||||
the linux/drivers/net directory.
|
||||
|
@ -125,10 +130,12 @@ There are four chipset options:
|
|||
|
||||
This is the normal ARCnet card, which you've probably got. This is the only
|
||||
chipset driver which will autoprobe if not told where the card is.
|
||||
It following options on the command line:
|
||||
It following options on the command line::
|
||||
|
||||
com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
|
||||
|
||||
If you load the chipset support as a module, the options are:
|
||||
If you load the chipset support as a module, the options are::
|
||||
|
||||
io=<io> irq=<irq> shmem=<shmem> device=<name>
|
||||
|
||||
To disable the autoprobe, just specify "com90xx=" on the kernel command line.
|
||||
|
@ -136,14 +143,17 @@ To specify the name alone, but allow autoprobe, just put "com90xx=<name>"
|
|||
|
||||
2. ARCnet COM20020 chipset.
|
||||
|
||||
This is the new chipset from SMC with support for promiscuous mode (packet
|
||||
This is the new chipset from SMC with support for promiscuous mode (packet
|
||||
sniffing), extra diagnostic information, etc. Unfortunately, there is no
|
||||
sensible method of autoprobing for these cards. You must specify the I/O
|
||||
address on the kernel command line.
|
||||
The command line options are:
|
||||
|
||||
The command line options are::
|
||||
|
||||
com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
|
||||
|
||||
If you load the chipset support as a module, the options are:
|
||||
If you load the chipset support as a module, the options are::
|
||||
|
||||
io=<io> irq=<irq> node=<node_ID> backplane=<backplane> clock=<CKP>
|
||||
timeout=<timeout> device=<name>
|
||||
|
||||
|
@ -160,8 +170,10 @@ you have a card which doesn't support shared memory, or (strangely) in case
|
|||
you have so many ARCnet cards in your machine that you run out of shmem slots.
|
||||
If you don't give the IO address on the kernel command line, then the driver
|
||||
will not find the card.
|
||||
The command line options are:
|
||||
com90io=<io>[,<irq>][,<name>]
|
||||
|
||||
The command line options are::
|
||||
|
||||
com90io=<io>[,<irq>][,<name>]
|
||||
|
||||
If you load the chipset support as a module, the options are:
|
||||
io=<io> irq=<irq> device=<name>
|
||||
|
@ -169,44 +181,49 @@ If you load the chipset support as a module, the options are:
|
|||
4. ARCnet RIM I cards.
|
||||
|
||||
These are COM90xx chips which are _completely_ memory mapped. The support for
|
||||
these is not tested. If you have one, please mail the author with a success
|
||||
these is not tested. If you have one, please mail the author with a success
|
||||
report. All options must be specified, except the device name.
|
||||
Command line options:
|
||||
Command line options::
|
||||
|
||||
arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
|
||||
|
||||
If you load the chipset support as a module, the options are:
|
||||
If you load the chipset support as a module, the options are::
|
||||
|
||||
shmem=<shmem> irq=<irq> node=<node_ID> device=<name>
|
||||
|
||||
|
||||
Loadable Module Support
|
||||
-----------------------
|
||||
|
||||
Configure and rebuild Linux. When asked, answer 'm' to "Generic ARCnet
|
||||
Configure and rebuild Linux. When asked, answer 'm' to "Generic ARCnet
|
||||
support" and to support for your ARCnet chipset if you want to use the
|
||||
loadable module. You can also say 'y' to "Generic ARCnet support" and 'm'
|
||||
loadable module. You can also say 'y' to "Generic ARCnet support" and 'm'
|
||||
to the chipset support if you wish.
|
||||
|
||||
::
|
||||
|
||||
make config
|
||||
make clean
|
||||
make clean
|
||||
make zImage
|
||||
make modules
|
||||
|
||||
|
||||
If you're using a loadable module, you need to use insmod to load it, and
|
||||
you can specify various characteristics of your card on the command
|
||||
line. (In recent versions of the driver, autoprobing is much more reliable
|
||||
and works as a module, so most of this is now unnecessary.)
|
||||
|
||||
For example:
|
||||
For example::
|
||||
|
||||
cd /usr/src/linux/modules
|
||||
insmod arcnet.o
|
||||
insmod com90xx.o
|
||||
insmod com20020.o io=0x2e0 device=eth1
|
||||
|
||||
|
||||
|
||||
Using the Driver
|
||||
----------------
|
||||
|
||||
If you build your kernel with ARCnet COM90xx support included, it should
|
||||
If you build your kernel with ARCnet COM90xx support included, it should
|
||||
probe for your card automatically when you boot. If you use a different
|
||||
chipset driver complied into the kernel, you must give the necessary options
|
||||
on the kernel command line, as detailed above.
|
||||
|
@ -224,69 +241,78 @@ Multiple Cards in One Computer
|
|||
------------------------------
|
||||
|
||||
Linux has pretty good support for this now, but since I've been busy, the
|
||||
ARCnet driver has somewhat suffered in this respect. COM90xx support, if
|
||||
compiled into the kernel, will (try to) autodetect all the installed cards.
|
||||
ARCnet driver has somewhat suffered in this respect. COM90xx support, if
|
||||
compiled into the kernel, will (try to) autodetect all the installed cards.
|
||||
|
||||
If you have other cards, with support compiled into the kernel, then you can
|
||||
just repeat the options on the kernel command line, e.g.:
|
||||
LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
|
||||
If you have other cards, with support compiled into the kernel, then you can
|
||||
just repeat the options on the kernel command line, e.g.::
|
||||
|
||||
LILO: linux com20020=0x2e0 com20020=0x380 com90io=0x260
|
||||
|
||||
If you have the chipset support built as a loadable module, then you need to
|
||||
do something like this::
|
||||
|
||||
If you have the chipset support built as a loadable module, then you need to
|
||||
do something like this:
|
||||
insmod -o arc0 com90xx
|
||||
insmod -o arc1 com20020 io=0x2e0
|
||||
insmod -o arc2 com90xx
|
||||
|
||||
The ARCnet drivers will now sort out their names automatically.
|
||||
|
||||
|
||||
How do I get it to work with...?
|
||||
--------------------------------
|
||||
|
||||
NFS: Should be fine linux->linux, just pretend you're using Ethernet cards.
|
||||
oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients. There
|
||||
is also a DOS-based NFS server called SOSS. It doesn't multitask
|
||||
quite the way Linux does (actually, it doesn't multitask AT ALL) but
|
||||
you never know what you might need.
|
||||
|
||||
With AmiTCP (and possibly others), you may need to set the following
|
||||
options in your Amiga nfstab: MD 1024 MR 1024 MW 1024
|
||||
(Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>
|
||||
NFS:
|
||||
Should be fine linux->linux, just pretend you're using Ethernet cards.
|
||||
oak.oakland.edu:/simtel/msdos/nfs has some nice DOS clients. There
|
||||
is also a DOS-based NFS server called SOSS. It doesn't multitask
|
||||
quite the way Linux does (actually, it doesn't multitask AT ALL) but
|
||||
you never know what you might need.
|
||||
|
||||
With AmiTCP (and possibly others), you may need to set the following
|
||||
options in your Amiga nfstab: MD 1024 MR 1024 MW 1024
|
||||
(Thanks to Christian Gottschling <ferksy@indigo.tng.oche.de>
|
||||
for this.)
|
||||
|
||||
|
||||
Probably these refer to maximum NFS data/read/write block sizes. I
|
||||
don't know why the defaults on the Amiga didn't work; write to me if
|
||||
you know more.
|
||||
|
||||
DOS: If you're using the freeware arcether.com, you might want to install
|
||||
the driver patch from my web page. It helps with PC/TCP, and also
|
||||
can get arcether to load if it timed out too quickly during
|
||||
initialization. In fact, if you use it on a 386+ you REALLY need
|
||||
the patch, really.
|
||||
|
||||
Windows: See DOS :) Trumpet Winsock works fine with either the Novell or
|
||||
DOS:
|
||||
If you're using the freeware arcether.com, you might want to install
|
||||
the driver patch from my web page. It helps with PC/TCP, and also
|
||||
can get arcether to load if it timed out too quickly during
|
||||
initialization. In fact, if you use it on a 386+ you REALLY need
|
||||
the patch, really.
|
||||
|
||||
Windows:
|
||||
See DOS :) Trumpet Winsock works fine with either the Novell or
|
||||
Arcether client, assuming you remember to load winpkt of course.
|
||||
|
||||
LAN Manager and Windows for Workgroups: These programs use protocols that
|
||||
are incompatible with the Internet standard. They try to pretend
|
||||
the cards are Ethernet, and confuse everyone else on the network.
|
||||
|
||||
However, v2.00 and higher of the Linux ARCnet driver supports this
|
||||
protocol via the 'arc0e' device. See the section on "Multiprotocol
|
||||
Support" for more information.
|
||||
LAN Manager and Windows for Workgroups:
|
||||
These programs use protocols that
|
||||
are incompatible with the Internet standard. They try to pretend
|
||||
the cards are Ethernet, and confuse everyone else on the network.
|
||||
|
||||
However, v2.00 and higher of the Linux ARCnet driver supports this
|
||||
protocol via the 'arc0e' device. See the section on "Multiprotocol
|
||||
Support" for more information.
|
||||
|
||||
Using the freeware Samba server and clients for Linux, you can now
|
||||
interface quite nicely with TCP/IP-based WfWg or Lan Manager
|
||||
networks.
|
||||
|
||||
Windows 95: Tools are included with Win95 that let you use either the LANMAN
|
||||
|
||||
Windows 95:
|
||||
Tools are included with Win95 that let you use either the LANMAN
|
||||
style network drivers (NDIS) or Novell drivers (ODI) to handle your
|
||||
ARCnet packets. If you use ODI, you'll need to use the 'arc0'
|
||||
device with Linux. If you use NDIS, then try the 'arc0e' device.
|
||||
device with Linux. If you use NDIS, then try the 'arc0e' device.
|
||||
See the "Multiprotocol Support" section below if you need arc0e,
|
||||
you're completely insane, and/or you need to build some kind of
|
||||
hybrid network that uses both encapsulation types.
|
||||
|
||||
OS/2: I've been told it works under Warp Connect with an ARCnet driver from
|
||||
OS/2:
|
||||
I've been told it works under Warp Connect with an ARCnet driver from
|
||||
SMC. You need to use the 'arc0e' interface for this. If you get
|
||||
the SMC driver to work with the TCP/IP stuff included in the
|
||||
"normal" Warp Bonus Pack, let me know.
|
||||
|
@ -295,7 +321,8 @@ OS/2: I've been told it works under Warp Connect with an ARCnet driver from
|
|||
which should use the same protocol as WfWg does. I had no luck
|
||||
installing it under Warp, however. Please mail me with any results.
|
||||
|
||||
NetBSD/AmiTCP: These use an old version of the Internet standard ARCnet
|
||||
NetBSD/AmiTCP:
|
||||
These use an old version of the Internet standard ARCnet
|
||||
protocol (RFC1051) which is compatible with the Linux driver v2.10
|
||||
ALPHA and above using the arc0s device. (See "Multiprotocol ARCnet"
|
||||
below.) ** Newer versions of NetBSD apparently support RFC1201.
|
||||
|
@ -307,16 +334,17 @@ Using Multiprotocol ARCnet
|
|||
The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
|
||||
"virtual network device":
|
||||
|
||||
arc0 - RFC1201 protocol, the official Internet standard which just
|
||||
happens to be 100% compatible with Novell's TRXNET driver.
|
||||
====== ===============================================================
|
||||
arc0 RFC1201 protocol, the official Internet standard which just
|
||||
happens to be 100% compatible with Novell's TRXNET driver.
|
||||
Version 1.00 of the ARCnet driver supported _only_ this
|
||||
protocol. arc0 is the fastest of the three protocols (for
|
||||
whatever reason), and allows larger packets to be used
|
||||
because it supports RFC1201 "packet splitting" operations.
|
||||
because it supports RFC1201 "packet splitting" operations.
|
||||
Unless you have a specific need to use a different protocol,
|
||||
I strongly suggest that you stick with this one.
|
||||
|
||||
arc0e - "Ethernet-Encapsulation" which sends packets over ARCnet
|
||||
|
||||
arc0e "Ethernet-Encapsulation" which sends packets over ARCnet
|
||||
that are actually a lot like Ethernet packets, including the
|
||||
6-byte hardware addresses. This protocol is compatible with
|
||||
Microsoft's NDIS ARCnet driver, like the one in WfWg and
|
||||
|
@ -328,8 +356,8 @@ The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
|
|||
fit. arc0e also works slightly more slowly than arc0, for
|
||||
reasons yet to be determined. (Probably it's the smaller
|
||||
MTU that does it.)
|
||||
|
||||
arc0s - The "[s]imple" RFC1051 protocol is the "previous" Internet
|
||||
|
||||
arc0s The "[s]imple" RFC1051 protocol is the "previous" Internet
|
||||
standard that is completely incompatible with the new
|
||||
standard. Some software today, however, continues to
|
||||
support the old standard (and only the old standard)
|
||||
|
@ -338,9 +366,10 @@ The ARCnet driver v2.10 ALPHA supports three protocols, each on its own
|
|||
smaller than the Internet "requirement," so it's quite
|
||||
possible that you may run into problems. It's also slower
|
||||
than RFC1201 by about 25%, for the same reason as arc0e.
|
||||
|
||||
|
||||
The arc0s support was contributed by Tomasz Motylewski
|
||||
and modified somewhat by me. Bugs are probably my fault.
|
||||
====== ===============================================================
|
||||
|
||||
You can choose not to compile arc0e and arc0s into the driver if you want -
|
||||
this will save you a bit of memory and avoid confusion when eg. trying to
|
||||
|
@ -358,19 +387,21 @@ can set up your network then:
|
|||
two available protocols. As mentioned above, it's a good idea to use
|
||||
only arc0 unless you have a good reason (like some other software, ie.
|
||||
WfWg, that only works with arc0e).
|
||||
|
||||
If you need only arc0, then the following commands should get you going:
|
||||
ifconfig arc0 MY.IP.ADD.RESS
|
||||
route add MY.IP.ADD.RESS arc0
|
||||
route add -net SUB.NET.ADD.RESS arc0
|
||||
[add other local routes here]
|
||||
|
||||
If you need arc0e (and only arc0e), it's a little different:
|
||||
ifconfig arc0 MY.IP.ADD.RESS
|
||||
ifconfig arc0e MY.IP.ADD.RESS
|
||||
route add MY.IP.ADD.RESS arc0e
|
||||
route add -net SUB.NET.ADD.RESS arc0e
|
||||
|
||||
|
||||
If you need only arc0, then the following commands should get you going::
|
||||
|
||||
ifconfig arc0 MY.IP.ADD.RESS
|
||||
route add MY.IP.ADD.RESS arc0
|
||||
route add -net SUB.NET.ADD.RESS arc0
|
||||
[add other local routes here]
|
||||
|
||||
If you need arc0e (and only arc0e), it's a little different::
|
||||
|
||||
ifconfig arc0 MY.IP.ADD.RESS
|
||||
ifconfig arc0e MY.IP.ADD.RESS
|
||||
route add MY.IP.ADD.RESS arc0e
|
||||
route add -net SUB.NET.ADD.RESS arc0e
|
||||
|
||||
arc0s works much the same way as arc0e.
|
||||
|
||||
|
||||
|
@ -391,29 +422,32 @@ can set up your network then:
|
|||
XT (patience), however, does not have its own Internet IP address and so
|
||||
I assigned it one on a "private subnet" (as defined by RFC1597).
|
||||
|
||||
To start with, take a simple network with just insight and freedom.
|
||||
To start with, take a simple network with just insight and freedom.
|
||||
Insight needs to:
|
||||
- talk to freedom via RFC1201 (arc0) protocol, because I like it
|
||||
|
||||
- talk to freedom via RFC1201 (arc0) protocol, because I like it
|
||||
more and it's faster.
|
||||
- use freedom as its Internet gateway.
|
||||
|
||||
That's pretty easy to do. Set up insight like this:
|
||||
ifconfig arc0 insight
|
||||
route add insight arc0
|
||||
route add freedom arc0 /* I would use the subnet here (like I said
|
||||
|
||||
That's pretty easy to do. Set up insight like this::
|
||||
|
||||
ifconfig arc0 insight
|
||||
route add insight arc0
|
||||
route add freedom arc0 /* I would use the subnet here (like I said
|
||||
to to in "single protocol" above),
|
||||
but the rest of the subnet
|
||||
unfortunately lies across the PPP
|
||||
link on freedom, which confuses
|
||||
things. */
|
||||
route add default gw freedom
|
||||
|
||||
And freedom gets configured like so:
|
||||
ifconfig arc0 freedom
|
||||
route add freedom arc0
|
||||
route add insight arc0
|
||||
/* and default gateway is configured by pppd */
|
||||
|
||||
but the rest of the subnet
|
||||
unfortunately lies across the PPP
|
||||
link on freedom, which confuses
|
||||
things. */
|
||||
route add default gw freedom
|
||||
|
||||
And freedom gets configured like so::
|
||||
|
||||
ifconfig arc0 freedom
|
||||
route add freedom arc0
|
||||
route add insight arc0
|
||||
/* and default gateway is configured by pppd */
|
||||
|
||||
Great, now insight talks to freedom directly on arc0, and sends packets
|
||||
to the Internet through freedom. If you didn't know how to do the above,
|
||||
you should probably stop reading this section now because it only gets
|
||||
|
@ -425,7 +459,7 @@ can set up your network then:
|
|||
Internet. (Recall that patience has a "private IP address" which won't
|
||||
work on the Internet; that's okay, I configured Linux IP masquerading on
|
||||
freedom for this subnet).
|
||||
|
||||
|
||||
So patience (necessarily; I don't have another IP number from my
|
||||
provider) has an IP address on a different subnet than freedom and
|
||||
insight, but needs to use freedom as an Internet gateway. Worse, most
|
||||
|
@ -435,53 +469,54 @@ can set up your network then:
|
|||
insight, patience WILL send through its default gateway, regardless of
|
||||
the fact that both freedom and insight (courtesy of the arc0e device)
|
||||
could understand a direct transmission.
|
||||
|
||||
I compensate by giving freedom an extra IP address - aliased 'gatekeeper'
|
||||
- that is on my private subnet, the same subnet that patience is on. I
|
||||
|
||||
I compensate by giving freedom an extra IP address - aliased 'gatekeeper' -
|
||||
that is on my private subnet, the same subnet that patience is on. I
|
||||
then define gatekeeper to be the default gateway for patience.
|
||||
|
||||
To configure freedom (in addition to the commands above):
|
||||
ifconfig arc0e gatekeeper
|
||||
route add gatekeeper arc0e
|
||||
route add patience arc0e
|
||||
|
||||
|
||||
To configure freedom (in addition to the commands above)::
|
||||
|
||||
ifconfig arc0e gatekeeper
|
||||
route add gatekeeper arc0e
|
||||
route add patience arc0e
|
||||
|
||||
This way, freedom will send all packets for patience through arc0e,
|
||||
giving its IP address as gatekeeper (on the private subnet). When it
|
||||
talks to insight or the Internet, it will use its "freedom" Internet IP
|
||||
address.
|
||||
|
||||
You will notice that we haven't configured the arc0e device on insight.
|
||||
|
||||
You will notice that we haven't configured the arc0e device on insight.
|
||||
This would work, but is not really necessary, and would require me to
|
||||
assign insight another special IP number from my private subnet. Since
|
||||
both insight and patience are using freedom as their default gateway, the
|
||||
two can already talk to each other.
|
||||
|
||||
|
||||
It's quite fortunate that I set things up like this the first time (cough
|
||||
cough) because it's really handy when I boot insight into DOS. There, it
|
||||
runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet.
|
||||
runs the Novell ODI protocol stack, which only works with RFC1201 ARCnet.
|
||||
In this mode it would be impossible for insight to communicate directly
|
||||
with patience, since the Novell stack is incompatible with Microsoft's
|
||||
Ethernet-Encap. Without changing any settings on freedom or patience, I
|
||||
simply set freedom as the default gateway for insight (now in DOS,
|
||||
remember) and all the forwarding happens "automagically" between the two
|
||||
hosts that would normally not be able to communicate at all.
|
||||
|
||||
|
||||
For those who like diagrams, I have created two "virtual subnets" on the
|
||||
same physical ARCnet wire. You can picture it like this:
|
||||
|
||||
|
||||
[RFC1201 NETWORK] [ETHER-ENCAP NETWORK]
|
||||
same physical ARCnet wire. You can picture it like this::
|
||||
|
||||
|
||||
[RFC1201 NETWORK] [ETHER-ENCAP NETWORK]
|
||||
(registered Internet subnet) (RFC1597 private subnet)
|
||||
|
||||
(IP Masquerade)
|
||||
/---------------\ * /---------------\
|
||||
| | * | |
|
||||
| +-Freedom-*-Gatekeeper-+ |
|
||||
| | | * | |
|
||||
\-------+-------/ | * \-------+-------/
|
||||
| | |
|
||||
Insight | Patience
|
||||
(Internet)
|
||||
|
||||
(IP Masquerade)
|
||||
/---------------\ * /---------------\
|
||||
| | * | |
|
||||
| +-Freedom-*-Gatekeeper-+ |
|
||||
| | | * | |
|
||||
\-------+-------/ | * \-------+-------/
|
||||
| | |
|
||||
Insight | Patience
|
||||
(Internet)
|
||||
|
||||
|
||||
|
||||
|
@ -491,6 +526,7 @@ It works: what now?
|
|||
Send mail describing your setup, preferably including driver version, kernel
|
||||
version, ARCnet card model, CPU type, number of systems on your network, and
|
||||
list of software in use to me at the following address:
|
||||
|
||||
apenwarr@worldvisions.ca
|
||||
|
||||
I do send (sometimes automated) replies to all messages I receive. My email
|
||||
|
@ -525,7 +561,7 @@ this, you should grab the pertinent RFCs. (some are listed near the top of
|
|||
arcnet.c). arcdump assumes your card is at 0xD0000. If it isn't, edit the
|
||||
script.
|
||||
|
||||
Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending.
|
||||
Buffers 0 and 1 are used for receiving, and Buffers 2 and 3 are for sending.
|
||||
Ping-pong buffers are implemented both ways.
|
||||
|
||||
If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,
|
||||
|
@ -535,9 +571,11 @@ decides that the driver is broken). During a transmit, unused parts of the
|
|||
buffer will be cleared to 0x42 as well. This is to make it easier to figure
|
||||
out which bytes are being used by a packet.
|
||||
|
||||
You can change the debug level without recompiling the kernel by typing:
|
||||
You can change the debug level without recompiling the kernel by typing::
|
||||
|
||||
ifconfig arc0 down metric 1xxx
|
||||
/etc/rc.d/rc.inet1
|
||||
|
||||
where "xxx" is the debug level you want. For example, "metric 1015" would put
|
||||
you at debug level 15. Debug level 7 is currently the default.
|
||||
|
||||
|
@ -546,7 +584,7 @@ combination of different debug flags; so debug level 7 is really 1+2+4 or
|
|||
D_NORMAL+D_EXTRA+D_INIT. To include D_DURING, you would add 16 to this,
|
||||
resulting in debug level 23.
|
||||
|
||||
If you don't understand that, you probably don't want to know anyway.
|
||||
If you don't understand that, you probably don't want to know anyway.
|
||||
E-mail me about your problem.
|
||||
|
||||
|
|
@ -1,3 +1,9 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===
|
||||
ATM
|
||||
===
|
||||
|
||||
In order to use anything but the most primitive functions of ATM,
|
||||
several user-mode programs are required to assist the kernel. These
|
||||
programs and related material can be found via the ATM on Linux Web
|
|
@ -1,3 +1,9 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====
|
||||
AX.25
|
||||
=====
|
||||
|
||||
To use the amateur radio protocols within Linux you will need to get a
|
||||
suitable copy of the AX.25 Utilities. More detailed information about
|
||||
AX.25, NET/ROM and ROSE, associated programs and and utilities can be
|
|
@ -1,26 +1,31 @@
|
|||
LINUX DRIVERS FOR BAYCOM MODEMS
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
|
||||
===============================
|
||||
Linux Drivers for Baycom Modems
|
||||
===============================
|
||||
|
||||
!!NEW!! (04/98) The drivers for the baycom modems have been split into
|
||||
Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
|
||||
|
||||
The drivers for the baycom modems have been split into
|
||||
separate drivers as they did not share any code, and the driver
|
||||
and device names have changed.
|
||||
|
||||
This document describes the Linux Kernel Drivers for simple Baycom style
|
||||
amateur radio modems.
|
||||
amateur radio modems.
|
||||
|
||||
The following drivers are available:
|
||||
====================================
|
||||
|
||||
baycom_ser_fdx:
|
||||
This driver supports the SER12 modems either full or half duplex.
|
||||
Its baud rate may be changed via the `baud' module parameter,
|
||||
Its baud rate may be changed via the ``baud`` module parameter,
|
||||
therefore it supports just about every bit bang modem on a
|
||||
serial port. Its devices are called bcsf0 through bcsf3.
|
||||
This is the recommended driver for SER12 type modems,
|
||||
however if you have a broken UART clone that does not have working
|
||||
delta status bits, you may try baycom_ser_hdx.
|
||||
delta status bits, you may try baycom_ser_hdx.
|
||||
|
||||
baycom_ser_hdx:
|
||||
baycom_ser_hdx:
|
||||
This is an alternative driver for SER12 type modems.
|
||||
It only supports half duplex, and only 1200 baud. Its devices
|
||||
are called bcsh0 through bcsh3. Use this driver only if baycom_ser_fdx
|
||||
|
@ -37,45 +42,48 @@ baycom_epp:
|
|||
|
||||
The following modems are supported:
|
||||
|
||||
ser12: This is a very simple 1200 baud AFSK modem. The modem consists only
|
||||
of a modulator/demodulator chip, usually a TI TCM3105. The computer
|
||||
is responsible for regenerating the receiver bit clock, as well as
|
||||
for handling the HDLC protocol. The modem connects to a serial port,
|
||||
hence the name. Since the serial port is not used as an async serial
|
||||
port, the kernel driver for serial ports cannot be used, and this
|
||||
driver only supports standard serial hardware (8250, 16450, 16550)
|
||||
======= ========================================================================
|
||||
ser12 This is a very simple 1200 baud AFSK modem. The modem consists only
|
||||
of a modulator/demodulator chip, usually a TI TCM3105. The computer
|
||||
is responsible for regenerating the receiver bit clock, as well as
|
||||
for handling the HDLC protocol. The modem connects to a serial port,
|
||||
hence the name. Since the serial port is not used as an async serial
|
||||
port, the kernel driver for serial ports cannot be used, and this
|
||||
driver only supports standard serial hardware (8250, 16450, 16550)
|
||||
|
||||
par96: This is a modem for 9600 baud FSK compatible to the G3RUH standard.
|
||||
The modem does all the filtering and regenerates the receiver clock.
|
||||
Data is transferred from and to the PC via a shift register.
|
||||
The shift register is filled with 16 bits and an interrupt is signalled.
|
||||
The PC then empties the shift register in a burst. This modem connects
|
||||
to the parallel port, hence the name. The modem leaves the
|
||||
implementation of the HDLC protocol and the scrambler polynomial to
|
||||
the PC.
|
||||
par96 This is a modem for 9600 baud FSK compatible to the G3RUH standard.
|
||||
The modem does all the filtering and regenerates the receiver clock.
|
||||
Data is transferred from and to the PC via a shift register.
|
||||
The shift register is filled with 16 bits and an interrupt is signalled.
|
||||
The PC then empties the shift register in a burst. This modem connects
|
||||
to the parallel port, hence the name. The modem leaves the
|
||||
implementation of the HDLC protocol and the scrambler polynomial to
|
||||
the PC.
|
||||
|
||||
picpar: This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
|
||||
is protocol compatible to par96, but uses only three low power ICs
|
||||
and can therefore be fed from the parallel port and does not require
|
||||
an additional power supply. Furthermore, it incorporates a carrier
|
||||
detect circuitry.
|
||||
picpar This is a redesign of the par96 modem by Henning Rech, DF9IC. The modem
|
||||
is protocol compatible to par96, but uses only three low power ICs
|
||||
and can therefore be fed from the parallel port and does not require
|
||||
an additional power supply. Furthermore, it incorporates a carrier
|
||||
detect circuitry.
|
||||
|
||||
EPP: This is a high-speed modem adaptor that connects to an enhanced parallel port.
|
||||
Its target audience is users working over a high speed hub (76.8kbit/s).
|
||||
|
||||
eppfpga: This is a redesign of the EPP adaptor.
|
||||
EPP This is a high-speed modem adaptor that connects to an enhanced parallel
|
||||
port.
|
||||
|
||||
Its target audience is users working over a high speed hub (76.8kbit/s).
|
||||
|
||||
eppfpga This is a redesign of the EPP adaptor.
|
||||
======= ========================================================================
|
||||
|
||||
All of the above modems only support half duplex communications. However,
|
||||
the driver supports the KISS (see below) fullduplex command. It then simply
|
||||
starts to send as soon as there's a packet to transmit and does not care
|
||||
about DCD, i.e. it starts to send even if there's someone else on the channel.
|
||||
This command is required by some implementations of the DAMA channel
|
||||
This command is required by some implementations of the DAMA channel
|
||||
access protocol.
|
||||
|
||||
|
||||
The Interface of the drivers
|
||||
============================
|
||||
|
||||
Unlike previous drivers, these drivers are no longer character devices,
|
||||
but they are now true kernel network interfaces. Installation is therefore
|
||||
|
@ -88,20 +96,22 @@ me for WAMPES which allows attaching a kernel network interface directly.
|
|||
|
||||
|
||||
Configuring the driver
|
||||
======================
|
||||
|
||||
Every time a driver is inserted into the kernel, it has to know which
|
||||
modems it should access at which ports. This can be done with the setbaycom
|
||||
utility. If you are only using one modem, you can also configure the
|
||||
driver from the insmod command line (or by means of an option line in
|
||||
/etc/modprobe.d/*.conf).
|
||||
``/etc/modprobe.d/*.conf``).
|
||||
|
||||
Examples::
|
||||
|
||||
Examples:
|
||||
modprobe baycom_ser_fdx mode="ser12*" iobase=0x3f8 irq=4
|
||||
sethdlc -i bcsf0 -p mode "ser12*" io 0x3f8 irq 4
|
||||
|
||||
Both lines configure the first port to drive a ser12 modem at the first
|
||||
serial port (COM1 under DOS). The * in the mode parameter instructs the driver to use
|
||||
the software DCD algorithm (see below).
|
||||
serial port (COM1 under DOS). The * in the mode parameter instructs the driver
|
||||
to use the software DCD algorithm (see below)::
|
||||
|
||||
insmod baycom_par mode="picpar" iobase=0x378
|
||||
sethdlc -i bcp0 -p mode "picpar" io 0x378
|
||||
|
@ -115,29 +125,33 @@ Note that both utilities interpret the values slightly differently.
|
|||
|
||||
|
||||
Hardware DCD versus Software DCD
|
||||
================================
|
||||
|
||||
To avoid collisions on the air, the driver must know when the channel is
|
||||
busy. This is the task of the DCD circuitry/software. The driver may either
|
||||
utilise a software DCD algorithm (options=1) or use a DCD signal from
|
||||
the hardware (options=0).
|
||||
|
||||
ser12: if software DCD is utilised, the radio's squelch should always be
|
||||
open. It is highly recommended to use the software DCD algorithm,
|
||||
as it is much faster than most hardware squelch circuitry. The
|
||||
disadvantage is a slightly higher load on the system.
|
||||
======= =================================================================
|
||||
ser12 if software DCD is utilised, the radio's squelch should always be
|
||||
open. It is highly recommended to use the software DCD algorithm,
|
||||
as it is much faster than most hardware squelch circuitry. The
|
||||
disadvantage is a slightly higher load on the system.
|
||||
|
||||
par96: the software DCD algorithm for this type of modem is rather poor.
|
||||
The modem simply does not provide enough information to implement
|
||||
a reasonable DCD algorithm in software. Therefore, if your radio
|
||||
feeds the DCD input of the PAR96 modem, the use of the hardware
|
||||
DCD circuitry is recommended.
|
||||
par96 the software DCD algorithm for this type of modem is rather poor.
|
||||
The modem simply does not provide enough information to implement
|
||||
a reasonable DCD algorithm in software. Therefore, if your radio
|
||||
feeds the DCD input of the PAR96 modem, the use of the hardware
|
||||
DCD circuitry is recommended.
|
||||
|
||||
picpar: the picpar modem features a builtin DCD hardware, which is highly
|
||||
recommended.
|
||||
picpar the picpar modem features a builtin DCD hardware, which is highly
|
||||
recommended.
|
||||
======= =================================================================
|
||||
|
||||
|
||||
|
||||
Compatibility with the rest of the Linux kernel
|
||||
===============================================
|
||||
|
||||
The serial driver and the baycom serial drivers compete
|
||||
for the same hardware resources. Of course only one driver can access a given
|
||||
|
@ -154,5 +168,7 @@ The parallel port drivers (baycom_par, baycom_epp) now use the parport subsystem
|
|||
to arbitrate the ports between different client drivers.
|
||||
|
||||
vy 73s de
|
||||
|
||||
Tom Sailer, sailer@ife.ee.ethz.ch
|
||||
|
||||
hb9jnx @ hb9w.ampr.org
|
File diff suppressed because it is too large
Load diff
|
@ -1,5 +1,3 @@
|
|||
:orphan:
|
||||
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
|
|
13
Documentation/networking/caif/index.rst
Normal file
13
Documentation/networking/caif/index.rst
Normal file
|
@ -0,0 +1,13 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
CAIF
|
||||
====
|
||||
|
||||
Contents:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
linux_caif
|
||||
caif
|
||||
spi_porting
|
|
@ -1,12 +1,19 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. include:: <isonum.txt>
|
||||
|
||||
==========
|
||||
Linux CAIF
|
||||
===========
|
||||
copyright (C) ST-Ericsson AB 2010
|
||||
Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
|
||||
License terms: GNU General Public License (GPL) version 2
|
||||
==========
|
||||
|
||||
Copyright |copy| ST-Ericsson AB 2010
|
||||
|
||||
:Author: Sjur Brendeland/ sjur.brandeland@stericsson.com
|
||||
:License terms: GNU General Public License (GPL) version 2
|
||||
|
||||
|
||||
Introduction
|
||||
------------
|
||||
============
|
||||
|
||||
CAIF is a MUX protocol used by ST-Ericsson cellular modems for
|
||||
communication between Modem and host. The host processes can open virtual AT
|
||||
channels, initiate GPRS Data connections, Video channels and Utility Channels.
|
||||
|
@ -16,13 +23,16 @@ ST-Ericsson modems support a number of transports between modem
|
|||
and host. Currently, UART and Loopback are available for Linux.
|
||||
|
||||
|
||||
Architecture:
|
||||
------------
|
||||
Architecture
|
||||
============
|
||||
|
||||
The implementation of CAIF is divided into:
|
||||
|
||||
* CAIF Socket Layer and GPRS IP Interface.
|
||||
* CAIF Core Protocol Implementation
|
||||
* CAIF Link Layer, implemented as NET devices.
|
||||
|
||||
::
|
||||
|
||||
RTNL
|
||||
!
|
||||
|
@ -46,12 +56,12 @@ The implementation of CAIF is divided into:
|
|||
|
||||
|
||||
|
||||
I M P L E M E N T A T I O N
|
||||
===========================
|
||||
Implementation
|
||||
==============
|
||||
|
||||
|
||||
CAIF Core Protocol Layer
|
||||
=========================================
|
||||
------------------------
|
||||
|
||||
CAIF Core layer implements the CAIF protocol as defined by ST-Ericsson.
|
||||
It implements the CAIF protocol stack in a layered approach, where
|
||||
|
@ -59,8 +69,11 @@ each layer described in the specification is implemented as a separate layer.
|
|||
The architecture is inspired by the design patterns "Protocol Layer" and
|
||||
"Protocol Packet".
|
||||
|
||||
== CAIF structure ==
|
||||
CAIF structure
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
The Core CAIF implementation contains:
|
||||
|
||||
- Simple implementation of CAIF.
|
||||
- Layered architecture (a la Streams), each layer in the CAIF
|
||||
specification is implemented in a separate c-file.
|
||||
|
@ -73,7 +86,8 @@ The Core CAIF implementation contains:
|
|||
to the called function (except for framing layers' receive function)
|
||||
|
||||
Layered Architecture
|
||||
--------------------
|
||||
====================
|
||||
|
||||
The CAIF protocol can be divided into two parts: Support functions and Protocol
|
||||
Implementation. The support functions include:
|
||||
|
||||
|
@ -112,7 +126,7 @@ The CAIF Protocol implementation contains:
|
|||
- CFSERL CAIF Serial layer. Handles concatenation/split of frames
|
||||
into CAIF Frames with correct length.
|
||||
|
||||
|
||||
::
|
||||
|
||||
+---------+
|
||||
| Config |
|
||||
|
@ -143,18 +157,24 @@ The CAIF Protocol implementation contains:
|
|||
|
||||
|
||||
In this layered approach the following "rules" apply.
|
||||
|
||||
- All layers embed the same structure "struct cflayer"
|
||||
- A layer does not depend on any other layer's private data.
|
||||
- Layers are stacked by setting the pointers
|
||||
- Layers are stacked by setting the pointers::
|
||||
|
||||
layer->up , layer->dn
|
||||
- In order to send data upwards, each layer should do
|
||||
|
||||
- In order to send data upwards, each layer should do::
|
||||
|
||||
layer->up->receive(layer->up, packet);
|
||||
- In order to send data downwards, each layer should do
|
||||
|
||||
- In order to send data downwards, each layer should do::
|
||||
|
||||
layer->dn->transmit(layer->dn, packet);
|
||||
|
||||
|
||||
CAIF Socket and IP interface
|
||||
===========================
|
||||
============================
|
||||
|
||||
The IP interface and CAIF socket API are implemented on top of the
|
||||
CAIF Core protocol. The IP Interface and CAIF socket have an instance of
|
229
Documentation/networking/caif/spi_porting.rst
Normal file
229
Documentation/networking/caif/spi_porting.rst
Normal file
|
@ -0,0 +1,229 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
================
|
||||
CAIF SPI porting
|
||||
================
|
||||
|
||||
CAIF SPI basics
|
||||
===============
|
||||
|
||||
Running CAIF over SPI needs some extra setup, owing to the nature of SPI.
|
||||
Two extra GPIOs have been added in order to negotiate the transfers
|
||||
between the master and the slave. The minimum requirement for running
|
||||
CAIF over SPI is a SPI slave chip and two GPIOs (more details below).
|
||||
Please note that running as a slave implies that you need to keep up
|
||||
with the master clock. An overrun or underrun event is fatal.
|
||||
|
||||
CAIF SPI framework
|
||||
==================
|
||||
|
||||
To make porting as easy as possible, the CAIF SPI has been divided in
|
||||
two parts. The first part (called the interface part) deals with all
|
||||
generic functionality such as length framing, SPI frame negotiation
|
||||
and SPI frame delivery and transmission. The other part is the CAIF
|
||||
SPI slave device part, which is the module that you have to write if
|
||||
you want to run SPI CAIF on a new hardware. This part takes care of
|
||||
the physical hardware, both with regard to SPI and to GPIOs.
|
||||
|
||||
- Implementing a CAIF SPI device:
|
||||
|
||||
- Functionality provided by the CAIF SPI slave device:
|
||||
|
||||
In order to implement a SPI device you will, as a minimum,
|
||||
need to implement the following
|
||||
functions:
|
||||
|
||||
::
|
||||
|
||||
int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev):
|
||||
|
||||
This function is called by the CAIF SPI interface to give
|
||||
you a chance to set up your hardware to be ready to receive
|
||||
a stream of data from the master. The xfer structure contains
|
||||
both physical and logical addresses, as well as the total length
|
||||
of the transfer in both directions.The dev parameter can be used
|
||||
to map to different CAIF SPI slave devices.
|
||||
|
||||
::
|
||||
|
||||
void (*sig_xfer) (bool xfer, struct cfspi_dev *dev):
|
||||
|
||||
This function is called by the CAIF SPI interface when the output
|
||||
(SPI_INT) GPIO needs to change state. The boolean value of the xfer
|
||||
variable indicates whether the GPIO should be asserted (HIGH) or
|
||||
deasserted (LOW). The dev parameter can be used to map to different CAIF
|
||||
SPI slave devices.
|
||||
|
||||
- Functionality provided by the CAIF SPI interface:
|
||||
|
||||
::
|
||||
|
||||
void (*ss_cb) (bool assert, struct cfspi_ifc *ifc);
|
||||
|
||||
This function is called by the CAIF SPI slave device in order to
|
||||
signal a change of state of the input GPIO (SS) to the interface.
|
||||
Only active edges are mandatory to be reported.
|
||||
This function can be called from IRQ context (recommended in order
|
||||
not to introduce latency). The ifc parameter should be the pointer
|
||||
returned from the platform probe function in the SPI device structure.
|
||||
|
||||
::
|
||||
|
||||
void (*xfer_done_cb) (struct cfspi_ifc *ifc);
|
||||
|
||||
This function is called by the CAIF SPI slave device in order to
|
||||
report that a transfer is completed. This function should only be
|
||||
called once both the transmission and the reception are completed.
|
||||
This function can be called from IRQ context (recommended in order
|
||||
not to introduce latency). The ifc parameter should be the pointer
|
||||
returned from the platform probe function in the SPI device structure.
|
||||
|
||||
- Connecting the bits and pieces:
|
||||
|
||||
- Filling in the SPI slave device structure:
|
||||
|
||||
Connect the necessary callback functions.
|
||||
|
||||
Indicate clock speed (used to calculate toggle delays).
|
||||
|
||||
Chose a suitable name (helps debugging if you use several CAIF
|
||||
SPI slave devices).
|
||||
|
||||
Assign your private data (can be used to map to your
|
||||
structure).
|
||||
|
||||
- Filling in the SPI slave platform device structure:
|
||||
|
||||
Add name of driver to connect to ("cfspi_sspi").
|
||||
|
||||
Assign the SPI slave device structure as platform data.
|
||||
|
||||
Padding
|
||||
=======
|
||||
|
||||
In order to optimize throughput, a number of SPI padding options are provided.
|
||||
Padding can be enabled independently for uplink and downlink transfers.
|
||||
Padding can be enabled for the head, the tail and for the total frame size.
|
||||
The padding needs to be correctly configured on both sides of the link.
|
||||
The padding can be changed via module parameters in cfspi_sspi.c or via
|
||||
the sysfs directory of the cfspi_sspi driver (before device registration).
|
||||
|
||||
- CAIF SPI device template::
|
||||
|
||||
/*
|
||||
* Copyright (C) ST-Ericsson AB 2010
|
||||
* Author: Daniel Martensson / Daniel.Martensson@stericsson.com
|
||||
* License terms: GNU General Public License (GPL), version 2.
|
||||
*
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/device.h>
|
||||
#include <linux/wait.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <net/caif/caif_spi.h>
|
||||
|
||||
MODULE_LICENSE("GPL");
|
||||
|
||||
struct sspi_struct {
|
||||
struct cfspi_dev sdev;
|
||||
struct cfspi_xfer *xfer;
|
||||
};
|
||||
|
||||
static struct sspi_struct slave;
|
||||
static struct platform_device slave_device;
|
||||
|
||||
static irqreturn_t sspi_irq(int irq, void *arg)
|
||||
{
|
||||
/* You only need to trigger on an edge to the active state of the
|
||||
* SS signal. Once a edge is detected, the ss_cb() function should be
|
||||
* called with the parameter assert set to true. It is OK
|
||||
* (and even advised) to call the ss_cb() function in IRQ context in
|
||||
* order not to add any delay. */
|
||||
|
||||
return IRQ_HANDLED;
|
||||
}
|
||||
|
||||
static void sspi_complete(void *context)
|
||||
{
|
||||
/* Normally the DMA or the SPI framework will call you back
|
||||
* in something similar to this. The only thing you need to
|
||||
* do is to call the xfer_done_cb() function, providing the pointer
|
||||
* to the CAIF SPI interface. It is OK to call this function
|
||||
* from IRQ context. */
|
||||
}
|
||||
|
||||
static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
|
||||
{
|
||||
/* Store transfer info. For a normal implementation you should
|
||||
* set up your DMA here and make sure that you are ready to
|
||||
* receive the data from the master SPI. */
|
||||
|
||||
struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
|
||||
|
||||
sspi->xfer = xfer;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
|
||||
{
|
||||
/* If xfer is true then you should assert the SPI_INT to indicate to
|
||||
* the master that you are ready to receive the data from the master
|
||||
* SPI. If xfer is false then you should de-assert SPI_INT to indicate
|
||||
* that the transfer is done.
|
||||
*/
|
||||
|
||||
struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
|
||||
}
|
||||
|
||||
static void sspi_release(struct device *dev)
|
||||
{
|
||||
/*
|
||||
* Here you should release your SPI device resources.
|
||||
*/
|
||||
}
|
||||
|
||||
static int __init sspi_init(void)
|
||||
{
|
||||
/* Here you should initialize your SPI device by providing the
|
||||
* necessary functions, clock speed, name and private data. Once
|
||||
* done, you can register your device with the
|
||||
* platform_device_register() function. This function will return
|
||||
* with the CAIF SPI interface initialized. This is probably also
|
||||
* the place where you should set up your GPIOs, interrupts and SPI
|
||||
* resources. */
|
||||
|
||||
int res = 0;
|
||||
|
||||
/* Initialize slave device. */
|
||||
slave.sdev.init_xfer = sspi_init_xfer;
|
||||
slave.sdev.sig_xfer = sspi_sig_xfer;
|
||||
slave.sdev.clk_mhz = 13;
|
||||
slave.sdev.priv = &slave;
|
||||
slave.sdev.name = "spi_sspi";
|
||||
slave_device.dev.release = sspi_release;
|
||||
|
||||
/* Initialize platform device. */
|
||||
slave_device.name = "cfspi_sspi";
|
||||
slave_device.dev.platform_data = &slave.sdev;
|
||||
|
||||
/* Register platform device. */
|
||||
res = platform_device_register(&slave_device);
|
||||
if (res) {
|
||||
printk(KERN_WARNING "sspi_init: failed to register dev.\n");
|
||||
return -ENODEV;
|
||||
}
|
||||
|
||||
return res;
|
||||
}
|
||||
|
||||
static void __exit sspi_exit(void)
|
||||
{
|
||||
platform_device_del(&slave_device);
|
||||
}
|
||||
|
||||
module_init(sspi_init);
|
||||
module_exit(sspi_exit);
|
|
@ -1,208 +0,0 @@
|
|||
- CAIF SPI porting -
|
||||
|
||||
- CAIF SPI basics:
|
||||
|
||||
Running CAIF over SPI needs some extra setup, owing to the nature of SPI.
|
||||
Two extra GPIOs have been added in order to negotiate the transfers
|
||||
between the master and the slave. The minimum requirement for running
|
||||
CAIF over SPI is a SPI slave chip and two GPIOs (more details below).
|
||||
Please note that running as a slave implies that you need to keep up
|
||||
with the master clock. An overrun or underrun event is fatal.
|
||||
|
||||
- CAIF SPI framework:
|
||||
|
||||
To make porting as easy as possible, the CAIF SPI has been divided in
|
||||
two parts. The first part (called the interface part) deals with all
|
||||
generic functionality such as length framing, SPI frame negotiation
|
||||
and SPI frame delivery and transmission. The other part is the CAIF
|
||||
SPI slave device part, which is the module that you have to write if
|
||||
you want to run SPI CAIF on a new hardware. This part takes care of
|
||||
the physical hardware, both with regard to SPI and to GPIOs.
|
||||
|
||||
- Implementing a CAIF SPI device:
|
||||
|
||||
- Functionality provided by the CAIF SPI slave device:
|
||||
|
||||
In order to implement a SPI device you will, as a minimum,
|
||||
need to implement the following
|
||||
functions:
|
||||
|
||||
int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev):
|
||||
|
||||
This function is called by the CAIF SPI interface to give
|
||||
you a chance to set up your hardware to be ready to receive
|
||||
a stream of data from the master. The xfer structure contains
|
||||
both physical and logical addresses, as well as the total length
|
||||
of the transfer in both directions.The dev parameter can be used
|
||||
to map to different CAIF SPI slave devices.
|
||||
|
||||
void (*sig_xfer) (bool xfer, struct cfspi_dev *dev):
|
||||
|
||||
This function is called by the CAIF SPI interface when the output
|
||||
(SPI_INT) GPIO needs to change state. The boolean value of the xfer
|
||||
variable indicates whether the GPIO should be asserted (HIGH) or
|
||||
deasserted (LOW). The dev parameter can be used to map to different CAIF
|
||||
SPI slave devices.
|
||||
|
||||
- Functionality provided by the CAIF SPI interface:
|
||||
|
||||
void (*ss_cb) (bool assert, struct cfspi_ifc *ifc);
|
||||
|
||||
This function is called by the CAIF SPI slave device in order to
|
||||
signal a change of state of the input GPIO (SS) to the interface.
|
||||
Only active edges are mandatory to be reported.
|
||||
This function can be called from IRQ context (recommended in order
|
||||
not to introduce latency). The ifc parameter should be the pointer
|
||||
returned from the platform probe function in the SPI device structure.
|
||||
|
||||
void (*xfer_done_cb) (struct cfspi_ifc *ifc);
|
||||
|
||||
This function is called by the CAIF SPI slave device in order to
|
||||
report that a transfer is completed. This function should only be
|
||||
called once both the transmission and the reception are completed.
|
||||
This function can be called from IRQ context (recommended in order
|
||||
not to introduce latency). The ifc parameter should be the pointer
|
||||
returned from the platform probe function in the SPI device structure.
|
||||
|
||||
- Connecting the bits and pieces:
|
||||
|
||||
- Filling in the SPI slave device structure:
|
||||
|
||||
Connect the necessary callback functions.
|
||||
Indicate clock speed (used to calculate toggle delays).
|
||||
Chose a suitable name (helps debugging if you use several CAIF
|
||||
SPI slave devices).
|
||||
Assign your private data (can be used to map to your structure).
|
||||
|
||||
- Filling in the SPI slave platform device structure:
|
||||
Add name of driver to connect to ("cfspi_sspi").
|
||||
Assign the SPI slave device structure as platform data.
|
||||
|
||||
- Padding:
|
||||
|
||||
In order to optimize throughput, a number of SPI padding options are provided.
|
||||
Padding can be enabled independently for uplink and downlink transfers.
|
||||
Padding can be enabled for the head, the tail and for the total frame size.
|
||||
The padding needs to be correctly configured on both sides of the link.
|
||||
The padding can be changed via module parameters in cfspi_sspi.c or via
|
||||
the sysfs directory of the cfspi_sspi driver (before device registration).
|
||||
|
||||
- CAIF SPI device template:
|
||||
|
||||
/*
|
||||
* Copyright (C) ST-Ericsson AB 2010
|
||||
* Author: Daniel Martensson / Daniel.Martensson@stericsson.com
|
||||
* License terms: GNU General Public License (GPL), version 2.
|
||||
*
|
||||
*/
|
||||
|
||||
#include <linux/init.h>
|
||||
#include <linux/module.h>
|
||||
#include <linux/device.h>
|
||||
#include <linux/wait.h>
|
||||
#include <linux/interrupt.h>
|
||||
#include <linux/dma-mapping.h>
|
||||
#include <net/caif/caif_spi.h>
|
||||
|
||||
MODULE_LICENSE("GPL");
|
||||
|
||||
struct sspi_struct {
|
||||
struct cfspi_dev sdev;
|
||||
struct cfspi_xfer *xfer;
|
||||
};
|
||||
|
||||
static struct sspi_struct slave;
|
||||
static struct platform_device slave_device;
|
||||
|
||||
static irqreturn_t sspi_irq(int irq, void *arg)
|
||||
{
|
||||
/* You only need to trigger on an edge to the active state of the
|
||||
* SS signal. Once a edge is detected, the ss_cb() function should be
|
||||
* called with the parameter assert set to true. It is OK
|
||||
* (and even advised) to call the ss_cb() function in IRQ context in
|
||||
* order not to add any delay. */
|
||||
|
||||
return IRQ_HANDLED;
|
||||
}
|
||||
|
||||
static void sspi_complete(void *context)
|
||||
{
|
||||
/* Normally the DMA or the SPI framework will call you back
|
||||
* in something similar to this. The only thing you need to
|
||||
* do is to call the xfer_done_cb() function, providing the pointer
|
||||
* to the CAIF SPI interface. It is OK to call this function
|
||||
* from IRQ context. */
|
||||
}
|
||||
|
||||
static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
|
||||
{
|
||||
/* Store transfer info. For a normal implementation you should
|
||||
* set up your DMA here and make sure that you are ready to
|
||||
* receive the data from the master SPI. */
|
||||
|
||||
struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
|
||||
|
||||
sspi->xfer = xfer;
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
|
||||
{
|
||||
/* If xfer is true then you should assert the SPI_INT to indicate to
|
||||
* the master that you are ready to receive the data from the master
|
||||
* SPI. If xfer is false then you should de-assert SPI_INT to indicate
|
||||
* that the transfer is done.
|
||||
*/
|
||||
|
||||
struct sspi_struct *sspi = (struct sspi_struct *)dev->priv;
|
||||
}
|
||||
|
||||
static void sspi_release(struct device *dev)
|
||||
{
|
||||
/*
|
||||
* Here you should release your SPI device resources.
|
||||
*/
|
||||
}
|
||||
|
||||
static int __init sspi_init(void)
|
||||
{
|
||||
/* Here you should initialize your SPI device by providing the
|
||||
* necessary functions, clock speed, name and private data. Once
|
||||
* done, you can register your device with the
|
||||
* platform_device_register() function. This function will return
|
||||
* with the CAIF SPI interface initialized. This is probably also
|
||||
* the place where you should set up your GPIOs, interrupts and SPI
|
||||
* resources. */
|
||||
|
||||
int res = 0;
|
||||
|
||||
/* Initialize slave device. */
|
||||
slave.sdev.init_xfer = sspi_init_xfer;
|
||||
slave.sdev.sig_xfer = sspi_sig_xfer;
|
||||
slave.sdev.clk_mhz = 13;
|
||||
slave.sdev.priv = &slave;
|
||||
slave.sdev.name = "spi_sspi";
|
||||
slave_device.dev.release = sspi_release;
|
||||
|
||||
/* Initialize platform device. */
|
||||
slave_device.name = "cfspi_sspi";
|
||||
slave_device.dev.platform_data = &slave.sdev;
|
||||
|
||||
/* Register platform device. */
|
||||
res = platform_device_register(&slave_device);
|
||||
if (res) {
|
||||
printk(KERN_WARNING "sspi_init: failed to register dev.\n");
|
||||
return -ENODEV;
|
||||
}
|
||||
|
||||
return res;
|
||||
}
|
||||
|
||||
static void __exit sspi_exit(void)
|
||||
{
|
||||
platform_device_del(&slave_device);
|
||||
}
|
||||
|
||||
module_init(sspi_init);
|
||||
module_exit(sspi_exit);
|
|
@ -1,5 +1,8 @@
|
|||
cdc_mbim - Driver for CDC MBIM Mobile Broadband modems
|
||||
========================================================
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================================================
|
||||
cdc_mbim - Driver for CDC MBIM Mobile Broadband modems
|
||||
======================================================
|
||||
|
||||
The cdc_mbim driver supports USB devices conforming to the "Universal
|
||||
Serial Bus Communications Class Subclass Specification for Mobile
|
||||
|
@ -19,9 +22,9 @@ by a cdc_ncm driver parameter:
|
|||
|
||||
prefer_mbim
|
||||
-----------
|
||||
Type: Boolean
|
||||
Valid Range: N/Y (0-1)
|
||||
Default Value: Y (MBIM is preferred)
|
||||
:Type: Boolean
|
||||
:Valid Range: N/Y (0-1)
|
||||
:Default Value: Y (MBIM is preferred)
|
||||
|
||||
This parameter sets the system policy for NCM/MBIM functions. Such
|
||||
functions will be handled by either the cdc_ncm driver or the cdc_mbim
|
||||
|
@ -44,11 +47,13 @@ userspace MBIM management application always is required to enable a
|
|||
MBIM function.
|
||||
|
||||
Such userspace applications includes, but are not limited to:
|
||||
|
||||
- mbimcli (included with the libmbim [3] library), and
|
||||
- ModemManager [4]
|
||||
|
||||
Establishing a MBIM IP session reequires at least these actions by the
|
||||
management application:
|
||||
|
||||
- open the control channel
|
||||
- configure network connection settings
|
||||
- connect to network
|
||||
|
@ -76,7 +81,7 @@ complies with all the control channel requirements in [1].
|
|||
|
||||
The cdc-wdmX device is created as a child of the MBIM control
|
||||
interface USB device. The character device associated with a specific
|
||||
MBIM function can be looked up using sysfs. For example:
|
||||
MBIM function can be looked up using sysfs. For example::
|
||||
|
||||
bjorn@nemi:~$ ls /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc
|
||||
cdc-wdm0
|
||||
|
@ -119,13 +124,15 @@ negotiated control message size.
|
|||
|
||||
|
||||
/dev/cdc-wdmX ioctl()
|
||||
--------------------
|
||||
---------------------
|
||||
IOCTL_WDM_MAX_COMMAND: Get Maximum Command Size
|
||||
This ioctl returns the wMaxControlMessage field of the CDC MBIM
|
||||
functional descriptor for MBIM devices. This is intended as a
|
||||
convenience, eliminating the need to parse the USB descriptors from
|
||||
userspace.
|
||||
|
||||
::
|
||||
|
||||
#include <stdio.h>
|
||||
#include <fcntl.h>
|
||||
#include <sys/ioctl.h>
|
||||
|
@ -178,7 +185,7 @@ VLAN links prior to establishing MBIM IP sessions where the SessionId
|
|||
is greater than 0. These links can be added by using the normal VLAN
|
||||
kernel interfaces, either ioctl or netlink.
|
||||
|
||||
For example, adding a link for a MBIM IP session with SessionId 3:
|
||||
For example, adding a link for a MBIM IP session with SessionId 3::
|
||||
|
||||
ip link add link wwan0 name wwan0.3 type vlan id 3
|
||||
|
||||
|
@ -207,6 +214,7 @@ the stream to the end user in an appropriate way for the stream type.
|
|||
The network device ABI requires a dummy ethernet header for every DSS
|
||||
data frame being transported. The contents of this header is
|
||||
arbitrary, with the following exceptions:
|
||||
|
||||
- TX frames using an IP protocol (0x0800 or 0x86dd) will be dropped
|
||||
- RX frames will have the protocol field set to ETH_P_802_3 (but will
|
||||
not be properly formatted 802.3 frames)
|
||||
|
@ -218,7 +226,7 @@ adding the dummy ethernet header on TX and stripping it on RX.
|
|||
|
||||
This is a simple example using tools commonly available, exporting
|
||||
DssSessionId 5 as a pty character device pointed to by a /dev/nmea
|
||||
symlink:
|
||||
symlink::
|
||||
|
||||
ip link add link wwan0 name wwan0.dss5 type vlan id 261
|
||||
ip link set dev wwan0.dss5 up
|
||||
|
@ -236,7 +244,7 @@ map frames to the correct DSS session and adding 18 byte VLAN ethernet
|
|||
headers with the appropriate tag on TX. In this case using a socket
|
||||
filter is recommended, matching only the DSS VLAN subset. This avoid
|
||||
unnecessary copying of unrelated IP session data to userspace. For
|
||||
example:
|
||||
example::
|
||||
|
||||
static struct sock_filter dssfilter[] = {
|
||||
/* use special negative offsets to get VLAN tag */
|
||||
|
@ -249,11 +257,11 @@ example:
|
|||
BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 512, 3, 0), /* 511 is last DSS VLAN */
|
||||
|
||||
/* verify ethertype */
|
||||
BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 2 * ETH_ALEN),
|
||||
BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_802_3, 0, 1),
|
||||
BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 2 * ETH_ALEN),
|
||||
BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_802_3, 0, 1),
|
||||
|
||||
BPF_STMT(BPF_RET|BPF_K, (u_int)-1), /* accept */
|
||||
BPF_STMT(BPF_RET|BPF_K, 0), /* ignore */
|
||||
BPF_STMT(BPF_RET|BPF_K, (u_int)-1), /* accept */
|
||||
BPF_STMT(BPF_RET|BPF_K, 0), /* ignore */
|
||||
};
|
||||
|
||||
|
||||
|
@ -266,6 +274,7 @@ network device.
|
|||
|
||||
This mapping implies a few restrictions on multiplexed IPS and DSS
|
||||
sessions, which may not always be practical:
|
||||
|
||||
- no IPS or DSS session can use a frame size greater than the MTU on
|
||||
IP session 0
|
||||
- no IPS or DSS session can be in the up state unless the network
|
||||
|
@ -280,7 +289,7 @@ device.
|
|||
|
||||
Tip: It might be less confusing to the end user to name this VLAN
|
||||
subdevice after the MBIM SessionID instead of the VLAN ID. For
|
||||
example:
|
||||
example::
|
||||
|
||||
ip link add link wwan0 name wwan0.0 type vlan id 4094
|
||||
|
||||
|
@ -290,7 +299,7 @@ VLAN mapping
|
|||
|
||||
Summarizing the cdc_mbim driver mapping described above, we have this
|
||||
relationship between VLAN tags on the wwanY network device and MBIM
|
||||
sessions on the shared USB data channel:
|
||||
sessions on the shared USB data channel::
|
||||
|
||||
VLAN ID MBIM type MBIM SessionID Notes
|
||||
---------------------------------------------------------
|
||||
|
@ -310,30 +319,37 @@ sessions on the shared USB data channel:
|
|||
References
|
||||
==========
|
||||
|
||||
[1] USB Implementers Forum, Inc. - "Universal Serial Bus
|
||||
Communications Class Subclass Specification for Mobile Broadband
|
||||
Interface Model", Revision 1.0 (Errata 1), May 1, 2013
|
||||
1) USB Implementers Forum, Inc. - "Universal Serial Bus
|
||||
Communications Class Subclass Specification for Mobile Broadband
|
||||
Interface Model", Revision 1.0 (Errata 1), May 1, 2013
|
||||
|
||||
- http://www.usb.org/developers/docs/devclass_docs/
|
||||
|
||||
[2] USB Implementers Forum, Inc. - "Universal Serial Bus
|
||||
Communications Class Subclass Specifications for Network Control
|
||||
Model Devices", Revision 1.0 (Errata 1), November 24, 2010
|
||||
2) USB Implementers Forum, Inc. - "Universal Serial Bus
|
||||
Communications Class Subclass Specifications for Network Control
|
||||
Model Devices", Revision 1.0 (Errata 1), November 24, 2010
|
||||
|
||||
- http://www.usb.org/developers/docs/devclass_docs/
|
||||
|
||||
[3] libmbim - "a glib-based library for talking to WWAN modems and
|
||||
devices which speak the Mobile Interface Broadband Model (MBIM)
|
||||
protocol"
|
||||
3) libmbim - "a glib-based library for talking to WWAN modems and
|
||||
devices which speak the Mobile Interface Broadband Model (MBIM)
|
||||
protocol"
|
||||
|
||||
- http://www.freedesktop.org/wiki/Software/libmbim/
|
||||
|
||||
[4] ModemManager - "a DBus-activated daemon which controls mobile
|
||||
broadband (2G/3G/4G) devices and connections"
|
||||
4) ModemManager - "a DBus-activated daemon which controls mobile
|
||||
broadband (2G/3G/4G) devices and connections"
|
||||
|
||||
- http://www.freedesktop.org/wiki/Software/ModemManager/
|
||||
|
||||
[5] "MBIM (Mobile Broadband Interface Model) Registry"
|
||||
5) "MBIM (Mobile Broadband Interface Model) Registry"
|
||||
|
||||
- http://compliance.usb.org/mbim/
|
||||
|
||||
[6] "/sys/kernel/debug/usb/devices output format"
|
||||
6) "/sys/kernel/debug/usb/devices output format"
|
||||
|
||||
- Documentation/driver-api/usb/usb.rst
|
||||
|
||||
[7] "/sys/bus/usb/devices/.../descriptors"
|
||||
7) "/sys/bus/usb/devices/.../descriptors"
|
||||
|
||||
- Documentation/ABI/stable/sysfs-bus-usb
|
80
Documentation/networking/cops.rst
Normal file
80
Documentation/networking/cops.rst
Normal file
|
@ -0,0 +1,80 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================================
|
||||
The COPS LocalTalk Linux driver (cops.c)
|
||||
========================================
|
||||
|
||||
By Jay Schulist <jschlst@samba.org>
|
||||
|
||||
This driver has two modes and they are: Dayna mode and Tangent mode.
|
||||
Each mode corresponds with the type of card. It has been found
|
||||
that there are 2 main types of cards and all other cards are
|
||||
the same and just have different names or only have minor differences
|
||||
such as more IO ports. As this driver is tested it will
|
||||
become more clear exactly what cards are supported.
|
||||
|
||||
Right now these cards are known to work with the COPS driver. The
|
||||
LT-200 cards work in a somewhat more limited capacity than the
|
||||
DL200 cards, which work very well and are in use by many people.
|
||||
|
||||
TANGENT driver mode:
|
||||
- Tangent ATB-II, Novell NL-1000, Daystar Digital LT-200
|
||||
|
||||
DAYNA driver mode:
|
||||
- Dayna DL2000/DaynaTalk PC (Half Length), COPS LT-95,
|
||||
- Farallon PhoneNET PC III, Farallon PhoneNET PC II
|
||||
|
||||
Other cards possibly supported mode unknown though:
|
||||
- Dayna DL2000 (Full length)
|
||||
|
||||
The COPS driver defaults to using Dayna mode. To change the driver's
|
||||
mode if you built a driver with dual support use board_type=1 or
|
||||
board_type=2 for Dayna or Tangent with insmod.
|
||||
|
||||
Operation/loading of the driver
|
||||
===============================
|
||||
|
||||
Use modprobe like this: /sbin/modprobe cops.o (IO #) (IRQ #)
|
||||
If you do not specify any options the driver will try and use the IO = 0x240,
|
||||
IRQ = 5. As of right now I would only use IRQ 5 for the card, if autoprobing.
|
||||
|
||||
To load multiple COPS driver Localtalk cards you can do one of the following::
|
||||
|
||||
insmod cops io=0x240 irq=5
|
||||
insmod -o cops2 cops io=0x260 irq=3
|
||||
|
||||
Or in lilo.conf put something like this::
|
||||
|
||||
append="ether=5,0x240,lt0 ether=3,0x260,lt1"
|
||||
|
||||
Then bring up the interface with ifconfig. It will look something like this::
|
||||
|
||||
lt0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-F7-00-00-00-00-00-00-00-00
|
||||
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
|
||||
UP BROADCAST RUNNING NOARP MULTICAST MTU:600 Metric:1
|
||||
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
|
||||
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0
|
||||
|
||||
Netatalk Configuration
|
||||
======================
|
||||
|
||||
You will need to configure atalkd with something like the following to make
|
||||
it work with the cops.c driver.
|
||||
|
||||
* For single LTalk card use::
|
||||
|
||||
dummy -seed -phase 2 -net 2000 -addr 2000.10 -zone "1033"
|
||||
lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
|
||||
|
||||
* For multiple cards, Ethernet and LocalTalk::
|
||||
|
||||
eth0 -seed -phase 2 -net 3000 -addr 3000.20 -zone "1033"
|
||||
lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
|
||||
|
||||
* For multiple LocalTalk cards, and an Ethernet card.
|
||||
|
||||
* Order seems to matter here, Ethernet last::
|
||||
|
||||
lt0 -seed -phase 1 -net 1000 -addr 1000.10 -zone "LocalTalk1"
|
||||
lt1 -seed -phase 1 -net 2000 -addr 2000.20 -zone "LocalTalk2"
|
||||
eth0 -seed -phase 2 -net 3000 -addr 3000.30 -zone "EtherTalk"
|
|
@ -1,63 +0,0 @@
|
|||
Text File for the COPS LocalTalk Linux driver (cops.c).
|
||||
By Jay Schulist <jschlst@samba.org>
|
||||
|
||||
This driver has two modes and they are: Dayna mode and Tangent mode.
|
||||
Each mode corresponds with the type of card. It has been found
|
||||
that there are 2 main types of cards and all other cards are
|
||||
the same and just have different names or only have minor differences
|
||||
such as more IO ports. As this driver is tested it will
|
||||
become more clear exactly what cards are supported.
|
||||
|
||||
Right now these cards are known to work with the COPS driver. The
|
||||
LT-200 cards work in a somewhat more limited capacity than the
|
||||
DL200 cards, which work very well and are in use by many people.
|
||||
|
||||
TANGENT driver mode:
|
||||
Tangent ATB-II, Novell NL-1000, Daystar Digital LT-200
|
||||
DAYNA driver mode:
|
||||
Dayna DL2000/DaynaTalk PC (Half Length), COPS LT-95,
|
||||
Farallon PhoneNET PC III, Farallon PhoneNET PC II
|
||||
Other cards possibly supported mode unknown though:
|
||||
Dayna DL2000 (Full length)
|
||||
|
||||
The COPS driver defaults to using Dayna mode. To change the driver's
|
||||
mode if you built a driver with dual support use board_type=1 or
|
||||
board_type=2 for Dayna or Tangent with insmod.
|
||||
|
||||
** Operation/loading of the driver.
|
||||
Use modprobe like this: /sbin/modprobe cops.o (IO #) (IRQ #)
|
||||
If you do not specify any options the driver will try and use the IO = 0x240,
|
||||
IRQ = 5. As of right now I would only use IRQ 5 for the card, if autoprobing.
|
||||
|
||||
To load multiple COPS driver Localtalk cards you can do one of the following.
|
||||
|
||||
insmod cops io=0x240 irq=5
|
||||
insmod -o cops2 cops io=0x260 irq=3
|
||||
|
||||
Or in lilo.conf put something like this:
|
||||
append="ether=5,0x240,lt0 ether=3,0x260,lt1"
|
||||
|
||||
Then bring up the interface with ifconfig. It will look something like this:
|
||||
lt0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-F7-00-00-00-00-00-00-00-00
|
||||
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
|
||||
UP BROADCAST RUNNING NOARP MULTICAST MTU:600 Metric:1
|
||||
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
|
||||
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 coll:0
|
||||
|
||||
** Netatalk Configuration
|
||||
You will need to configure atalkd with something like the following to make
|
||||
it work with the cops.c driver.
|
||||
|
||||
* For single LTalk card use.
|
||||
dummy -seed -phase 2 -net 2000 -addr 2000.10 -zone "1033"
|
||||
lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
|
||||
|
||||
* For multiple cards, Ethernet and LocalTalk.
|
||||
eth0 -seed -phase 2 -net 3000 -addr 3000.20 -zone "1033"
|
||||
lt0 -seed -phase 1 -net 1000 -addr 1000.50 -zone "1033"
|
||||
|
||||
* For multiple LocalTalk cards, and an Ethernet card.
|
||||
* Order seems to matter here, Ethernet last.
|
||||
lt0 -seed -phase 1 -net 1000 -addr 1000.10 -zone "LocalTalk1"
|
||||
lt1 -seed -phase 1 -net 2000 -addr 2000.20 -zone "LocalTalk2"
|
||||
eth0 -seed -phase 2 -net 3000 -addr 3000.30 -zone "EtherTalk"
|
|
@ -1,3 +1,9 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================
|
||||
ATM cxacru device driver
|
||||
========================
|
||||
|
||||
Firmware is required for this device: http://accessrunner.sourceforge.net/
|
||||
|
||||
While it is capable of managing/maintaining the ADSL connection without the
|
||||
|
@ -19,29 +25,35 @@ several sysfs attribute files for retrieving device statistics:
|
|||
|
||||
* adsl_headend
|
||||
* adsl_headend_environment
|
||||
Information about the remote headend.
|
||||
|
||||
- Information about the remote headend.
|
||||
|
||||
* adsl_config
|
||||
Configuration writing interface.
|
||||
Write parameters in hexadecimal format <index>=<value>,
|
||||
separated by whitespace, e.g.:
|
||||
|
||||
- Configuration writing interface.
|
||||
- Write parameters in hexadecimal format <index>=<value>,
|
||||
separated by whitespace, e.g.:
|
||||
|
||||
"1=0 a=5"
|
||||
Up to 7 parameters at a time will be sent and the modem will restart
|
||||
the ADSL connection when any value is set. These are logged for future
|
||||
reference.
|
||||
|
||||
- Up to 7 parameters at a time will be sent and the modem will restart
|
||||
the ADSL connection when any value is set. These are logged for future
|
||||
reference.
|
||||
|
||||
* downstream_attenuation (dB)
|
||||
* downstream_bits_per_frame
|
||||
* downstream_rate (kbps)
|
||||
* downstream_snr_margin (dB)
|
||||
Downstream stats.
|
||||
|
||||
- Downstream stats.
|
||||
|
||||
* upstream_attenuation (dB)
|
||||
* upstream_bits_per_frame
|
||||
* upstream_rate (kbps)
|
||||
* upstream_snr_margin (dB)
|
||||
* transmitter_power (dBm/Hz)
|
||||
Upstream stats.
|
||||
|
||||
- Upstream stats.
|
||||
|
||||
* downstream_crc_errors
|
||||
* downstream_fec_errors
|
||||
|
@ -49,48 +61,56 @@ several sysfs attribute files for retrieving device statistics:
|
|||
* upstream_crc_errors
|
||||
* upstream_fec_errors
|
||||
* upstream_hec_errors
|
||||
Error counts.
|
||||
|
||||
- Error counts.
|
||||
|
||||
* line_startable
|
||||
Indicates that ADSL support on the device
|
||||
is/can be enabled, see adsl_start.
|
||||
|
||||
- Indicates that ADSL support on the device
|
||||
is/can be enabled, see adsl_start.
|
||||
|
||||
* line_status
|
||||
"initialising"
|
||||
"down"
|
||||
"attempting to activate"
|
||||
"training"
|
||||
"channel analysis"
|
||||
"exchange"
|
||||
"waiting"
|
||||
"up"
|
||||
|
||||
- "initialising"
|
||||
- "down"
|
||||
- "attempting to activate"
|
||||
- "training"
|
||||
- "channel analysis"
|
||||
- "exchange"
|
||||
- "waiting"
|
||||
- "up"
|
||||
|
||||
Changes between "down" and "attempting to activate"
|
||||
if there is no signal.
|
||||
|
||||
* link_status
|
||||
"not connected"
|
||||
"connected"
|
||||
"lost"
|
||||
|
||||
- "not connected"
|
||||
- "connected"
|
||||
- "lost"
|
||||
|
||||
* mac_address
|
||||
|
||||
* modulation
|
||||
"" (when not connected)
|
||||
"ANSI T1.413"
|
||||
"ITU-T G.992.1 (G.DMT)"
|
||||
"ITU-T G.992.2 (G.LITE)"
|
||||
|
||||
- "" (when not connected)
|
||||
- "ANSI T1.413"
|
||||
- "ITU-T G.992.1 (G.DMT)"
|
||||
- "ITU-T G.992.2 (G.LITE)"
|
||||
|
||||
* startup_attempts
|
||||
Count of total attempts to initialise ADSL.
|
||||
|
||||
- Count of total attempts to initialise ADSL.
|
||||
|
||||
To enable/disable ADSL, the following can be written to the adsl_state file:
|
||||
"start"
|
||||
"stop
|
||||
"restart" (stops, waits 1.5s, then starts)
|
||||
"poll" (used to resume status polling if it was disabled due to failure)
|
||||
|
||||
Changes in adsl/line state are reported via kernel log messages:
|
||||
- "start"
|
||||
- "stop
|
||||
- "restart" (stops, waits 1.5s, then starts)
|
||||
- "poll" (used to resume status polling if it was disabled due to failure)
|
||||
|
||||
Changes in adsl/line state are reported via kernel log messages::
|
||||
|
||||
[4942145.150704] ATM dev 0: ADSL state: running
|
||||
[4942243.663766] ATM dev 0: ADSL line: down
|
||||
[4942249.665075] ATM dev 0: ADSL line: attempting to activate
|
|
@ -1,16 +1,18 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=============
|
||||
DCCP protocol
|
||||
=============
|
||||
|
||||
|
||||
Contents
|
||||
========
|
||||
- Introduction
|
||||
- Missing features
|
||||
- Socket options
|
||||
- Sysctl variables
|
||||
- IOCTLs
|
||||
- Other tunables
|
||||
- Notes
|
||||
.. Contents
|
||||
- Introduction
|
||||
- Missing features
|
||||
- Socket options
|
||||
- Sysctl variables
|
||||
- IOCTLs
|
||||
- Other tunables
|
||||
- Notes
|
||||
|
||||
|
||||
Introduction
|
||||
|
@ -38,6 +40,7 @@ The Linux DCCP implementation does not currently support all the features that a
|
|||
specified in RFCs 4340...42.
|
||||
|
||||
The known bugs are at:
|
||||
|
||||
http://www.linuxfoundation.org/collaborate/workgroups/networking/todo#DCCP
|
||||
|
||||
For more up-to-date versions of the DCCP implementation, please consider using
|
||||
|
@ -54,7 +57,8 @@ defined: the "simple" policy (DCCPQ_POLICY_SIMPLE), which does nothing special,
|
|||
and a priority-based variant (DCCPQ_POLICY_PRIO). The latter allows to pass an
|
||||
u32 priority value as ancillary data to sendmsg(), where higher numbers indicate
|
||||
a higher packet priority (similar to SO_PRIORITY). This ancillary data needs to
|
||||
be formatted using a cmsg(3) message header filled in as follows:
|
||||
be formatted using a cmsg(3) message header filled in as follows::
|
||||
|
||||
cmsg->cmsg_level = SOL_DCCP;
|
||||
cmsg->cmsg_type = DCCP_SCM_PRIORITY;
|
||||
cmsg->cmsg_len = CMSG_LEN(sizeof(uint32_t)); /* or CMSG_LEN(4) */
|
||||
|
@ -94,7 +98,7 @@ must be registered on the socket before calling connect() or listen().
|
|||
|
||||
DCCP_SOCKOPT_TX_CCID is read/write. It returns the current CCID (if set) or sets
|
||||
the preference list for the TX CCID, using the same format as DCCP_SOCKOPT_CCID.
|
||||
Please note that the getsockopt argument type here is `int', not uint8_t.
|
||||
Please note that the getsockopt argument type here is ``int``, not uint8_t.
|
||||
|
||||
DCCP_SOCKOPT_RX_CCID is analogous to DCCP_SOCKOPT_TX_CCID, but for the RX CCID.
|
||||
|
||||
|
@ -113,6 +117,7 @@ be enabled at the receiver, too with suitable choice of CsCov.
|
|||
DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
|
||||
range 0..15 are acceptable. The default setting is 0 (full coverage),
|
||||
values between 1..15 indicate partial coverage.
|
||||
|
||||
DCCP_SOCKOPT_RECV_CSCOV is for the receiver and has a different meaning: it
|
||||
sets a threshold, where again values 0..15 are acceptable. The default
|
||||
of 0 means that all packets with a partial coverage will be discarded.
|
||||
|
@ -123,11 +128,13 @@ DCCP_SOCKOPT_RECV_CSCOV is for the receiver and has a different meaning: it
|
|||
|
||||
The following two options apply to CCID 3 exclusively and are getsockopt()-only.
|
||||
In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned.
|
||||
|
||||
DCCP_SOCKOPT_CCID_RX_INFO
|
||||
Returns a `struct tfrc_rx_info' in optval; the buffer for optval and
|
||||
Returns a ``struct tfrc_rx_info`` in optval; the buffer for optval and
|
||||
optlen must be set to at least sizeof(struct tfrc_rx_info).
|
||||
|
||||
DCCP_SOCKOPT_CCID_TX_INFO
|
||||
Returns a `struct tfrc_tx_info' in optval; the buffer for optval and
|
||||
Returns a ``struct tfrc_tx_info`` in optval; the buffer for optval and
|
||||
optlen must be set to at least sizeof(struct tfrc_tx_info).
|
||||
|
||||
On unidirectional connections it is useful to close the unused half-connection
|
||||
|
@ -182,7 +189,7 @@ sync_ratelimit = 125 ms
|
|||
IOCTLS
|
||||
======
|
||||
FIONREAD
|
||||
Works as in udp(7): returns in the `int' argument pointer the size of
|
||||
Works as in udp(7): returns in the ``int`` argument pointer the size of
|
||||
the next pending datagram in bytes, or 0 when no datagram is pending.
|
||||
|
||||
|
||||
|
@ -191,10 +198,12 @@ Other tunables
|
|||
Per-route rto_min support
|
||||
CCID-2 supports the RTAX_RTO_MIN per-route setting for the minimum value
|
||||
of the RTO timer. This setting can be modified via the 'rto_min' option
|
||||
of iproute2; for example:
|
||||
of iproute2; for example::
|
||||
|
||||
> ip route change 10.0.0.0/24 rto_min 250j dev wlan0
|
||||
> ip route add 10.0.0.254/32 rto_min 800j dev wlan0
|
||||
> ip route show dev wlan0
|
||||
|
||||
CCID-3 also supports the rto_min setting: it is used to define the lower
|
||||
bound for the expiry of the nofeedback timer. This can be useful on LANs
|
||||
with very low RTTs (e.g., loopback, Gbit ethernet).
|
|
@ -1,11 +1,14 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================
|
||||
DCTCP (DataCenter TCP)
|
||||
----------------------
|
||||
======================
|
||||
|
||||
DCTCP is an enhancement to the TCP congestion control algorithm for data
|
||||
center networks and leverages Explicit Congestion Notification (ECN) in
|
||||
the data center network to provide multi-bit feedback to the end hosts.
|
||||
|
||||
To enable it on end hosts:
|
||||
To enable it on end hosts::
|
||||
|
||||
sysctl -w net.ipv4.tcp_congestion_control=dctcp
|
||||
sysctl -w net.ipv4.tcp_ecn_fallback=0 (optional)
|
||||
|
@ -25,14 +28,19 @@ SIGCOMM/SIGMETRICS papers:
|
|||
|
||||
i) Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye,
|
||||
Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan:
|
||||
"Data Center TCP (DCTCP)", Data Center Networks session
|
||||
|
||||
"Data Center TCP (DCTCP)", Data Center Networks session"
|
||||
|
||||
Proc. ACM SIGCOMM, New Delhi, 2010.
|
||||
|
||||
http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp-final.pdf
|
||||
http://www.sigcomm.org/ccr/papers/2010/October/1851275.1851192
|
||||
|
||||
ii) Mohammad Alizadeh, Adel Javanmard, and Balaji Prabhakar:
|
||||
|
||||
"Analysis of DCTCP: Stability, Convergence, and Fairness"
|
||||
Proc. ACM SIGMETRICS, San Jose, 2011.
|
||||
|
||||
http://simula.stanford.edu/~alizade/Site/DCTCP_files/dctcp_analysis-full.pdf
|
||||
|
||||
IETF informational draft:
|
|
@ -1,26 +1,31 @@
|
|||
Linux DECnet Networking Layer Information
|
||||
===========================================
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
1) Other documentation....
|
||||
=========================================
|
||||
Linux DECnet Networking Layer Information
|
||||
=========================================
|
||||
|
||||
o Project Home Pages
|
||||
http://www.chygwyn.com/ - Kernel info
|
||||
http://linux-decnet.sourceforge.net/ - Userland tools
|
||||
http://www.sourceforge.net/projects/linux-decnet/ - Status page
|
||||
1. Other documentation....
|
||||
==========================
|
||||
|
||||
2) Configuring the kernel
|
||||
- Project Home Pages
|
||||
- http://www.chygwyn.com/ - Kernel info
|
||||
- http://linux-decnet.sourceforge.net/ - Userland tools
|
||||
- http://www.sourceforge.net/projects/linux-decnet/ - Status page
|
||||
|
||||
2. Configuring the kernel
|
||||
=========================
|
||||
|
||||
Be sure to turn on the following options:
|
||||
|
||||
CONFIG_DECNET (obviously)
|
||||
CONFIG_PROC_FS (to see what's going on)
|
||||
CONFIG_SYSCTL (for easy configuration)
|
||||
- CONFIG_DECNET (obviously)
|
||||
- CONFIG_PROC_FS (to see what's going on)
|
||||
- CONFIG_SYSCTL (for easy configuration)
|
||||
|
||||
if you want to try out router support (not properly debugged yet)
|
||||
you'll need the following options as well...
|
||||
|
||||
CONFIG_DECNET_ROUTER (to be able to add/delete routes)
|
||||
CONFIG_NETFILTER (will be required for the DECnet routing daemon)
|
||||
- CONFIG_DECNET_ROUTER (to be able to add/delete routes)
|
||||
- CONFIG_NETFILTER (will be required for the DECnet routing daemon)
|
||||
|
||||
Don't turn on SIOCGIFCONF support for DECnet unless you are really sure
|
||||
that you need it, in general you won't and it can cause ifconfig to
|
||||
|
@ -29,7 +34,7 @@ malfunction.
|
|||
Run time configuration has changed slightly from the 2.4 system. If you
|
||||
want to configure an endnode, then the simplified procedure is as follows:
|
||||
|
||||
o Set the MAC address on your ethernet card before starting _any_ other
|
||||
- Set the MAC address on your ethernet card before starting _any_ other
|
||||
network protocols.
|
||||
|
||||
As soon as your network card is brought into the UP state, DECnet should
|
||||
|
@ -37,7 +42,8 @@ start working. If you need something more complicated or are unsure how
|
|||
to set the MAC address, see the next section. Also all configurations which
|
||||
worked with 2.4 will work under 2.5 with no change.
|
||||
|
||||
3) Command line options
|
||||
3. Command line options
|
||||
=======================
|
||||
|
||||
You can set a DECnet address on the kernel command line for compatibility
|
||||
with the 2.4 configuration procedure, but in general it's not needed any more.
|
||||
|
@ -56,7 +62,7 @@ interface then you won't see any entries in /proc/net/neigh for the local
|
|||
host until such time as you start a connection. This doesn't affect the
|
||||
operation of the local communications in any other way though.
|
||||
|
||||
The kernel command line takes options looking like the following:
|
||||
The kernel command line takes options looking like the following::
|
||||
|
||||
decnet.addr=1,2
|
||||
|
||||
|
@ -82,7 +88,7 @@ address of the node in order for it to be autoconfigured (and then appear in
|
|||
FTP sites called dn2ethaddr which can compute the correct ethernet
|
||||
address to use. The address can be set by ifconfig either before or
|
||||
at the time the device is brought up. If you are using RedHat you can
|
||||
add the line:
|
||||
add the line::
|
||||
|
||||
MACADDR=AA:00:04:00:03:04
|
||||
|
||||
|
@ -95,7 +101,7 @@ verify with iproute2).
|
|||
The default device for routing can be set through the /proc filesystem
|
||||
by setting /proc/sys/net/decnet/default_device to the
|
||||
device you want DECnet to route packets out of when no specific route
|
||||
is available. Usually this will be eth0, for example:
|
||||
is available. Usually this will be eth0, for example::
|
||||
|
||||
echo -n "eth0" >/proc/sys/net/decnet/default_device
|
||||
|
||||
|
@ -106,7 +112,9 @@ confirm that by looking in the default_device file of course.
|
|||
There is a list of what the other files under /proc/sys/net/decnet/ do
|
||||
on the kernel patch web site (shown above).
|
||||
|
||||
4) Run time kernel configuration
|
||||
4. Run time kernel configuration
|
||||
================================
|
||||
|
||||
|
||||
This is either done through the sysctl/proc interface (see the kernel web
|
||||
pages for details on what the various options do) or through the iproute2
|
||||
|
@ -122,20 +130,21 @@ since its the _only_ way to add and delete routes currently. Eventually
|
|||
there will be a routing daemon to send and receive routing messages for
|
||||
each interface and update the kernel routing tables accordingly. The
|
||||
routing daemon will use netfilter to listen to routing packets, and
|
||||
rtnetlink to update the kernels routing tables.
|
||||
rtnetlink to update the kernels routing tables.
|
||||
|
||||
The DECnet raw socket layer has been removed since it was there purely
|
||||
for use by the routing daemon which will now use netfilter (a much cleaner
|
||||
and more generic solution) instead.
|
||||
|
||||
5) How can I tell if its working ?
|
||||
5. How can I tell if its working?
|
||||
=================================
|
||||
|
||||
Here is a quick guide of what to look for in order to know if your DECnet
|
||||
kernel subsystem is working.
|
||||
|
||||
- Is the node address set (see /proc/sys/net/decnet/node_address)
|
||||
- Is the node of the correct type
|
||||
(see /proc/sys/net/decnet/conf/<dev>/forwarding)
|
||||
- Is the node of the correct type
|
||||
(see /proc/sys/net/decnet/conf/<dev>/forwarding)
|
||||
- Is the Ethernet MAC address of each Ethernet card set to match
|
||||
the DECnet address. If in doubt use the dn2ethaddr utility available
|
||||
at the ftp archive.
|
||||
|
@ -160,7 +169,8 @@ kernel subsystem is working.
|
|||
network, and see if you can obtain the same results.
|
||||
- At this point you are on your own... :-)
|
||||
|
||||
6) How to send a bug report
|
||||
6. How to send a bug report
|
||||
===========================
|
||||
|
||||
If you've found a bug and want to report it, then there are several things
|
||||
you can do to help me work out exactly what it is that is wrong. Useful
|
||||
|
@ -175,18 +185,19 @@ information (_most_ of which _is_ _essential_) includes:
|
|||
- How much data was being transferred ?
|
||||
- Was the network congested ?
|
||||
- How can the problem be reproduced ?
|
||||
- Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of
|
||||
- Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of
|
||||
tcpdump don't understand how to dump DECnet properly, so including
|
||||
the hex listing of the packet contents is _essential_, usually the -x flag.
|
||||
You may also need to increase the length grabbed with the -s flag. The
|
||||
-e flag also provides very useful information (ethernet MAC addresses))
|
||||
|
||||
7) MAC FAQ
|
||||
7. MAC FAQ
|
||||
==========
|
||||
|
||||
A quick FAQ on ethernet MAC addresses to explain how Linux and DECnet
|
||||
interact and how to get the best performance from your hardware.
|
||||
interact and how to get the best performance from your hardware.
|
||||
|
||||
Ethernet cards are designed to normally only pass received network frames
|
||||
Ethernet cards are designed to normally only pass received network frames
|
||||
to a host computer when they are addressed to it, or to the broadcast address.
|
||||
|
||||
Linux has an interface which allows the setting of extra addresses for
|
||||
|
@ -197,8 +208,8 @@ significant processor time and bus bandwidth can be used up on a busy
|
|||
network (see the NAPI documentation for a longer explanation of these
|
||||
effects).
|
||||
|
||||
DECnet makes use of this interface to allow running DECnet on an ethernet
|
||||
card which has already been configured using TCP/IP (presumably using the
|
||||
DECnet makes use of this interface to allow running DECnet on an ethernet
|
||||
card which has already been configured using TCP/IP (presumably using the
|
||||
built in MAC address of the card, as usual) and/or to allow multiple DECnet
|
||||
addresses on each physical interface. If you do this, be aware that if your
|
||||
ethernet card doesn't support perfect hashing in its MAC address filter
|
||||
|
@ -210,7 +221,8 @@ to gain the best efficiency. Better still is to use a card which supports
|
|||
NAPI as well.
|
||||
|
||||
|
||||
8) Mailing list
|
||||
8. Mailing list
|
||||
===============
|
||||
|
||||
If you are keen to get involved in development, or want to ask questions
|
||||
about configuration, or even just report bugs, then there is a mailing
|
||||
|
@ -218,7 +230,8 @@ list that you can join, details are at:
|
|||
|
||||
http://sourceforge.net/mail/?group_id=4993
|
||||
|
||||
9) Legal Info
|
||||
9. Legal Info
|
||||
=============
|
||||
|
||||
The Linux DECnet project team have placed their code under the GPL. The
|
||||
software is provided "as is" and without warranty express or implied.
|
|
@ -1,4 +1,10 @@
|
|||
Notes on the DEC FDDIcontroller 700 (DEFZA-xx) driver v.1.1.4.
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====================================================
|
||||
Notes on the DEC FDDIcontroller 700 (DEFZA-xx) driver
|
||||
=====================================================
|
||||
|
||||
:Version: v.1.1.4
|
||||
|
||||
|
||||
DEC FDDIcontroller 700 is DEC's first-generation TURBOchannel FDDI
|
|
@ -33,7 +33,7 @@ The following features are now available in supported kernels:
|
|||
- SNMP
|
||||
|
||||
Channel Bonding documentation can be found in the Linux kernel source:
|
||||
/Documentation/networking/bonding.txt
|
||||
/Documentation/networking/bonding.rst
|
||||
|
||||
|
||||
Identifying Your Adapter
|
||||
|
|
|
@ -37,7 +37,7 @@ The following features are available in this kernel:
|
|||
- SNMP
|
||||
|
||||
Channel Bonding documentation can be found in the Linux kernel source:
|
||||
/Documentation/networking/bonding.txt
|
||||
/Documentation/networking/bonding.rst
|
||||
|
||||
The driver information previously displayed in the /proc filesystem is not
|
||||
supported in this release. Alternatively, you can use ethtool (version 1.6
|
||||
|
|
|
@ -1,8 +1,10 @@
|
|||
===================
|
||||
DNS Resolver Module
|
||||
===================
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Contents:
|
||||
===================
|
||||
DNS Resolver Module
|
||||
===================
|
||||
|
||||
.. Contents:
|
||||
|
||||
- Overview.
|
||||
- Compilation.
|
||||
|
@ -12,8 +14,7 @@ Contents:
|
|||
- Debugging.
|
||||
|
||||
|
||||
========
|
||||
OVERVIEW
|
||||
Overview
|
||||
========
|
||||
|
||||
The DNS resolver module provides a way for kernel services to make DNS queries
|
||||
|
@ -33,50 +34,50 @@ It does not yet support the following AFS features:
|
|||
This code is extracted from the CIFS filesystem.
|
||||
|
||||
|
||||
===========
|
||||
COMPILATION
|
||||
Compilation
|
||||
===========
|
||||
|
||||
The module should be enabled by turning on the kernel configuration options:
|
||||
The module should be enabled by turning on the kernel configuration options::
|
||||
|
||||
CONFIG_DNS_RESOLVER - tristate "DNS Resolver support"
|
||||
|
||||
|
||||
==========
|
||||
SETTING UP
|
||||
Setting up
|
||||
==========
|
||||
|
||||
To set up this facility, the /etc/request-key.conf file must be altered so that
|
||||
/sbin/request-key can appropriately direct the upcalls. For example, to handle
|
||||
basic dname to IPv4/IPv6 address resolution, the following line should be
|
||||
added:
|
||||
added::
|
||||
|
||||
|
||||
#OP TYPE DESC CO-INFO PROGRAM ARG1 ARG2 ARG3 ...
|
||||
#====== ============ ======= ======= ==========================
|
||||
create dns_resolver * * /usr/sbin/cifs.upcall %k
|
||||
|
||||
To direct a query for query type 'foo', a line of the following should be added
|
||||
before the more general line given above as the first match is the one taken.
|
||||
before the more general line given above as the first match is the one taken::
|
||||
|
||||
create dns_resolver foo:* * /usr/sbin/dns.foo %k
|
||||
|
||||
|
||||
=====
|
||||
USAGE
|
||||
Usage
|
||||
=====
|
||||
|
||||
To make use of this facility, one of the following functions that are
|
||||
implemented in the module can be called after doing:
|
||||
implemented in the module can be called after doing::
|
||||
|
||||
#include <linux/dns_resolver.h>
|
||||
|
||||
(1) int dns_query(const char *type, const char *name, size_t namelen,
|
||||
const char *options, char **_result, time_t *_expiry);
|
||||
::
|
||||
|
||||
int dns_query(const char *type, const char *name, size_t namelen,
|
||||
const char *options, char **_result, time_t *_expiry);
|
||||
|
||||
This is the basic access function. It looks for a cached DNS query and if
|
||||
it doesn't find it, it upcalls to userspace to make a new DNS query, which
|
||||
may then be cached. The key description is constructed as a string of the
|
||||
form:
|
||||
form::
|
||||
|
||||
[<type>:]<name>
|
||||
|
||||
|
@ -107,16 +108,14 @@ This can be cleared by any process that has the CAP_SYS_ADMIN capability by
|
|||
the use of KEYCTL_KEYRING_CLEAR on the keyring ID.
|
||||
|
||||
|
||||
===============================
|
||||
READING DNS KEYS FROM USERSPACE
|
||||
Reading DNS Keys from Userspace
|
||||
===============================
|
||||
|
||||
Keys of dns_resolver type can be read from userspace using keyctl_read() or
|
||||
"keyctl read/print/pipe".
|
||||
|
||||
|
||||
=========
|
||||
MECHANISM
|
||||
Mechanism
|
||||
=========
|
||||
|
||||
The dnsresolver module registers a key type called "dns_resolver". Keys of
|
||||
|
@ -147,11 +146,10 @@ See <file:Documentation/security/keys/request-key.rst> for further
|
|||
information about request-key function.
|
||||
|
||||
|
||||
=========
|
||||
DEBUGGING
|
||||
Debugging
|
||||
=========
|
||||
|
||||
Debugging messages can be turned on dynamically by writing a 1 into the
|
||||
following file:
|
||||
following file::
|
||||
|
||||
/sys/module/dnsresolver/parameters/debug
|
||||
/sys/module/dnsresolver/parameters/debug
|
|
@ -1,4 +1,8 @@
|
|||
Document about softnet driver issues
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====================
|
||||
Softnet Driver Issues
|
||||
=====================
|
||||
|
||||
Transmit path guidelines:
|
||||
|
||||
|
@ -8,7 +12,7 @@ Transmit path guidelines:
|
|||
transmit function will become busy.
|
||||
|
||||
Instead it must maintain the queue properly. For example,
|
||||
for a driver implementing scatter-gather this means:
|
||||
for a driver implementing scatter-gather this means::
|
||||
|
||||
static netdev_tx_t drv_hard_start_xmit(struct sk_buff *skb,
|
||||
struct net_device *dev)
|
||||
|
@ -38,25 +42,25 @@ Transmit path guidelines:
|
|||
return NETDEV_TX_OK;
|
||||
}
|
||||
|
||||
And then at the end of your TX reclamation event handling:
|
||||
And then at the end of your TX reclamation event handling::
|
||||
|
||||
if (netif_queue_stopped(dp->dev) &&
|
||||
TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1))
|
||||
TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1))
|
||||
netif_wake_queue(dp->dev);
|
||||
|
||||
For a non-scatter-gather supporting card, the three tests simply become:
|
||||
For a non-scatter-gather supporting card, the three tests simply become::
|
||||
|
||||
/* This is a hard error log it. */
|
||||
if (TX_BUFFS_AVAIL(dp) <= 0)
|
||||
|
||||
and:
|
||||
and::
|
||||
|
||||
if (TX_BUFFS_AVAIL(dp) == 0)
|
||||
|
||||
and:
|
||||
and::
|
||||
|
||||
if (netif_queue_stopped(dp->dev) &&
|
||||
TX_BUFFS_AVAIL(dp) > 0)
|
||||
TX_BUFFS_AVAIL(dp) > 0)
|
||||
netif_wake_queue(dp->dev);
|
||||
|
||||
2) An ndo_start_xmit method must not modify the shared parts of a
|
||||
|
@ -86,7 +90,7 @@ Close/stop guidelines:
|
|||
|
||||
1) After the ndo_stop routine has been called, the hardware must
|
||||
not receive or transmit any data. All in flight packets must
|
||||
be aborted. If necessary, poll or wait for completion of
|
||||
be aborted. If necessary, poll or wait for completion of
|
||||
any reset commands.
|
||||
|
||||
2) The ndo_stop routine will be called by unregister_netdevice
|
|
@ -1,5 +1,11 @@
|
|||
EQL Driver: Serial IP Load Balancing HOWTO
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==========================================
|
||||
EQL Driver: Serial IP Load Balancing HOWTO
|
||||
==========================================
|
||||
|
||||
Simon "Guru Aleph-Null" Janes, simon@ncm.com
|
||||
|
||||
v1.1, February 27, 1995
|
||||
|
||||
This is the manual for the EQL device driver. EQL is a software device
|
||||
|
@ -12,7 +18,8 @@
|
|||
which was only created to patch cleanly in the very latest kernel
|
||||
source trees. (Yes, it worked fine.)
|
||||
|
||||
1. Introduction
|
||||
1. Introduction
|
||||
===============
|
||||
|
||||
Which is worse? A huge fee for a 56K leased line or two phone lines?
|
||||
It's probably the former. If you find yourself craving more bandwidth,
|
||||
|
@ -41,47 +48,40 @@
|
|||
Hey, we can all dream you know...
|
||||
|
||||
|
||||
2. Kernel Configuration
|
||||
2. Kernel Configuration
|
||||
=======================
|
||||
|
||||
Here I describe the general steps of getting a kernel up and working
|
||||
with the eql driver. From patching, building, to installing.
|
||||
|
||||
|
||||
2.1. Patching The Kernel
|
||||
2.1. Patching The Kernel
|
||||
------------------------
|
||||
|
||||
If you do not have or cannot get a copy of the kernel with the eql
|
||||
driver folded into it, get your copy of the driver from
|
||||
ftp://slaughter.ncm.com/pub/Linux/LOAD_BALANCING/eql-1.1.tar.gz.
|
||||
Unpack this archive someplace obvious like /usr/local/src/. It will
|
||||
create the following files:
|
||||
create the following files::
|
||||
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
-rw-r--r-- guru/ncm 198 Jan 19 18:53 1995 eql-1.1/NO-WARRANTY
|
||||
-rw-r--r-- guru/ncm 30620 Feb 27 21:40 1995 eql-1.1/eql-1.1.patch
|
||||
-rwxr-xr-x guru/ncm 16111 Jan 12 22:29 1995 eql-1.1/eql_enslave
|
||||
-rw-r--r-- guru/ncm 2195 Jan 10 21:48 1995 eql-1.1/eql_enslave.c
|
||||
______________________________________________________________________
|
||||
|
||||
Unpack a recent kernel (something after 1.1.92) someplace convenient
|
||||
like say /usr/src/linux-1.1.92.eql. Use symbolic links to point
|
||||
/usr/src/linux to this development directory.
|
||||
|
||||
|
||||
Apply the patch by running the commands:
|
||||
Apply the patch by running the commands::
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
cd /usr/src
|
||||
patch </usr/local/src/eql-1.1/eql-1.1.patch
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
2.2. Building The Kernel
|
||||
2.2. Building The Kernel
|
||||
------------------------
|
||||
|
||||
After patching the kernel, run make config and configure the kernel
|
||||
for your hardware.
|
||||
|
@ -90,7 +90,8 @@
|
|||
After configuration, make and install according to your habit.
|
||||
|
||||
|
||||
3. Network Configuration
|
||||
3. Network Configuration
|
||||
========================
|
||||
|
||||
So far, I have only used the eql device with the DSLIP SLIP connection
|
||||
manager by Matt Dillon (-- "The man who sold his soul to code so much
|
||||
|
@ -100,37 +101,27 @@
|
|||
connection.
|
||||
|
||||
|
||||
3.1. /etc/rc.d/rc.inet1
|
||||
3.1. /etc/rc.d/rc.inet1
|
||||
-----------------------
|
||||
|
||||
In rc.inet1, ifconfig the eql device to the IP address you usually use
|
||||
for your machine, and the MTU you prefer for your SLIP lines. One
|
||||
could argue that MTU should be roughly half the usual size for two
|
||||
modems, one-third for three, one-fourth for four, etc... But going
|
||||
too far below 296 is probably overkill. Here is an example ifconfig
|
||||
command that sets up the eql device:
|
||||
command that sets up the eql device::
|
||||
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
ifconfig eql 198.67.33.239 mtu 1006
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Once the eql device is up and running, add a static default route to
|
||||
it in the routing table using the cool new route syntax that makes
|
||||
life so much easier:
|
||||
life so much easier::
|
||||
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
route add default eql
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
3.2. Enslaving Devices By Hand
|
||||
3.2. Enslaving Devices By Hand
|
||||
------------------------------
|
||||
|
||||
Enslaving devices by hand requires two utility programs: eql_enslave
|
||||
and eql_emancipate (-- eql_emancipate hasn't been written because when
|
||||
|
@ -140,87 +131,56 @@
|
|||
|
||||
|
||||
The syntax for enslaving a device is "eql_enslave <master-name>
|
||||
<slave-name> <estimated-bps>". Here are some example enslavings:
|
||||
<slave-name> <estimated-bps>". Here are some example enslavings::
|
||||
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
eql_enslave eql sl0 28800
|
||||
eql_enslave eql ppp0 14400
|
||||
eql_enslave eql sl1 57600
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
When you want to free a device from its life of slavery, you can
|
||||
either down the device with ifconfig (eql will automatically bury the
|
||||
dead slave and remove it from its queue) or use eql_emancipate to free
|
||||
it. (-- Or just ifconfig it down, and the eql driver will take it out
|
||||
for you.--)
|
||||
for you.--)::
|
||||
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
eql_emancipate eql sl0
|
||||
eql_emancipate eql ppp0
|
||||
eql_emancipate eql sl1
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3.3. DSLIP Configuration for the eql Device
|
||||
3.3. DSLIP Configuration for the eql Device
|
||||
-------------------------------------------
|
||||
|
||||
The general idea is to bring up and keep up as many SLIP connections
|
||||
as you need, automatically.
|
||||
|
||||
|
||||
3.3.1. /etc/slip/runslip.conf
|
||||
3.3.1. /etc/slip/runslip.conf
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Here is an example runslip.conf:
|
||||
Here is an example runslip.conf::
|
||||
|
||||
name sl-line-1
|
||||
enabled
|
||||
baud 38400
|
||||
mtu 576
|
||||
ducmd -e /etc/slip/dialout/cua2-288.xp -t 9
|
||||
command eql_enslave eql $interface 28800
|
||||
address 198.67.33.239
|
||||
line /dev/cua2
|
||||
|
||||
name sl-line-2
|
||||
enabled
|
||||
baud 38400
|
||||
mtu 576
|
||||
ducmd -e /etc/slip/dialout/cua3-288.xp -t 9
|
||||
command eql_enslave eql $interface 28800
|
||||
address 198.67.33.239
|
||||
line /dev/cua3
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
______________________________________________________________________
|
||||
name sl-line-1
|
||||
enabled
|
||||
baud 38400
|
||||
mtu 576
|
||||
ducmd -e /etc/slip/dialout/cua2-288.xp -t 9
|
||||
command eql_enslave eql $interface 28800
|
||||
address 198.67.33.239
|
||||
line /dev/cua2
|
||||
|
||||
name sl-line-2
|
||||
enabled
|
||||
baud 38400
|
||||
mtu 576
|
||||
ducmd -e /etc/slip/dialout/cua3-288.xp -t 9
|
||||
command eql_enslave eql $interface 28800
|
||||
address 198.67.33.239
|
||||
line /dev/cua3
|
||||
______________________________________________________________________
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
3.4. Using PPP and the eql Device
|
||||
3.4. Using PPP and the eql Device
|
||||
---------------------------------
|
||||
|
||||
I have not yet done any load-balancing testing for PPP devices, mainly
|
||||
because I don't have a PPP-connection manager like SLIP has with
|
||||
|
@ -235,7 +195,8 @@
|
|||
year.
|
||||
|
||||
|
||||
4. About the Slave Scheduler Algorithm
|
||||
4. About the Slave Scheduler Algorithm
|
||||
======================================
|
||||
|
||||
The slave scheduler probably could be replaced with a dozen other
|
||||
things and push traffic much faster. The formula in the current set
|
||||
|
@ -254,7 +215,8 @@
|
|||
traffic and the "slower" modem starved.
|
||||
|
||||
|
||||
5. Testers' Reports
|
||||
5. Testers' Reports
|
||||
===================
|
||||
|
||||
Some people have experimented with the eql device with newer
|
||||
kernels (than 1.1.75). I have since updated the driver to patch
|
||||
|
@ -262,87 +224,29 @@
|
|||
balancing" driver config option.
|
||||
|
||||
|
||||
o icee from LinuxNET patched 1.1.86 without any rejects and was able
|
||||
- icee from LinuxNET patched 1.1.86 without any rejects and was able
|
||||
to boot the kernel and enslave a couple of ISDN PPP links.
|
||||
|
||||
5.1. Randolph Bentson's Test Report
|
||||
5.1. Randolph Bentson's Test Report
|
||||
-----------------------------------
|
||||
|
||||
::
|
||||
|
||||
From bentson@grieg.seaslug.org Wed Feb 8 19:08:09 1995
|
||||
Date: Tue, 7 Feb 95 22:57 PST
|
||||
From: Randolph Bentson <bentson@grieg.seaslug.org>
|
||||
To: guru@ncm.com
|
||||
Subject: EQL driver tests
|
||||
|
||||
|
||||
I have been checking out your eql driver. (Nice work, that!)
|
||||
Although you may already done this performance testing, here
|
||||
are some data I've discovered.
|
||||
|
||||
Randolph Bentson
|
||||
bentson@grieg.seaslug.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
From bentson@grieg.seaslug.org Wed Feb 8 19:08:09 1995
|
||||
Date: Tue, 7 Feb 95 22:57 PST
|
||||
From: Randolph Bentson <bentson@grieg.seaslug.org>
|
||||
To: guru@ncm.com
|
||||
Subject: EQL driver tests
|
||||
|
||||
|
||||
I have been checking out your eql driver. (Nice work, that!)
|
||||
Although you may already done this performance testing, here
|
||||
are some data I've discovered.
|
||||
|
||||
Randolph Bentson
|
||||
bentson@grieg.seaslug.org
|
||||
|
||||
---------------------------------------------------------
|
||||
------------------------------------------------------------------
|
||||
|
||||
|
||||
A pseudo-device driver, EQL, written by Simon Janes, can be used
|
||||
|
@ -363,7 +267,7 @@
|
|||
Once a link was established, I timed a binary ftp transfer of
|
||||
289284 bytes of data. If there were no overhead (packet headers,
|
||||
inter-character and inter-packet delays, etc.) the transfers
|
||||
would take the following times:
|
||||
would take the following times::
|
||||
|
||||
bits/sec seconds
|
||||
345600 8.3
|
||||
|
@ -388,141 +292,82 @@
|
|||
that the connection establishment seemed fragile for the higher
|
||||
speeds. Once established, the connection seemed robust enough.)
|
||||
|
||||
#lines speed mtu seconds theory actual %of
|
||||
kbit/sec duration speed speed max
|
||||
3 115200 900 _ 345600
|
||||
3 115200 400 18.1 345600 159825 46
|
||||
2 115200 900 _ 230400
|
||||
2 115200 600 18.1 230400 159825 69
|
||||
2 115200 400 19.3 230400 149888 65
|
||||
4 57600 900 _ 234600
|
||||
4 57600 600 _ 234600
|
||||
4 57600 400 _ 234600
|
||||
3 57600 600 20.9 172800 138413 80
|
||||
3 57600 900 21.2 172800 136455 78
|
||||
3 115200 600 21.7 345600 133311 38
|
||||
3 57600 400 22.5 172800 128571 74
|
||||
4 38400 900 25.2 153600 114795 74
|
||||
4 38400 600 26.4 153600 109577 71
|
||||
4 38400 400 27.3 153600 105965 68
|
||||
2 57600 900 29.1 115200 99410.3 86
|
||||
1 115200 900 30.7 115200 94229.3 81
|
||||
2 57600 600 30.2 115200 95789.4 83
|
||||
3 38400 900 30.3 115200 95473.3 82
|
||||
3 38400 600 31.2 115200 92719.2 80
|
||||
1 115200 600 31.3 115200 92423 80
|
||||
2 57600 400 32.3 115200 89561.6 77
|
||||
1 115200 400 32.8 115200 88196.3 76
|
||||
3 38400 400 33.5 115200 86353.4 74
|
||||
2 38400 900 43.7 76800 66197.7 86
|
||||
2 38400 600 44 76800 65746.4 85
|
||||
2 38400 400 47.2 76800 61289 79
|
||||
4 19200 900 50.8 76800 56945.7 74
|
||||
4 19200 400 53.2 76800 54376.7 70
|
||||
4 19200 600 53.7 76800 53870.4 70
|
||||
1 57600 900 54.6 57600 52982.4 91
|
||||
1 57600 600 56.2 57600 51474 89
|
||||
3 19200 900 60.5 57600 47815.5 83
|
||||
1 57600 400 60.2 57600 48053.8 83
|
||||
3 19200 600 62 57600 46658.7 81
|
||||
3 19200 400 64.7 57600 44711.6 77
|
||||
1 38400 900 79.4 38400 36433.8 94
|
||||
1 38400 600 82.4 38400 35107.3 91
|
||||
2 19200 900 84.4 38400 34275.4 89
|
||||
1 38400 400 86.8 38400 33327.6 86
|
||||
2 19200 600 87.6 38400 33023.3 85
|
||||
2 19200 400 91.2 38400 31719.7 82
|
||||
4 9600 900 94.7 38400 30547.4 79
|
||||
4 9600 400 106 38400 27290.9 71
|
||||
4 9600 600 110 38400 26298.5 68
|
||||
3 9600 900 118 28800 24515.6 85
|
||||
3 9600 600 120 28800 24107 83
|
||||
3 9600 400 131 28800 22082.7 76
|
||||
1 19200 900 155 19200 18663.5 97
|
||||
1 19200 600 161 19200 17968 93
|
||||
1 19200 400 170 19200 17016.7 88
|
||||
2 9600 600 176 19200 16436.6 85
|
||||
2 9600 900 180 19200 16071.3 83
|
||||
2 9600 400 181 19200 15982.5 83
|
||||
1 9600 900 305 9600 9484.72 98
|
||||
1 9600 600 314 9600 9212.87 95
|
||||
1 9600 400 332 9600 8713.37 90
|
||||
====== ======== === ======== ======= ======= ===
|
||||
#lines speed mtu seconds theory actual %of
|
||||
kbit/sec duration speed speed max
|
||||
====== ======== === ======== ======= ======= ===
|
||||
3 115200 900 _ 345600
|
||||
3 115200 400 18.1 345600 159825 46
|
||||
2 115200 900 _ 230400
|
||||
2 115200 600 18.1 230400 159825 69
|
||||
2 115200 400 19.3 230400 149888 65
|
||||
4 57600 900 _ 234600
|
||||
4 57600 600 _ 234600
|
||||
4 57600 400 _ 234600
|
||||
3 57600 600 20.9 172800 138413 80
|
||||
3 57600 900 21.2 172800 136455 78
|
||||
3 115200 600 21.7 345600 133311 38
|
||||
3 57600 400 22.5 172800 128571 74
|
||||
4 38400 900 25.2 153600 114795 74
|
||||
4 38400 600 26.4 153600 109577 71
|
||||
4 38400 400 27.3 153600 105965 68
|
||||
2 57600 900 29.1 115200 99410.3 86
|
||||
1 115200 900 30.7 115200 94229.3 81
|
||||
2 57600 600 30.2 115200 95789.4 83
|
||||
3 38400 900 30.3 115200 95473.3 82
|
||||
3 38400 600 31.2 115200 92719.2 80
|
||||
1 115200 600 31.3 115200 92423 80
|
||||
2 57600 400 32.3 115200 89561.6 77
|
||||
1 115200 400 32.8 115200 88196.3 76
|
||||
3 38400 400 33.5 115200 86353.4 74
|
||||
2 38400 900 43.7 76800 66197.7 86
|
||||
2 38400 600 44 76800 65746.4 85
|
||||
2 38400 400 47.2 76800 61289 79
|
||||
4 19200 900 50.8 76800 56945.7 74
|
||||
4 19200 400 53.2 76800 54376.7 70
|
||||
4 19200 600 53.7 76800 53870.4 70
|
||||
1 57600 900 54.6 57600 52982.4 91
|
||||
1 57600 600 56.2 57600 51474 89
|
||||
3 19200 900 60.5 57600 47815.5 83
|
||||
1 57600 400 60.2 57600 48053.8 83
|
||||
3 19200 600 62 57600 46658.7 81
|
||||
3 19200 400 64.7 57600 44711.6 77
|
||||
1 38400 900 79.4 38400 36433.8 94
|
||||
1 38400 600 82.4 38400 35107.3 91
|
||||
2 19200 900 84.4 38400 34275.4 89
|
||||
1 38400 400 86.8 38400 33327.6 86
|
||||
2 19200 600 87.6 38400 33023.3 85
|
||||
2 19200 400 91.2 38400 31719.7 82
|
||||
4 9600 900 94.7 38400 30547.4 79
|
||||
4 9600 400 106 38400 27290.9 71
|
||||
4 9600 600 110 38400 26298.5 68
|
||||
3 9600 900 118 28800 24515.6 85
|
||||
3 9600 600 120 28800 24107 83
|
||||
3 9600 400 131 28800 22082.7 76
|
||||
1 19200 900 155 19200 18663.5 97
|
||||
1 19200 600 161 19200 17968 93
|
||||
1 19200 400 170 19200 17016.7 88
|
||||
2 9600 600 176 19200 16436.6 85
|
||||
2 9600 900 180 19200 16071.3 83
|
||||
2 9600 400 181 19200 15982.5 83
|
||||
1 9600 900 305 9600 9484.72 98
|
||||
1 9600 600 314 9600 9212.87 95
|
||||
1 9600 400 332 9600 8713.37 90
|
||||
====== ======== === ======== ======= ======= ===
|
||||
|
||||
5.2. Anthony Healy's Report
|
||||
---------------------------
|
||||
|
||||
::
|
||||
|
||||
Date: Mon, 13 Feb 1995 16:17:29 +1100 (EST)
|
||||
From: Antony Healey <ahealey@st.nepean.uws.edu.au>
|
||||
To: Simon Janes <guru@ncm.com>
|
||||
Subject: Re: Load Balancing
|
||||
|
||||
|
||||
5.2. Anthony Healy's Report
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Date: Mon, 13 Feb 1995 16:17:29 +1100 (EST)
|
||||
From: Antony Healey <ahealey@st.nepean.uws.edu.au>
|
||||
To: Simon Janes <guru@ncm.com>
|
||||
Subject: Re: Load Balancing
|
||||
|
||||
Hi Simon,
|
||||
Hi Simon,
|
||||
I've installed your patch and it works great. I have trialed
|
||||
it over twin SL/IP lines, just over null modems, but I was
|
||||
able to data at over 48Kb/s [ISDN link -Simon]. I managed a
|
||||
transfer of up to 7.5 Kbyte/s on one go, but averaged around
|
||||
6.4 Kbyte/s, which I think is pretty cool. :)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,8 +1,12 @@
|
|||
LC-trie implementation notes.
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
============================
|
||||
LC-trie implementation notes
|
||||
============================
|
||||
|
||||
Node types
|
||||
----------
|
||||
leaf
|
||||
leaf
|
||||
An end node with data. This has a copy of the relevant key, along
|
||||
with 'hlist' with routing table entries sorted by prefix length.
|
||||
See struct leaf and struct leaf_info.
|
||||
|
@ -13,7 +17,7 @@ trie node or tnode
|
|||
|
||||
A few concepts explained
|
||||
------------------------
|
||||
Bits (tnode)
|
||||
Bits (tnode)
|
||||
The number of bits in the key segment used for indexing into the
|
||||
child array - the "child index". See Level Compression.
|
||||
|
||||
|
@ -23,7 +27,7 @@ Pos (tnode)
|
|||
|
||||
Path Compression / skipped bits
|
||||
Any given tnode is linked to from the child array of its parent, using
|
||||
a segment of the key specified by the parent's "pos" and "bits"
|
||||
a segment of the key specified by the parent's "pos" and "bits"
|
||||
In certain cases, this tnode's own "pos" will not be immediately
|
||||
adjacent to the parent (pos+bits), but there will be some bits
|
||||
in the key skipped over because they represent a single path with no
|
||||
|
@ -56,8 +60,8 @@ full_children
|
|||
Comments
|
||||
---------
|
||||
|
||||
We have tried to keep the structure of the code as close to fib_hash as
|
||||
possible to allow verification and help up reviewing.
|
||||
We have tried to keep the structure of the code as close to fib_hash as
|
||||
possible to allow verification and help up reviewing.
|
||||
|
||||
fib_find_node()
|
||||
A good start for understanding this code. This function implements a
|
File diff suppressed because it is too large
Load diff
|
@ -1,6 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=============================================
|
||||
FORE Systems PCA-200E/SBA-200E ATM NIC driver
|
||||
---------------------------------------------
|
||||
=============================================
|
||||
|
||||
This driver adds support for the FORE Systems 200E-series ATM adapters
|
||||
to the Linux operating system. It is based on the earlier PCA-200E driver
|
||||
|
@ -27,8 +29,8 @@ in the linux/drivers/atm directory for details and restrictions.
|
|||
Firmware Updates
|
||||
----------------
|
||||
|
||||
The FORE Systems 200E-series driver is shipped with firmware data being
|
||||
uploaded to the ATM adapters at system boot time or at module loading time.
|
||||
The FORE Systems 200E-series driver is shipped with firmware data being
|
||||
uploaded to the ATM adapters at system boot time or at module loading time.
|
||||
The supplied firmware images should work with all adapters.
|
||||
|
||||
However, if you encounter problems (the firmware doesn't start or the driver
|
|
@ -1,4 +1,10 @@
|
|||
Frame Relay (FR) support for linux is built into a two tiered system of device
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
================
|
||||
Frame Relay (FR)
|
||||
================
|
||||
|
||||
Frame Relay (FR) support for linux is built into a two tiered system of device
|
||||
drivers. The upper layer implements RFC1490 FR specification, and uses the
|
||||
Data Link Connection Identifier (DLCI) as its hardware address. Usually these
|
||||
are assigned by your network supplier, they give you the number/numbers of
|
||||
|
@ -7,18 +13,18 @@ the Virtual Connections (VC) assigned to you.
|
|||
Each DLCI is a point-to-point link between your machine and a remote one.
|
||||
As such, a separate device is needed to accommodate the routing. Within the
|
||||
net-tools archives is 'dlcicfg'. This program will communicate with the
|
||||
base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'...
|
||||
base "DLCI" device, and create new net devices named 'dlci00', 'dlci01'...
|
||||
The configuration script will ask you how many DLCIs you need, as well as
|
||||
how many DLCIs you want to assign to each Frame Relay Access Device (FRAD).
|
||||
|
||||
The DLCI uses a number of function calls to communicate with the FRAD, all
|
||||
of which are stored in the FRAD's private data area. assoc/deassoc,
|
||||
of which are stored in the FRAD's private data area. assoc/deassoc,
|
||||
activate/deactivate and dlci_config. The DLCI supplies a receive function
|
||||
to the FRAD to accept incoming packets.
|
||||
|
||||
With this initial offering, only 1 FRAD driver is available. With many thanks
|
||||
to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E &
|
||||
S508 are supported. This driver is currently set up for only FR, but as
|
||||
to Sangoma Technologies, David Mandelstam & Gene Kozin, the S502A, S502E &
|
||||
S508 are supported. This driver is currently set up for only FR, but as
|
||||
Sangoma makes more firmware modules available, it can be updated to provide
|
||||
them as well.
|
||||
|
||||
|
@ -32,8 +38,7 @@ an initial configuration.
|
|||
Additional FRAD device drivers can be added as hardware is available.
|
||||
|
||||
At this time, the dlcicfg and fradcfg programs have not been incorporated into
|
||||
the net-tools distribution. They can be found at ftp.invlogic.com, in
|
||||
the net-tools distribution. They can be found at ftp.invlogic.com, in
|
||||
/pub/linux. Note that with OS/2 FTPD, you end up in /pub by default, so just
|
||||
use 'cd linux'. v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for
|
||||
use 'cd linux'. v0.10 is for use on pre-2.0.3 and earlier, v0.15 is for
|
||||
pre-2.0.4 and later.
|
||||
|
|
@ -1,67 +1,76 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===============================================
|
||||
Generic networking statistics for netlink users
|
||||
======================================================================
|
||||
===============================================
|
||||
|
||||
Statistic counters are grouped into structs:
|
||||
|
||||
==================== ===================== =====================
|
||||
Struct TLV type Description
|
||||
----------------------------------------------------------------------
|
||||
==================== ===================== =====================
|
||||
gnet_stats_basic TCA_STATS_BASIC Basic statistics
|
||||
gnet_stats_rate_est TCA_STATS_RATE_EST Rate estimator
|
||||
gnet_stats_queue TCA_STATS_QUEUE Queue statistics
|
||||
none TCA_STATS_APP Application specific
|
||||
==================== ===================== =====================
|
||||
|
||||
|
||||
Collecting:
|
||||
-----------
|
||||
|
||||
Declare the statistic structs you need:
|
||||
struct mystruct {
|
||||
struct gnet_stats_basic bstats;
|
||||
struct gnet_stats_queue qstats;
|
||||
...
|
||||
};
|
||||
Declare the statistic structs you need::
|
||||
|
||||
Update statistics, in dequeue() methods only, (while owning qdisc->running)
|
||||
mystruct->tstats.packet++;
|
||||
mystruct->qstats.backlog += skb->pkt_len;
|
||||
struct mystruct {
|
||||
struct gnet_stats_basic bstats;
|
||||
struct gnet_stats_queue qstats;
|
||||
...
|
||||
};
|
||||
|
||||
Update statistics, in dequeue() methods only, (while owning qdisc->running)::
|
||||
|
||||
mystruct->tstats.packet++;
|
||||
mystruct->qstats.backlog += skb->pkt_len;
|
||||
|
||||
|
||||
Export to userspace (Dump):
|
||||
---------------------------
|
||||
|
||||
my_dumping_routine(struct sk_buff *skb, ...)
|
||||
{
|
||||
struct gnet_dump dump;
|
||||
::
|
||||
|
||||
if (gnet_stats_start_copy(skb, TCA_STATS2, &mystruct->lock, &dump,
|
||||
TCA_PAD) < 0)
|
||||
goto rtattr_failure;
|
||||
my_dumping_routine(struct sk_buff *skb, ...)
|
||||
{
|
||||
struct gnet_dump dump;
|
||||
|
||||
if (gnet_stats_copy_basic(&dump, &mystruct->bstats) < 0 ||
|
||||
gnet_stats_copy_queue(&dump, &mystruct->qstats) < 0 ||
|
||||
gnet_stats_copy_app(&dump, &xstats, sizeof(xstats)) < 0)
|
||||
goto rtattr_failure;
|
||||
if (gnet_stats_start_copy(skb, TCA_STATS2, &mystruct->lock, &dump,
|
||||
TCA_PAD) < 0)
|
||||
goto rtattr_failure;
|
||||
|
||||
if (gnet_stats_finish_copy(&dump) < 0)
|
||||
goto rtattr_failure;
|
||||
...
|
||||
}
|
||||
if (gnet_stats_copy_basic(&dump, &mystruct->bstats) < 0 ||
|
||||
gnet_stats_copy_queue(&dump, &mystruct->qstats) < 0 ||
|
||||
gnet_stats_copy_app(&dump, &xstats, sizeof(xstats)) < 0)
|
||||
goto rtattr_failure;
|
||||
|
||||
if (gnet_stats_finish_copy(&dump) < 0)
|
||||
goto rtattr_failure;
|
||||
...
|
||||
}
|
||||
|
||||
TCA_STATS/TCA_XSTATS backward compatibility:
|
||||
--------------------------------------------
|
||||
|
||||
Prior users of struct tc_stats and xstats can maintain backward
|
||||
compatibility by calling the compat wrappers to keep providing the
|
||||
existing TLV types.
|
||||
existing TLV types::
|
||||
|
||||
my_dumping_routine(struct sk_buff *skb, ...)
|
||||
{
|
||||
if (gnet_stats_start_copy_compat(skb, TCA_STATS2, TCA_STATS,
|
||||
TCA_XSTATS, &mystruct->lock, &dump,
|
||||
TCA_PAD) < 0)
|
||||
goto rtattr_failure;
|
||||
...
|
||||
}
|
||||
my_dumping_routine(struct sk_buff *skb, ...)
|
||||
{
|
||||
if (gnet_stats_start_copy_compat(skb, TCA_STATS2, TCA_STATS,
|
||||
TCA_XSTATS, &mystruct->lock, &dump,
|
||||
TCA_PAD) < 0)
|
||||
goto rtattr_failure;
|
||||
...
|
||||
}
|
||||
|
||||
A struct tc_stats will be filled out during gnet_stats_copy_* calls
|
||||
and appended to the skb. TCA_XSTATS is provided if gnet_stats_copy_app
|
||||
|
@ -77,7 +86,7 @@ are responsible for making sure that the lock is initialized.
|
|||
|
||||
|
||||
Rate Estimator:
|
||||
--------------
|
||||
---------------
|
||||
|
||||
0) Prepare an estimator attribute. Most likely this would be in user
|
||||
space. The value of this TLV should contain a tc_estimator structure.
|
||||
|
@ -92,18 +101,19 @@ Rate Estimator:
|
|||
TCA_RATE to your code in the kernel.
|
||||
|
||||
In the kernel when setting up:
|
||||
|
||||
1) make sure you have basic stats and rate stats setup first.
|
||||
2) make sure you have initialized stats lock that is used to setup such
|
||||
stats.
|
||||
3) Now initialize a new estimator:
|
||||
3) Now initialize a new estimator::
|
||||
|
||||
int ret = gen_new_estimator(my_basicstats,my_rate_est_stats,
|
||||
mystats_lock, attr_with_tcestimator_struct);
|
||||
int ret = gen_new_estimator(my_basicstats,my_rate_est_stats,
|
||||
mystats_lock, attr_with_tcestimator_struct);
|
||||
|
||||
if ret == 0
|
||||
success
|
||||
else
|
||||
failed
|
||||
if ret == 0
|
||||
success
|
||||
else
|
||||
failed
|
||||
|
||||
From now on, every time you dump my_rate_est_stats it will contain
|
||||
up-to-date info.
|
||||
|
@ -115,5 +125,5 @@ are still valid (i.e still exist) at the time of making this call.
|
|||
|
||||
Authors:
|
||||
--------
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Jamal Hadi Salim <hadi@cyberus.ca>
|
||||
- Thomas Graf <tgraf@suug.ch>
|
||||
- Jamal Hadi Salim <hadi@cyberus.ca>
|
|
@ -1,14 +1,22 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==================
|
||||
Generic HDLC layer
|
||||
==================
|
||||
|
||||
Krzysztof Halasa <khc@pm.waw.pl>
|
||||
|
||||
|
||||
Generic HDLC layer currently supports:
|
||||
|
||||
1. Frame Relay (ANSI, CCITT, Cisco and no LMI)
|
||||
|
||||
- Normal (routed) and Ethernet-bridged (Ethernet device emulation)
|
||||
interfaces can share a single PVC.
|
||||
- ARP support (no InARP support in the kernel - there is an
|
||||
experimental InARP user-space daemon available on:
|
||||
http://www.kernel.org/pub/linux/utils/net/hdlc/).
|
||||
|
||||
2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation
|
||||
3. Cisco HDLC
|
||||
4. PPP
|
||||
|
@ -24,19 +32,24 @@ with IEEE 802.1Q (VLANs) and 802.1D (Ethernet bridging).
|
|||
Make sure the hdlc.o and the hardware driver are loaded. It should
|
||||
create a number of "hdlc" (hdlc0 etc) network devices, one for each
|
||||
WAN port. You'll need the "sethdlc" utility, get it from:
|
||||
|
||||
http://www.kernel.org/pub/linux/utils/net/hdlc/
|
||||
|
||||
Compile sethdlc.c utility:
|
||||
Compile sethdlc.c utility::
|
||||
|
||||
gcc -O2 -Wall -o sethdlc sethdlc.c
|
||||
|
||||
Make sure you're using a correct version of sethdlc for your kernel.
|
||||
|
||||
Use sethdlc to set physical interface, clock rate, HDLC mode used,
|
||||
and add any required PVCs if using Frame Relay.
|
||||
Usually you want something like:
|
||||
Usually you want something like::
|
||||
|
||||
sethdlc hdlc0 clock int rate 128000
|
||||
sethdlc hdlc0 cisco interval 10 timeout 25
|
||||
or
|
||||
|
||||
or::
|
||||
|
||||
sethdlc hdlc0 rs232 clock ext
|
||||
sethdlc hdlc0 fr lmi ansi
|
||||
sethdlc hdlc0 create 99
|
||||
|
@ -49,46 +62,63 @@ any IP address to it) before using pvc devices.
|
|||
|
||||
Setting interface:
|
||||
|
||||
* v35 | rs232 | x21 | t1 | e1 - sets physical interface for a given port
|
||||
if the card has software-selectable interfaces
|
||||
loopback - activate hardware loopback (for testing only)
|
||||
* clock ext - both RX clock and TX clock external
|
||||
* clock int - both RX clock and TX clock internal
|
||||
* clock txint - RX clock external, TX clock internal
|
||||
* clock txfromrx - RX clock external, TX clock derived from RX clock
|
||||
* rate - sets clock rate in bps (for "int" or "txint" clock only)
|
||||
* v35 | rs232 | x21 | t1 | e1
|
||||
- sets physical interface for a given port
|
||||
if the card has software-selectable interfaces
|
||||
loopback
|
||||
- activate hardware loopback (for testing only)
|
||||
* clock ext
|
||||
- both RX clock and TX clock external
|
||||
* clock int
|
||||
- both RX clock and TX clock internal
|
||||
* clock txint
|
||||
- RX clock external, TX clock internal
|
||||
* clock txfromrx
|
||||
- RX clock external, TX clock derived from RX clock
|
||||
* rate
|
||||
- sets clock rate in bps (for "int" or "txint" clock only)
|
||||
|
||||
|
||||
Setting protocol:
|
||||
|
||||
* hdlc - sets raw HDLC (IP-only) mode
|
||||
|
||||
nrz / nrzi / fm-mark / fm-space / manchester - sets transmission code
|
||||
|
||||
no-parity / crc16 / crc16-pr0 (CRC16 with preset zeros) / crc32-itu
|
||||
|
||||
crc16-itu (CRC16 with ITU-T polynomial) / crc16-itu-pr0 - sets parity
|
||||
|
||||
* hdlc-eth - Ethernet device emulation using HDLC. Parity and encoding
|
||||
as above.
|
||||
|
||||
* cisco - sets Cisco HDLC mode (IP, IPv6 and IPX supported)
|
||||
|
||||
interval - time in seconds between keepalive packets
|
||||
|
||||
timeout - time in seconds after last received keepalive packet before
|
||||
we assume the link is down
|
||||
we assume the link is down
|
||||
|
||||
* ppp - sets synchronous PPP mode
|
||||
|
||||
* x25 - sets X.25 mode
|
||||
|
||||
* fr - Frame Relay mode
|
||||
|
||||
lmi ansi / ccitt / cisco / none - LMI (link management) type
|
||||
|
||||
dce - Frame Relay DCE (network) side LMI instead of default DTE (user).
|
||||
|
||||
It has nothing to do with clocks!
|
||||
t391 - link integrity verification polling timer (in seconds) - user
|
||||
t392 - polling verification timer (in seconds) - network
|
||||
n391 - full status polling counter - user
|
||||
n392 - error threshold - both user and network
|
||||
n393 - monitored events count - both user and network
|
||||
|
||||
- t391 - link integrity verification polling timer (in seconds) - user
|
||||
- t392 - polling verification timer (in seconds) - network
|
||||
- n391 - full status polling counter - user
|
||||
- n392 - error threshold - both user and network
|
||||
- n393 - monitored events count - both user and network
|
||||
|
||||
Frame-Relay only:
|
||||
|
||||
* create n | delete n - adds / deletes PVC interface with DLCI #n.
|
||||
Newly created interface will be named pvc0, pvc1 etc.
|
||||
|
||||
|
@ -101,26 +131,34 @@ Frame-Relay only:
|
|||
Board-specific issues
|
||||
---------------------
|
||||
|
||||
n2.o and c101.o need parameters to work:
|
||||
n2.o and c101.o need parameters to work::
|
||||
|
||||
insmod n2 hw=io,irq,ram,ports[:io,irq,...]
|
||||
example:
|
||||
|
||||
example::
|
||||
|
||||
insmod n2 hw=0x300,10,0xD0000,01
|
||||
|
||||
or
|
||||
or::
|
||||
|
||||
insmod c101 hw=irq,ram[:irq,...]
|
||||
example:
|
||||
|
||||
example::
|
||||
|
||||
insmod c101 hw=9,0xdc000
|
||||
|
||||
If built into the kernel, these drivers need kernel (command line) parameters:
|
||||
If built into the kernel, these drivers need kernel (command line) parameters::
|
||||
|
||||
n2.hw=io,irq,ram,ports:...
|
||||
or
|
||||
|
||||
or::
|
||||
|
||||
c101.hw=irq,ram:...
|
||||
|
||||
|
||||
|
||||
If you have a problem with N2, C101 or PLX200SYN card, you can issue the
|
||||
"private" command to see port's packet descriptor rings (in kernel logs):
|
||||
"private" command to see port's packet descriptor rings (in kernel logs)::
|
||||
|
||||
sethdlc hdlc0 private
|
||||
|
|
@ -1,3 +1,9 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===============
|
||||
Generic Netlink
|
||||
===============
|
||||
|
||||
A wiki document on how to use Generic Netlink can be found here:
|
||||
|
||||
* http://www.linuxfoundation.org/collaborate/workgroups/networking/generic_netlink_howto
|
|
@ -1,12 +1,18 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====================================
|
||||
The Linux kernel GTP tunneling module
|
||||
======================================================================
|
||||
Documentation by Harald Welte <laforge@gnumonks.org> and
|
||||
Andreas Schultz <aschultz@tpip.net>
|
||||
=====================================
|
||||
|
||||
Documentation by
|
||||
Harald Welte <laforge@gnumonks.org> and
|
||||
Andreas Schultz <aschultz@tpip.net>
|
||||
|
||||
In 'drivers/net/gtp.c' you are finding a kernel-level implementation
|
||||
of a GTP tunnel endpoint.
|
||||
|
||||
== What is GTP ==
|
||||
What is GTP
|
||||
===========
|
||||
|
||||
GTP is the Generic Tunnel Protocol, which is a 3GPP protocol used for
|
||||
tunneling User-IP payload between a mobile station (phone, modem)
|
||||
|
@ -41,7 +47,8 @@ publicly via the 3GPP website at http://www.3gpp.org/DynaReport/29060.htm
|
|||
A direct PDF link to v13.6.0 is provided for convenience below:
|
||||
http://www.etsi.org/deliver/etsi_ts/129000_129099/129060/13.06.00_60/ts_129060v130600p.pdf
|
||||
|
||||
== The Linux GTP tunnelling module ==
|
||||
The Linux GTP tunnelling module
|
||||
===============================
|
||||
|
||||
The module implements the function of a tunnel endpoint, i.e. it is
|
||||
able to decapsulate tunneled IP packets in the uplink originated by
|
||||
|
@ -70,7 +77,8 @@ Userspace :)
|
|||
The official homepage of the module is at
|
||||
https://osmocom.org/projects/linux-kernel-gtp-u/wiki
|
||||
|
||||
== Userspace Programs with Linux Kernel GTP-U support ==
|
||||
Userspace Programs with Linux Kernel GTP-U support
|
||||
==================================================
|
||||
|
||||
At the time of this writing, there are at least two Free Software
|
||||
implementations that implement GTP-C and can use the netlink interface
|
||||
|
@ -82,7 +90,8 @@ to make use of the Linux kernel GTP-U support:
|
|||
* ergw (GGSN + P-GW in Erlang):
|
||||
https://github.com/travelping/ergw
|
||||
|
||||
== Userspace Library / Command Line Utilities ==
|
||||
Userspace Library / Command Line Utilities
|
||||
==========================================
|
||||
|
||||
There is a userspace library called 'libgtpnl' which is based on
|
||||
libmnl and which implements a C-language API towards the netlink
|
||||
|
@ -90,7 +99,8 @@ interface provided by the Kernel GTP module:
|
|||
|
||||
http://git.osmocom.org/libgtpnl/
|
||||
|
||||
== Protocol Versions ==
|
||||
Protocol Versions
|
||||
=================
|
||||
|
||||
There are two different versions of GTP-U: v0 [GSM TS 09.60] and v1
|
||||
[3GPP TS 29.281]. Both are implemented in the Kernel GTP module.
|
||||
|
@ -105,7 +115,8 @@ doesn't implement GTP-C, we don't have to worry about this. It's the
|
|||
responsibility of the control plane implementation in userspace to
|
||||
implement that.
|
||||
|
||||
== IPv6 ==
|
||||
IPv6
|
||||
====
|
||||
|
||||
The 3GPP specifications indicate either IPv4 or IPv6 can be used both
|
||||
on the inner (user) IP layer, or on the outer (transport) layer.
|
||||
|
@ -114,22 +125,25 @@ Unfortunately, the Kernel module currently supports IPv6 neither for
|
|||
the User IP payload, nor for the outer IP layer. Patches or other
|
||||
Contributions to fix this are most welcome!
|
||||
|
||||
== Mailing List ==
|
||||
Mailing List
|
||||
============
|
||||
|
||||
If yo have questions regarding how to use the Kernel GTP module from
|
||||
If you have questions regarding how to use the Kernel GTP module from
|
||||
your own software, or want to contribute to the code, please use the
|
||||
osmocom-net-grps mailing list for related discussion. The list can be
|
||||
reached at osmocom-net-gprs@lists.osmocom.org and the mailman
|
||||
interface for managing your subscription is at
|
||||
https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs
|
||||
|
||||
== Issue Tracker ==
|
||||
Issue Tracker
|
||||
=============
|
||||
|
||||
The Osmocom project maintains an issue tracker for the Kernel GTP-U
|
||||
module at
|
||||
https://osmocom.org/projects/linux-kernel-gtp-u/issues
|
||||
|
||||
== History / Acknowledgements ==
|
||||
History / Acknowledgements
|
||||
==========================
|
||||
|
||||
The Module was originally created in 2012 by Harald Welte, but never
|
||||
completed. Pablo came in to finish the mess Harald left behind. But
|
||||
|
@ -139,9 +153,11 @@ In 2015, Andreas Schultz came to the rescue and fixed lots more bugs,
|
|||
extended it with new features and finally pushed all of us to get it
|
||||
mainline, where it was merged in 4.7.0.
|
||||
|
||||
== Architectural Details ==
|
||||
Architectural Details
|
||||
=====================
|
||||
|
||||
=== Local GTP-U entity and tunnel identification ===
|
||||
Local GTP-U entity and tunnel identification
|
||||
--------------------------------------------
|
||||
|
||||
GTP-U uses UDP for transporting PDU's. The receiving UDP port is 2152
|
||||
for GTPv1-U and 3386 for GTPv0-U.
|
||||
|
@ -164,15 +180,15 @@ Therefore:
|
|||
destination IP and the tunnel endpoint id. The source IP and port
|
||||
have no meaning and can change at any time.
|
||||
|
||||
[3GPP TS 29.281] Section 4.3.0 defines this so:
|
||||
[3GPP TS 29.281] Section 4.3.0 defines this so::
|
||||
|
||||
> The TEID in the GTP-U header is used to de-multiplex traffic
|
||||
> incoming from remote tunnel endpoints so that it is delivered to the
|
||||
> User plane entities in a way that allows multiplexing of different
|
||||
> users, different packet protocols and different QoS levels.
|
||||
> Therefore no two remote GTP-U endpoints shall send traffic to a
|
||||
> GTP-U protocol entity using the same TEID value except
|
||||
> for data forwarding as part of mobility procedures.
|
||||
The TEID in the GTP-U header is used to de-multiplex traffic
|
||||
incoming from remote tunnel endpoints so that it is delivered to the
|
||||
User plane entities in a way that allows multiplexing of different
|
||||
users, different packet protocols and different QoS levels.
|
||||
Therefore no two remote GTP-U endpoints shall send traffic to a
|
||||
GTP-U protocol entity using the same TEID value except
|
||||
for data forwarding as part of mobility procedures.
|
||||
|
||||
The definition above only defines that two remote GTP-U endpoints
|
||||
*should not* send to the same TEID, it *does not* forbid or exclude
|
||||
|
@ -183,7 +199,8 @@ multiple or unknown peers.
|
|||
Therefore, the receiving side identifies tunnels exclusively based on
|
||||
TEIDs, not based on the source IP!
|
||||
|
||||
== APN vs. Network Device ==
|
||||
APN vs. Network Device
|
||||
======================
|
||||
|
||||
The GTP-U driver creates a Linux network device for each Gi/SGi
|
||||
interface.
|
||||
|
@ -201,29 +218,33 @@ number of Gi/SGi interfaces implemented by a GGSN/P-GW.
|
|||
|
||||
[3GPP TS 29.061] Section 11.3 makes it clear that the selection of a
|
||||
specific Gi/SGi interfaces is made through the Access Point Name
|
||||
(APN):
|
||||
(APN)::
|
||||
|
||||
> 2. each private network manages its own addressing. In general this
|
||||
> will result in different private networks having overlapping
|
||||
> address ranges. A logically separate connection (e.g. an IP in IP
|
||||
> tunnel or layer 2 virtual circuit) is used between the GGSN/P-GW
|
||||
> and each private network.
|
||||
>
|
||||
> In this case the IP address alone is not necessarily unique. The
|
||||
> pair of values, Access Point Name (APN) and IPv4 address and/or
|
||||
> IPv6 prefixes, is unique.
|
||||
2. each private network manages its own addressing. In general this
|
||||
will result in different private networks having overlapping
|
||||
address ranges. A logically separate connection (e.g. an IP in IP
|
||||
tunnel or layer 2 virtual circuit) is used between the GGSN/P-GW
|
||||
and each private network.
|
||||
|
||||
In this case the IP address alone is not necessarily unique. The
|
||||
pair of values, Access Point Name (APN) and IPv4 address and/or
|
||||
IPv6 prefixes, is unique.
|
||||
|
||||
In order to support the overlapping address range use case, each APN
|
||||
is mapped to a separate Gi/SGi interface (network device).
|
||||
|
||||
NOTE: The Access Point Name is purely a control plane (GTP-C) concept.
|
||||
At the GTP-U level, only Tunnel Endpoint Identifiers are present in
|
||||
GTP-U packets and network devices are known
|
||||
.. note::
|
||||
|
||||
The Access Point Name is purely a control plane (GTP-C) concept.
|
||||
At the GTP-U level, only Tunnel Endpoint Identifiers are present in
|
||||
GTP-U packets and network devices are known
|
||||
|
||||
Therefore for a given UE the mapping in IP to PDN network is:
|
||||
|
||||
* network device + MS IP -> Peer IP + Peer TEID,
|
||||
|
||||
and from PDN to IP network:
|
||||
|
||||
* local GTP-U IP + TEID -> network device
|
||||
|
||||
Furthermore, before a received T-PDU is injected into the network
|
|
@ -1,3 +1,6 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
============================================================
|
||||
Linux Kernel Driver for Huawei Intelligent NIC(HiNIC) family
|
||||
============================================================
|
||||
|
||||
|
@ -110,7 +113,7 @@ hinic_dev - de/constructs the Logical Tx and Rx Queues.
|
|||
(hinic_main.c, hinic_dev.h)
|
||||
|
||||
|
||||
Miscellaneous:
|
||||
Miscellaneous
|
||||
=============
|
||||
|
||||
Common functions that are used by HW and Logical Device.
|
|
@ -1,4 +1,8 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===================================
|
||||
Identifier Locator Addressing (ILA)
|
||||
===================================
|
||||
|
||||
|
||||
Introduction
|
||||
|
@ -26,11 +30,13 @@ The ILA protocol is described in Internet-Draft draft-herbert-intarea-ila.
|
|||
ILA terminology
|
||||
===============
|
||||
|
||||
- Identifier A number that identifies an addressable node in the network
|
||||
- Identifier
|
||||
A number that identifies an addressable node in the network
|
||||
independent of its location. ILA identifiers are sixty-four
|
||||
bit values.
|
||||
|
||||
- Locator A network prefix that routes to a physical host. Locators
|
||||
- Locator
|
||||
A network prefix that routes to a physical host. Locators
|
||||
provide the topological location of an addressed node. ILA
|
||||
locators are sixty-four bit prefixes.
|
||||
|
||||
|
@ -51,17 +57,20 @@ ILA terminology
|
|||
bits) and an identifier (low order sixty-four bits). ILA
|
||||
addresses are never visible to an application.
|
||||
|
||||
- ILA host An end host that is capable of performing ILA translations
|
||||
- ILA host
|
||||
An end host that is capable of performing ILA translations
|
||||
on transmit or receive.
|
||||
|
||||
- ILA router A network node that performs ILA translation and forwarding
|
||||
- ILA router
|
||||
A network node that performs ILA translation and forwarding
|
||||
of translated packets.
|
||||
|
||||
- ILA forwarding cache
|
||||
A type of ILA router that only maintains a working set
|
||||
cache of mappings.
|
||||
|
||||
- ILA node A network node capable of performing ILA translations. This
|
||||
- ILA node
|
||||
A network node capable of performing ILA translations. This
|
||||
can be an ILA router, ILA forwarding cache, or ILA host.
|
||||
|
||||
|
||||
|
@ -82,18 +91,18 @@ Configuration and datapath for these two points of deployment is somewhat
|
|||
different.
|
||||
|
||||
The diagram below illustrates the flow of packets through ILA as well
|
||||
as showing ILA hosts and routers.
|
||||
as showing ILA hosts and routers::
|
||||
|
||||
+--------+ +--------+
|
||||
| Host A +-+ +--->| Host B |
|
||||
| | | (2) ILA (') | |
|
||||
+--------+ | ...addressed.... ( ) +--------+
|
||||
V +---+--+ . packet . +---+--+ (_)
|
||||
V +---+--+ . packet . +---+--+ (_)
|
||||
(1) SIR | | ILA |----->-------->---->| ILA | | (3) SIR
|
||||
addressed +->|router| . . |router|->-+ addressed
|
||||
packet +---+--+ . IPv6 . +---+--+ packet
|
||||
/ . Network .
|
||||
/ . . +--+-++--------+
|
||||
/ . Network .
|
||||
/ . . +--+-++--------+
|
||||
+--------+ / . . |ILA || Host |
|
||||
| Host +--+ . .- -|host|| |
|
||||
| | . . +--+-++--------+
|
||||
|
@ -173,7 +182,7 @@ ILA address, never a SIR address.
|
|||
|
||||
In the simplest format the identifier types, C-bit, and checksum
|
||||
adjustment value are not present so an identifier is considered an
|
||||
unstructured sixty-four bit value.
|
||||
unstructured sixty-four bit value::
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Identifier |
|
||||
|
@ -184,7 +193,7 @@ unstructured sixty-four bit value.
|
|||
The checksum neutral adjustment may be configured to always be
|
||||
present using neutral-map-auto. In this case there is no C-bit, but the
|
||||
checksum adjustment is in the low order 16 bits. The identifier is
|
||||
still sixty-four bits.
|
||||
still sixty-four bits::
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Identifier |
|
||||
|
@ -193,7 +202,7 @@ still sixty-four bits.
|
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
The C-bit may used to explicitly indicate that checksum neutral
|
||||
mapping has been applied to an ILA address. The format is:
|
||||
mapping has been applied to an ILA address. The format is::
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| |C| Identifier |
|
||||
|
@ -204,7 +213,7 @@ mapping has been applied to an ILA address. The format is:
|
|||
The identifier type field may be present to indicate the identifier
|
||||
type. If it is not present then the type is inferred based on mapping
|
||||
configuration. The checksum neutral adjustment may automatically
|
||||
used with the identifier type as illustrated below.
|
||||
used with the identifier type as illustrated below::
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Type| Identifier |
|
||||
|
@ -213,7 +222,7 @@ used with the identifier type as illustrated below.
|
|||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
If the identifier type and the C-bit can be present simultaneously so
|
||||
the identifier format would be:
|
||||
the identifier format would be::
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Type|C| Identifier |
|
||||
|
@ -258,28 +267,30 @@ same meanings as described above.
|
|||
Some examples
|
||||
=============
|
||||
|
||||
# Configure an ILA route that uses checksum neutral mapping as well
|
||||
# as type field. Note that the type field is set in the SIR address
|
||||
# (the 2000 implies type is 1 which is LUID).
|
||||
ip route add 3333:0:0:1:2000:0:1:87/128 encap ila 2001:0:87:0 \
|
||||
csum-mode neutral-map ident-type use-format
|
||||
::
|
||||
|
||||
# Configure an ILA LWT route that uses auto checksum neutral mapping
|
||||
# (no C-bit) and configure identifier type to be LUID so that the
|
||||
# identifier type field will not be present.
|
||||
ip route add 3333:0:0:1:2000:0:2:87/128 encap ila 2001:0:87:1 \
|
||||
csum-mode neutral-map-auto ident-type luid
|
||||
# Configure an ILA route that uses checksum neutral mapping as well
|
||||
# as type field. Note that the type field is set in the SIR address
|
||||
# (the 2000 implies type is 1 which is LUID).
|
||||
ip route add 3333:0:0:1:2000:0:1:87/128 encap ila 2001:0:87:0 \
|
||||
csum-mode neutral-map ident-type use-format
|
||||
|
||||
ila_xlat configuration
|
||||
# Configure an ILA LWT route that uses auto checksum neutral mapping
|
||||
# (no C-bit) and configure identifier type to be LUID so that the
|
||||
# identifier type field will not be present.
|
||||
ip route add 3333:0:0:1:2000:0:2:87/128 encap ila 2001:0:87:1 \
|
||||
csum-mode neutral-map-auto ident-type luid
|
||||
|
||||
# Configure an ILA to SIR mapping that matches a locator and overwrites
|
||||
# it with a SIR address (3333:0:0:1 in this example). The C-bit and
|
||||
# identifier field are used.
|
||||
ip ila add loc_match 2001:0:119:0 loc 3333:0:0:1 \
|
||||
csum-mode neutral-map-auto ident-type use-format
|
||||
ila_xlat configuration
|
||||
|
||||
# Configure an ILA to SIR mapping where checksum neutral is automatically
|
||||
# set without the C-bit and the identifier type is configured to be LUID
|
||||
# so that the identifier type field is not present.
|
||||
ip ila add loc_match 2001:0:119:0 loc 3333:0:0:1 \
|
||||
csum-mode neutral-map-auto ident-type use-format
|
||||
# Configure an ILA to SIR mapping that matches a locator and overwrites
|
||||
# it with a SIR address (3333:0:0:1 in this example). The C-bit and
|
||||
# identifier field are used.
|
||||
ip ila add loc_match 2001:0:119:0 loc 3333:0:0:1 \
|
||||
csum-mode neutral-map-auto ident-type use-format
|
||||
|
||||
# Configure an ILA to SIR mapping where checksum neutral is automatically
|
||||
# set without the C-bit and the identifier type is configured to be LUID
|
||||
# so that the identifier type field is not present.
|
||||
ip ila add loc_match 2001:0:119:0 loc 3333:0:0:1 \
|
||||
csum-mode neutral-map-auto ident-type use-format
|
|
@ -15,6 +15,7 @@ Contents:
|
|||
device_drivers/index
|
||||
dsa/index
|
||||
devlink/index
|
||||
caif/index
|
||||
ethtool-netlink
|
||||
ieee802154
|
||||
j1939
|
||||
|
@ -36,6 +37,43 @@ Contents:
|
|||
tls-offload
|
||||
nfc
|
||||
6lowpan
|
||||
6pack
|
||||
altera_tse
|
||||
arcnet-hardware
|
||||
arcnet
|
||||
atm
|
||||
ax25
|
||||
baycom
|
||||
bonding
|
||||
cdc_mbim
|
||||
cops
|
||||
cxacru
|
||||
dccp
|
||||
dctcp
|
||||
decnet
|
||||
defza
|
||||
dns_resolver
|
||||
driver
|
||||
eql
|
||||
fib_trie
|
||||
filter
|
||||
fore200e
|
||||
framerelay
|
||||
generic-hdlc
|
||||
generic_netlink
|
||||
gen_stats
|
||||
gtp
|
||||
hinic
|
||||
ila
|
||||
ipddp
|
||||
ip_dynaddr
|
||||
iphase
|
||||
ipsec
|
||||
ip-sysctl
|
||||
ipv6
|
||||
ipvlan
|
||||
ipvs-sysctl
|
||||
kcm
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
|
|
File diff suppressed because it is too large
Load diff
|
@ -1,10 +1,15 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==================================
|
||||
IP dynamic address hack-port v0.03
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
==================================
|
||||
|
||||
This stuff allows diald ONESHOT connections to get established by
|
||||
dynamically changing packet source address (and socket's if local procs).
|
||||
It is implemented for TCP diald-box connections(1) and IP_MASQuerading(2).
|
||||
|
||||
If enabled[*] and forwarding interface has changed:
|
||||
If enabled\ [#]_ and forwarding interface has changed:
|
||||
|
||||
1) Socket (and packet) source address is rewritten ON RETRANSMISSIONS
|
||||
while in SYN_SENT state (diald-box processes).
|
||||
2) Out-bounded MASQueraded source address changes ON OUTPUT (when
|
||||
|
@ -12,18 +17,24 @@ If enabled[*] and forwarding interface has changed:
|
|||
received by the tunnel.
|
||||
|
||||
This is specially helpful for auto dialup links (diald), where the
|
||||
``actual'' outgoing address is unknown at the moment the link is
|
||||
``actual`` outgoing address is unknown at the moment the link is
|
||||
going up. So, the *same* (local AND masqueraded) connections requests that
|
||||
bring the link up will be able to get established.
|
||||
|
||||
[*] At boot, by default no address rewriting is attempted.
|
||||
To enable:
|
||||
.. [#] At boot, by default no address rewriting is attempted.
|
||||
|
||||
To enable::
|
||||
|
||||
# echo 1 > /proc/sys/net/ipv4/ip_dynaddr
|
||||
To enable verbose mode:
|
||||
# echo 2 > /proc/sys/net/ipv4/ip_dynaddr
|
||||
To disable (default)
|
||||
|
||||
To enable verbose mode::
|
||||
|
||||
# echo 2 > /proc/sys/net/ipv4/ip_dynaddr
|
||||
|
||||
To disable (default)::
|
||||
|
||||
# echo 0 > /proc/sys/net/ipv4/ip_dynaddr
|
||||
|
||||
Enjoy!
|
||||
|
||||
-- Juanjo <jjciarla@raiz.uncu.edu.ar>
|
||||
Juanjo <jjciarla@raiz.uncu.edu.ar>
|
|
@ -1,7 +1,12 @@
|
|||
Text file for ipddp.c:
|
||||
AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
This text file is written by Jay Schulist <jschlst@samba.org>
|
||||
=========================================================
|
||||
AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation
|
||||
=========================================================
|
||||
|
||||
Documentation ipddp.c
|
||||
|
||||
This file is written by Jay Schulist <jschlst@samba.org>
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
@ -21,7 +26,7 @@ kernel AppleTalk layer and drivers are available.
|
|||
Each mode requires its own user space software.
|
||||
|
||||
Compiling AppleTalk-IP Decapsulation/Encapsulation
|
||||
=================================================
|
||||
==================================================
|
||||
|
||||
AppleTalk-IP decapsulation needs to be compiled into your kernel. You
|
||||
will need to turn on AppleTalk-IP driver support. Then you will need to
|
|
@ -1,27 +1,35 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==================================
|
||||
ATM (i)Chip IA Linux Driver Source
|
||||
==================================
|
||||
|
||||
READ ME FISRT
|
||||
|
||||
READ ME FISRT
|
||||
ATM (i)Chip IA Linux Driver Source
|
||||
--------------------------------------------------------------------------------
|
||||
Read This Before You Begin!
|
||||
|
||||
Read This Before You Begin!
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
Description
|
||||
-----------
|
||||
===========
|
||||
|
||||
This is the README file for the Interphase PCI ATM (i)Chip IA Linux driver
|
||||
This is the README file for the Interphase PCI ATM (i)Chip IA Linux driver
|
||||
source release.
|
||||
|
||||
The features and limitations of this driver are as follows:
|
||||
|
||||
- A single VPI (VPI value of 0) is supported.
|
||||
- Supports 4K VCs for the server board (with 512K control memory) and 1K
|
||||
- Supports 4K VCs for the server board (with 512K control memory) and 1K
|
||||
VCs for the client board (with 128K control memory).
|
||||
- UBR, ABR and CBR service categories are supported.
|
||||
- Only AAL5 is supported.
|
||||
- Supports setting of PCR on the VCs.
|
||||
- Only AAL5 is supported.
|
||||
- Supports setting of PCR on the VCs.
|
||||
- Multiple adapters in a system are supported.
|
||||
- All variants of Interphase ATM PCI (i)Chip adapter cards are supported,
|
||||
including x575 (OC3, control memory 128K , 512K and packet memory 128K,
|
||||
512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See
|
||||
- All variants of Interphase ATM PCI (i)Chip adapter cards are supported,
|
||||
including x575 (OC3, control memory 128K , 512K and packet memory 128K,
|
||||
512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See
|
||||
http://www.iphase.com/
|
||||
for details.
|
||||
- Only x86 platforms are supported.
|
||||
|
@ -29,128 +37,155 @@ The features and limitations of this driver are as follows:
|
|||
|
||||
|
||||
Before You Start
|
||||
----------------
|
||||
================
|
||||
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
1. Installing the adapters in the system
|
||||
|
||||
To install the ATM adapters in the system, follow the steps below.
|
||||
|
||||
a. Login as root.
|
||||
b. Shut down the system and power off the system.
|
||||
c. Install one or more ATM adapters in the system.
|
||||
d. Connect each adapter to a port on an ATM switch. The green 'Link'
|
||||
LED on the front panel of the adapter will be on if the adapter is
|
||||
connected to the switch properly when the system is powered up.
|
||||
d. Connect each adapter to a port on an ATM switch. The green 'Link'
|
||||
LED on the front panel of the adapter will be on if the adapter is
|
||||
connected to the switch properly when the system is powered up.
|
||||
e. Power on and boot the system.
|
||||
|
||||
2. [ Removed ]
|
||||
|
||||
3. Rebuild kernel with ABR support
|
||||
|
||||
[ a. and b. removed ]
|
||||
c. Reconfigure the kernel, choose the Interphase ia driver through "make
|
||||
|
||||
c. Reconfigure the kernel, choose the Interphase ia driver through "make
|
||||
menuconfig" or "make xconfig".
|
||||
d. Rebuild the kernel, loadable modules and the atm tools.
|
||||
d. Rebuild the kernel, loadable modules and the atm tools.
|
||||
e. Install the new built kernel and modules and reboot.
|
||||
|
||||
4. Load the adapter hardware driver (ia driver) if it is built as a module
|
||||
|
||||
a. Login as root.
|
||||
b. Change directory to /lib/modules/<kernel-version>/atm.
|
||||
c. Run "insmod suni.o;insmod iphase.o"
|
||||
The yellow 'status' LED on the front panel of the adapter will blink
|
||||
while the driver is loaded in the system.
|
||||
d. To verify that the 'ia' driver is loaded successfully, run the
|
||||
following command:
|
||||
The yellow 'status' LED on the front panel of the adapter will blink
|
||||
while the driver is loaded in the system.
|
||||
d. To verify that the 'ia' driver is loaded successfully, run the
|
||||
following command::
|
||||
|
||||
cat /proc/atm/devices
|
||||
cat /proc/atm/devices
|
||||
|
||||
If the driver is loaded successfully, the output of the command will
|
||||
be similar to the following lines:
|
||||
If the driver is loaded successfully, the output of the command will
|
||||
be similar to the following lines::
|
||||
|
||||
Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...
|
||||
0 ia xxxxxxxxx 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 )
|
||||
Itf Type ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...
|
||||
0 ia xxxxxxxxx 0 ( 0 0 0 0 0 ) 5 ( 0 0 0 0 0 )
|
||||
|
||||
You can also check the system log file /var/log/messages for messages
|
||||
related to the ATM driver.
|
||||
You can also check the system log file /var/log/messages for messages
|
||||
related to the ATM driver.
|
||||
|
||||
5. Ia Driver Configuration
|
||||
5. Ia Driver Configuration
|
||||
|
||||
5.1 Configuration of adapter buffers
|
||||
The (i)Chip boards have 3 different packet RAM size variants: 128K, 512K and
|
||||
1M. The RAM size decides the number of buffers and buffer size. The default
|
||||
size and number of buffers are set as following:
|
||||
1M. The RAM size decides the number of buffers and buffer size. The default
|
||||
size and number of buffers are set as following:
|
||||
|
||||
Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
|
||||
RAM size size size size size cnt cnt
|
||||
-------- ------ ------ ------ ------ ------ ------
|
||||
128K 64K 64K 10K 10K 6 6
|
||||
512K 256K 256K 10K 10K 25 25
|
||||
1M 512K 512K 10K 10K 51 51
|
||||
========= ======= ====== ====== ====== ====== ======
|
||||
Total Rx RAM Tx RAM Rx Buf Tx Buf Rx buf Tx buf
|
||||
RAM size size size size size cnt cnt
|
||||
========= ======= ====== ====== ====== ====== ======
|
||||
128K 64K 64K 10K 10K 6 6
|
||||
512K 256K 256K 10K 10K 25 25
|
||||
1M 512K 512K 10K 10K 51 51
|
||||
========= ======= ====== ====== ====== ====== ======
|
||||
|
||||
These setting should work well in most environments, but can be
|
||||
changed by typing the following command:
|
||||
|
||||
insmod <IA_DIR>/ia.o IA_RX_BUF=<RX_CNT> IA_RX_BUF_SZ=<RX_SIZE> \
|
||||
IA_TX_BUF=<TX_CNT> IA_TX_BUF_SZ=<TX_SIZE>
|
||||
Where:
|
||||
RX_CNT = number of receive buffers in the range (1-128)
|
||||
RX_SIZE = size of receive buffers in the range (48-64K)
|
||||
TX_CNT = number of transmit buffers in the range (1-128)
|
||||
TX_SIZE = size of transmit buffers in the range (48-64K)
|
||||
changed by typing the following command::
|
||||
|
||||
1. Transmit and receive buffer size must be a multiple of 4.
|
||||
2. Care should be taken so that the memory required for the
|
||||
transmit and receive buffers is less than or equal to the
|
||||
total adapter packet memory.
|
||||
insmod <IA_DIR>/ia.o IA_RX_BUF=<RX_CNT> IA_RX_BUF_SZ=<RX_SIZE> \
|
||||
IA_TX_BUF=<TX_CNT> IA_TX_BUF_SZ=<TX_SIZE>
|
||||
|
||||
Where:
|
||||
|
||||
- RX_CNT = number of receive buffers in the range (1-128)
|
||||
- RX_SIZE = size of receive buffers in the range (48-64K)
|
||||
- TX_CNT = number of transmit buffers in the range (1-128)
|
||||
- TX_SIZE = size of transmit buffers in the range (48-64K)
|
||||
|
||||
1. Transmit and receive buffer size must be a multiple of 4.
|
||||
2. Care should be taken so that the memory required for the
|
||||
transmit and receive buffers is less than or equal to the
|
||||
total adapter packet memory.
|
||||
|
||||
5.2 Turn on ia debug trace
|
||||
|
||||
When the ia driver is built with the CONFIG_ATM_IA_DEBUG flag, the driver
|
||||
can provide more debug trace if needed. There is a bit mask variable,
|
||||
IADebugFlag, which controls the output of the traces. You can find the bit
|
||||
map of the IADebugFlag in iphase.h.
|
||||
The debug trace can be turn on through the insmod command line option, for
|
||||
example, "insmod iphase.o IADebugFlag=0xffffffff" can turn on all the debug
|
||||
When the ia driver is built with the CONFIG_ATM_IA_DEBUG flag, the driver
|
||||
can provide more debug trace if needed. There is a bit mask variable,
|
||||
IADebugFlag, which controls the output of the traces. You can find the bit
|
||||
map of the IADebugFlag in iphase.h.
|
||||
The debug trace can be turn on through the insmod command line option, for
|
||||
example, "insmod iphase.o IADebugFlag=0xffffffff" can turn on all the debug
|
||||
traces together with loading the driver.
|
||||
|
||||
6. Ia Driver Test Using ttcp_atm and PVC
|
||||
|
||||
For the PVC setup, the test machines can either be connected back-to-back or
|
||||
through a switch. If connected through the switch, the switch must be
|
||||
For the PVC setup, the test machines can either be connected back-to-back or
|
||||
through a switch. If connected through the switch, the switch must be
|
||||
configured for the PVC(s).
|
||||
|
||||
a. For UBR test:
|
||||
At the test machine intended to receive data, type:
|
||||
ttcp_atm -r -a -s 0.100
|
||||
At the other test machine, type:
|
||||
ttcp_atm -t -a -s 0.100 -n 10000
|
||||
|
||||
At the test machine intended to receive data, type::
|
||||
|
||||
ttcp_atm -r -a -s 0.100
|
||||
|
||||
At the other test machine, type::
|
||||
|
||||
ttcp_atm -t -a -s 0.100 -n 10000
|
||||
|
||||
Run "ttcp_atm -h" to display more options of the ttcp_atm tool.
|
||||
b. For ABR test:
|
||||
It is the same as the UBR testing, but with an extra command option:
|
||||
-Pabr:max_pcr=<xxx>
|
||||
where:
|
||||
xxx = the maximum peak cell rate, from 170 - 353207.
|
||||
This option must be set on both the machines.
|
||||
|
||||
It is the same as the UBR testing, but with an extra command option::
|
||||
|
||||
-Pabr:max_pcr=<xxx>
|
||||
|
||||
where:
|
||||
|
||||
xxx = the maximum peak cell rate, from 170 - 353207.
|
||||
|
||||
This option must be set on both the machines.
|
||||
|
||||
c. For CBR test:
|
||||
It is the same as the UBR testing, but with an extra command option:
|
||||
-Pcbr:max_pcr=<xxx>
|
||||
where:
|
||||
xxx = the maximum peak cell rate, from 170 - 353207.
|
||||
This option may only be set on the transmit machine.
|
||||
|
||||
It is the same as the UBR testing, but with an extra command option::
|
||||
|
||||
-Pcbr:max_pcr=<xxx>
|
||||
|
||||
where:
|
||||
|
||||
xxx = the maximum peak cell rate, from 170 - 353207.
|
||||
|
||||
This option may only be set on the transmit machine.
|
||||
|
||||
|
||||
OUTSTANDING ISSUES
|
||||
------------------
|
||||
Outstanding Issues
|
||||
==================
|
||||
|
||||
|
||||
|
||||
Contact Information
|
||||
-------------------
|
||||
|
||||
::
|
||||
|
||||
Customer Support:
|
||||
United States: Telephone: (214) 654-5555
|
||||
Fax: (214) 654-5500
|
||||
United States: Telephone: (214) 654-5555
|
||||
Fax: (214) 654-5500
|
||||
E-Mail: intouch@iphase.com
|
||||
Europe: Telephone: 33 (0)1 41 15 44 00
|
||||
Fax: 33 (0)1 41 15 12 13
|
|
@ -1,12 +1,20 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=====
|
||||
IPsec
|
||||
=====
|
||||
|
||||
|
||||
Here documents known IPsec corner cases which need to be keep in mind when
|
||||
deploy various IPsec configuration in real world production environment.
|
||||
|
||||
1. IPcomp: Small IP packet won't get compressed at sender, and failed on
|
||||
1. IPcomp:
|
||||
Small IP packet won't get compressed at sender, and failed on
|
||||
policy check on receiver.
|
||||
|
||||
Quote from RFC3173:
|
||||
2.2. Non-Expansion Policy
|
||||
Quote from RFC3173::
|
||||
|
||||
2.2. Non-Expansion Policy
|
||||
|
||||
If the total size of a compressed payload and the IPComp header, as
|
||||
defined in section 3, is not smaller than the size of the original
|
|
@ -1,9 +1,15 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
====
|
||||
IPv6
|
||||
====
|
||||
|
||||
|
||||
Options for the ipv6 module are supplied as parameters at load time.
|
||||
|
||||
Module options may be given as command line arguments to the insmod
|
||||
or modprobe command, but are usually specified in either
|
||||
/etc/modules.d/*.conf configuration files, or in a distro-specific
|
||||
``/etc/modules.d/*.conf`` configuration files, or in a distro-specific
|
||||
configuration file.
|
||||
|
||||
The available ipv6 module parameters are listed below. If a parameter
|
|
@ -1,11 +1,15 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
IPVLAN Driver HOWTO
|
||||
===================
|
||||
IPVLAN Driver HOWTO
|
||||
===================
|
||||
|
||||
Initial Release:
|
||||
Mahesh Bandewar <maheshb AT google.com>
|
||||
|
||||
1. Introduction:
|
||||
This is conceptually very similar to the macvlan driver with one major
|
||||
================
|
||||
This is conceptually very similar to the macvlan driver with one major
|
||||
exception of using L3 for mux-ing /demux-ing among slaves. This property makes
|
||||
the master device share the L2 with it's slave devices. I have developed this
|
||||
driver in conjunction with network namespaces and not sure if there is use case
|
||||
|
@ -13,34 +17,48 @@ outside of it.
|
|||
|
||||
|
||||
2. Building and Installation:
|
||||
In order to build the driver, please select the config item CONFIG_IPVLAN.
|
||||
=============================
|
||||
|
||||
In order to build the driver, please select the config item CONFIG_IPVLAN.
|
||||
The driver can be built into the kernel (CONFIG_IPVLAN=y) or as a module
|
||||
(CONFIG_IPVLAN=m).
|
||||
|
||||
|
||||
3. Configuration:
|
||||
There are no module parameters for this driver and it can be configured
|
||||
=================
|
||||
|
||||
There are no module parameters for this driver and it can be configured
|
||||
using IProute2/ip utility.
|
||||
::
|
||||
|
||||
ip link add link <master> name <slave> type ipvlan [ mode MODE ] [ FLAGS ]
|
||||
where
|
||||
MODE: l3 (default) | l3s | l2
|
||||
FLAGS: bridge (default) | private | vepa
|
||||
MODE: l3 (default) | l3s | l2
|
||||
FLAGS: bridge (default) | private | vepa
|
||||
|
||||
e.g.
|
||||
|
||||
e.g.
|
||||
(a) Following will create IPvlan link with eth0 as master in
|
||||
L3 bridge mode
|
||||
bash# ip link add link eth0 name ipvl0 type ipvlan
|
||||
(b) This command will create IPvlan link in L2 bridge mode.
|
||||
bash# ip link add link eth0 name ipvl0 type ipvlan mode l2 bridge
|
||||
(c) This command will create an IPvlan device in L2 private mode.
|
||||
bash# ip link add link eth0 name ipvlan type ipvlan mode l2 private
|
||||
(d) This command will create an IPvlan device in L2 vepa mode.
|
||||
bash# ip link add link eth0 name ipvlan type ipvlan mode l2 vepa
|
||||
L3 bridge mode::
|
||||
|
||||
bash# ip link add link eth0 name ipvl0 type ipvlan
|
||||
(b) This command will create IPvlan link in L2 bridge mode::
|
||||
|
||||
bash# ip link add link eth0 name ipvl0 type ipvlan mode l2 bridge
|
||||
|
||||
(c) This command will create an IPvlan device in L2 private mode::
|
||||
|
||||
bash# ip link add link eth0 name ipvlan type ipvlan mode l2 private
|
||||
|
||||
(d) This command will create an IPvlan device in L2 vepa mode::
|
||||
|
||||
bash# ip link add link eth0 name ipvlan type ipvlan mode l2 vepa
|
||||
|
||||
|
||||
4. Operating modes:
|
||||
IPvlan has two modes of operation - L2 and L3. For a given master device,
|
||||
===================
|
||||
|
||||
IPvlan has two modes of operation - L2 and L3. For a given master device,
|
||||
you can select one of these two modes and all slaves on that master will
|
||||
operate in the same (selected) mode. The RX mode is almost identical except
|
||||
that in L3 mode the slaves wont receive any multicast / broadcast traffic.
|
||||
|
@ -48,39 +66,50 @@ L3 mode is more restrictive since routing is controlled from the other (mostly)
|
|||
default namespace.
|
||||
|
||||
4.1 L2 mode:
|
||||
In this mode TX processing happens on the stack instance attached to the
|
||||
------------
|
||||
|
||||
In this mode TX processing happens on the stack instance attached to the
|
||||
slave device and packets are switched and queued to the master device to send
|
||||
out. In this mode the slaves will RX/TX multicast and broadcast (if applicable)
|
||||
as well.
|
||||
|
||||
4.2 L3 mode:
|
||||
In this mode TX processing up to L3 happens on the stack instance attached
|
||||
------------
|
||||
|
||||
In this mode TX processing up to L3 happens on the stack instance attached
|
||||
to the slave device and packets are switched to the stack instance of the
|
||||
master device for the L2 processing and routing from that instance will be
|
||||
used before packets are queued on the outbound device. In this mode the slaves
|
||||
will not receive nor can send multicast / broadcast traffic.
|
||||
|
||||
4.3 L3S mode:
|
||||
This is very similar to the L3 mode except that iptables (conn-tracking)
|
||||
-------------
|
||||
|
||||
This is very similar to the L3 mode except that iptables (conn-tracking)
|
||||
works in this mode and hence it is L3-symmetric (L3s). This will have slightly less
|
||||
performance but that shouldn't matter since you are choosing this mode over plain-L3
|
||||
mode to make conn-tracking work.
|
||||
|
||||
5. Mode flags:
|
||||
At this time following mode flags are available
|
||||
==============
|
||||
|
||||
At this time following mode flags are available
|
||||
|
||||
5.1 bridge:
|
||||
This is the default option. To configure the IPvlan port in this mode,
|
||||
-----------
|
||||
This is the default option. To configure the IPvlan port in this mode,
|
||||
user can choose to either add this option on the command-line or don't specify
|
||||
anything. This is the traditional mode where slaves can cross-talk among
|
||||
themselves apart from talking through the master device.
|
||||
|
||||
5.2 private:
|
||||
If this option is added to the command-line, the port is set in private
|
||||
------------
|
||||
If this option is added to the command-line, the port is set in private
|
||||
mode. i.e. port won't allow cross communication between slaves.
|
||||
|
||||
5.3 vepa:
|
||||
If this is added to the command-line, the port is set in VEPA mode.
|
||||
---------
|
||||
If this is added to the command-line, the port is set in VEPA mode.
|
||||
i.e. port will offload switching functionality to the external entity as
|
||||
described in 802.1Qbg
|
||||
Note: VEPA mode in IPvlan has limitations. IPvlan uses the mac-address of the
|
||||
|
@ -89,18 +118,25 @@ neighbor will have source and destination mac same. This will make the switch /
|
|||
router send the redirect message.
|
||||
|
||||
6. What to choose (macvlan vs. ipvlan)?
|
||||
These two devices are very similar in many regards and the specific use
|
||||
=======================================
|
||||
|
||||
These two devices are very similar in many regards and the specific use
|
||||
case could very well define which device to choose. if one of the following
|
||||
situations defines your use case then you can choose to use ipvlan -
|
||||
(a) The Linux host that is connected to the external switch / router has
|
||||
policy configured that allows only one mac per port.
|
||||
(b) No of virtual devices created on a master exceed the mac capacity and
|
||||
puts the NIC in promiscuous mode and degraded performance is a concern.
|
||||
(c) If the slave device is to be put into the hostile / untrusted network
|
||||
namespace where L2 on the slave could be changed / misused.
|
||||
situations defines your use case then you can choose to use ipvlan:
|
||||
|
||||
|
||||
(a) The Linux host that is connected to the external switch / router has
|
||||
policy configured that allows only one mac per port.
|
||||
(b) No of virtual devices created on a master exceed the mac capacity and
|
||||
puts the NIC in promiscuous mode and degraded performance is a concern.
|
||||
(c) If the slave device is to be put into the hostile / untrusted network
|
||||
namespace where L2 on the slave could be changed / misused.
|
||||
|
||||
|
||||
6. Example configuration:
|
||||
=========================
|
||||
|
||||
::
|
||||
|
||||
+=============================================================+
|
||||
| Host: host1 |
|
||||
|
@ -117,30 +153,37 @@ namespace where L2 on the slave could be changed / misused.
|
|||
+==============================#==============================+
|
||||
|
||||
|
||||
(a) Create two network namespaces - ns0, ns1
|
||||
ip netns add ns0
|
||||
ip netns add ns1
|
||||
(a) Create two network namespaces - ns0, ns1::
|
||||
|
||||
(b) Create two ipvlan slaves on eth0 (master device)
|
||||
ip link add link eth0 ipvl0 type ipvlan mode l2
|
||||
ip link add link eth0 ipvl1 type ipvlan mode l2
|
||||
ip netns add ns0
|
||||
ip netns add ns1
|
||||
|
||||
(c) Assign slaves to the respective network namespaces
|
||||
ip link set dev ipvl0 netns ns0
|
||||
ip link set dev ipvl1 netns ns1
|
||||
(b) Create two ipvlan slaves on eth0 (master device)::
|
||||
|
||||
(d) Now switch to the namespace (ns0 or ns1) to configure the slave devices
|
||||
- For ns0
|
||||
(1) ip netns exec ns0 bash
|
||||
(2) ip link set dev ipvl0 up
|
||||
(3) ip link set dev lo up
|
||||
(4) ip -4 addr add 127.0.0.1 dev lo
|
||||
(5) ip -4 addr add $IPADDR dev ipvl0
|
||||
(6) ip -4 route add default via $ROUTER dev ipvl0
|
||||
- For ns1
|
||||
(1) ip netns exec ns1 bash
|
||||
(2) ip link set dev ipvl1 up
|
||||
(3) ip link set dev lo up
|
||||
(4) ip -4 addr add 127.0.0.1 dev lo
|
||||
(5) ip -4 addr add $IPADDR dev ipvl1
|
||||
(6) ip -4 route add default via $ROUTER dev ipvl1
|
||||
ip link add link eth0 ipvl0 type ipvlan mode l2
|
||||
ip link add link eth0 ipvl1 type ipvlan mode l2
|
||||
|
||||
(c) Assign slaves to the respective network namespaces::
|
||||
|
||||
ip link set dev ipvl0 netns ns0
|
||||
ip link set dev ipvl1 netns ns1
|
||||
|
||||
(d) Now switch to the namespace (ns0 or ns1) to configure the slave devices
|
||||
|
||||
- For ns0::
|
||||
|
||||
(1) ip netns exec ns0 bash
|
||||
(2) ip link set dev ipvl0 up
|
||||
(3) ip link set dev lo up
|
||||
(4) ip -4 addr add 127.0.0.1 dev lo
|
||||
(5) ip -4 addr add $IPADDR dev ipvl0
|
||||
(6) ip -4 route add default via $ROUTER dev ipvl0
|
||||
|
||||
- For ns1::
|
||||
|
||||
(1) ip netns exec ns1 bash
|
||||
(2) ip link set dev ipvl1 up
|
||||
(3) ip link set dev lo up
|
||||
(4) ip -4 addr add 127.0.0.1 dev lo
|
||||
(5) ip -4 addr add $IPADDR dev ipvl1
|
||||
(6) ip -4 route add default via $ROUTER dev ipvl1
|
|
@ -1,23 +1,30 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===========
|
||||
IPvs-sysctl
|
||||
===========
|
||||
|
||||
/proc/sys/net/ipv4/vs/* Variables:
|
||||
==================================
|
||||
|
||||
am_droprate - INTEGER
|
||||
default 10
|
||||
default 10
|
||||
|
||||
It sets the always mode drop rate, which is used in the mode 3
|
||||
of the drop_rate defense.
|
||||
It sets the always mode drop rate, which is used in the mode 3
|
||||
of the drop_rate defense.
|
||||
|
||||
amemthresh - INTEGER
|
||||
default 1024
|
||||
default 1024
|
||||
|
||||
It sets the available memory threshold (in pages), which is
|
||||
used in the automatic modes of defense. When there is no
|
||||
enough available memory, the respective strategy will be
|
||||
enabled and the variable is automatically set to 2, otherwise
|
||||
the strategy is disabled and the variable is set to 1.
|
||||
It sets the available memory threshold (in pages), which is
|
||||
used in the automatic modes of defense. When there is no
|
||||
enough available memory, the respective strategy will be
|
||||
enabled and the variable is automatically set to 2, otherwise
|
||||
the strategy is disabled and the variable is set to 1.
|
||||
|
||||
backup_only - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
If set, disable the director function while the server is
|
||||
in backup mode to avoid packet loops for DR/TUN methods.
|
||||
|
@ -44,8 +51,8 @@ conn_reuse_mode - INTEGER
|
|||
real servers to a very busy cluster.
|
||||
|
||||
conntrack - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
If set, maintain connection tracking entries for
|
||||
connections handled by IPVS.
|
||||
|
@ -61,28 +68,28 @@ conntrack - BOOLEAN
|
|||
Only available when IPVS is compiled with CONFIG_IP_VS_NFCT enabled.
|
||||
|
||||
cache_bypass - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
If it is enabled, forward packets to the original destination
|
||||
directly when no cache server is available and destination
|
||||
address is not local (iph->daddr is RTN_UNICAST). It is mostly
|
||||
used in transparent web cache cluster.
|
||||
If it is enabled, forward packets to the original destination
|
||||
directly when no cache server is available and destination
|
||||
address is not local (iph->daddr is RTN_UNICAST). It is mostly
|
||||
used in transparent web cache cluster.
|
||||
|
||||
debug_level - INTEGER
|
||||
0 - transmission error messages (default)
|
||||
1 - non-fatal error messages
|
||||
2 - configuration
|
||||
3 - destination trash
|
||||
4 - drop entry
|
||||
5 - service lookup
|
||||
6 - scheduling
|
||||
7 - connection new/expire, lookup and synchronization
|
||||
8 - state transition
|
||||
9 - binding destination, template checks and applications
|
||||
10 - IPVS packet transmission
|
||||
11 - IPVS packet handling (ip_vs_in/ip_vs_out)
|
||||
12 or more - packet traversal
|
||||
- 0 - transmission error messages (default)
|
||||
- 1 - non-fatal error messages
|
||||
- 2 - configuration
|
||||
- 3 - destination trash
|
||||
- 4 - drop entry
|
||||
- 5 - service lookup
|
||||
- 6 - scheduling
|
||||
- 7 - connection new/expire, lookup and synchronization
|
||||
- 8 - state transition
|
||||
- 9 - binding destination, template checks and applications
|
||||
- 10 - IPVS packet transmission
|
||||
- 11 - IPVS packet handling (ip_vs_in/ip_vs_out)
|
||||
- 12 or more - packet traversal
|
||||
|
||||
Only available when IPVS is compiled with CONFIG_IP_VS_DEBUG enabled.
|
||||
|
||||
|
@ -92,58 +99,58 @@ debug_level - INTEGER
|
|||
the level.
|
||||
|
||||
drop_entry - INTEGER
|
||||
0 - disabled (default)
|
||||
- 0 - disabled (default)
|
||||
|
||||
The drop_entry defense is to randomly drop entries in the
|
||||
connection hash table, just in order to collect back some
|
||||
memory for new connections. In the current code, the
|
||||
drop_entry procedure can be activated every second, then it
|
||||
randomly scans 1/32 of the whole and drops entries that are in
|
||||
the SYN-RECV/SYNACK state, which should be effective against
|
||||
syn-flooding attack.
|
||||
The drop_entry defense is to randomly drop entries in the
|
||||
connection hash table, just in order to collect back some
|
||||
memory for new connections. In the current code, the
|
||||
drop_entry procedure can be activated every second, then it
|
||||
randomly scans 1/32 of the whole and drops entries that are in
|
||||
the SYN-RECV/SYNACK state, which should be effective against
|
||||
syn-flooding attack.
|
||||
|
||||
The valid values of drop_entry are from 0 to 3, where 0 means
|
||||
that this strategy is always disabled, 1 and 2 mean automatic
|
||||
modes (when there is no enough available memory, the strategy
|
||||
is enabled and the variable is automatically set to 2,
|
||||
otherwise the strategy is disabled and the variable is set to
|
||||
1), and 3 means that that the strategy is always enabled.
|
||||
The valid values of drop_entry are from 0 to 3, where 0 means
|
||||
that this strategy is always disabled, 1 and 2 mean automatic
|
||||
modes (when there is no enough available memory, the strategy
|
||||
is enabled and the variable is automatically set to 2,
|
||||
otherwise the strategy is disabled and the variable is set to
|
||||
1), and 3 means that that the strategy is always enabled.
|
||||
|
||||
drop_packet - INTEGER
|
||||
0 - disabled (default)
|
||||
- 0 - disabled (default)
|
||||
|
||||
The drop_packet defense is designed to drop 1/rate packets
|
||||
before forwarding them to real servers. If the rate is 1, then
|
||||
drop all the incoming packets.
|
||||
The drop_packet defense is designed to drop 1/rate packets
|
||||
before forwarding them to real servers. If the rate is 1, then
|
||||
drop all the incoming packets.
|
||||
|
||||
The value definition is the same as that of the drop_entry. In
|
||||
the automatic mode, the rate is determined by the follow
|
||||
formula: rate = amemthresh / (amemthresh - available_memory)
|
||||
when available memory is less than the available memory
|
||||
threshold. When the mode 3 is set, the always mode drop rate
|
||||
is controlled by the /proc/sys/net/ipv4/vs/am_droprate.
|
||||
The value definition is the same as that of the drop_entry. In
|
||||
the automatic mode, the rate is determined by the follow
|
||||
formula: rate = amemthresh / (amemthresh - available_memory)
|
||||
when available memory is less than the available memory
|
||||
threshold. When the mode 3 is set, the always mode drop rate
|
||||
is controlled by the /proc/sys/net/ipv4/vs/am_droprate.
|
||||
|
||||
expire_nodest_conn - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
The default value is 0, the load balancer will silently drop
|
||||
packets when its destination server is not available. It may
|
||||
be useful, when user-space monitoring program deletes the
|
||||
destination server (because of server overload or wrong
|
||||
detection) and add back the server later, and the connections
|
||||
to the server can continue.
|
||||
The default value is 0, the load balancer will silently drop
|
||||
packets when its destination server is not available. It may
|
||||
be useful, when user-space monitoring program deletes the
|
||||
destination server (because of server overload or wrong
|
||||
detection) and add back the server later, and the connections
|
||||
to the server can continue.
|
||||
|
||||
If this feature is enabled, the load balancer will expire the
|
||||
connection immediately when a packet arrives and its
|
||||
destination server is not available, then the client program
|
||||
will be notified that the connection is closed. This is
|
||||
equivalent to the feature some people requires to flush
|
||||
connections when its destination is not available.
|
||||
If this feature is enabled, the load balancer will expire the
|
||||
connection immediately when a packet arrives and its
|
||||
destination server is not available, then the client program
|
||||
will be notified that the connection is closed. This is
|
||||
equivalent to the feature some people requires to flush
|
||||
connections when its destination is not available.
|
||||
|
||||
expire_quiescent_template - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
When set to a non-zero value, the load balancer will expire
|
||||
persistent templates when the destination server is quiescent.
|
||||
|
@ -158,8 +165,8 @@ expire_quiescent_template - BOOLEAN
|
|||
connection and the destination server is quiescent.
|
||||
|
||||
ignore_tunneled - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
If set, ipvs will set the ipvs_property on all packets which are of
|
||||
unrecognized protocols. This prevents us from routing tunneled
|
||||
|
@ -168,30 +175,30 @@ ignore_tunneled - BOOLEAN
|
|||
ipvs routing loops when ipvs is also acting as a real server).
|
||||
|
||||
nat_icmp_send - BOOLEAN
|
||||
0 - disabled (default)
|
||||
not 0 - enabled
|
||||
- 0 - disabled (default)
|
||||
- not 0 - enabled
|
||||
|
||||
It controls sending icmp error messages (ICMP_DEST_UNREACH)
|
||||
for VS/NAT when the load balancer receives packets from real
|
||||
servers but the connection entries don't exist.
|
||||
It controls sending icmp error messages (ICMP_DEST_UNREACH)
|
||||
for VS/NAT when the load balancer receives packets from real
|
||||
servers but the connection entries don't exist.
|
||||
|
||||
pmtu_disc - BOOLEAN
|
||||
0 - disabled
|
||||
not 0 - enabled (default)
|
||||
- 0 - disabled
|
||||
- not 0 - enabled (default)
|
||||
|
||||
By default, reject with FRAG_NEEDED all DF packets that exceed
|
||||
the PMTU, irrespective of the forwarding method. For TUN method
|
||||
the flag can be disabled to fragment such packets.
|
||||
|
||||
secure_tcp - INTEGER
|
||||
0 - disabled (default)
|
||||
- 0 - disabled (default)
|
||||
|
||||
The secure_tcp defense is to use a more complicated TCP state
|
||||
transition table. For VS/NAT, it also delays entering the
|
||||
TCP ESTABLISHED state until the three way handshake is completed.
|
||||
|
||||
The value definition is the same as that of drop_entry and
|
||||
drop_packet.
|
||||
The value definition is the same as that of drop_entry and
|
||||
drop_packet.
|
||||
|
||||
sync_threshold - vector of 2 INTEGERs: sync_threshold, sync_period
|
||||
default 3 50
|
||||
|
@ -248,8 +255,8 @@ sync_ports - INTEGER
|
|||
8848+sync_ports-1.
|
||||
|
||||
snat_reroute - BOOLEAN
|
||||
0 - disabled
|
||||
not 0 - enabled (default)
|
||||
- 0 - disabled
|
||||
- not 0 - enabled (default)
|
||||
|
||||
If enabled, recalculate the route of SNATed packets from
|
||||
realservers so that they are routed as if they originate from the
|
||||
|
@ -270,6 +277,7 @@ sync_persist_mode - INTEGER
|
|||
Controls the synchronisation of connections when using persistence
|
||||
|
||||
0: All types of connections are synchronised
|
||||
|
||||
1: Attempt to reduce the synchronisation traffic depending on
|
||||
the connection type. For persistent services avoid synchronisation
|
||||
for normal connections, do it only for persistence templates.
|
|
@ -1,35 +1,38 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=============================
|
||||
Kernel Connection Multiplexor
|
||||
-----------------------------
|
||||
=============================
|
||||
|
||||
Kernel Connection Multiplexor (KCM) is a mechanism that provides a message based
|
||||
interface over TCP for generic application protocols. With KCM an application
|
||||
can efficiently send and receive application protocol messages over TCP using
|
||||
datagram sockets.
|
||||
|
||||
KCM implements an NxM multiplexor in the kernel as diagrammed below:
|
||||
KCM implements an NxM multiplexor in the kernel as diagrammed below::
|
||||
|
||||
+------------+ +------------+ +------------+ +------------+
|
||||
| KCM socket | | KCM socket | | KCM socket | | KCM socket |
|
||||
+------------+ +------------+ +------------+ +------------+
|
||||
| | | |
|
||||
+-----------+ | | +----------+
|
||||
| | | |
|
||||
+----------------------------------+
|
||||
| Multiplexor |
|
||||
+----------------------------------+
|
||||
| | | | |
|
||||
+---------+ | | | ------------+
|
||||
| | | | |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
| Psock | | Psock | | Psock | | Psock | | Psock |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
| | | | |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
| TCP sock | | TCP sock | | TCP sock | | TCP sock | | TCP sock |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
+------------+ +------------+ +------------+ +------------+
|
||||
| KCM socket | | KCM socket | | KCM socket | | KCM socket |
|
||||
+------------+ +------------+ +------------+ +------------+
|
||||
| | | |
|
||||
+-----------+ | | +----------+
|
||||
| | | |
|
||||
+----------------------------------+
|
||||
| Multiplexor |
|
||||
+----------------------------------+
|
||||
| | | | |
|
||||
+---------+ | | | ------------+
|
||||
| | | | |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
| Psock | | Psock | | Psock | | Psock | | Psock |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
| | | | |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
| TCP sock | | TCP sock | | TCP sock | | TCP sock | | TCP sock |
|
||||
+----------+ +----------+ +----------+ +----------+ +----------+
|
||||
|
||||
KCM sockets
|
||||
-----------
|
||||
===========
|
||||
|
||||
The KCM sockets provide the user interface to the multiplexor. All the KCM sockets
|
||||
bound to a multiplexor are considered to have equivalent function, and I/O
|
||||
|
@ -37,7 +40,7 @@ operations in different sockets may be done in parallel without the need for
|
|||
synchronization between threads in userspace.
|
||||
|
||||
Multiplexor
|
||||
-----------
|
||||
===========
|
||||
|
||||
The multiplexor provides the message steering. In the transmit path, messages
|
||||
written on a KCM socket are sent atomically on an appropriate TCP socket.
|
||||
|
@ -45,14 +48,14 @@ Similarly, in the receive path, messages are constructed on each TCP socket
|
|||
(Psock) and complete messages are steered to a KCM socket.
|
||||
|
||||
TCP sockets & Psocks
|
||||
--------------------
|
||||
====================
|
||||
|
||||
TCP sockets may be bound to a KCM multiplexor. A Psock structure is allocated
|
||||
for each bound TCP socket, this structure holds the state for constructing
|
||||
messages on receive as well as other connection specific information for KCM.
|
||||
|
||||
Connected mode semantics
|
||||
------------------------
|
||||
========================
|
||||
|
||||
Each multiplexor assumes that all attached TCP connections are to the same
|
||||
destination and can use the different connections for load balancing when
|
||||
|
@ -60,7 +63,7 @@ transmitting. The normal send and recv calls (include sendmmsg and recvmmsg)
|
|||
can be used to send and receive messages from the KCM socket.
|
||||
|
||||
Socket types
|
||||
------------
|
||||
============
|
||||
|
||||
KCM supports SOCK_DGRAM and SOCK_SEQPACKET socket types.
|
||||
|
||||
|
@ -110,23 +113,23 @@ User interface
|
|||
Creating a multiplexor
|
||||
----------------------
|
||||
|
||||
A new multiplexor and initial KCM socket is created by a socket call:
|
||||
A new multiplexor and initial KCM socket is created by a socket call::
|
||||
|
||||
socket(AF_KCM, type, protocol)
|
||||
|
||||
- type is either SOCK_DGRAM or SOCK_SEQPACKET
|
||||
- protocol is KCMPROTO_CONNECTED
|
||||
- type is either SOCK_DGRAM or SOCK_SEQPACKET
|
||||
- protocol is KCMPROTO_CONNECTED
|
||||
|
||||
Cloning KCM sockets
|
||||
-------------------
|
||||
|
||||
After the first KCM socket is created using the socket call as described
|
||||
above, additional sockets for the multiplexor can be created by cloning
|
||||
a KCM socket. This is accomplished by an ioctl on a KCM socket:
|
||||
a KCM socket. This is accomplished by an ioctl on a KCM socket::
|
||||
|
||||
/* From linux/kcm.h */
|
||||
struct kcm_clone {
|
||||
int fd;
|
||||
int fd;
|
||||
};
|
||||
|
||||
struct kcm_clone info;
|
||||
|
@ -142,11 +145,11 @@ Attach transport sockets
|
|||
------------------------
|
||||
|
||||
Attaching of transport sockets to a multiplexor is performed by calling an
|
||||
ioctl on a KCM socket for the multiplexor. e.g.:
|
||||
ioctl on a KCM socket for the multiplexor. e.g.::
|
||||
|
||||
/* From linux/kcm.h */
|
||||
struct kcm_attach {
|
||||
int fd;
|
||||
int fd;
|
||||
int bpf_fd;
|
||||
};
|
||||
|
||||
|
@ -160,18 +163,19 @@ ioctl on a KCM socket for the multiplexor. e.g.:
|
|||
ioctl(kcmfd, SIOCKCMATTACH, &info);
|
||||
|
||||
The kcm_attach structure contains:
|
||||
fd: file descriptor for TCP socket being attached
|
||||
bpf_prog_fd: file descriptor for compiled BPF program downloaded
|
||||
|
||||
- fd: file descriptor for TCP socket being attached
|
||||
- bpf_prog_fd: file descriptor for compiled BPF program downloaded
|
||||
|
||||
Unattach transport sockets
|
||||
--------------------------
|
||||
|
||||
Unattaching a transport socket from a multiplexor is straightforward. An
|
||||
"unattach" ioctl is done with the kcm_unattach structure as the argument:
|
||||
"unattach" ioctl is done with the kcm_unattach structure as the argument::
|
||||
|
||||
/* From linux/kcm.h */
|
||||
struct kcm_unattach {
|
||||
int fd;
|
||||
int fd;
|
||||
};
|
||||
|
||||
struct kcm_unattach info;
|
||||
|
@ -190,7 +194,7 @@ When receive is disabled, any pending messages in the socket's
|
|||
receive buffer are moved to other sockets. This feature is useful
|
||||
if an application thread knows that it will be doing a lot of
|
||||
work on a request and won't be able to service new messages for a
|
||||
while. Example use:
|
||||
while. Example use::
|
||||
|
||||
int val = 1;
|
||||
|
||||
|
@ -200,7 +204,7 @@ BFP programs for message delineation
|
|||
------------------------------------
|
||||
|
||||
BPF programs can be compiled using the BPF LLVM backend. For example,
|
||||
the BPF program for parsing Thrift is:
|
||||
the BPF program for parsing Thrift is::
|
||||
|
||||
#include "bpf.h" /* for __sk_buff */
|
||||
#include "bpf_helpers.h" /* for load_word intrinsic */
|
||||
|
@ -250,6 +254,7 @@ based on groups, or batches of messages, can be beneficial for performance.
|
|||
|
||||
On transmit, there are three ways an application can batch (pipeline)
|
||||
messages on a KCM socket.
|
||||
|
||||
1) Send multiple messages in a single sendmmsg.
|
||||
2) Send a group of messages each with a sendmsg call, where all messages
|
||||
except the last have MSG_BATCH in the flags of sendmsg call.
|
|
@ -99,7 +99,7 @@ treat the LocalTalk device like an ordinary Ethernet device, even if
|
|||
that's what it looks like to Netatalk.
|
||||
|
||||
Instead, you follow the same procedure as for doing IP in EtherTalk.
|
||||
See Documentation/networking/ipddp.txt for more information about the
|
||||
See Documentation/networking/ipddp.rst for more information about the
|
||||
kernel driver and userspace tools needed.
|
||||
|
||||
--------------------------------------
|
||||
|
|
|
@ -1051,7 +1051,7 @@ for more information on hardware timestamps.
|
|||
-------------------------------------------------------------------------------
|
||||
|
||||
- Packet sockets work well together with Linux socket filters, thus you also
|
||||
might want to have a look at Documentation/networking/filter.txt
|
||||
might want to have a look at Documentation/networking/filter.rst
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
+ THANKS
|
||||
|
|
|
@ -792,7 +792,7 @@ counters to indicate the ACK is skipped in which scenario. The ACK
|
|||
would only be skipped if the received packet is either a SYN packet or
|
||||
it has no data.
|
||||
|
||||
.. _sysctl document: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
|
||||
.. _sysctl document: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.rst
|
||||
|
||||
* TcpExtTCPACKSkippedSynRecv
|
||||
|
||||
|
|
|
@ -3192,7 +3192,7 @@ Q: https://patchwork.ozlabs.org/project/netdev/list/?delegate=77147
|
|||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git
|
||||
F: Documentation/bpf/
|
||||
F: Documentation/networking/filter.txt
|
||||
F: Documentation/networking/filter.rst
|
||||
F: arch/*/net/*
|
||||
F: include/linux/bpf*
|
||||
F: include/linux/filter.h
|
||||
|
@ -4728,7 +4728,7 @@ DECnet NETWORK LAYER
|
|||
L: linux-decnet-user@lists.sourceforge.net
|
||||
S: Orphan
|
||||
W: http://linux-decnet.sourceforge.net
|
||||
F: Documentation/networking/decnet.txt
|
||||
F: Documentation/networking/decnet.rst
|
||||
F: net/decnet/
|
||||
|
||||
DECSTATION PLATFORM SUPPORT
|
||||
|
@ -7815,7 +7815,7 @@ HUAWEI ETHERNET DRIVER
|
|||
M: Aviad Krawczyk <aviad.krawczyk@huawei.com>
|
||||
L: netdev@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/networking/hinic.txt
|
||||
F: Documentation/networking/hinic.rst
|
||||
F: drivers/net/ethernet/huawei/hinic/
|
||||
|
||||
HUGETLB FILESYSTEM
|
||||
|
@ -8934,7 +8934,7 @@ L: lvs-devel@vger.kernel.org
|
|||
S: Maintained
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git
|
||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs.git
|
||||
F: Documentation/networking/ipvs-sysctl.txt
|
||||
F: Documentation/networking/ipvs-sysctl.rst
|
||||
F: include/net/ip_vs.h
|
||||
F: include/uapi/linux/ip_vs.h
|
||||
F: net/netfilter/ipvs/
|
||||
|
|
|
@ -306,7 +306,7 @@ config ATM_IA
|
|||
for more info about the cards. Say Y (or M to compile as a module
|
||||
named iphase) here if you have one of these cards.
|
||||
|
||||
See the file <file:Documentation/networking/iphase.txt> for further
|
||||
See the file <file:Documentation/networking/iphase.rst> for further
|
||||
details.
|
||||
|
||||
config ATM_IA_DEBUG
|
||||
|
@ -336,7 +336,7 @@ config ATM_FORE200E
|
|||
on PCI and SBUS hosts. Say Y (or M to compile as a module
|
||||
named fore_200e) here if you have one of these ATM adapters.
|
||||
|
||||
See the file <file:Documentation/networking/fore200e.txt> for
|
||||
See the file <file:Documentation/networking/fore200e.rst> for
|
||||
further details.
|
||||
|
||||
config ATM_FORE200E_USE_TASKLET
|
||||
|
|
|
@ -50,7 +50,7 @@ config BONDING
|
|||
The driver supports multiple bonding modes to allow for both high
|
||||
performance and high availability operation.
|
||||
|
||||
Refer to <file:Documentation/networking/bonding.txt> for more
|
||||
Refer to <file:Documentation/networking/bonding.rst> for more
|
||||
information.
|
||||
|
||||
To compile this driver as a module, choose M here: the module
|
||||
|
@ -126,7 +126,7 @@ config EQUALIZER
|
|||
Linux driver or with a Livingston Portmaster 2e.
|
||||
|
||||
Say Y if you want this and read
|
||||
<file:Documentation/networking/eql.txt>. You may also want to read
|
||||
<file:Documentation/networking/eql.rst>. You may also want to read
|
||||
section 6.2 of the NET-3-HOWTO, available from
|
||||
<http://www.tldp.org/docs.html#howto>.
|
||||
|
||||
|
|
|
@ -59,7 +59,7 @@ config COPS
|
|||
package. This driver is experimental, which means that it may not
|
||||
work. This driver will only work if you choose "AppleTalk DDP"
|
||||
networking support, above.
|
||||
Please read the file <file:Documentation/networking/cops.txt>.
|
||||
Please read the file <file:Documentation/networking/cops.rst>.
|
||||
|
||||
config COPS_DAYNA
|
||||
bool "Dayna firmware support"
|
||||
|
@ -86,7 +86,7 @@ config IPDDP
|
|||
box is stuck on an AppleTalk only network) or decapsulate (e.g. if
|
||||
you want your Linux box to act as an Internet gateway for a zoo of
|
||||
AppleTalk connected Macs). Please see the file
|
||||
<file:Documentation/networking/ipddp.txt> for more information.
|
||||
<file:Documentation/networking/ipddp.rst> for more information.
|
||||
|
||||
If you say Y here, the AppleTalk-IP support will be compiled into
|
||||
the kernel. In this case, you can either use encapsulation or
|
||||
|
@ -107,4 +107,4 @@ config IPDDP_ENCAP
|
|||
IP packets inside AppleTalk frames; this is useful if your Linux box
|
||||
is stuck on an AppleTalk network (which hopefully contains a
|
||||
decapsulator somewhere). Please see
|
||||
<file:Documentation/networking/ipddp.txt> for more information.
|
||||
<file:Documentation/networking/ipddp.rst> for more information.
|
||||
|
|
|
@ -9,7 +9,7 @@ menuconfig ARCNET
|
|||
---help---
|
||||
If you have a network card of this type, say Y and check out the
|
||||
(arguably) beautiful poetry in
|
||||
<file:Documentation/networking/arcnet.txt>.
|
||||
<file:Documentation/networking/arcnet.rst>.
|
||||
|
||||
You need both this driver, and the driver for the particular ARCnet
|
||||
chipset of your card. If you don't know, then it's probably a
|
||||
|
@ -28,7 +28,7 @@ config ARCNET_1201
|
|||
arc0 device. You need to say Y here to communicate with
|
||||
industry-standard RFC1201 implementations, like the arcether.com
|
||||
packet driver or most DOS/Windows ODI drivers. Please read the
|
||||
ARCnet documentation in <file:Documentation/networking/arcnet.txt>
|
||||
ARCnet documentation in <file:Documentation/networking/arcnet.rst>
|
||||
for more information about using arc0.
|
||||
|
||||
config ARCNET_1051
|
||||
|
@ -42,7 +42,7 @@ config ARCNET_1051
|
|||
industry-standard RFC1201 implementations, like the arcether.com
|
||||
packet driver or most DOS/Windows ODI drivers. RFC1201 is included
|
||||
automatically as the arc0 device. Please read the ARCnet
|
||||
documentation in <file:Documentation/networking/arcnet.txt> for more
|
||||
documentation in <file:Documentation/networking/arcnet.rst> for more
|
||||
information about using arc0e and arc0s.
|
||||
|
||||
config ARCNET_RAW
|
||||
|
|
|
@ -28,7 +28,7 @@ config CAIF_SPI_SLAVE
|
|||
The CAIF Link layer SPI Protocol driver for Slave SPI interface.
|
||||
This driver implements a platform driver to accommodate for a
|
||||
platform specific SPI device. A sample CAIF SPI Platform device is
|
||||
provided in <file:Documentation/networking/caif/spi_porting.txt>.
|
||||
provided in <file:Documentation/networking/caif/spi_porting.rst>.
|
||||
|
||||
config CAIF_SPI_SYNC
|
||||
bool "Next command and length in start of frame"
|
||||
|
|
|
@ -30,7 +30,7 @@ config 6PACK
|
|||
|
||||
Note that this driver is still experimental and might cause
|
||||
problems. For details about the features and the usage of the
|
||||
driver, read <file:Documentation/networking/6pack.txt>.
|
||||
driver, read <file:Documentation/networking/6pack.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the module
|
||||
will be called 6pack.
|
||||
|
@ -127,7 +127,7 @@ config BAYCOM_SER_FDX
|
|||
your serial interface chip. To configure the driver, use the sethdlc
|
||||
utility available in the standard ax25 utilities package. For
|
||||
information on the modems, see <http://www.baycom.de/> and
|
||||
<file:Documentation/networking/baycom.txt>.
|
||||
<file:Documentation/networking/baycom.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the module
|
||||
will be called baycom_ser_fdx. This is recommended.
|
||||
|
@ -145,7 +145,7 @@ config BAYCOM_SER_HDX
|
|||
the driver, use the sethdlc utility available in the standard ax25
|
||||
utilities package. For information on the modems, see
|
||||
<http://www.baycom.de/> and
|
||||
<file:Documentation/networking/baycom.txt>.
|
||||
<file:Documentation/networking/baycom.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the module
|
||||
will be called baycom_ser_hdx. This is recommended.
|
||||
|
@ -160,7 +160,7 @@ config BAYCOM_PAR
|
|||
par96 designs. To configure the driver, use the sethdlc utility
|
||||
available in the standard ax25 utilities package. For information on
|
||||
the modems, see <http://www.baycom.de/> and the file
|
||||
<file:Documentation/networking/baycom.txt>.
|
||||
<file:Documentation/networking/baycom.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the module
|
||||
will be called baycom_par. This is recommended.
|
||||
|
@ -175,7 +175,7 @@ config BAYCOM_EPP
|
|||
designs. To configure the driver, use the sethdlc utility available
|
||||
in the standard ax25 utilities package. For information on the
|
||||
modems, see <http://www.baycom.de/> and the file
|
||||
<file:Documentation/networking/baycom.txt>.
|
||||
<file:Documentation/networking/baycom.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the module
|
||||
will be called baycom_epp. This is recommended.
|
||||
|
|
|
@ -336,7 +336,7 @@ config DLCI
|
|||
|
||||
To use frame relay, you need supporting hardware (called FRAD) and
|
||||
certain programs from the net-tools package as explained in
|
||||
<file:Documentation/networking/framerelay.txt>.
|
||||
<file:Documentation/networking/framerelay.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the
|
||||
module will be called dlci.
|
||||
|
@ -361,7 +361,7 @@ config SDLA
|
|||
|
||||
These are multi-protocol cards, but only Frame Relay is supported
|
||||
by the driver at this time. Please read
|
||||
<file:Documentation/networking/framerelay.txt>.
|
||||
<file:Documentation/networking/framerelay.rst>.
|
||||
|
||||
To compile this driver as a module, choose M here: the
|
||||
module will be called sdla.
|
||||
|
|
|
@ -86,7 +86,7 @@ config INET
|
|||
"Sysctl support" below, you can change various aspects of the
|
||||
behavior of the TCP/IP code by writing to the (virtual) files in
|
||||
/proc/sys/net/ipv4/*; the options are explained in the file
|
||||
<file:Documentation/networking/ip-sysctl.txt>.
|
||||
<file:Documentation/networking/ip-sysctl.rst>.
|
||||
|
||||
Short answer: say Y.
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ config ATM
|
|||
of your ATM card below.
|
||||
|
||||
Note that you need a set of user-space programs to actually make use
|
||||
of ATM. See the file <file:Documentation/networking/atm.txt> for
|
||||
of ATM. See the file <file:Documentation/networking/atm.rst> for
|
||||
further details.
|
||||
|
||||
config ATM_CLIP
|
||||
|
|
|
@ -40,7 +40,7 @@ config AX25
|
|||
radio as well as information about how to configure an AX.25 port is
|
||||
contained in the AX25-HOWTO, available from
|
||||
<http://www.tldp.org/docs.html#howto>. You might also want to
|
||||
check out the file <file:Documentation/networking/ax25.txt> in the
|
||||
check out the file <file:Documentation/networking/ax25.rst> in the
|
||||
kernel source. More information about digital amateur radio in
|
||||
general is on the WWW at
|
||||
<http://www.tapr.org/>.
|
||||
|
@ -88,7 +88,7 @@ config NETROM
|
|||
users as well as information about how to configure an AX.25 port is
|
||||
contained in the Linux Ham Wiki, available from
|
||||
<http://www.linux-ax25.org>. You also might want to check out the
|
||||
file <file:Documentation/networking/ax25.txt>. More information about
|
||||
file <file:Documentation/networking/ax25.rst>. More information about
|
||||
digital amateur radio in general is on the WWW at
|
||||
<http://www.tapr.org/>.
|
||||
|
||||
|
@ -107,7 +107,7 @@ config ROSE
|
|||
users as well as information about how to configure an AX.25 port is
|
||||
contained in the Linux Ham Wiki, available from
|
||||
<http://www.linux-ax25.org>. You also might want to check out the
|
||||
file <file:Documentation/networking/ax25.txt>. More information about
|
||||
file <file:Documentation/networking/ax25.rst>. More information about
|
||||
digital amateur radio in general is on the WWW at
|
||||
<http://www.tapr.org/>.
|
||||
|
||||
|
|
|
@ -39,6 +39,6 @@ config CEPH_LIB_USE_DNS_RESOLVER
|
|||
be resolved using the CONFIG_DNS_RESOLVER facility.
|
||||
|
||||
For information on how to use CONFIG_DNS_RESOLVER consult
|
||||
Documentation/networking/dns_resolver.txt
|
||||
Documentation/networking/dns_resolver.rst
|
||||
|
||||
If unsure, say N.
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
* Jamal Hadi Salim
|
||||
* Alexey Kuznetsov, <kuznet@ms2.inr.ac.ru>
|
||||
*
|
||||
* See Documentation/networking/gen_stats.txt
|
||||
* See Documentation/networking/gen_stats.rst
|
||||
*/
|
||||
|
||||
#include <linux/types.h>
|
||||
|
|
|
@ -15,7 +15,7 @@ config DECNET
|
|||
<http://linux-decnet.sourceforge.net/>.
|
||||
|
||||
More detailed documentation is available in
|
||||
<file:Documentation/networking/decnet.txt>.
|
||||
<file:Documentation/networking/decnet.rst>.
|
||||
|
||||
Be sure to say Y to "/proc file system support" and "Sysctl support"
|
||||
below when using DECnet, since you will need sysctl support to aid
|
||||
|
@ -40,4 +40,4 @@ config DECNET_ROUTER
|
|||
filtering" option will be required for the forthcoming routing daemon
|
||||
to work.
|
||||
|
||||
See <file:Documentation/networking/decnet.txt> for more information.
|
||||
See <file:Documentation/networking/decnet.rst> for more information.
|
||||
|
|
|
@ -19,7 +19,7 @@ config DNS_RESOLVER
|
|||
SMB2 later. DNS Resolver is supported by the userspace upcall
|
||||
helper "/sbin/dns.resolver" via /etc/request-key.conf.
|
||||
|
||||
See <file:Documentation/networking/dns_resolver.txt> for further
|
||||
See <file:Documentation/networking/dns_resolver.rst> for further
|
||||
information.
|
||||
|
||||
To compile this as a module, choose M here: the module will be called
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
/* Key type used to cache DNS lookups made by the kernel
|
||||
*
|
||||
* See Documentation/networking/dns_resolver.txt
|
||||
* See Documentation/networking/dns_resolver.rst
|
||||
*
|
||||
* Copyright (c) 2007 Igor Mammedov
|
||||
* Author(s): Igor Mammedov (niallain@gmail.com)
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
/* Upcall routine, designed to work as a key type and working through
|
||||
* /sbin/request-key to contact userspace when handling DNS queries.
|
||||
*
|
||||
* See Documentation/networking/dns_resolver.txt
|
||||
* See Documentation/networking/dns_resolver.rst
|
||||
*
|
||||
* Copyright (c) 2007 Igor Mammedov
|
||||
* Author(s): Igor Mammedov (niallain@gmail.com)
|
||||
|
|
|
@ -49,7 +49,7 @@ config IP_ADVANCED_ROUTER
|
|||
|
||||
Note that some distributions enable it in startup scripts.
|
||||
For details about rp_filter strict and loose mode read
|
||||
<file:Documentation/networking/ip-sysctl.txt>.
|
||||
<file:Documentation/networking/ip-sysctl.rst>.
|
||||
|
||||
If unsure, say N here.
|
||||
|
||||
|
|
|
@ -853,7 +853,7 @@ static bool icmp_unreach(struct sk_buff *skb)
|
|||
case ICMP_FRAG_NEEDED:
|
||||
/* for documentation of the ip_no_pmtu_disc
|
||||
* values please see
|
||||
* Documentation/networking/ip-sysctl.txt
|
||||
* Documentation/networking/ip-sysctl.rst
|
||||
*/
|
||||
switch (net->ipv4.sysctl_ip_no_pmtu_disc) {
|
||||
default:
|
||||
|
|
|
@ -13,7 +13,7 @@ menuconfig IPV6
|
|||
For general information about IPv6, see
|
||||
<https://en.wikipedia.org/wiki/IPv6>.
|
||||
For specific information about IPv6 under Linux, see
|
||||
Documentation/networking/ipv6.txt and read the HOWTO at
|
||||
Documentation/networking/ipv6.rst and read the HOWTO at
|
||||
<http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/>
|
||||
|
||||
To compile this protocol support as a module, choose M here: the
|
||||
|
|
|
@ -11,7 +11,7 @@
|
|||
*
|
||||
* How to get into it:
|
||||
*
|
||||
* 1) read Documentation/networking/filter.txt
|
||||
* 1) read Documentation/networking/filter.rst
|
||||
* 2) Run `bpf_asm [-c] <filter-prog file>` to translate into binary
|
||||
* blob that is loadable with xt_bpf, cls_bpf et al. Note: -c will
|
||||
* pretty print a C-like construct.
|
||||
|
|
|
@ -13,7 +13,7 @@
|
|||
* for making a verdict when multiple simple BPF programs are combined
|
||||
* into one in order to prevent parsing same headers multiple times.
|
||||
*
|
||||
* More on how to debug BPF opcodes see Documentation/networking/filter.txt
|
||||
* More on how to debug BPF opcodes see Documentation/networking/filter.rst
|
||||
* which is the main document on BPF. Mini howto for getting started:
|
||||
*
|
||||
* 1) `./bpf_dbg` to enter the shell (shell cmds denoted with '>'):
|
||||
|
|
Loading…
Reference in a new issue