bkgpl/cyb4_linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Creation of Cybook 2416 (actually Gen4) repository

Browse Source
This commit is contained in:
mlt
2009-12-18 17:10:00 +00:00
committed by godzil
commit 76f20f4d40
13791 changed files with 6812321 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

125
Documentation/networking/00-INDEX Normal file
View File

@@ -0,0 +1,125 @@
00-INDEX
- this file
3c505.txt
- information on the 3Com EtherLink Plus (3c505) driver.
6pack.txt
- info on the 6pack protocol, an alternative to KISS for AX.25
Configurable
- info on some of the configurable network parameters
DLINK.txt
- info on the D-Link DE-600/DE-620 parallel port pocket adapters
PLIP.txt
- PLIP: The Parallel Line Internet Protocol device driver
README.sb1000
- info on General Instrument/NextLevel SURFboard1000 cable modem.
alias.txt
- info on using alias network devices
arcnet-hardware.txt
- tons of info on ARCnet, hubs, jumper settings for ARCnet cards, etc.
arcnet.txt
- info on the using the ARCnet driver itself.
atm.txt
- info on where to get ATM programs and support for Linux.
ax25.txt
- info on using AX.25 and NET/ROM code for Linux
baycom.txt
- info on the driver for Baycom style amateur radio modems
bridge.txt
- where to get user space programs for ethernet bridging with Linux.
comx.txt
- info on drivers for COMX line of synchronous serial adapters.
cops.txt
- info on the COPS LocalTalk Linux driver
cs89x0.txt
- the Crystal LAN (CS8900/20-based) Ethernet ISA adapter driver
de4x5.txt
- the Digital EtherWORKS DE4?? and DE5?? PCI Ethernet driver
decnet.txt
- info on using the DECnet networking layer in Linux.
depca.txt
- the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver
dgrs.txt
- the Digi International RightSwitch SE-X Ethernet driver
dmfe.txt
- info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver.
e100.txt
- info on Intel's EtherExpress PRO/100 line of 10/100 boards
e1000.txt
- info on Intel's E1000 line of gigabit ethernet boards
eql.txt
- serial IP load balancing
ethertap.txt
- the Ethertap user space packet reception and transmission driver
ewrk3.txt
- the Digital EtherWORKS 3 DE203/4/5 Ethernet driver
filter.txt
- Linux Socket Filtering
fore200e.txt
- FORE Systems PCA-200E/SBA-200E ATM NIC driver info.
framerelay.txt
- info on using Frame Relay/Data Link Connection Identifier (DLCI).
generic_netlink.txt
- info on Generic Netlink
ip-sysctl.txt
- /proc/sys/net/ipv4/* variables
ip_dynaddr.txt
- IP dynamic address hack e.g. for auto-dialup links
ipddp.txt
- AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation
iphase.txt
- Interphase PCI ATM (i)Chip IA Linux driver info.
irda.txt
- where to get IrDA (infrared) utilities and info for Linux.
lapb-module.txt
- programming information of the LAPB module.
ltpc.txt
- the Apple or Farallon LocalTalk PC card driver
multicast.txt
- Behaviour of cards under Multicast
ncsa-telnet
- notes on how NCSA telnet (DOS) breaks with MTU discovery enabled.
net-modules.txt
- info and "insmod" parameters for all network driver modules.
netdevices.txt
- info on network device driver functions exported to the kernel.
olympic.txt
- IBM PCI Pit/Pit-Phy/Olympic Token Ring driver info.
policy-routing.txt
- IP policy-based routing
pt.txt
- the Gracilis Packetwin AX.25 device driver
ray_cs.txt
- Raylink Wireless LAN card driver info.
routing.txt
- the new routing mechanism
shaper.txt
- info on the module that can shape/limit transmitted traffic.
sk98lin.txt
- Marvell Yukon Chipset / SysKonnect SK-98xx compliant Gigabit
Ethernet Adapter family driver info
skfp.txt
- SysKonnect FDDI (SK-5xxx, Compaq Netelligent) driver info.
smc9.txt
- the driver for SMC's 9000 series of Ethernet cards
smctr.txt
- SMC TokenCard TokenRing Linux driver info.
tcp.txt
- short blurb on how TCP output takes place.
tlan.txt
- ThunderLAN (Compaq Netelligent 10/100, Olicom OC-2xxx) driver info.
tms380tr.txt
- SysKonnect Token Ring ISA/PCI adapter driver info.
tuntap.txt
- TUN/TAP device driver, allowing user space Rx/Tx of packets.
vortex.txt
- info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards.
wan-router.txt
- WAN router documentation
wavelan.txt
- AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver
x25.txt
- general info on X.25 development.
x25-iface.txt
- description of the X.25 Packet Layer to LAPB device interface.
z8530drv.txt
- info about Linux driver for Z8530 based HDLC cards for AX.25

58
Documentation/networking/3c359.txt Normal file
View File

@@ -0,0 +1,58 @@
3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS README
Release 0.9.0 - Release
Jul 17th 2000 Mike Phillips
1.2.0 - Final
Feb 17th 2002 Mike Phillips
Updated for submission to the 2.4.x kernel.
Thanks:
Terry Murphy from 3Com for tech docs and support,
Adam D. Ligas for testing the driver.
Note:
This driver will NOT work with the 3C339 Token Ring cards, you need
to use the tms380 driver instead.
Options:
The driver accepts three options: ringspeed, pkt_buf_sz and message_level.
These options can be specified differently for each card found.
ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will
make the card autosense the ringspeed and join at the appropriate speed,
this will be the default option for most people. 4 or 16 allow you to
explicitly force the card to operate at a certain speed. The card will fail
if you try to insert it at the wrong speed. (Although some hubs will allow
this so be *very* careful). The main purpose for explicitly setting the ring
speed is for when the card is first on the ring. In autosense mode, if the card
cannot detect any active monitors on the ring it will open at the same speed as
its last opening. This can be hazardous if this speed does not match the speed
you want the ring to operate at.
pkt_buf_sz: This is this initial receive buffer allocation size. This will
default to 4096 if no value is entered. You may increase performance of the
driver by setting this to a value larger than the network packet size, although
the driver now re-sizes buffers based on MTU settings as well.
message_level: Controls level of messages created by the driver. Defaults to 0:
which only displays start-up and critical messages. Presently any non-zero
value will display all soft messages as well. NB This does not turn
debugging messages on, that must be done by modified the source code.
Variable MTU size:
The driver can handle a MTU size upto either 4500 or 18000 depending upon
ring speed. The driver also changes the size of the receive buffers as part
of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
position = 296,000 bytes of memory space, plus of course anything
necessary for the tx sk_buff's. Remember this is per card, so if you are
building routers, gateway's etc, you could start to use a lot of memory
real fast.
2/17/02 Mike Phillips

46
Documentation/networking/3c505.txt Normal file
View File

@@ -0,0 +1,46 @@
The 3Com Etherlink Plus (3c505) driver.
This driver now uses DMA. There is currently no support for PIO operation.
The default DMA channel is 6; this is _not_ autoprobed, so you must
make sure you configure it correctly. If loading the driver as a
module, you can do this with "modprobe 3c505 dma=n". If the driver is
linked statically into the kernel, you must either use an "ether="
statement on the command line, or change the definition of ELP_DMA in 3c505.h.
The driver will warn you if it has to fall back on the compiled in
default DMA channel.
If no base address is given at boot time, the driver will autoprobe
ports 0x300, 0x280 and 0x310 (in that order). If no IRQ is given, the driver
will try to probe for it.
The driver can be used as a loadable module. See net-modules.txt for details
of the parameters it can take.
Theoretically, one instance of the driver can now run multiple cards,
in the standard way (when loading a module, say "modprobe 3c505
io=0x300,0x340 irq=10,11 dma=6,7" or whatever). I have not tested
this, though.
The driver may now support revision 2 hardware; the dependency on
being able to read the host control register has been removed. This
is also untested, since I don't have a suitable card.
Known problems:
I still see "DMA upload timed out" messages from time to time. These
seem to be fairly non-fatal though.
The card is old and slow.
To do:
Improve probe/setup code
Test multicast and promiscuous operation
Authors:
The driver is mainly written by Craig Southeren, email
<craigs@ineluki.apana.org.au>.
Parts of the driver (adapting the driver to 1.1.4+ kernels,
IRQ/address detection, some changes) and this README by
Juha Laiho <jlaiho@ichaos.nullnet.fi>.
DMA mode, more fixes, etc, by Philip Blundell <pjb27@cam.ac.uk>
Multicard support, Software configurable DMA, etc., by
Christopher Collins <ccollins@pcug.org.au>

210
Documentation/networking/3c509.txt Normal file
View File

@@ -0,0 +1,210 @@
Linux and the 3Com EtherLink III Series Ethercards (driver v1.18c and higher)
----------------------------------------------------------------------------
This file contains the instructions and caveats for v1.18c and higher versions
of the 3c509 driver. You should not use the driver without reading this file.
release 1.0
28 February 2002
Current maintainer (corrections to):
David Ruggiero <jdr@farfalle.com>
----------------------------------------------------------------------------
(0) Introduction
The following are notes and information on using the 3Com EtherLink III series
ethercards in Linux. These cards are commonly known by the most widely-used
card's 3Com model number, 3c509. They are all 10mb/s ISA-bus cards and shouldn't
be (but sometimes are) confused with the similarly-numbered PCI-bus "3c905"
(aka "Vortex" or "Boomerang") series. Kernel support for the 3c509 family is
provided by the module 3c509.c, which has code to support all of the following
models:
3c509 (original ISA card)
3c509B (later revision of the ISA card; supports full-duplex)
3c589 (PCMCIA)
3c589B (later revision of the 3c589; supports full-duplex)
3c529 (MCA)
3c579 (EISA)
Large portions of this documentation were heavily borrowed from the guide
written the original author of the 3c509 driver, Donald Becker. The master
copy of that document, which contains notes on older versions of the driver,
currently resides on Scyld web server: http://www.scyld.com/network/3c509.html.
(1) Special Driver Features
Overriding card settings
The driver allows boot- or load-time overriding of the card's detected IOADDR,
IRQ, and transceiver settings, although this capability shouldn't generally be
needed except to enable full-duplex mode (see below). An example of the syntax
for LILO parameters for doing this:
ether=10,0x310,3,0x3c509,eth0
This configures the first found 3c509 card for IRQ 10, base I/O 0x310, and
transceiver type 3 (10base2). The flag "0x3c509" must be set to avoid conflicts
with other card types when overriding the I/O address. When the driver is
loaded as a module, only the IRQ and transceiver setting may be overridden.
For example, setting two cards to 10base2/IRQ10 and AUI/IRQ11 is done by using
the xcvr and irq module options:
options 3c509 xcvr=3,1 irq=10,11
(2) Full-duplex mode
The v1.18c driver added support for the 3c509B's full-duplex capabilities.
In order to enable and successfully use full-duplex mode, three conditions
must be met:
(a) You must have a Etherlink III card model whose hardware supports full-
duplex operations. Currently, the only members of the 3c509 family that are
positively known to support full-duplex are the 3c509B (ISA bus) and 3c589B
(PCMCIA) cards. Cards without the "B" model designation do *not* support
full-duplex mode; these include the original 3c509 (no "B"), the original
3c589, the 3c529 (MCA bus), and the 3c579 (EISA bus).
(b) You must be using your card's 10baseT transceiver (i.e., the RJ-45
connector), not its AUI (thick-net) or 10base2 (thin-net/coax) interfaces.
AUI and 10base2 network cabling is physically incapable of full-duplex
operation.
(c) Most importantly, your 3c509B must be connected to a link partner that is
itself full-duplex capable. This is almost certainly one of two things: a full-
duplex-capable Ethernet switch (*not* a hub), or a full-duplex-capable NIC on
another system that's connected directly to the 3c509B via a crossover cable.
/////Extremely important caution concerning full-duplex mode/////
Understand that the 3c509B's hardware's full-duplex support is much more
limited than that provide by more modern network interface cards. Although
at the physical layer of the network it fully supports full-duplex operation,
the card was designed before the current Ethernet auto-negotiation (N-way)
spec was written. This means that the 3c509B family ***cannot and will not
auto-negotiate a full-duplex connection with its link partner under any
circumstances, no matter how it is initialized***. If the full-duplex mode
of the 3c509B is enabled, its link partner will very likely need to be
independently _forced_ into full-duplex mode as well; otherwise various nasty
failures will occur - at the very least, you'll see massive numbers of packet
collisions. This is one of very rare circumstances where disabling auto-
negotiation and forcing the duplex mode of a network interface card or switch
would ever be necessary or desirable.
(3) Available Transceiver Types
For versions of the driver v1.18c and above, the available transceiver types are:
0 transceiver type from EEPROM config (normally 10baseT); force half-duplex
1 AUI (thick-net / DB15 connector)
2 (undefined)
3 10base2 (thin-net == coax / BNC connector)
4 10baseT (RJ-45 connector); force half-duplex mode
8 transceiver type and duplex mode taken from card's EEPROM config settings
12 10baseT (RJ-45 connector); force full-duplex mode
Prior to driver version 1.18c, only transceiver codes 0-4 were supported. Note
that the new transceiver codes 8 and 12 are the *only* ones that will enable
full-duplex mode, no matter what the card's detected EEPROM settings might be.
This insured that merely upgrading the driver from an earlier version would
never automatically enable full-duplex mode in an existing installation;
it must always be explicitly enabled via one of these code in order to be
activated.
(4a) Interpretation of error messages and common problems
Error Messages
eth0: Infinite loop in interrupt, status 2011.
These are "mostly harmless" message indicating that the driver had too much
work during that interrupt cycle. With a status of 0x2011 you are receiving
packets faster than they can be removed from the card. This should be rare
or impossible in normal operation. Possible causes of this error report are:
- a "green" mode enabled that slows the processor down when there is no
keyboard activity.
- some other device or device driver hogging the bus or disabling interrupts.
Check /proc/interrupts for excessive interrupt counts. The timer tick
interrupt should always be incrementing faster than the others.
No received packets
If a 3c509, 3c562 or 3c589 can successfully transmit packets, but never
receives packets (as reported by /proc/net/dev or 'ifconfig') you likely
have an interrupt line problem. Check /proc/interrupts to verify that the
card is actually generating interrupts. If the interrupt count is not
increasing you likely have a physical conflict with two devices trying to
use the same ISA IRQ line. The common conflict is with a sound card on IRQ10
or IRQ5, and the easiest solution is to move the 3c509 to a different
interrupt line. If the device is receiving packets but 'ping' doesn't work,
you have a routing problem.
Tx Carrier Errors Reported in /proc/net/dev
If an EtherLink III appears to transmit packets, but the "Tx carrier errors"
field in /proc/net/dev increments as quickly as the Tx packet count, you
likely have an unterminated network or the incorrect media transceiver selected.
3c509B card is not detected on machines with an ISA PnP BIOS.
While the updated driver works with most PnP BIOS programs, it does not work
with all. This can be fixed by disabling PnP support using the 3Com-supplied
setup program.
3c509 card is not detected on overclocked machines
Increase the delay time in id_read_eeprom() from the current value, 500,
to an absurdly high value, such as 5000.
(4b) Decoding Status and Error Messages
The bits in the main status register are:
value description
0x01 Interrupt latch
0x02 Tx overrun, or Rx underrun
0x04 Tx complete
0x08 Tx FIFO room available
0x10 A complete Rx packet has arrived
0x20 A Rx packet has started to arrive
0x40 The driver has requested an interrupt
0x80 Statistics counter nearly full
The bits in the transmit (Tx) status word are:
value description
0x02 Out-of-window collision.
0x04 Status stack overflow (normally impossible).
0x08 16 collisions.
0x10 Tx underrun (not enough PCI bus bandwidth).
0x20 Tx jabber.
0x40 Tx interrupt requested.
0x80 Status is valid (this should always be set).
When a transmit error occurs the driver produces a status message such as
eth0: Transmit error, Tx status register 82
The two values typically seen here are:
0x82
Out of window collision. This typically occurs when some other Ethernet
host is incorrectly set to full duplex on a half duplex network.
0x88
16 collisions. This typically occurs when the network is exceptionally busy
or when another host doesn't correctly back off after a collision. If this
error is mixed with 0x82 errors it is the result of a host incorrectly set
to full duplex (see above).
Both of these errors are the result of network problems that should be
corrected. They do not represent driver malfunction.
(5) Revision history (this file)
28Feb02 v1.0 DR New; major portions based on Becker original 3c509 docs

175
Documentation/networking/6pack.txt Normal file
View File

@@ -0,0 +1,175 @@
This is the 6pack-mini-HOWTO, written by
Andreas K<>nsgen DG3KQ
Internet: ajk@iehk.rwth-aachen.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
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
(however, this feature is not supported yet by the Linux 6pack driver).
- Each packet transferred over the serial line is supplied with a checksum,
so it is easy to detect errors due to problems on the serial line.
Received packets that are corrupt are not passed on to the AX.25 layer.
Damaged packets that the TNC has received from the PC are not transmitted.
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
Matthias Welwarsky DG2FEF, comes along with the PC version of FlexNet.
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
program an EPROM yourself. The image file for 6pack EPROMs should be
available on any packet radio box where PC/FlexNet can be found. The name of
the file is 6pack.bin. This file is copyrighted and maintained by the FlexNet
team. It can be used under the terms of the license that comes along
with PC/FlexNet. Please do not ask me about the internals of this file as I
don't know anything about it. I used a textual description of the 6pack
protocol to program the Linux driver.
TNCs contain a 64kByte EPROM, the lower half of which is used for
the firmware/KISS. The upper half is either empty or is sometimes
programmed with software called TAPR. In the latter case, the TNC
is supplied with a DIP switch so you can easily change between the
two systems. When programming a new EPROM, one of the systems is replaced
by 6pack. It is useful to replace TAPR, as this software is rarely used
nowadays. If your TNC is not equipped with the switch mentioned above, you
can build in one yourself that switches over the highest address pin
of the EPROM between HIGH and LOW level. After having inserted the new EPROM
and switched to 6pack, apply power to the TNC for a first test. The connect
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.
- Select the amateur radio support menu and turn on the serial port 6pack
driver.
- Compile and install the kernel and the modules.
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:
#ifndef N_6PACK
#define N_6PACK (N_AX25+1)
#endif
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
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'.
- From here, everything should work as if you were setting up a KISS port.
The only difference is that the network device that represents
the 6pack port is called sp instead of sl or ax. So, sp0 would be the
first 6pack port.
Although the driver has been tested on various platforms, I still declare it
ALPHA. BE CAREFUL! Sync your disks before insmoding the 6pack module
and spattaching. Watch out if your computer behaves strangely. Read section
6 of this file about known problems.
Note that the connect and status LEDs of the TNC are controlled in a
different way than they are when the TNC is used with PC/FlexNet. When using
FlexNet, the connect LED is on if there is a connection; the status LED is
on if there is data in the buffer of the PC's AX.25 engine that has to be
transmitted. Under Linux, the 6pack layer is beyond the AX.25 layer,
so the 6pack driver doesn't know anything about connects or data that
has not yet been transmitted. Therefore the LEDs are controlled
as they are in KISS mode: The connect LED is turned on if data is transferred
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,
the driver may, on certain systems, sometimes print the message '6pack:
bad checksum', which is due to data loss if the other station sends two
or more subsequent packets. I have been told that this is due to a problem
with the serial driver of 2.0.3x kernels. I don't know yet if the problem
still exists with 2.1.x kernels, as I have heard that the serial driver
code has been changed with 2.1.x.
When shutting down the sp interface with ifconfig, the kernel crashes if
there is still an AX.25 connection left over which an IP connection was
running, even if that IP connection is already closed. The problem does not
occur when there is a bare AX.25 connection still running. I don't know if
this is a problem of the 6pack driver or something else in the kernel.
The driver has been tested as a module, not yet as a kernel-builtin driver.
The 6pack protocol supports daisy-chaining of TNCs in a token ring, which is
connected to one serial port of the PC. This feature is not implemented
and at least at the moment I won't be able to do it because I do not have
the opportunity to build a TNC daisy-chain and test it.
Some of the comments in the source code are inaccurate. They are left from
the SLIP/KISS driver, from which the 6pack driver has been derived.
I haven't modified or removed them yet -- sorry! The code itself needs
some cleaning and optimizing. This will be done in a later release.
If you encounter a bug or if you have a question or suggestion concerning the
driver, feel free to mail me, using the addresses given at the beginning of
this file.
Have fun!
Andreas

34
Documentation/networking/Configurable Normal file
View File

@@ -0,0 +1,34 @@
There are a few network parameters that can be tuned to better match
the kernel to your system hardware and intended usage. The defaults
are usually a good choice for 99% of the people 99% of the time, but
you should be aware they do exist and can be changed.
The current list of parameters can be found in the files:
linux/net/TUNABLE
Documentation/networking/ip-sysctl.txt
Some of these are accessible via the sysctl interface, and many more are
scheduled to be added in this way. For example, some parameters related
to Address Resolution Protocol (ARP) are very easily viewed and altered.
# cat /proc/sys/net/ipv4/arp_timeout
6000
# echo 7000 > /proc/sys/net/ipv4/arp_timeout
# cat /proc/sys/net/ipv4/arp_timeout
7000
Others are already accessible via the related user space programs.
For example, MAX_WINDOW has a default of 32 k which is a good choice for
modern hardware, but if you have a slow (8 bit) Ethernet card and/or a slow
machine, then this will be far too big for the card to keep up with fast
machines transmitting on the same net, resulting in overruns and receive errors.
A value of about 4 k would be more appropriate, which can be set via:
# route add -net 192.168.3.0 window 4096
The remainder of these can only be presently changed by altering a #define
in the related header file. This means an edit and recompile cycle.
Paul Gortmaker 06/96

203
Documentation/networking/DLINK.txt Normal file
View File

@@ -0,0 +1,203 @@
Released 1994-06-13
CONTENTS:
1. Introduction.
2. License.
3. Files in this release.
4. Installation.
5. Problems and tuning.
6. Using the drivers with earlier releases.
7. Acknowledgments.
1. INTRODUCTION.
This is a set of Ethernet drivers for the D-Link DE-600/DE-620
pocket adapters, for the parallel port on a Linux based machine.
Some adapter "clones" will also work. Xircom is _not_ a clone...
These drivers _can_ be used as loadable modules,
and were developed for use on Linux 1.1.13 and above.
For use on Linux 1.0.X, or earlier releases, see below.
I have used these drivers for NFS, ftp, telnet and X-clients on
remote machines. Transmissions with ftp seems to work as
good as can be expected (i.e. > 80k bytes/sec) from a
parallel port...:-) Receive speeds will be about 60-80% of this.
Depending on your machine, somewhat higher speeds can be achieved.
All comments/fixes to Bjorn Ekwall (bj0rn@blox.se).
2. LICENSE.
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either
version 2, or (at your option) any later version.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details.
You should have received a copy of the GNU General Public
License along with this program; if not, write to the Free
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA
02139, USA.
3. FILES IN THIS RELEASE.
README.DLINK This file.
de600.c The Source (may it be with You :-) for the DE-600
de620.c ditto for the DE-620
de620.h Macros for de620.c
If you are upgrading from the d-link tar release, there will
also be a "dlink-patches" file that will patch Linux 1.1.18:
linux/drivers/net/Makefile
linux/drivers/net/CONFIG
linux/drivers/net/MODULES
linux/drivers/net/Space.c
linux/config.in
Apply the patch by:
"cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches"
The old source, "linux/drivers/net/d_link.c", can be removed.
4. INSTALLATION.
o Get the latest net binaries, according to current net.wisdom.
o Read the NET-2 and Ethernet HOWTOs and modify your setup.
o If your parallel port has a strange address or irq,
modify "linux/drivers/net/CONFIG" accordingly, or adjust
the parameters in the "tuning" section in the sources.
If you are going to use the drivers as loadable modules, do _not_
enable them while doing "make config", but instead make sure that
the drivers are included in "linux/drivers/net/MODULES".
If you are _not_ going to use the driver(s) as loadable modules,
but instead have them included in the kernel, remember to enable
the drivers while doing "make config".
o To include networking and DE600/DE620 support in your kernel:
# cd /linux
(as modules:)
# make config (answer yes on CONFIG_NET and CONFIG_INET)
(else included in the kernel:)
# make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620)
# make clean
# make zImage (or whatever magic you usually do)
o I use lilo to boot multiple kernels, so that I at least
can have one working kernel :-). If you do too, append
these lines to /etc/lilo/config:
image = /linux/zImage
label = newlinux
root = /dev/hda2 (or whatever YOU have...)
# /etc/lilo/install
o Do "sync" and reboot the new kernel with a D-Link
DE-600/DE-620 pocket adapter connected.
o The adapter can be configured with ifconfig eth?
where the actual number is decided by the kernel
when the drivers are initialized.
5. "PROBLEMS" AND TUNING,
o If you see error messages from the driver, and if the traffic
stops on the adapter, try to do "ifconfig" and "route" once
more, just as in "rc.inet1". This should take care of most
problems, including effects from power loss, or adapters that
aren't connected to the printer port in some way or another.
You can somewhat change the behaviour by enabling/disabling
the macro SHUTDOWN_WHEN_LOST in the "tuning" section.
For the DE-600 there is another macro, CHECK_LOST_DE600,
that you might want to read about in the "tuning" section.
o Some machines have trouble handling the parallel port and
the adapter at high speed. If you experience problems:
DE-600:
- The adapter is not recognized at boot, i.e. an Ethernet
address of 00:80:c8:... is not shown, try to add another
"; SLOW_DOWN_IO"
at DE600_SLOW_DOWN in the "tuning" section. As a last resort,
uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints).
- You experience "timeout" messages: first try to add another
"; SLOW_DOWN_IO"
at DE600_SLOW_DOWN in the "tuning" section, _then_ try to
increase the value (original value: 5) at
"if (tickssofar < 5)" near line 422.
DE-620:
- Your parallel port might be "sluggish". To cater for
this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY
in the "tuning" section. Your first step should be to enable
LOWSPEED, and after that you can "tune" the XXX_DELAY values.
o If the adapter _is_ recognized at boot but you get messages
about "Network Unreachable", then the problem is probably
_not_ with the driver. Check your net configuration instead
(ifconfig and route) in "rc.inet1".
o There is some rudimentary support for debugging, look at
the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3"
when compiling, or include it in "linux/drivers/net/CONFIG".
IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER
WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT!
6. USING THE DRIVERS WITH EARLIER RELEASES.
The later 1.1.X releases of the Linux kernel include some
changes in the networking layer (a.k.a. NET3). This affects
these drivers in a few places. The hints that follow are
_not_ tested by me, since I don't have the disk space to keep
all releases on-line.
Known needed changes to date:
- release patchfile: some patches will fail, but they should
be easy to apply "by hand", since they are trivial.
(Space.c: d_link_init() is now called de600_probe())
- de600.c: change "mark_bh(NET_BH)" to "mark_bh(INET_BH)".
- de620.c: (maybe) change the code around "netif_rx(skb);" to be
similar to the code around "dev_rint(...)" in de600.c
7. ACKNOWLEDGMENTS.
These drivers wouldn't have been done without the base
(and support) from Ross Biro, and D-Link Systems Inc.
The driver relies upon GPL-ed source from D-Link Systems Inc.
and from Russel Nelson at Crynwr Software <nelson@crynwr.com>.
Additional input also from:
Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk>
and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG>
DE-600 alpha release primary victim^H^H^H^H^H^Htester:
- Erik Proper <erikp@cs.kun.nl>.
Good input also from several users, most notably
- Mark Burton <markb@ordern.demon.co.uk>.
DE-620 alpha release victims^H^H^H^H^H^H^Htesters:
- J. Joshua Kopper <kopper@rtsg.mot.com>
- Olav Kvittem <Olav.Kvittem@uninett.no>
- Germano Caronni <caronni@nessie.cs.id.ethz.ch>
- Jeremy Fitzhardinge <jeremy@suite.sw.oz.au>
Happy hacking!
Bjorn Ekwall == bj0rn@blox.se

46
Documentation/networking/LICENSE.qla3xxx Normal file
View File

@@ -0,0 +1,46 @@
Copyright (c) 2003-2006 QLogic Corporation
QLogic Linux Networking HBA Driver
This program includes a device driver for Linux 2.6 that may be
distributed with QLogic hardware specific firmware binary file.
You may modify and redistribute the device driver code under the
GNU General Public License as published by the Free Software
Foundation (version 2 or a later version).
You may redistribute the hardware specific firmware binary file
under the following terms:
1. Redistribution of source code (only if applicable),
must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistribution in binary form must reproduce the above
copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other
materials provided with the distribution.
3. The name of QLogic Corporation may not be used to
endorse or promote products derived from this software
without specific prior written permission
REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
COMBINATION WITH THIS PROGRAM.

766
Documentation/networking/NAPI_HOWTO.txt Normal file
View File

@@ -0,0 +1,766 @@
HISTORY:
February 16/2002 -- revision 0.2.1:
COR typo corrected
February 10/2002 -- revision 0.2:
some spell checking ;->
January 12/2002 -- revision 0.1
This is still work in progress so may change.
To keep up to date please watch this space.
Introduction to NAPI
====================
NAPI is a proven (www.cyberus.ca/~hadi/usenix-paper.tgz) technique
to improve network performance on Linux. For more details please
read that paper.
NAPI provides a "inherent mitigation" which is bound by system capacity
as can be seen from the following data collected by Robert on Gigabit
ethernet (e1000):
Psize Ipps Tput Rxint Txint Done Ndone
---------------------------------------------------------------
60 890000 409362 17 27622 7 6823
128 758150 464364 21 9301 10 7738
256 445632 774646 42 15507 21 12906
512 232666 994445 241292 19147 241192 1062
1024 119061 1000003 872519 19258 872511 0
1440 85193 1000003 946576 19505 946569 0
Legend:
"Ipps" stands for input packets per second.
"Tput" == packets out of total 1M that made it out.
"txint" == transmit completion interrupts seen
"Done" == The number of times that the poll() managed to pull all
packets out of the rx ring. Note from this that the lower the
load the more we could clean up the rxring
"Ndone" == is the converse of "Done". Note again, that the higher
the load the more times we couldn't clean up the rxring.
Observe that:
when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated.
The system cant handle the processing at 1 interrupt/packet at that load level.
At lower rates on the other hand, rx interrupts go up and therefore the
interrupt/packet ratio goes up (as observable from that table). So there is
possibility that under low enough input, you get one poll call for each
input packet caused by a single interrupt each time. And if the system
cant handle interrupt per packet ratio of 1, then it will just have to
chug along ....
0) Prerequisites:
==================
A driver MAY continue using the old 2.4 technique for interfacing
to the network stack and not benefit from the NAPI changes.
NAPI additions to the kernel do not break backward compatibility.
NAPI, however, requires the following features to be available:
A) DMA ring or enough RAM to store packets in software devices.
B) Ability to turn off interrupts or maybe events that send packets up
the stack.
NAPI processes packet events in what is known as dev->poll() method.
Typically, only packet receive events are processed in dev->poll().
The rest of the events MAY be processed by the regular interrupt handler
to reduce processing latency (justified also because there are not that
many of them).
Note, however, NAPI does not enforce that dev->poll() only processes
receive events.
Tests with the tulip driver indicated slightly increased latency if
all of the interrupt handler is moved to dev->poll(). Also MII handling
gets a little trickier.
The example used in this document is to move the receive processing only
to dev->poll(); this is shown with the patch for the tulip driver.
For an example of code that moves all the interrupt driver to
dev->poll() look at the ported e1000 code.
There are caveats that might force you to go with moving everything to
dev->poll(). Different NICs work differently depending on their status/event
acknowledgement setup.
There are two types of event register ACK mechanisms.
I) what is known as Clear-on-read (COR).
when you read the status/event register, it clears everything!
The natsemi and sunbmac NICs are known to do this.
In this case your only choice is to move all to dev->poll()
II) Clear-on-write (COW)
i) you clear the status by writing a 1 in the bit-location you want.
These are the majority of the NICs and work the best with NAPI.
Put only receive events in dev->poll(); leave the rest in
the old interrupt handler.
ii) whatever you write in the status register clears every thing ;->
Cant seem to find any supported by Linux which do this. If
someone knows such a chip email us please.
Move all to dev->poll()
C) Ability to detect new work correctly.
NAPI works by shutting down event interrupts when there's work and
turning them on when there's none.
New packets might show up in the small window while interrupts were being
re-enabled (refer to appendix 2). A packet might sneak in during the period
we are enabling interrupts. We only get to know about such a packet when the
next new packet arrives and generates an interrupt.
Essentially, there is a small window of opportunity for a race condition
which for clarity we'll refer to as the "rotting packet".
This is a very important topic and appendix 2 is dedicated for more
discussion.
Locking rules and environmental guarantees
==========================================
-Guarantee: Only one CPU at any time can call dev->poll(); this is because
only one CPU can pick the initial interrupt and hence the initial
netif_rx_schedule(dev);
- The core layer invokes devices to send packets in a round robin format.
This implies receive is totally lockless because of the guarantee that only
one CPU is executing it.
- contention can only be the result of some other CPU accessing the rx
ring. This happens only in close() and suspend() (when these methods
try to clean the rx ring);
****guarantee: driver authors need not worry about this; synchronization
is taken care for them by the top net layer.
-local interrupts are enabled (if you dont move all to dev->poll()). For
example link/MII and txcomplete continue functioning just same old way.
This improves the latency of processing these events. It is also assumed that
the receive interrupt is the largest cause of noise. Note this might not
always be true.
[according to Manfred Spraul, the winbond insists on sending one
txmitcomplete interrupt for each packet (although this can be mitigated)].
For these broken drivers, move all to dev->poll().
For the rest of this text, we'll assume that dev->poll() only
processes receive events.
new methods introduce by NAPI
=============================
a) netif_rx_schedule(dev)
Called by an IRQ handler to schedule a poll for device
b) netif_rx_schedule_prep(dev)
puts the device in a state which allows for it to be added to the
CPU polling list if it is up and running. You can look at this as
the first half of netif_rx_schedule(dev) above; the second half
being c) below.
c) __netif_rx_schedule(dev)
Add device to the poll list for this CPU; assuming that _prep above
has already been called and returned 1.
d) netif_rx_reschedule(dev, undo)
Called to reschedule polling for device specifically for some
deficient hardware. Read Appendix 2 for more details.
e) netif_rx_complete(dev)
Remove interface from the CPU poll list: it must be in the poll list
on current cpu. This primitive is called by dev->poll(), when
it completes its work. The device cannot be out of poll list at this
call, if it is then clearly it is a BUG(). You'll know ;->
All these above nethods are used below. So keep reading for clarity.
Device driver changes to be made when porting NAPI
==================================================
Below we describe what kind of changes are required for NAPI to work.
1) introduction of dev->poll() method
=====================================
This is the method that is invoked by the network core when it requests
for new packets from the driver. A driver is allowed to send upto
dev->quota packets by the current CPU before yielding to the network
subsystem (so other devices can also get opportunity to send to the stack).
dev->poll() prototype looks as follows:
int my_poll(struct net_device *dev, int *budget)
budget is the remaining number of packets the network subsystem on the
current CPU can send up the stack before yielding to other system tasks.
*Each driver is responsible for decrementing budget by the total number of
packets sent.
Total number of packets cannot exceed dev->quota.
dev->poll() method is invoked by the top layer, the driver just sends if it
can to the stack the packet quantity requested.
more on dev->poll() below after the interrupt changes are explained.
2) registering dev->poll() method
===================================
dev->poll should be set in the dev->probe() method.
e.g:
dev->open = my_open;
.
.
/* two new additions */
/* first register my poll method */
dev->poll = my_poll;
/* next register my weight/quanta; can be overridden in /proc */
dev->weight = 16;
.
.
dev->stop = my_close;
3) scheduling dev->poll()
=============================
This involves modifying the interrupt handler and the code
path which takes the packet off the NIC and sends them to the
stack.
it's important at this point to introduce the classical D Becker
interrupt processor:
------------------
static irqreturn_t
netdevice_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
struct net_device *dev = (struct net_device *)dev_instance;
struct my_private *tp = (struct my_private *)dev->priv;
int work_count = my_work_count;
status = read_interrupt_status_reg();
if (status == 0)
return IRQ_NONE; /* Shared IRQ: not us */
if (status == 0xffff)
return IRQ_HANDLED; /* Hot unplug */
if (status & error)
do_some_error_handling()
do {
acknowledge_ints_ASAP();
if (status & link_interrupt) {
spin_lock(&tp->link_lock);
do_some_link_stat_stuff();
spin_lock(&tp->link_lock);
}
if (status & rx_interrupt) {
receive_packets(dev);
}
if (status & rx_nobufs) {
make_rx_buffs_avail();
}
if (status & tx_related) {
spin_lock(&tp->lock);
tx_ring_free(dev);
if (tx_died)
restart_tx();
spin_unlock(&tp->lock);
}
status = read_interrupt_status_reg();
} while (!(status & error) || more_work_to_be_done);
return IRQ_HANDLED;
}
----------------------------------------------------------------------
We now change this to what is shown below to NAPI-enable it:
----------------------------------------------------------------------
static irqreturn_t
netdevice_interrupt(int irq, void *dev_id, struct pt_regs *regs)
{
struct net_device *dev = (struct net_device *)dev_instance;
struct my_private *tp = (struct my_private *)dev->priv;
status = read_interrupt_status_reg();
if (status == 0)
return IRQ_NONE; /* Shared IRQ: not us */
if (status == 0xffff)
return IRQ_HANDLED; /* Hot unplug */
if (status & error)
do_some_error_handling();
do {
/************************ start note *********************************/
acknowledge_ints_ASAP(); // dont ack rx and rxnobuff here
/************************ end note *********************************/
if (status & link_interrupt) {
spin_lock(&tp->link_lock);
do_some_link_stat_stuff();
spin_unlock(&tp->link_lock);
}
/************************ start note *********************************/
if (status & rx_interrupt || (status & rx_nobuffs)) {
if (netif_rx_schedule_prep(dev)) {
/* disable interrupts caused
* by arriving packets */
disable_rx_and_rxnobuff_ints();
/* tell system we have work to be done. */
__netif_rx_schedule(dev);
} else {
printk("driver bug! interrupt while in poll\n");
/* FIX by disabling interrupts */
disable_rx_and_rxnobuff_ints();
}
}
/************************ end note note *********************************/
if (status & tx_related) {
spin_lock(&tp->lock);
tx_ring_free(dev);
if (tx_died)
restart_tx();
spin_unlock(&tp->lock);
}
status = read_interrupt_status_reg();
/************************ start note *********************************/
} while (!(status & error) || more_work_to_be_done(status));
/************************ end note note *********************************/
return IRQ_HANDLED;
}
---------------------------------------------------------------------
We note several things from above:
I) Any interrupt source which is caused by arriving packets is now
turned off when it occurs. Depending on the hardware, there could be
several reasons that arriving packets would cause interrupts; these are the
interrupt sources we wish to avoid. The two common ones are a) a packet
arriving (rxint) b) a packet arriving and finding no DMA buffers available
(rxnobuff) .
This means also acknowledge_ints_ASAP() will not clear the status
register for those two items above; clearing is done in the place where
proper work is done within NAPI; at the poll() and refill_rx_ring()
discussed further below.
netif_rx_schedule_prep() returns 1 if device is in running state and
gets successfully added to the core poll list. If we get a zero value
we can _almost_ assume are already added to the list (instead of not running.
Logic based on the fact that you shouldn't get interrupt if not running)
We rectify this by disabling rx and rxnobuf interrupts.
II) that receive_packets(dev) and make_rx_buffs_avail() may have disappeared.
These functionalities are still around actually......
infact, receive_packets(dev) is very close to my_poll() and
make_rx_buffs_avail() is invoked from my_poll()
4) converting receive_packets() to dev->poll()
===============================================
We need to convert the classical D Becker receive_packets(dev) to my_poll()
First the typical receive_packets() below:
-------------------------------------------------------------------
/* this is called by interrupt handler */
static void receive_packets (struct net_device *dev)
{
struct my_private *tp = (struct my_private *)dev->priv;
rx_ring = tp->rx_ring;
cur_rx = tp->cur_rx;
int entry = cur_rx % RX_RING_SIZE;
int received = 0;
int rx_work_limit = tp->dirty_rx + RX_RING_SIZE - tp->cur_rx;
while (rx_ring_not_empty) {
u32 rx_status;
unsigned int rx_size;
unsigned int pkt_size;
struct sk_buff *skb;
/* read size+status of next frame from DMA ring buffer */
/* the number 16 and 4 are just examples */
rx_status = le32_to_cpu (*(u32 *) (rx_ring + ring_offset));
rx_size = rx_status >> 16;
pkt_size = rx_size - 4;
/* process errors */
if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) ||
(!(rx_status & RxStatusOK))) {
netdrv_rx_err (rx_status, dev, tp, ioaddr);
return;
}
if (--rx_work_limit < 0)
break;
/* grab a skb */
skb = dev_alloc_skb (pkt_size + 2);
if (skb) {
.
.
netif_rx (skb);
.
.
} else { /* OOM */
/*seems very driver specific ... some just pass
whatever is on the ring already. */
}
/* move to the next skb on the ring */
entry = (++tp->cur_rx) % RX_RING_SIZE;
received++ ;
}
/* store current ring pointer state */
tp->cur_rx = cur_rx;
/* Refill the Rx ring buffers if they are needed */
refill_rx_ring();
.
.
}
-------------------------------------------------------------------
We change it to a new one below; note the additional parameter in
the call.
-------------------------------------------------------------------
/* this is called by the network core */
static int my_poll (struct net_device *dev, int *budget)
{
struct my_private *tp = (struct my_private *)dev->priv;
rx_ring = tp->rx_ring;
cur_rx = tp->cur_rx;
int entry = cur_rx % RX_BUF_LEN;
/* maximum packets to send to the stack */
/************************ note note *********************************/
int rx_work_limit = dev->quota;
/************************ end note note *********************************/
do { // outer beginning loop starts here
clear_rx_status_register_bit();
while (rx_ring_not_empty) {
u32 rx_status;
unsigned int rx_size;
unsigned int pkt_size;
struct sk_buff *skb;
/* read size+status of next frame from DMA ring buffer */
/* the number 16 and 4 are just examples */
rx_status = le32_to_cpu (*(u32 *) (rx_ring + ring_offset));
rx_size = rx_status >> 16;
pkt_size = rx_size - 4;
/* process errors */
if ((rx_size > (MAX_ETH_FRAME_SIZE+4)) ||
(!(rx_status & RxStatusOK))) {
netdrv_rx_err (rx_status, dev, tp, ioaddr);
return 1;
}
/************************ note note *********************************/
if (--rx_work_limit < 0) { /* we got packets, but no quota */
/* store current ring pointer state */
tp->cur_rx = cur_rx;
/* Refill the Rx ring buffers if they are needed */
refill_rx_ring(dev);
goto not_done;
}
/********************** end note **********************************/
/* grab a skb */
skb = dev_alloc_skb (pkt_size + 2);
if (skb) {
.
.
/************************ note note *********************************/
netif_receive_skb (skb);
/********************** end note **********************************/
.
.
} else { /* OOM */
/*seems very driver specific ... common is just pass
whatever is on the ring already. */
}
/* move to the next skb on the ring */
entry = (++tp->cur_rx) % RX_RING_SIZE;
received++ ;
}
/* store current ring pointer state */
tp->cur_rx = cur_rx;
/* Refill the Rx ring buffers if they are needed */
refill_rx_ring(dev);
/* no packets on ring; but new ones can arrive since we last
checked */
status = read_interrupt_status_reg();
if (rx status is not set) {
/* If something arrives in this narrow window,
an interrupt will be generated */
goto done;
}
/* done! at least that's what it looks like ;->
if new packets came in after our last check on status bits
they'll be caught by the while check and we go back and clear them
since we havent exceeded our quota */
} while (rx_status_is_set);
done:
/************************ note note *********************************/
dev->quota -= received;
*budget -= received;
/* If RX ring is not full we are out of memory. */
if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
goto oom;
/* we are happy/done, no more packets on ring; put us back
to where we can start processing interrupts again */
netif_rx_complete(dev);
enable_rx_and_rxnobuf_ints();
/* The last op happens after poll completion. Which means the following:
* 1. it can race with disabling irqs in irq handler (which are done to
* schedule polls)
* 2. it can race with dis/enabling irqs in other poll threads
* 3. if an irq raised after the beginning of the outer beginning
* loop (marked in the code above), it will be immediately
* triggered here.
*
* Summarizing: the logic may result in some redundant irqs both
* due to races in masking and due to too late acking of already
* processed irqs. The good news: no events are ever lost.
*/
return 0; /* done */
not_done:
if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 ||
tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
refill_rx_ring(dev);
if (!received) {
printk("received==0\n");
received = 1;
}
dev->quota -= received;
*budget -= received;
return 1; /* not_done */
oom:
/* Start timer, stop polling, but do not enable rx interrupts. */
start_poll_timer(dev);
return 0; /* we'll take it from here so tell core "done"*/
/************************ End note note *********************************/
}
-------------------------------------------------------------------
From above we note that:
0) rx_work_limit = dev->quota
1) refill_rx_ring() is in charge of clearing the bit for rxnobuff when
it does the work.
2) We have a done and not_done state.
3) instead of netif_rx() we call netif_receive_skb() to pass the skb.
4) we have a new way of handling oom condition
5) A new outer for (;;) loop has been added. This serves the purpose of
ensuring that if a new packet has come in, after we are all set and done,
and we have not exceeded our quota that we continue sending packets up.
-----------------------------------------------------------
Poll timer code will need to do the following:
a)
if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 ||
tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
refill_rx_ring(dev);
/* If RX ring is not full we are still out of memory.
Restart the timer again. Else we re-add ourselves
to the master poll list.
*/
if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL)
restart_timer();
else netif_rx_schedule(dev); /* we are back on the poll list */
5) dev->close() and dev->suspend() issues
==========================================
The driver writer needn't worry about this; the top net layer takes
care of it.
6) Adding new Stats to /proc
=============================
In order to debug some of the new features, we introduce new stats
that need to be collected.
TODO: Fill this later.
APPENDIX 1: discussion on using ethernet HW FC
==============================================
Most chips with FC only send a pause packet when they run out of Rx buffers.
Since packets are pulled off the DMA ring by a softirq in NAPI,
if the system is slow in grabbing them and we have a high input
rate (faster than the system's capacity to remove packets), then theoretically
there will only be one rx interrupt for all packets during a given packetstorm.
Under low load, we might have a single interrupt per packet.
FC should be programmed to apply in the case when the system cant pull out
packets fast enough i.e send a pause only when you run out of rx buffers.
Note FC in itself is a good solution but we have found it to not be
much of a commodity feature (both in NICs and switches) and hence falls
under the same category as using NIC based mitigation. Also, experiments
indicate that it's much harder to resolve the resource allocation
issue (aka lazy receiving that NAPI offers) and hence quantify its usefulness
proved harder. In any case, FC works even better with NAPI but is not
necessary.
APPENDIX 2: the "rotting packet" race-window avoidance scheme
=============================================================
There are two types of associations seen here
1) status/int which honors level triggered IRQ
If a status bit for receive or rxnobuff is set and the corresponding
interrupt-enable bit is not on, then no interrupts will be generated. However,
as soon as the "interrupt-enable" bit is unmasked, an immediate interrupt is
generated. [assuming the status bit was not turned off].
Generally the concept of level triggered IRQs in association with a status and
interrupt-enable CSR register set is used to avoid the race.
If we take the example of the tulip:
"pending work" is indicated by the status bit(CSR5 in tulip).
the corresponding interrupt bit (CSR7 in tulip) might be turned off (but
the CSR5 will continue to be turned on with new packet arrivals even if
we clear it the first time)
Very important is the fact that if we turn on the interrupt bit on when
status is set that an immediate irq is triggered.
If we cleared the rx ring and proclaimed there was "no more work
to be done" and then went on to do a few other things; then when we enable
interrupts, there is a possibility that a new packet might sneak in during
this phase. It helps to look at the pseudo code for the tulip poll
routine:
--------------------------
do {
ACK;
while (ring_is_not_empty()) {
work-work-work
if quota is exceeded: exit, no touching irq status/mask
}
/* No packets, but new can arrive while we are doing this*/
CSR5 := read
if (CSR5 is not set) {
/* If something arrives in this narrow window here,
* where the comments are ;-> irq will be generated */
unmask irqs;
exit poll;
}
} while (rx_status_is_set);
------------------------
CSR5 bit of interest is only the rx status.
If you look at the last if statement:
you just finished grabbing all the packets from the rx ring .. you check if
status bit says there are more packets just in ... it says none; you then
enable rx interrupts again; if a new packet just came in during this check,
we are counting that CSR5 will be set in that small window of opportunity
and that by re-enabling interrupts, we would actually trigger an interrupt
to register the new packet for processing.
[The above description nay be very verbose, if you have better wording
that will make this more understandable, please suggest it.]
2) non-capable hardware
These do not generally respect level triggered IRQs. Normally,
irqs may be lost while being masked and the only way to leave poll is to do
a double check for new input after netif_rx_complete() is invoked
and re-enable polling (after seeing this new input).
Sample code:
---------
.
.
restart_poll:
while (ring_is_not_empty()) {
work-work-work
if quota is exceeded: exit, not touching irq status/mask
}
.
.
.
enable_rx_interrupts()
netif_rx_complete(dev);
if (ring_has_new_packet() && netif_rx_reschedule(dev, received)) {
disable_rx_and_rxnobufs()
goto restart_poll
} while (rx_status_is_set);
---------
Basically netif_rx_complete() removes us from the poll list, but because a
new packet which will never be caught due to the possibility of a race
might come in, we attempt to re-add ourselves to the poll list.
APPENDIX 3: Scheduling issues.
==============================
As seen NAPI moves processing to softirq level. Linux uses the ksoftirqd as the
general solution to schedule softirq's to run before next interrupt and by putting
them under scheduler control. Also this prevents consecutive softirq's from
monopolize the CPU. This also have the effect that the priority of ksoftirq needs
to be considered when running very CPU-intensive applications and networking to
get the proper balance of softirq/user balance. Increasing ksoftirq priority to 0
(eventually more) is reported cure problems with low network performance at high
CPU load.
Most used processes in a GIGE router:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
root 3 0.2 0.0 0 0 ? RWN Aug 15 602:00 (ksoftirqd_CPU0)
root 232 0.0 7.9 41400 40884 ? S Aug 15 74:12 gated
--------------------------------------------------------------------
relevant sites:
==================
ftp://robur.slu.se/pub/Linux/net-development/NAPI/
--------------------------------------------------------------------
TODO: Write net-skeleton.c driver.
-------------------------------------------------------------
Authors:
========
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Jamal Hadi Salim <hadi@cyberus.ca>
Robert Olsson <Robert.Olsson@data.slu.se>
Acknowledgements:
================
People who made this document better:
Lennert Buytenhek <buytenh@gnu.org>
Andrew Morton <akpm@zip.com.au>
Manfred Spraul <manfred@colorfullife.com>
Donald Becker <becker@scyld.com>
Jeff Garzik <jgarzik@pobox.com>

215
Documentation/networking/PLIP.txt Normal file
View File

@@ -0,0 +1,215 @@
PLIP: The Parallel Line Internet Protocol Device
Donald Becker (becker@super.org)
I.D.A. Supercomputing Research Center, Bowie MD 20715
At some point T. Thorn will probably contribute text,
Tommy Thorn (tthorn@daimi.aau.dk)
PLIP Introduction
-----------------
This document describes the parallel port packet pusher for Net/LGX.
This device interface allows a point-to-point connection between two
parallel ports to appear as a IP network interface.
What is PLIP?
=============
PLIP is Parallel Line IP, that is, the transportation of IP packages
over a parallel port. In the case of a PC, the obvious choice is the
printer port. PLIP is a non-standard, but [can use] uses the standard
LapLink null-printer cable [can also work in turbo mode, with a PLIP
cable]. [The protocol used to pack IP packages, is a simple one
initiated by Crynwr.]
Advantages of PLIP
==================
It's cheap, it's available everywhere, and it's easy.
The PLIP cable is all that's needed to connect two Linux boxes, and it
can be built for very few bucks.
Connecting two Linux boxes takes only a second's decision and a few
minutes' work, no need to search for a [supported] netcard. This might
even be especially important in the case of notebooks, where netcards
are not easily available.
Not requiring a netcard also means that apart from connecting the
cables, everything else is software configuration [which in principle
could be made very easy.]
Disadvantages of PLIP
=====================
Doesn't work over a modem, like SLIP and PPP. Limited range, 15 m.
Can only be used to connect three (?) Linux boxes. Doesn't connect to
an existing Ethernet. Isn't standard (not even de facto standard, like
SLIP).
Performance
===========
PLIP easily outperforms Ethernet cards....(ups, I was dreaming, but
it *is* getting late. EOB)
PLIP driver details
-------------------
The Linux PLIP driver is an implementation of the original Crynwr protocol,
that uses the parallel port subsystem of the kernel in order to properly
share parallel ports between PLIP and other services.
IRQs and trigger timeouts
=========================
When a parallel port used for a PLIP driver has an IRQ configured to it, the
PLIP driver is signaled whenever data is sent to it via the cable, such that
when no data is available, the driver isn't being used.
However, on some machines it is hard, if not impossible, to configure an IRQ
to a certain parallel port, mainly because it is used by some other device.
On these machines, the PLIP driver can be used in IRQ-less mode, where
the PLIP driver would constantly poll the parallel port for data waiting,
and if such data is available, process it. This mode is less efficient than
the IRQ mode, because the driver has to check the parallel port many times
per second, even when no data at all is sent. Some rough measurements
indicate that there isn't a noticeable performance drop when using IRQ-less
mode as compared to IRQ mode as far as the data transfer speed is involved.
There is a performance drop on the machine hosting the driver.
When the PLIP driver is used in IRQ mode, the timeout used for triggering a
data transfer (the maximal time the PLIP driver would allow the other side
before announcing a timeout, when trying to handshake a transfer of some
data) is, by default, 500usec. As IRQ delivery is more or less immediate,
this timeout is quite sufficient.
When in IRQ-less mode, the PLIP driver polls the parallel port HZ times
per second (where HZ is typically 100 on most platforms, and 1024 on an
Alpha, as of this writing). Between two such polls, there are 10^6/HZ usecs.
On an i386, for example, 10^6/100 = 10000usec. It is easy to see that it is
quite possible for the trigger timeout to expire between two such polls, as
the timeout is only 500usec long. As a result, it is required to change the
trigger timeout on the *other* side of a PLIP connection, to about
10^6/HZ usecs. If both sides of a PLIP connection are used in IRQ-less mode,
this timeout is required on both sides.
It appears that in practice, the trigger timeout can be shorter than in the
above calculation. It isn't an important issue, unless the wire is faulty,
in which case a long timeout would stall the machine when, for whatever
reason, bits are dropped.
A utility that can perform this change in Linux is plipconfig, which is part
of the net-tools package (its location can be found in the
Documentation/Changes file). An example command would be
'plipconfig plipX trigger 10000', where plipX is the appropriate
PLIP device.
PLIP hardware interconnection
-----------------------------
PLIP uses several different data transfer methods. The first (and the
only one implemented in the early version of the code) uses a standard
printer "null" cable to transfer data four bits at a time using
data bit outputs connected to status bit inputs.
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer''
ports. This allows byte-wide transfers and avoids reconstructing
nibbles into bytes, leading to much faster transfers.
Parallel Transfer Mode 0 Cable
==============================
The cable for the first transfer mode is a standard
printer "null" cable which transfers data four bits at a time using
data bit outputs of the first port (machine T) connected to the
status bit inputs of the second port (machine R). There are five
status inputs, and they are used as four data inputs and a clock (data
strobe) input, arranged so that the data input bits appear as contiguous
bits with standard status register implementation.
A cable that implements this protocol is available commercially as a
"Null Printer" or "Turbo Laplink" cable. It can be constructed with
two DB-25 male connectors symmetrically connected as follows:
STROBE output 1*
D0->ERROR 2 - 15 15 - 2
D1->SLCT 3 - 13 13 - 3
D2->PAPOUT 4 - 12 12 - 4
D3->ACK 5 - 10 10 - 5
D4->BUSY 6 - 11 11 - 6
D5,D6,D7 are 7*, 8*, 9*
AUTOFD output 14*
INIT output 16*
SLCTIN 17 - 17
extra grounds are 18*,19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
If the cable you are using has a metallic shield it should be
connected to the metallic DB-25 shell at one end only.
Parallel Transfer Mode 1
========================
The second data transfer method relies on both machines having
bi-directional parallel ports, rather than output-only ``printer''
ports. This allows byte-wide transfers, and avoids reconstructing
nibbles into bytes. This cable should not be used on unidirectional
``printer'' (as opposed to ``parallel'') ports or when the machine
isn't configured for PLIP, as it will result in output driver
conflicts and the (unlikely) possibility of damage.
The cable for this transfer mode should be constructed as follows:
STROBE->BUSY 1 - 11
D0->D0 2 - 2
D1->D1 3 - 3
D2->D2 4 - 4
D3->D3 5 - 5
D4->D4 6 - 6
D5->D5 7 - 7
D6->D6 8 - 8
D7->D7 9 - 9
INIT -> ACK 16 - 10
AUTOFD->PAPOUT 14 - 12
SLCT->SLCTIN 13 - 17
GND->ERROR 18 - 15
extra grounds are 19*,20*,21*,22*,23*,24*
GROUND 25 - 25
* Do not connect these pins on either end
Once again, if the cable you are using has a metallic shield it should
be connected to the metallic DB-25 shell at one end only.
PLIP Mode 0 transfer protocol
=============================
The PLIP driver is compatible with the "Crynwr" parallel port transfer
standard in Mode 0. That standard specifies the following protocol:
send header nibble '0x8'
count-low octet
count-high octet
... data octets
checksum octet
Each octet is sent as
<wait for rx. '0x1?'> <send 0x10+(octet&0x0F)>
<wait for rx. '0x0?'> <send 0x00+((octet>>4)&0x0F)>
To start a transfer the transmitting machine outputs a nibble 0x08.
That raises the ACK line, triggering an interrupt in the receiving
machine. The receiving machine disables interrupts and raises its own ACK
line.
Restated:
(OUT is bit 0-4, OUT.j is bit j from OUT. IN likewise)
Send_Byte:
OUT := low nibble, OUT.4 := 1
WAIT FOR IN.4 = 1
OUT := high nibble, OUT.4 := 0
WAIT FOR IN.4 = 0

294
Documentation/networking/README.ipw2100 Normal file
View File

@@ -0,0 +1,294 @@
Intel(R) PRO/Wireless 2100 Driver for Linux in support of:
Intel(R) PRO/Wireless 2100 Network Connection
Copyright (C) 2003-2006, Intel Corporation
README.ipw2100
Version: git-1.1.5
Date : January 25, 2006
Index
-----------------------------------------------
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
1. Introduction
2. Release git-1.1.5 Current Features
3. Command Line Parameters
4. Sysfs Helper Files
5. Radio Kill Switch
6. Dynamic Firmware
7. Power Management
8. Support
9. License
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-----------------------------------------------
Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
Intel wireless LAN adapters are engineered, manufactured, tested, and
quality checked to ensure that they meet all necessary local and
governmental regulatory agency requirements for the regions that they
are designated and/or marked to ship into. Since wireless LANs are
generally unlicensed devices that share spectrum with radars,
satellites, and other licensed and unlicensed devices, it is sometimes
necessary to dynamically detect, avoid, and limit usage to avoid
interference with these devices. In many instances Intel is required to
provide test data to prove regional and local compliance to regional and
governmental regulations before certification or approval to use the
product is granted. Intel's wireless LAN's EEPROM, firmware, and
software driver are designed to carefully control parameters that affect
radio operation and to ensure electromagnetic compliance (EMC). These
parameters include, without limitation, RF power, spectrum usage,
channel scanning, and human exposure.
For these reasons Intel cannot permit any manipulation by third parties
of the software provided in binary format with the wireless WLAN
adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
patches, utilities, or code with the Intel wireless LAN adapters that
have been manipulated by an unauthorized party (i.e., patches,
utilities, or code (including open source code modifications) which have
not been validated by Intel), (i) you will be solely responsible for
ensuring the regulatory compliance of the products, (ii) Intel will bear
no liability, under any theory of liability for any issues associated
with the modified products, including without limitation, claims under
the warranty and/or issues arising from regulatory non-compliance, and
(iii) Intel will not provide or be required to assist in providing
support to any third parties for such modified products.
Note: Many regulatory agencies consider Wireless LAN adapters to be
modules, and accordingly, condition system-level regulatory approval
upon receipt and review of test data documenting that the antennas and
system configuration do not cause the EMC and radio operation to be
non-compliant.
The drivers available for download from SourceForge are provided as a
part of a development project. Conformance to local regulatory
requirements is the responsibility of the individual developer. As
such, if you are interested in deploying or shipping a driver as part of
solution intended to be used for purposes other than development, please
obtain a tested driver from Intel Customer Support at:
http://support.intel.com/support/notebook/sb/CS-006408.htm
1. Introduction
-----------------------------------------------
This document provides a brief overview of the features supported by the
IPW2100 driver project. The main project website, where the latest
development version of the driver can be found, is:
http://ipw2100.sourceforge.net
There you can find the not only the latest releases, but also information about
potential fixes and patches, as well as links to the development mailing list
for the driver project.
2. Release git-1.1.5 Current Supported Features
-----------------------------------------------
- Managed (BSS) and Ad-Hoc (IBSS)
- WEP (shared key and open)
- Wireless Tools support
- 802.1x (tested with XSupplicant 1.0.1)
Enabled (but not supported) features:
- Monitor/RFMon mode
- WPA/WPA2
The distinction between officially supported and enabled is a reflection
on the amount of validation and interoperability testing that has been
performed on a given feature.
3. Command Line Parameters
-----------------------------------------------
If the driver is built as a module, the following optional parameters are used
by entering them on the command line with the modprobe command using this
syntax:
modprobe ipw2100 [<option>=<VAL1><,VAL2>...]
For example, to disable the radio on driver loading, enter:
modprobe ipw2100 disable=1
The ipw2100 driver supports the following module parameters:
Name Value Example:
debug 0x0-0xffffffff debug=1024
mode 0,1,2 mode=1 /* AdHoc */
channel int channel=3 /* Only valid in AdHoc or Monitor */
associate boolean associate=0 /* Do NOT auto associate */
disable boolean disable=1 /* Do not power the HW */
4. Sysfs Helper Files
---------------------------
-----------------------------------------------
There are several ways to control the behavior of the driver. Many of the
general capabilities are exposed through the Wireless Tools (iwconfig). There
are a few capabilities that are exposed through entries in the Linux Sysfs.
----- Driver Level ------
For the driver level files, look in /sys/bus/pci/drivers/ipw2100/
debug_level
This controls the same global as the 'debug' module parameter. For
information on the various debugging levels available, run the 'dvals'
script found in the driver source directory.
NOTE: 'debug_level' is only enabled if CONFIG_IPW2100_DEBUG is turn
on.
----- Device Level ------
For the device level files look in
/sys/bus/pci/drivers/ipw2100/{PCI-ID}/
For example:
/sys/bus/pci/drivers/ipw2100/0000:02:01.0
For the device level files, see /sys/bus/pci/drivers/ipw2100:
rf_kill
read -
0 = RF kill not enabled (radio on)
1 = SW based RF kill active (radio off)
2 = HW based RF kill active (radio off)
3 = Both HW and SW RF kill active (radio off)
write -
0 = If SW based RF kill active, turn the radio back on
1 = If radio is on, activate SW based RF kill
NOTE: If you enable the SW based RF kill and then toggle the HW
based RF kill from ON -> OFF -> ON, the radio will NOT come back on
5. Radio Kill Switch
-----------------------------------------------
Most laptops provide the ability for the user to physically disable the radio.
Some vendors have implemented this as a physical switch that requires no
software to turn the radio off and on. On other laptops, however, the switch
is controlled through a button being pressed and a software driver then making
calls to turn the radio off and on. This is referred to as a "software based
RF kill switch"
See the Sysfs helper file 'rf_kill' for determining the state of the RF switch
on your system.
6. Dynamic Firmware
-----------------------------------------------
As the firmware is licensed under a restricted use license, it can not be
included within the kernel sources. To enable the IPW2100 you will need a
firmware image to load into the wireless NIC's processors.
You can obtain these images from <http://ipw2100.sf.net/firmware.php>.
See INSTALL for instructions on installing the firmware.
7. Power Management
-----------------------------------------------
The IPW2100 supports the configuration of the Power Save Protocol
through a private wireless extension interface. The IPW2100 supports
the following different modes:
off No power management. Radio is always on.
on Automatic power management
1-5 Different levels of power management. The higher the
number the greater the power savings, but with an impact to
packet latencies.
Power management works by powering down the radio after a certain
interval of time has passed where no packets are passed through the
radio. Once powered down, the radio remains in that state for a given
period of time. For higher power savings, the interval between last
packet processed to sleep is shorter and the sleep period is longer.
When the radio is asleep, the access point sending data to the station
must buffer packets at the AP until the station wakes up and requests
any buffered packets. If you have an AP that does not correctly support
the PSP protocol you may experience packet loss or very poor performance
while power management is enabled. If this is the case, you will need
to try and find a firmware update for your AP, or disable power
management (via `iwconfig eth1 power off`)
To configure the power level on the IPW2100 you use a combination of
iwconfig and iwpriv. iwconfig is used to turn power management on, off,
and set it to auto.
iwconfig eth1 power off Disables radio power down
iwconfig eth1 power on Enables radio power management to
last set level (defaults to AUTO)
iwpriv eth1 set_power 0 Sets power level to AUTO and enables
power management if not previously
enabled.
iwpriv eth1 set_power 1-5 Set the power level as specified,
enabling power management if not
previously enabled.
You can view the current power level setting via:
iwpriv eth1 get_power
It will return the current period or timeout that is configured as a string
in the form of xxxx/yyyy (z) where xxxx is the timeout interval (amount of
time after packet processing), yyyy is the period to sleep (amount of time to
wait before powering the radio and querying the access point for buffered
packets), and z is the 'power level'. If power management is turned off the
xxxx/yyyy will be replaced with 'off' -- the level reported will be the active
level if `iwconfig eth1 power on` is invoked.
8. Support
-----------------------------------------------
For general development information and support,
go to:
http://ipw2100.sf.net/
The ipw2100 1.1.0 driver and firmware can be downloaded from:
http://support.intel.com
For installation support on the ipw2100 1.1.0 driver on Linux kernels
2.6.8 or greater, email support is available from:
http://supportmail.intel.com
9. License
-----------------------------------------------
Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License (version 2) as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
The full GNU General Public License is included in this distribution in the
file called LICENSE.
License Contact Information:
James P. Ketrenos <ipw2100-admin@linux.intel.com>
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497

472
Documentation/networking/README.ipw2200 Normal file
View File

@@ -0,0 +1,472 @@
Intel(R) PRO/Wireless 2915ABG Driver for Linux in support of:
Intel(R) PRO/Wireless 2200BG Network Connection
Intel(R) PRO/Wireless 2915ABG Network Connection
Note: The Intel(R) PRO/Wireless 2915ABG Driver for Linux and Intel(R)
PRO/Wireless 2200BG Driver for Linux is a unified driver that works on
both hardware adapters listed above. In this document the Intel(R)
PRO/Wireless 2915ABG Driver for Linux will be used to reference the
unified driver.
Copyright (C) 2004-2006, Intel Corporation
README.ipw2200
Version: 1.1.2
Date : March 30, 2006
Index
-----------------------------------------------
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
1. Introduction
1.1. Overview of features
1.2. Module parameters
1.3. Wireless Extension Private Methods
1.4. Sysfs Helper Files
1.5. Supported channels
2. Ad-Hoc Networking
3. Interacting with Wireless Tools
3.1. iwconfig mode
3.2. iwconfig sens
4. About the Version Numbers
5. Firmware installation
6. Support
7. License
0. IMPORTANT INFORMATION BEFORE USING THIS DRIVER
-----------------------------------------------
Important Notice FOR ALL USERS OR DISTRIBUTORS!!!!
Intel wireless LAN adapters are engineered, manufactured, tested, and
quality checked to ensure that they meet all necessary local and
governmental regulatory agency requirements for the regions that they
are designated and/or marked to ship into. Since wireless LANs are
generally unlicensed devices that share spectrum with radars,
satellites, and other licensed and unlicensed devices, it is sometimes
necessary to dynamically detect, avoid, and limit usage to avoid
interference with these devices. In many instances Intel is required to
provide test data to prove regional and local compliance to regional and
governmental regulations before certification or approval to use the
product is granted. Intel's wireless LAN's EEPROM, firmware, and
software driver are designed to carefully control parameters that affect
radio operation and to ensure electromagnetic compliance (EMC). These
parameters include, without limitation, RF power, spectrum usage,
channel scanning, and human exposure.
For these reasons Intel cannot permit any manipulation by third parties
of the software provided in binary format with the wireless WLAN
adapters (e.g., the EEPROM and firmware). Furthermore, if you use any
patches, utilities, or code with the Intel wireless LAN adapters that
have been manipulated by an unauthorized party (i.e., patches,
utilities, or code (including open source code modifications) which have
not been validated by Intel), (i) you will be solely responsible for
ensuring the regulatory compliance of the products, (ii) Intel will bear
no liability, under any theory of liability for any issues associated
with the modified products, including without limitation, claims under
the warranty and/or issues arising from regulatory non-compliance, and
(iii) Intel will not provide or be required to assist in providing
support to any third parties for such modified products.
Note: Many regulatory agencies consider Wireless LAN adapters to be
modules, and accordingly, condition system-level regulatory approval
upon receipt and review of test data documenting that the antennas and
system configuration do not cause the EMC and radio operation to be
non-compliant.
The drivers available for download from SourceForge are provided as a
part of a development project. Conformance to local regulatory
requirements is the responsibility of the individual developer. As
such, if you are interested in deploying or shipping a driver as part of
solution intended to be used for purposes other than development, please
obtain a tested driver from Intel Customer Support at:
http://support.intel.com/support/notebook/sb/CS-006408.htm
1. Introduction
-----------------------------------------------
The following sections attempt to provide a brief introduction to using
the Intel(R) PRO/Wireless 2915ABG Driver for Linux.
This document is not meant to be a comprehensive manual on
understanding or using wireless technologies, but should be sufficient
to get you moving without wires on Linux.
For information on building and installing the driver, see the INSTALL
file.
1.1. Overview of Features
-----------------------------------------------
The current release (1.1.2) supports the following features:
+ BSS mode (Infrastructure, Managed)
+ IBSS mode (Ad-Hoc)
+ WEP (OPEN and SHARED KEY mode)
+ 802.1x EAP via wpa_supplicant and xsupplicant
+ Wireless Extension support
+ Full B and G rate support (2200 and 2915)
+ Full A rate support (2915 only)
+ Transmit power control
+ S state support (ACPI suspend/resume)
The following features are currently enabled, but not officially
supported:
+ WPA
+ long/short preamble support
+ Monitor mode (aka RFMon)
The distinction between officially supported and enabled is a reflection
on the amount of validation and interoperability testing that has been
performed on a given feature.
1.2. Command Line Parameters
-----------------------------------------------
Like many modules used in the Linux kernel, the Intel(R) PRO/Wireless
2915ABG Driver for Linux allows configuration options to be provided
as module parameters. The most common way to specify a module parameter
is via the command line.
The general form is:
% modprobe ipw2200 parameter=value
Where the supported parameter are:
associate
Set to 0 to disable the auto scan-and-associate functionality of the
driver. If disabled, the driver will not attempt to scan
for and associate to a network until it has been configured with
one or more properties for the target network, for example configuring
the network SSID. Default is 1 (auto-associate)
Example: % modprobe ipw2200 associate=0
auto_create
Set to 0 to disable the auto creation of an Ad-Hoc network
matching the channel and network name parameters provided.
Default is 1.
channel
channel number for association. The normal method for setting
the channel would be to use the standard wireless tools
(i.e. `iwconfig eth1 channel 10`), but it is useful sometimes
to set this while debugging. Channel 0 means 'ANY'
debug
If using a debug build, this is used to control the amount of debug
info is logged. See the 'dvals' and 'load' script for more info on
how to use this (the dvals and load scripts are provided as part
of the ipw2200 development snapshot releases available from the
SourceForge project at http://ipw2200.sf.net)
led
Can be used to turn on experimental LED code.
0 = Off, 1 = On. Default is 0.
mode
Can be used to set the default mode of the adapter.
0 = Managed, 1 = Ad-Hoc, 2 = Monitor
1.3. Wireless Extension Private Methods
-----------------------------------------------
As an interface designed to handle generic hardware, there are certain
capabilities not exposed through the normal Wireless Tool interface. As
such, a provision is provided for a driver to declare custom, or
private, methods. The Intel(R) PRO/Wireless 2915ABG Driver for Linux
defines several of these to configure various settings.
The general form of using the private wireless methods is:
% iwpriv $IFNAME method parameters
Where $IFNAME is the interface name the device is registered with
(typically eth1, customized via one of the various network interface
name managers, such as ifrename)
The supported private methods are:
get_mode
Can be used to report out which IEEE mode the driver is
configured to support. Example:
% iwpriv eth1 get_mode
eth1 get_mode:802.11bg (6)
set_mode
Can be used to configure which IEEE mode the driver will
support.
Usage:
% iwpriv eth1 set_mode {mode}
Where {mode} is a number in the range 1-7:
1 802.11a (2915 only)
2 802.11b
3 802.11ab (2915 only)
4 802.11g
5 802.11ag (2915 only)
6 802.11bg
7 802.11abg (2915 only)
get_preamble
Can be used to report configuration of preamble length.
set_preamble
Can be used to set the configuration of preamble length:
Usage:
% iwpriv eth1 set_preamble {mode}
Where {mode} is one of:
1 Long preamble only
0 Auto (long or short based on connection)
1.4. Sysfs Helper Files:
-----------------------------------------------
The Linux kernel provides a pseudo file system that can be used to
access various components of the operating system. The Intel(R)
PRO/Wireless 2915ABG Driver for Linux exposes several configuration
parameters through this mechanism.
An entry in the sysfs can support reading and/or writing. You can
typically query the contents of a sysfs entry through the use of cat,
and can set the contents via echo. For example:
% cat /sys/bus/pci/drivers/ipw2200/debug_level
Will report the current debug level of the driver's logging subsystem
(only available if CONFIG_IPW2200_DEBUG was configured when the driver
was built).
You can set the debug level via:
% echo $VALUE > /sys/bus/pci/drivers/ipw2200/debug_level
Where $VALUE would be a number in the case of this sysfs entry. The
input to sysfs files does not have to be a number. For example, the
firmware loader used by hotplug utilizes sysfs entries for transfering
the firmware image from user space into the driver.
The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries
at two levels -- driver level, which apply to all instances of the driver
(in the event that there are more than one device installed) and device
level, which applies only to the single specific instance.
1.4.1 Driver Level Sysfs Helper Files
-----------------------------------------------
For the driver level files, look in /sys/bus/pci/drivers/ipw2200/
debug_level
This controls the same global as the 'debug' module parameter
1.4.2 Device Level Sysfs Helper Files
-----------------------------------------------
For the device level files, look in
/sys/bus/pci/drivers/ipw2200/{PCI-ID}/
For example:
/sys/bus/pci/drivers/ipw2200/0000:02:01.0
For the device level files, see /sys/bus/pci/drivers/ipw2200:
rf_kill
read -
0 = RF kill not enabled (radio on)
1 = SW based RF kill active (radio off)
2 = HW based RF kill active (radio off)
3 = Both HW and SW RF kill active (radio off)
write -
0 = If SW based RF kill active, turn the radio back on
1 = If radio is on, activate SW based RF kill
NOTE: If you enable the SW based RF kill and then toggle the HW
based RF kill from ON -> OFF -> ON, the radio will NOT come back on
ucode
read-only access to the ucode version number
led
read -
0 = LED code disabled
1 = LED code enabled
write -
0 = Disable LED code
1 = Enable LED code
NOTE: The LED code has been reported to hang some systems when
running ifconfig and is therefore disabled by default.
1.5. Supported channels
-----------------------------------------------
Upon loading the Intel(R) PRO/Wireless 2915ABG Driver for Linux, a
message stating the detected geography code and the number of 802.11
channels supported by the card will be displayed in the log.
The geography code corresponds to a regulatory domain as shown in the
table below.
Supported channels
Code Geography 802.11bg 802.11a
--- Restricted 11 0
ZZF Custom US/Canada 11 8
ZZD Rest of World 13 0
ZZA Custom USA & Europe & High 11 13
ZZB Custom NA & Europe 11 13
ZZC Custom Japan 11 4
ZZM Custom 11 0
ZZE Europe 13 19
ZZJ Custom Japan 14 4
ZZR Rest of World 14 0
ZZH High Band 13 4
ZZG Custom Europe 13 4
ZZK Europe 13 24
ZZL Europe 11 13
2. Ad-Hoc Networking
-----------------------------------------------
When using a device in an Ad-Hoc network, it is useful to understand the
sequence and requirements for the driver to be able to create, join, or
merge networks.
The following attempts to provide enough information so that you can
have a consistent experience while using the driver as a member of an
Ad-Hoc network.
2.1. Joining an Ad-Hoc Network
-----------------------------------------------
The easiest way to get onto an Ad-Hoc network is to join one that
already exists.
2.2. Creating an Ad-Hoc Network
-----------------------------------------------
An Ad-Hoc networks is created using the syntax of the Wireless tool.
For Example:
iwconfig eth1 mode ad-hoc essid testing channel 2
2.3. Merging Ad-Hoc Networks
-----------------------------------------------
3. Interaction with Wireless Tools
-----------------------------------------------
3.1 iwconfig mode
-----------------------------------------------
When configuring the mode of the adapter, all run-time configured parameters
are reset to the value used when the module was loaded. This includes
channels, rates, ESSID, etc.
3.2 iwconfig sens
-----------------------------------------------
The 'iwconfig ethX sens XX' command will not set the signal sensitivity
threshold, as described in iwconfig documentation, but rather the number
of consecutive missed beacons that will trigger handover, i.e. roaming
to another access point. At the same time, it will set the disassociation
threshold to 3 times the given value.
4. About the Version Numbers
-----------------------------------------------
Due to the nature of open source development projects, there are
frequently changes being incorporated that have not gone through
a complete validation process. These changes are incorporated into
development snapshot releases.
Releases are numbered with a three level scheme:
major.minor.development
Any version where the 'development' portion is 0 (for example
1.0.0, 1.1.0, etc.) indicates a stable version that will be made
available for kernel inclusion.
Any version where the 'development' portion is not a 0 (for
example 1.0.1, 1.1.5, etc.) indicates a development version that is
being made available for testing and cutting edge users. The stability
and functionality of the development releases are not know. We make
efforts to try and keep all snapshots reasonably stable, but due to the
frequency of their release, and the desire to get those releases
available as quickly as possible, unknown anomalies should be expected.
The major version number will be incremented when significant changes
are made to the driver. Currently, there are no major changes planned.
5. Firmware installation
----------------------------------------------
The driver requires a firmware image, download it and extract the
files under /lib/firmware (or wherever your hotplug's firmware.agent
will look for firmware files)
The firmware can be downloaded from the following URL:
http://ipw2200.sf.net/
6. Support
-----------------------------------------------
For direct support of the 1.0.0 version, you can contact
http://supportmail.intel.com, or you can use the open source project
support.
For general information and support, go to:
http://ipw2200.sf.net/
7. License
-----------------------------------------------
Copyright(c) 2003 - 2006 Intel Corporation. All rights reserved.
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License version 2 as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 59
Temple Place - Suite 330, Boston, MA 02111-1307, USA.
The full GNU General Public License is included in this distribution in the
file called LICENSE.
Contact Information:
James P. Ketrenos <ipw2100-admin@linux.intel.com>
Intel Corporation, 5200 N.E. Elam Young Parkway, Hillsboro, OR 97124-6497

207
Documentation/networking/README.sb1000 Normal file
View File

@@ -0,0 +1,207 @@
sb1000 is a module network device driver for the General Instrument (also known
as NextLevel) SURFboard1000 internal cable modem board. This is an ISA card
which is used by a number of cable TV companies to provide cable modem access.
It's a one-way downstream-only cable modem, meaning that your upstream net link
is provided by your regular phone modem.
This driver was written by Franco Venturi <fventuri@mediaone.net>. He deserves
a great deal of thanks for this wonderful piece of code!
-----------------------------------------------------------------------------
Support for this device is now a part of the standard Linux kernel. The
driver source code file is drivers/net/sb1000.c. In addition to this
you will need:
1.) The "cmconfig" program. This is a utility which supplements "ifconfig"
to configure the cable modem and network interface (usually called "cm0");
and
2.) Several PPP scripts which live in /etc/ppp to make connecting via your
cable modem easy.
These utilities can be obtained from:
http://www.jacksonville.net/~fventuri/
in Franco's original source code distribution .tar.gz file. Support for
the sb1000 driver can be found at:
http://home.adelphia.net/~siglercm/sb1000.html
http://linuxpower.cx/~cable/
along with these utilities.
3.) The standard isapnp tools. These are necessary to configure your SB1000
card at boot time (or afterwards by hand) since it's a PnP card.
If you don't have these installed as a standard part of your Linux
distribution, you can find them at:
http://www.roestock.demon.co.uk/isapnptools/
or check your Linux distribution binary CD or their web site. For help with
isapnp, pnpdump, or /etc/isapnp.conf, go to:
http://www.roestock.demon.co.uk/isapnptools/isapnpfaq.html
-----------------------------------------------------------------------------
To make the SB1000 card work, follow these steps:
1.) Run `make config', or `make menuconfig', or `make xconfig', whichever
you prefer, in the top kernel tree directory to set up your kernel
configuration. Make sure to say "Y" to "Prompt for development drivers"
and to say "M" to the sb1000 driver. Also say "Y" or "M" to all the standard
networking questions to get TCP/IP and PPP networking support.
2.) *BEFORE* you build the kernel, edit drivers/net/sb1000.c. Make sure
to redefine the value of READ_DATA_PORT to match the I/O address used
by isapnp to access your PnP cards. This is the value of READPORT in
/etc/isapnp.conf or given by the output of pnpdump.
3.) Build and install the kernel and modules as usual.
4.) Boot your new kernel following the usual procedures.
5.) Set up to configure the new SB1000 PnP card by capturing the output
of "pnpdump" to a file and editing this file to set the correct I/O ports,
IRQ, and DMA settings for all your PnP cards. Make sure none of the settings
conflict with one another. Then test this configuration by running the
"isapnp" command with your new config file as the input. Check for
errors and fix as necessary. (As an aside, I use I/O ports 0x110 and
0x310 and IRQ 11 for my SB1000 card and these work well for me. YMMV.)
Then save the finished config file as /etc/isapnp.conf for proper configuration
on subsequent reboots.
6.) Download the original file sb1000-1.1.2.tar.gz from Franco's site or one of
the others referenced above. As root, unpack it into a temporary directory and
do a `make cmconfig' and then `install -c cmconfig /usr/local/sbin'. Don't do
`make install' because it expects to find all the utilities built and ready for
installation, not just cmconfig.
7.) As root, copy all the files under the ppp/ subdirectory in Franco's
tar file into /etc/ppp, being careful not to overwrite any files that are
already in there. Then modify ppp@gi-on to set the correct login name,
phone number, and frequency for the cable modem. Also edit pap-secrets
to specify your login name and password and any site-specific information
you need.
8.) Be sure to modify /etc/ppp/firewall to use ipchains instead of
the older ipfwadm commands from the 2.0.x kernels. There's a neat utility to
convert ipfwadm commands to ipchains commands:
http://users.dhp.com/~whisper/ipfwadm2ipchains/
You may also wish to modify the firewall script to implement a different
firewalling scheme.
9.) Start the PPP connection via the script /etc/ppp/ppp@gi-on. You must be
root to do this. It's better to use a utility like sudo to execute
frequently used commands like this with root permissions if possible. If you
connect successfully the cable modem interface will come up and you'll see a
driver message like this at the console:
cm0: sb1000 at (0x110,0x310), csn 1, S/N 0x2a0d16d8, IRQ 11.
sb1000.c:v1.1.2 6/01/98 (fventuri@mediaone.net)
The "ifconfig" command should show two new interfaces, ppp0 and cm0.
The command "cmconfig cm0" will give you information about the cable modem
interface.
10.) Try pinging a site via `ping -c 5 www.yahoo.com', for example. You should
see packets received.
11.) If you can't get site names (like www.yahoo.com) to resolve into
IP addresses (like 204.71.200.67), be sure your /etc/resolv.conf file
has no syntax errors and has the right nameserver IP addresses in it.
If this doesn't help, try something like `ping -c 5 204.71.200.67' to
see if the networking is running but the DNS resolution is where the
problem lies.
12.) If you still have problems, go to the support web sites mentioned above
and read the information and documentation there.
-----------------------------------------------------------------------------
Common problems:
1.) Packets go out on the ppp0 interface but don't come back on the cm0
interface. It looks like I'm connected but I can't even ping any
numerical IP addresses. (This happens predominantly on Debian systems due
to a default boot-time configuration script.)
Solution -- As root `echo 0 > /proc/sys/net/ipv4/conf/cm0/rp_filter' so it
can share the same IP address as the ppp0 interface. Note that this
command should probably be added to the /etc/ppp/cablemodem script
*right*between* the "/sbin/ifconfig" and "/sbin/cmconfig" commands.
You may need to do this to /proc/sys/net/ipv4/conf/ppp0/rp_filter as well.
If you do this to /proc/sys/net/ipv4/conf/default/rp_filter on each reboot
(in rc.local or some such) then any interfaces can share the same IP
addresses.
2.) I get "unresolved symbol" error messages on executing `insmod sb1000.o'.
Solution -- You probably have a non-matching kernel source tree and
/usr/include/linux and /usr/include/asm header files. Make sure you
install the correct versions of the header files in these two directories.
Then rebuild and reinstall the kernel.
3.) When isapnp runs it reports an error, and my SB1000 card isn't working.
Solution -- There's a problem with later versions of isapnp using the "(CHECK)"
option in the lines that allocate the two I/O addresses for the SB1000 card.
This first popped up on RH 6.0. Delete "(CHECK)" for the SB1000 I/O addresses.
Make sure they don't conflict with any other pieces of hardware first! Then
rerun isapnp and go from there.
4.) I can't execute the /etc/ppp/ppp@gi-on file.
Solution -- As root do `chmod ug+x /etc/ppp/ppp@gi-on'.
5.) The firewall script isn't working (with 2.2.x and higher kernels).
Solution -- Use the ipfwadm2ipchains script referenced above to convert the
/etc/ppp/firewall script from the deprecated ipfwadm commands to ipchains.
6.) I'm getting *tons* of firewall deny messages in the /var/kern.log,
/var/messages, and/or /var/syslog files, and they're filling up my /var
partition!!!
Solution -- First, tell your ISP that you're receiving DoS (Denial of Service)
and/or portscanning (UDP connection attempts) attacks! Look over the deny
messages to figure out what the attack is and where it's coming from. Next,
edit /etc/ppp/cablemodem and make sure the ",nobroadcast" option is turned on
to the "cmconfig" command (uncomment that line). If you're not receiving these
denied packets on your broadcast interface (IP address xxx.yyy.zzz.255
typically), then someone is attacking your machine in particular. Be careful
out there....
7.) Everything seems to work fine but my computer locks up after a while
(and typically during a lengthy download through the cable modem)!
Solution -- You may need to add a short delay in the driver to 'slow down' the
SURFboard because your PC might not be able to keep up with the transfer rate
of the SB1000. To do this, it's probably best to download Franco's
sb1000-1.1.2.tar.gz archive and build and install sb1000.o manually. You'll
want to edit the 'Makefile' and look for the 'SB1000_DELAY'
define. Uncomment those 'CFLAGS' lines (and comment out the default ones)
and try setting the delay to something like 60 microseconds with:
'-DSB1000_DELAY=60'. Then do `make' and as root `make install' and try
it out. If it still doesn't work or you like playing with the driver, you may
try other numbers. Remember though that the higher the delay, the slower the
driver (which slows down the rest of the PC too when it is actively
used). Thanks to Ed Daiga for this tip!
-----------------------------------------------------------------------------
Credits: This README came from Franco Venturi's original README file which is
still supplied with his driver .tar.gz archive. I and all other sb1000 users
owe Franco a tremendous "Thank you!" Additional thanks goes to Carl Patten
and Ralph Bonnell who are now managing the Linux SB1000 web site, and to
the SB1000 users who reported and helped debug the common problems listed
above.
Clemmitt Sigler
csigler@vt.edu

53
Documentation/networking/alias.txt Normal file
View File

@@ -0,0 +1,53 @@
IP-Aliasing:
============
IP-aliases are additional IP-addresses/masks hooked up to a base
interface by adding a colon and a string when running ifconfig.
This string is usually numeric, but this is not a must.
IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking)
is configured in the kernel.
o Alias creation.
Alias creation is done by 'magic' interface naming: eg. to create a
200.1.1.1 alias for eth0 ...
# ifconfig eth0:0 200.1.1.1 etc,etc....
~~ -> request alias #0 creation (if not yet exists) for eth0
The corresponding route is also set up by this command.
Please note: The route always points to the base interface.
o Alias deletion.
The alias is removed by shutting the alias down:
# ifconfig eth0:0 down
~~~~~~~~~~ -> will delete alias
o Alias (re-)configuring
Aliases are not real devices, but programs should be able to configure and
refer to them as usual (ifconfig, route, etc).
o Relationship with main device
If the base device is shut down the added aliases will be deleted
too.
Contact
-------
Please finger or e-mail me:
Juan Jose Ciarlante <jjciarla@raiz.uncu.edu.ar>
Updated by Erik Schoenfelder <schoenfr@gaertner.DE>
; local variables:
; mode: indented-text
; mode: auto-fill
; end:

3133
Documentation/networking/arcnet-hardware.txt Normal file
View File

File diff suppressed because it is too large Load Diff

555
Documentation/networking/arcnet.txt Normal file
View File

@@ -0,0 +1,555 @@
----------------------------------------------------------------------------
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:
This driver's getting fat and beefy,
But my cat is still named Fifi.
Hmm, I think I'm allowed to call that a poem, even though it's only two
lines. Hey, I'm in Computer Science, not English. Give me a break.
The point is: I REALLY REALLY REALLY REALLY REALLY want to hear from you if
you test this and get it working. Or if you don't. Or anything.
ARCnet 0.32 ALPHA first made it into the Linux kernel 1.1.80 - this was
nice, but after that even FEWER people started writing to me because they
didn't even have to install the patch. <sigh>
Come on, be a sport! Send me a success report!
(hey, that was even better than my original poem... this is getting bad!)
--------
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?
(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
---------------------------------------------------------------------------
These are the ARCnet drivers for Linux.
This new release (2.91) has been put together by David Woodhouse
<dwmw2@cam.ac.uk>, 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
#ifdefs! I've changed this file a bit, but kept it in the first person from
Avery, because I didn't want to completely rewrite it.
The previous release resulted from many months of on-and-off effort from me
(Avery Pennarun), many bug reports/fixes and suggestions from others, and in
particular a lot of input and coding from Tomasz Motylewski. Starting with
ARCnet 2.10 ALPHA, Tomasz's all-new-and-improved RFC1051 support has been
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.
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://tichy.ch.uj.edu.pl/lists/linux-arcnet
The people on linux-net@vger.kernel.org have also been known to be very
helpful, especially when we're talking about ALPHA Linux kernels that may or
may not work right in the first place.
Other Drivers and Info
----------------------
You can try my ARCNET page on the World Wide Web at:
http://www.worldvisions.ca/~apenwarr/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.
You can get the Crynwr packet driver collection (including arcether.com, the
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.
Installing the Driver
---------------------
All you will need to do in order to install the driver is:
make config
(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.
You will know the driver is installed properly if you get some ARCnet
messages when you reboot into the new Linux kernel.
There are four chipset options:
1. Standard ARCnet COM90xx chipset.
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:
com90xx=[<io>[,<irq>[,<shmem>]]][,<name>] | <name>
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.
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
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:
com20020=<io>[,<irq>[,<node_ID>[,backplane[,CKP[,timeout]]]]][,name]
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>
The COM20020 chipset allows you to set the node ID in software, overriding the
default which is still set in DIP switches on the card. If you don't have the
COM20020 data sheets, and you don't know what the other three options refer
to, then they won't interest you - forget them.
3. ARCnet COM90xx chipset in IO-mapped mode.
This will also work with the normal ARCnet cards, but doesn't use the shared
memory. It performs less well than the above driver, but is provided in case
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>]
If you load the chipset support as a module, the options are:
io=<io> irq=<irq> device=<name>
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
report. All options must be specified, except the device name.
Command line options:
arcrimi=<shmem>,<irq>,<node_ID>[,<name>]
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
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'
to the chipset support if you wish.
make config
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:
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
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.
Go read the NET-2-HOWTO and ETHERNET-HOWTO for Linux; they should be
available where you picked up this driver. Think of your ARCnet as a
souped-up (or down, as the case may be) Ethernet card.
By the way, be sure to change all references from "eth0" to "arc0" in the
HOWTOs. Remember that ARCnet isn't a "true" Ethernet, and the device name
is DIFFERENT.
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.
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:
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>
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
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.
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
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.
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
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.
ftp.microsoft.com also has a freeware "Lan Manager for OS/2" client
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
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.
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.
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.
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
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
LANMAN. Because the MTU of 493 is actually smaller than the
one "required" by TCP/IP (576), there is a chance that some
network operations will not function properly. The Linux
TCP/IP layer can compensate in most cases, however, by
automatically fragmenting the TCP/IP packets to make them
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
standard that is completely incompatible with the new
standard. Some software today, however, continues to
support the old standard (and only the old standard)
including NetBSD and AmiTCP. RFC1051 also does not support
RFC1201's packet splitting, and the MTU of 507 is still
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
use the "NFS-root" stuff in recent Linux kernels.
The arc0e and arc0s devices are created automatically when you first
ifconfig the arc0 device. To actually use them, though, you need to also
ifconfig the other virtual devices you need. There are a number of ways you
can set up your network then:
1. Single Protocol.
This is the simplest way to configure your network: use just one of the
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
arc0s works much the same way as arc0e.
2. More than one protocol on the same wire.
Now things start getting confusing. To even try it, you may need to be
partly crazy. Here's what *I* did. :) Note that I don't include arc0s in
my home network; I don't have any NetBSD or AmiTCP computers, so I only
use arc0s during limited testing.
I have three computers on my home network; two Linux boxes (which prefer
RFC1201 protocol, for reasons listed above), and one XT that can't run
Linux but runs the free Microsoft LANMAN Client instead.
Worse, one of the Linux computers (freedom) also has a modem and acts as
a router to my Internet provider. The other Linux box (insight) also has
its own IP address and needs to use freedom as its default gateway. The
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.
Insight needs to:
- 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
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 */
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
worse.
Now, how do I add patience into the network? It will be using LANMAN
Client, which means I need the arc0e device. It needs to be able to talk
to both insight and freedom, and also use freedom as a gateway to the
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
DOS networking programs, including LANMAN, have braindead networking
schemes that rely completely on the netmask and a 'default gateway' to
determine how to route packets. This means that to get to freedom or
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
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
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.
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.
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]
(registered Internet subnet) (RFC1597 private subnet)
(IP Masquerade)
/---------------\ * /---------------\
| | * | |
| +-Freedom-*-Gatekeeper-+ |
| | | * | |
\-------+-------/ | * \-------+-------/
| | |
Insight | Patience
(Internet)
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
can be weird (and also usually gets forwarded all over the place along the
way to me), so if you don't get a reply within a reasonable time, please
resend.
It doesn't work: what now?
--------------------------
Do the same as above, but also include the output of the ifconfig and route
commands, as well as any pertinent log entries (ie. anything that starts
with "arcnet:" and has shown up since the last reboot) in your mail.
If you want to try fixing it yourself (I strongly recommend that you mail me
about the problem first, since it might already have been solved) you may
want to try some of the debug levels available. For heavy testing on
D_DURING or more, it would be a REALLY good idea to kill your klogd daemon
first! D_DURING displays 4-5 lines for each packet sent or received. D_TX,
D_RX, and D_SKB actually DISPLAY each packet as it is sent or received,
which is obviously quite big.
Starting with v2.40 ALPHA, the autoprobe routines have changed
significantly. In particular, they won't tell you why the card was not
found unless you turn on the D_INIT_REASONS debugging flag.
Once the driver is running, you can run the arcdump shell script (available
from me or in the full ARCnet package, if you have it) as root to list the
contents of the arcnet buffers at any time. To make any sense at all out of
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.
Ping-pong buffers are implemented both ways.
If your debug level includes D_DURING and you did NOT define SLOW_XMIT_COPY,
the buffers are cleared to a constant value of 0x42 every time the card is
reset (which should only happen when you do an ifconfig up, or when Linux
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:
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.
Note that the debug level is (starting with v1.90 ALPHA) a binary
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.
E-mail me about your problem.
I want to send money: what now?
-------------------------------
Go take a nap or something. You'll feel better in the morning.

8
Documentation/networking/atm.txt Normal file
View File

@@ -0,0 +1,8 @@
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
page at http://linux-atm.sourceforge.net/
If you encounter problems with ATM, please report them on the ATM
on Linux mailing list. Subscription information, archives, etc.,
can be found on http://linux-atm.sourceforge.net/

10
Documentation/networking/ax25.txt Normal file
View File

@@ -0,0 +1,10 @@
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
found on http://www.linux-ax25.org.
There is an active mailing list for discussing Linux amateur radio matters
called linux-hams@vger.kernel.org. To subscribe to it, send a message to
majordomo@vger.kernel.org with the words "subscribe linux-hams" in the body
of the message, the subject field is ignored. You don't need to be
subscribed to post but of course that means you might miss an answer.

158
Documentation/networking/baycom.txt Normal file
View File

@@ -0,0 +1,158 @@
LINUX DRIVERS FOR BAYCOM MODEMS
Thomas M. Sailer, HB9JNX/AE4WA, <sailer@ife.ee.ethz.ch>
!!NEW!! (04/98) 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.
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,
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.
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
does not work with your UART.
baycom_par:
This driver supports the par96 and picpar modems.
Its devices are called bcp0 through bcp3.
baycom_epp:
This driver supports the EPP modem.
Its devices are called bce0 through bce3.
This driver is work-in-progress.
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)
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.
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
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
simple. Once installed, four interfaces named bc{sf,sh,p,e}[0-3] are available.
sethdlc from the ax25 utilities may be used to set driver states etc.
Users of userland AX.25 stacks may use the net2kiss utility (also available
in the ax25 utilities package) to convert packets of a network interface
to a KISS stream on a pseudo tty. There's also a patch available from
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.conf).
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).
insmod baycom_par mode="picpar" iobase=0x378
sethdlc -i bcp0 -p mode "picpar" io 0x378
Both lines configure the first port to drive a picpar modem at the
first parallel port (LPT1 under DOS). (Note: picpar implies
hardware DCD, par96 implies software DCD).
The channel access parameters can be set with sethdlc -a or kissparms.
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.
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.
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
interface at a time. The serial driver grabs all interfaces it can find at
startup time. Therefore the baycom drivers subsequently won't be able to
access a serial port. You might therefore find it necessary to release
a port owned by the serial driver with 'setserial /dev/ttyS# uart none', where
# is the number of the interface. The baycom drivers do not reserve any
ports at startup, unless one is specified on the 'insmod' command line. Another
method to solve the problem is to compile all drivers as modules and
leave it to kmod to load the correct driver depending on the application.
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

36
Documentation/networking/bcm43xx.txt Normal file
View File

@@ -0,0 +1,36 @@
BCM43xx Linux Driver Project
============================
About this software
-------------------
The goal of this project is to develop a linux driver for Broadcom
BCM43xx chips, based on the specification at
http://bcm-specs.sipsolutions.net/
The project page is http://bcm43xx.berlios.de/
Requirements
------------
1) Linux Kernel 2.6.16 or later
http://www.kernel.org/
You may want to configure your kernel with:
CONFIG_DEBUG_FS (optional):
-> Kernel hacking
-> Debug Filesystem
2) SoftMAC IEEE 802.11 Networking Stack extension and patched ieee80211
modules:
http://softmac.sipsolutions.net/
3) Firmware Files
Please try fwcutter. Fwcutter can extract the firmware from various
binary driver files. It supports driver files from Windows, MacOS and
Linux. You can get fwcutter from http://bcm43xx.berlios.de/.
Also, fwcutter comes with a README file for further instructions.

2187
Documentation/networking/bonding.txt Normal file
View File

File diff suppressed because it is too large Load Diff

8
Documentation/networking/bridge.txt Normal file
View File

@@ -0,0 +1,8 @@
In order to use the Ethernet bridging functionality, you'll need the
userspace tools. These programs and documentation are available
at http://bridge.sourceforge.net. The download page is
http://prdownloads.sourceforge.net/bridge.
If you still have questions, don't hesitate to post to the mailing list
(more info http://lists.osdl.org/mailman/listinfo/bridge).

248
Documentation/networking/comx.txt Normal file
View File

@@ -0,0 +1,248 @@
COMX drivers for the 2.2 kernel
Originally written by: Tivadar Szemethy, <tiv@itc.hu>
Currently maintained by: Gergely Madarasz <gorgo@itc.hu>
Last change: 21/06/1999.
INTRODUCTION
This document describes the software drivers and their use for the
COMX line of synchronous serial adapters for Linux version 2.2.0 and
above.
The cards are produced and sold by ITC-Pro Ltd. Budapest, Hungary
For further info contact <info@itc.hu>
or http://www.itc.hu (mostly in Hungarian).
The firmware files and software are available from ftp://ftp.itc.hu
Currently, the drivers support the following cards and protocols:
COMX (2x64 kbps intelligent board)
CMX (1x256 + 1x128 kbps intelligent board)
HiCOMX (2x2Mbps intelligent board)
LoCOMX (1x512 kbps passive board)
MixCOM (1x512 or 2x512kbps passive board with a hardware watchdog an
optional BRI interface and optional flashROM (1-32M))
SliceCOM (1x2Mbps channelized E1 board)
PciCOM (X21)
At the moment of writing this document, the (Cisco)-HDLC, LAPB, SyncPPP and
Frame Relay (DTE, rfc1294 IP encapsulation with partially implemented Q933a
LMI) protocols are available as link-level protocol.
X.25 support is being worked on.
USAGE
Load the comx.o module and the hardware-specific and protocol-specific
modules you'll need into the running kernel using the insmod utility.
This creates the /proc/comx directory.
See the example scripts in the 'etc' directory.
/proc INTERFACE INTRO
The COMX driver set has a new type of user interface based on the /proc
filesystem which eliminates the need for external user-land software doing
IOCTL calls.
Each network interface or device (i.e. those ones you configure with 'ifconfig'
and 'route' etc.) has a corresponding directory under /proc/comx. You can
dynamically create a new interface by saying 'mkdir /proc/comx/comx0' (or you
can name it whatever you want up to 8 characters long, comx[n] is just a
convention).
Generally the files contained in these directories are text files, which can
be viewed by 'cat filename' and you can write a string to such a file by
saying 'echo _string_ >filename'. This is very similar to the sysctl interface.
Don't use a text editor to edit these files, always use 'echo' (or 'cat'
where appropriate).
When you've created the comx[n] directory, two files are created automagically
in it: 'boardtype' and 'protocol'. You have to fill in these files correctly
for your board and protocol you intend to use (see the board and protocol
descriptions in this file below or the example scripts in the 'etc' directory).
After filling in these files, other files will appear in the directory for
setting the various hardware- and protocol-related informations (for example
irq and io addresses, keepalive values etc.) These files are set to default
values upon creation, so you don't necessarily have to change all of them.
When you're ready with filling in the files in the comx[n] directory, you can
configure the corresponding network interface with the standard network
configuration utilities. If you're unable to bring the interfaces up, look up
the various kernel log files on your system, and consult the messages for
a probable reason.
EXAMPLE
To create the interface 'comx0' which is the first channel of a COMX card:
insmod comx
# insmod comx-hw-comx ; insmod comx-proto-ppp (these are usually
autoloaded if you use the kernel module loader)
mkdir /proc/comx/comx0
echo comx >/proc/comx/comx0/boardtype
echo 0x360 >/proc/comx/comx0/io <- jumper-selectable I/O port
echo 0x0a >/proc/comx/comx0/irq <- jumper-selectable IRQ line
echo 0xd000 >/proc/comx/comx0/memaddr <- software-configurable memory
address. COMX uses 64 KB, and this
can be: 0xa000, 0xb000, 0xc000,
0xd000, 0xe000. Avoid conflicts
with other hardware.
cat </etc/siol1.rom >/proc/comx/comx0/firmware <- the firmware for the card
echo HDLC >/proc/comx/comx0/protocol <- the data-link protocol
echo 10 >/proc/comx/comx0/keepalive <- the keepalive for the protocol
ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255 <-
finally configure it with ifconfig
Check its status:
cat /proc/comx/comx0/status
If you want to use the second channel of this board:
mkdir /proc/comx/comx1
echo comx >/proc/comx/comx1/boardtype
echo 0x360 >/proc/comx/comx1/io
echo 10 >/proc/comx/comx1/irq
echo 0xd000 >/proc/comx/comx1/memaddr
echo 1 >/proc/comx/comx1/channel <- channels are numbered
as 0 (default) and 1
Now, check if the driver recognized that you're going to use the other
channel of the same adapter:
cat /proc/comx/comx0/twin
comx1
cat /proc/comx/comx1/twin
comx0
You don't have to load the firmware twice, if you use both channels of
an adapter, just write it into the channel 0's /proc firmware file.
Default values: io 0x360 for COMX, 0x320 (HICOMX), irq 10, memaddr 0xd0000
THE LOCOMX HARDWARE DRIVER
The LoCOMX driver doesn't require firmware, and it doesn't use memory either,
but it uses DMA channels 1 and 3. You can set the clock rate (if enabled by
jumpers on the board) by writing the kbps value into the file named 'clock'.
Set it to 'external' (it is the default) if you have external clock source.
(Note: currently the LoCOMX driver does not support the internal clock)
THE COMX, CMX AND HICOMX DRIVERS
On the HICOMX, COMX and CMX, you have to load the firmware (it is different for
the three cards!). All these adapters can share the same memory
address (we usually use 0xd0000). On the CMX you can set the internal
clock rate (if enabled by jumpers on the small adapter boards) by writing
the kbps value into the 'clock' file. You have to do this before initializing
the card. If you use both HICOMX and CMX/COMX cards, initialize the HICOMX
first. The I/O address of the HICOMX board is not configurable by any
method available to the user: it is hardwired to 0x320, and if you have to
change it, consult ITC-Pro Ltd.
THE MIXCOM DRIVER
The MixCOM board doesn't require firmware, the driver communicates with
it through I/O ports. You can have three of these cards in one machine.
THE SLICECOM DRIVER
The SliceCOM board doesn't require firmware. You can have 4 of these cards
in one machine. The driver doesn't (yet) support shared interrupts, so
you will need a separate IRQ line for every board.
Read Documentation/networking/slicecom.txt for help on configuring
this adapter.
THE HDLC/PPP LINE PROTOCOL DRIVER
The HDLC/SyncPPP line protocol driver uses the kernel's built-in syncppp
driver (syncppp.o). You don't have to manually select syncppp.o when building
the kernel, the dependencies compile it in automatically.
EXAMPLE
(setting up hw parameters, see above)
# using HDLC:
echo hdlc >/proc/comx/comx0/protocol
echo 10 >/proc/comx/comx0/keepalive <- not necessary, 10 is the default
ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
(setting up hw parameters, see above)
# using PPP:
echo ppp >/proc/comx/comx0/protocol
ifconfig comx0 up
ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
THE LAPB LINE PROTOCOL DRIVER
For this, you'll need to configure LAPB support (See 'LAPB Data Link Driver' in
'Network options' section) into your kernel (thanks to Jonathan Naylor for his
excellent implementation).
comx-proto-lapb.o provides the following files in the appropriate directory
(the default values in parens): t1 (5), t2 (1), n2 (20), mode (DTE, STD) and
window (7). Agree with the administrator of your peer router on these
settings (most people use defaults, but you have to know if you are DTE or
DCE).
EXAMPLE
(setting up hw parameters, see above)
echo lapb >/proc/comx/comx0/protocol
echo dce >/proc/comx/comx0/mode <- DCE interface in this example
ifconfig comx0 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.255
THE FRAME RELAY PROTOCOL DRIVER
You DON'T need any other frame relay related modules from the kernel to use
COMX-Frame Relay. This protocol is a bit more complicated than the others,
because it allows to use 'subinterfaces' or DLCIs within one physical device.
First you have to create the 'master' device (the actual physical interface)
as you would do for other protocols. Specify 'frad' as protocol type.
Now you can bring this interface up by saying 'ifconfig comx0 up' (or whatever
you've named the interface). Do not assign any IP address to this interface
and do not set any routes through it.
Then, set up your DLCIs the following way: create a comx interface for each
DLCI you intend to use (with mkdir), and write 'dlci' to the 'boardtype' file,
and 'ietf-ip' to the 'protocol' file. Currently, the only supported
encapsulation type is this (also called as RFC1294/1490 IP encapsulation).
Write the DLCI number to the 'dlci' file, and write the name of the physical
COMX device to the file called 'master'.
Now you can assign an IP address to this interface and set routes using it.
See the example file for further info and example config script.
Notes: this driver implements a DTE interface with partially implemented
Q933a LMI.
You can find an extensively commented example in the 'etc' directory.
FURTHER /proc FILES
boardtype:
Type of the hardware. Valid values are:
'comx', 'hicomx', 'locomx', 'cmx', 'slicecom'.
protocol:
Data-link protocol on this channel. Can be: HDLC, LAPB, PPP, FRAD
status:
You can read the channel's actual status from the 'status' file, for example
'cat /proc/comx/comx3/status'.
lineup_delay:
Interpreted in seconds (default is 1). Used to avoid line jitter: the system
will consider the line status 'UP' only if it is up for at least this number
of seconds.
debug:
You can set various debug options through this file. Valid options are:
'comx_events', 'comx_tx', 'comx_rx', 'hw_events', 'hw_tx', 'hw_rx'.
You can enable a debug options by writing its name prepended by a '+' into
the debug file, for example 'echo +comx_rx >comx0/debug'.
Disabling an option happens similarly, use the '-' prefix
(e.g. 'echo -hw_rx >debug').
Debug results can be read from the debug file, for example:
tail -f /proc/comx/comx2/debug

63
Documentation/networking/cops.txt Normal file
View File

@@ -0,0 +1,63 @@
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"

703
Documentation/networking/cs89x0.txt Normal file
View File

@@ -0,0 +1,703 @@
NOTE
----
This document was contributed by Cirrus Logic for kernel 2.2.5. This version
has been updated for 2.3.48 by Andrew Morton <andrewm@uow.edu.au>
Cirrus make a copy of this driver available at their website, as
described below. In general, you should use the driver version which
comes with your Linux distribution.
CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
Linux Network Interface Driver ver. 2.00 <kernel 2.3.48>
===============================================================================
TABLE OF CONTENTS
1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
1.1 Product Overview
1.2 Driver Description
1.2.1 Driver Name
1.2.2 File in the Driver Package
1.3 System Requirements
1.4 Licensing Information
2.0 ADAPTER INSTALLATION and CONFIGURATION
2.1 CS8900-based Adapter Configuration
2.2 CS8920-based Adapter Configuration
3.0 LOADING THE DRIVER AS A MODULE
4.0 COMPILING THE DRIVER
4.1 Compiling the Driver as a Loadable Module
4.2 Compiling the driver to support memory mode
4.3 Compiling the driver to support Rx DMA
4.4 Compiling the Driver into the Kernel
5.0 TESTING AND TROUBLESHOOTING
5.1 Known Defects and Limitations
5.2 Testing the Adapter
5.2.1 Diagnostic Self-Test
5.2.2 Diagnostic Network Test
5.3 Using the Adapter's LEDs
5.4 Resolving I/O Conflicts
6.0 TECHNICAL SUPPORT
6.1 Contacting Cirrus Logic's Technical Support
6.2 Information Required Before Contacting Technical Support
6.3 Obtaining the Latest Driver Version
6.4 Current maintainer
6.5 Kernel boot parameters
1.0 CIRRUS LOGIC LAN CS8900/CS8920 ETHERNET ADAPTERS
===============================================================================
1.1 PRODUCT OVERVIEW
The CS8900-based ISA Ethernet Adapters from Cirrus Logic follow
IEEE 802.3 standards and support half or full-duplex operation in ISA bus
computers on 10 Mbps Ethernet networks. The adapters are designed for operation
in 16-bit ISA or EISA bus expansion slots and are available in
10BaseT-only or 3-media configurations (10BaseT, 10Base2, and AUI for 10Base-5
or fiber networks).
CS8920-based adapters are similar to the CS8900-based adapter with additional
features for Plug and Play (PnP) support and Wakeup Frame recognition. As
such, the configuration procedures differ somewhat between the two types of
adapters. Refer to the "Adapter Configuration" section for details on
configuring both types of adapters.
1.2 DRIVER DESCRIPTION
The CS8900/CS8920 Ethernet Adapter driver for Linux supports the Linux
v2.3.48 or greater kernel. It can be compiled directly into the kernel
or loaded at run-time as a device driver module.
1.2.1 Driver Name: cs89x0
1.2.2 Files in the Driver Archive:
The files in the driver at Cirrus' website include:
readme.txt - this file
build - batch file to compile cs89x0.c.
cs89x0.c - driver C code
cs89x0.h - driver header file
cs89x0.o - pre-compiled module (for v2.2.5 kernel)
config/Config.in - sample file to include cs89x0 driver in the kernel.
config/Makefile - sample file to include cs89x0 driver in the kernel.
config/Space.c - sample file to include cs89x0 driver in the kernel.
1.3 SYSTEM REQUIREMENTS
The following hardware is required:
* Cirrus Logic LAN (CS8900/20-based) Ethernet ISA Adapter
* IBM or IBM-compatible PC with:
* An 80386 or higher processor
* 16 bytes of contiguous IO space available between 210h - 370h
* One available IRQ (5,10,11,or 12 for the CS8900, 3-7,9-15 for CS8920).
* Appropriate cable (and connector for AUI, 10BASE-2) for your network
topology.
The following software is required:
* LINUX kernel version 2.3.48 or higher
* CS8900/20 Setup Utility (DOS-based)
* LINUX kernel sources for your kernel (if compiling into kernel)
* GNU Toolkit (gcc and make) v2.6 or above (if compiling into kernel
or a module)
1.4 LICENSING INFORMATION
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, version 1.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
more details.
For a full copy of the GNU General Public License, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
2.0 ADAPTER INSTALLATION and CONFIGURATION
===============================================================================
Both the CS8900 and CS8920-based adapters can be configured using parameters
stored in an on-board EEPROM. You must use the DOS-based CS8900/20 Setup
Utility if you want to change the adapter's configuration in EEPROM.
When loading the driver as a module, you can specify many of the adapter's
configuration parameters on the command-line to override the EEPROM's settings
or for interface configuration when an EEPROM is not used. (CS8920-based
adapters must use an EEPROM.) See Section 3.0 LOADING THE DRIVER AS A MODULE.
Since the CS8900/20 Setup Utility is a DOS-based application, you must install
and configure the adapter in a DOS-based system using the CS8900/20 Setup
Utility before installation in the target LINUX system. (Not required if
installing a CS8900-based adapter and the default configuration is acceptable.)
2.1 CS8900-BASED ADAPTER CONFIGURATION
CS8900-based adapters shipped from Cirrus Logic have been configured
with the following "default" settings:
Operation Mode: Memory Mode
IRQ: 10
Base I/O Address: 300
Memory Base Address: D0000
Optimization: DOS Client
Transmission Mode: Half-duplex
BootProm: None
Media Type: Autodetect (3-media cards) or
10BASE-T (10BASE-T only adapter)
You should only change the default configuration settings if conflicts with
another adapter exists. To change the adapter's configuration, run the
CS8900/20 Setup Utility.
2.2 CS8920-BASED ADAPTER CONFIGURATION
CS8920-based adapters are shipped from Cirrus Logic configured as Plug
and Play (PnP) enabled. However, since the cs89x0 driver does NOT
support PnP, you must install the CS8920 adapter in a DOS-based PC and
run the CS8900/20 Setup Utility to disable PnP and configure the
adapter before installation in the target Linux system. Failure to do
this will leave the adapter inactive and the driver will be unable to
communicate with the adapter.
****************************************************************
* CS8920-BASED ADAPTERS: *
* *
* CS8920-BASED ADAPTERS ARE PLUG and PLAY ENABLED BY DEFAULT. *
* THE CS89X0 DRIVER DOES NOT SUPPORT PnP. THEREFORE, YOU MUST *
* RUN THE CS8900/20 SETUP UTILITY TO DISABLE PnP SUPPORT AND *
* TO ACTIVATE THE ADAPTER. *
****************************************************************
3.0 LOADING THE DRIVER AS A MODULE
===============================================================================
If the driver is compiled as a loadable module, you can load the driver module
with the 'modprobe' command. Many of the adapter's configuration parameters can
be specified as command-line arguments to the load command. This facility
provides a means to override the EEPROM's settings or for interface
configuration when an EEPROM is not used.
Example:
insmod cs89x0.o io=0x200 irq=0xA media=aui
This example loads the module and configures the adapter to use an IO port base
address of 200h, interrupt 10, and use the AUI media connection. The following
configuration options are available on the command line:
* io=### - specify IO address (200h-360h)
* irq=## - specify interrupt level
* use_dma=1 - Enable DMA
* dma=# - specify dma channel (Driver is compiled to support
Rx DMA only)
* dmasize=# (16 or 64) - DMA size 16K or 64K. Default value is set to 16.
* media=rj45 - specify media type
or media=bnc
or media=aui
or media=auto
* duplex=full - specify forced half/full/autonegotiate duplex
or duplex=half
or duplex=auto
* debug=# - debug level (only available if the driver was compiled
for debugging)
NOTES:
a) If an EEPROM is present, any specified command-line parameter
will override the corresponding configuration value stored in
EEPROM.
b) The "io" parameter must be specified on the command-line.
c) The driver's hardware probe routine is designed to avoid
writing to I/O space until it knows that there is a cs89x0
card at the written addresses. This could cause problems
with device probing. To avoid this behaviour, add one
to the `io=' module parameter. This doesn't actually change
the I/O address, but it is a flag to tell the driver
to partially initialise the hardware before trying to
identify the card. This could be dangerous if you are
not sure that there is a cs89x0 card at the provided address.
For example, to scan for an adapter located at IO base 0x300,
specify an IO address of 0x301.
d) The "duplex=auto" parameter is only supported for the CS8920.
e) The minimum command-line configuration required if an EEPROM is
not present is:
io
irq
media type (no autodetect)
f) The following additional parameters are CS89XX defaults (values
used with no EEPROM or command-line argument).
* DMA Burst = enabled
* IOCHRDY Enabled = enabled
* UseSA = enabled
* CS8900 defaults to half-duplex if not specified on command-line
* CS8920 defaults to autoneg if not specified on command-line
* Use reset defaults for other config parameters
* dma_mode = 0
g) You can use ifconfig to set the adapter's Ethernet address.
h) Many Linux distributions use the 'modprobe' command to load
modules. This program uses the '/etc/conf.modules' file to
determine configuration information which is passed to a driver
module when it is loaded. All the configuration options which are
described above may be placed within /etc/conf.modules.
For example:
> cat /etc/conf.modules
...
alias eth0 cs89x0
options cs89x0 io=0x0200 dma=5 use_dma=1
...
In this example we are telling the module system that the
ethernet driver for this machine should use the cs89x0 driver. We
are asking 'modprobe' to pass the 'io', 'dma' and 'use_dma'
arguments to the driver when it is loaded.
i) Cirrus recommend that the cs89x0 use the ISA DMA channels 5, 6 or
7. You will probably find that other DMA channels will not work.
j) The cs89x0 supports DMA for receiving only. DMA mode is
significantly more efficient. Flooding a 400 MHz Celeron machine
with large ping packets consumes 82% of its CPU capacity in non-DMA
mode. With DMA this is reduced to 45%.
k) If your Linux kernel was compiled with inbuilt plug-and-play
support you will be able to find information about the cs89x0 card
with the command
cat /proc/isapnp
l) If during DMA operation you find erratic behavior or network data
corruption you should use your PC's BIOS to slow the EISA bus clock.
m) If the cs89x0 driver is compiled directly into the kernel
(non-modular) then its I/O address is automatically determined by
ISA bus probing. The IRQ number, media options, etc are determined
from the card's EEPROM.
n) If the cs89x0 driver is compiled directly into the kernel, DMA
mode may be selected by providing the kernel with a boot option
'cs89x0_dma=N' where 'N' is the desired DMA channel number (5, 6 or 7).
Kernel boot options may be provided on the LILO command line:
LILO boot: linux cs89x0_dma=5
or they may be placed in /etc/lilo.conf:
image=/boot/bzImage-2.3.48
append="cs89x0_dma=5"
label=linux
root=/dev/hda5
read-only
The DMA Rx buffer size is hardwired to 16 kbytes in this mode.
(64k mode is not available).
4.0 COMPILING THE DRIVER
===============================================================================
The cs89x0 driver can be compiled directly into the kernel or compiled into
a loadable device driver module.
4.1 COMPILING THE DRIVER AS A LOADABLE MODULE
To compile the driver into a loadable module, use the following command
(single command line, without quotes):
"gcc -D__KERNEL__ -I/usr/src/linux/include -I/usr/src/linux/net/inet -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -DMODULE -DCONFIG_MODVERSIONS
-c cs89x0.c"
4.2 COMPILING THE DRIVER TO SUPPORT MEMORY MODE
Support for memory mode was not carried over into the 2.3 series kernels.
4.3 COMPILING THE DRIVER TO SUPPORT Rx DMA
The compile-time optionality for DMA was removed in the 2.3 kernel
series. DMA support is now unconditionally part of the driver. It is
enabled by the 'use_dma=1' module option.
4.4 COMPILING THE DRIVER INTO THE KERNEL
If your Linux distribution already has support for the cs89x0 driver
then simply copy the source file to the /usr/src/linux/drivers/net
directory to replace the original ones and run the make utility to
rebuild the kernel. See Step 3 for rebuilding the kernel.
If your Linux does not include the cs89x0 driver, you need to edit three
configuration files, copy the source file to the /usr/src/linux/drivers/net
directory, and then run the make utility to rebuild the kernel.
1. Edit the following configuration files by adding the statements as
indicated. (When possible, try to locate the added text to the section of the
file containing similar statements).
a.) In /usr/src/linux/drivers/net/Config.in, add:
tristate 'CS89x0 support' CONFIG_CS89x0
Example:
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'ICL EtherTeam 16i/32 support' CONFIG_ETH16I
fi
tristate 'CS89x0 support' CONFIG_CS89x0
tristate 'NE2000/NE1000 support' CONFIG_NE2000
if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
tristate 'NI5210 support' CONFIG_NI52
b.) In /usr/src/linux/drivers/net/Makefile, add the following lines:
ifeq ($(CONFIG_CS89x0),y)
L_OBJS += cs89x0.o
else
ifeq ($(CONFIG_CS89x0),m)
M_OBJS += cs89x0.o
endif
endif
c.) In /linux/drivers/net/Space.c file, add the line:
extern int cs89x0_probe(struct device *dev);
Example:
extern int ultra_probe(struct device *dev);
extern int wd_probe(struct device *dev);
extern int el2_probe(struct device *dev);
extern int cs89x0_probe(struct device *dev);
extern int ne_probe(struct device *dev);
extern int hp_probe(struct device *dev);
extern int hp_plus_probe(struct device *dev);
Also add:
#ifdef CONFIG_CS89x0
{ cs89x0_probe,0 },
#endif
2.) Copy the driver source files (cs89x0.c and cs89x0.h)
into the /usr/src/linux/drivers/net directory.
3.) Go to /usr/src/linux directory and run 'make config' followed by 'make'
(or make bzImage) to rebuild the kernel.
4.) Use the DOS 'setup' utility to disable plug and play on the NIC.
5.0 TESTING AND TROUBLESHOOTING
===============================================================================
5.1 KNOWN DEFECTS and LIMITATIONS
Refer to the RELEASE.TXT file distributed as part of this archive for a list of
known defects, driver limitations, and work arounds.
5.2 TESTING THE ADAPTER
Once the adapter has been installed and configured, the diagnostic option of
the CS8900/20 Setup Utility can be used to test the functionality of the
adapter and its network connection. Use the diagnostics 'Self Test' option to
test the functionality of the adapter with the hardware configuration you have
assigned. You can use the diagnostics 'Network Test' to test the ability of the
adapter to communicate across the Ethernet with another PC equipped with a
CS8900/20-based adapter card (it must also be running the CS8900/20 Setup
Utility).
NOTE: The Setup Utility's diagnostics are designed to run in a
DOS-only operating system environment. DO NOT run the diagnostics
from a DOS or command prompt session under Windows 95, Windows NT,
OS/2, or other operating system.
To run the diagnostics tests on the CS8900/20 adapter:
1.) Boot DOS on the PC and start the CS8900/20 Setup Utility.
2.) The adapter's current configuration is displayed. Hit the ENTER key to
get to the main menu.
4.) Select 'Diagnostics' (ALT-G) from the main menu.
* Select 'Self-Test' to test the adapter's basic functionality.
* Select 'Network Test' to test the network connection and cabling.
5.2.1 DIAGNOSTIC SELF-TEST
The diagnostic self-test checks the adapter's basic functionality as well as
its ability to communicate across the ISA bus based on the system resources
assigned during hardware configuration. The following tests are performed:
* IO Register Read/Write Test
The IO Register Read/Write test insures that the CS8900/20 can be
accessed in IO mode, and that the IO base address is correct.
* Shared Memory Test
The Shared Memory test insures the CS8900/20 can be accessed in memory
mode and that the range of memory addresses assigned does not conflict
with other devices in the system.
* Interrupt Test
The Interrupt test insures there are no conflicts with the assigned IRQ
signal.
* EEPROM Test
The EEPROM test insures the EEPROM can be read.
* Chip RAM Test
The Chip RAM test insures the 4K of memory internal to the CS8900/20 is
working properly.
* Internal Loop-back Test
The Internal Loop Back test insures the adapter's transmitter and
receiver are operating properly. If this test fails, make sure the
adapter's cable is connected to the network (check for LED activity for
example).
* Boot PROM Test
The Boot PROM test insures the Boot PROM is present, and can be read.
Failure indicates the Boot PROM was not successfully read due to a
hardware problem or due to a conflicts on the Boot PROM address
assignment. (Test only applies if the adapter is configured to use the
Boot PROM option.)
Failure of a test item indicates a possible system resource conflict with
another device on the ISA bus. In this case, you should use the Manual Setup
option to reconfigure the adapter by selecting a different value for the system
resource that failed.
5.2.2 DIAGNOSTIC NETWORK TEST
The Diagnostic Network Test verifies a working network connection by
transferring data between two CS8900/20 adapters installed in different PCs
on the same network. (Note: the diagnostic network test should not be run
between two nodes across a router.)
This test requires that each of the two PCs have a CS8900/20-based adapter
installed and have the CS8900/20 Setup Utility running. The first PC is
configured as a Responder and the other PC is configured as an Initiator.
Once the Initiator is started, it sends data frames to the Responder which
returns the frames to the Initiator.
The total number of frames received and transmitted are displayed on the
Initiator's display, along with a count of the number of frames received and
transmitted OK or in error. The test can be terminated anytime by the user at
either PC.
To setup the Diagnostic Network Test:
1.) Select a PC with a CS8900/20-based adapter and a known working network
connection to act as the Responder. Run the CS8900/20 Setup Utility
and select 'Diagnostics -> Network Test -> Responder' from the main
menu. Hit ENTER to start the Responder.
2.) Return to the PC with the CS8900/20-based adapter you want to test and
start the CS8900/20 Setup Utility.
3.) From the main menu, Select 'Diagnostic -> Network Test -> Initiator'.
Hit ENTER to start the test.
You may stop the test on the Initiator at any time while allowing the Responder
to continue running. In this manner, you can move to additional PCs and test
them by starting the Initiator on another PC without having to stop/start the
Responder.
5.3 USING THE ADAPTER'S LEDs
The 2 and 3-media adapters have two LEDs visible on the back end of the board
located near the 10Base-T connector.
Link Integrity LED: A "steady" ON of the green LED indicates a valid 10Base-T
connection. (Only applies to 10Base-T. The green LED has no significance for
a 10Base-2 or AUI connection.)
TX/RX LED: The yellow LED lights briefly each time the adapter transmits or
receives data. (The yellow LED will appear to "flicker" on a typical network.)
5.4 RESOLVING I/O CONFLICTS
An IO conflict occurs when two or more adapter use the same ISA resource (IO
address, memory address or IRQ). You can usually detect an IO conflict in one
of four ways after installing and or configuring the CS8900/20-based adapter:
1.) The system does not boot properly (or at all).
2.) The driver cannot communicate with the adapter, reporting an "Adapter
not found" error message.
3.) You cannot connect to the network or the driver will not load.
4.) If you have configured the adapter to run in memory mode but the driver
reports it is using IO mode when loading, this is an indication of a
memory address conflict.
If an IO conflict occurs, run the CS8900/20 Setup Utility and perform a
diagnostic self-test. Normally, the ISA resource in conflict will fail the
self-test. If so, reconfigure the adapter selecting another choice for the
resource in conflict. Run the diagnostics again to check for further IO
conflicts.
In some cases, such as when the PC will not boot, it may be necessary to remove
the adapter and reconfigure it by installing it in another PC to run the
CS8900/20 Setup Utility. Once reinstalled in the target system, run the
diagnostics self-test to ensure the new configuration is free of conflicts
before loading the driver again.
When manually configuring the adapter, keep in mind the typical ISA system
resource usage as indicated in the tables below.
I/O Address Device IRQ Device
----------- -------- --- --------
200-20F Game I/O adapter 3 COM2, Bus Mouse
230-23F Bus Mouse 4 COM1
270-27F LPT3: third parallel port 5 LPT2
2F0-2FF COM2: second serial port 6 Floppy Disk controller
320-32F Fixed disk controller 7 LPT1
8 Real-time Clock
9 EGA/VGA display adapter
12 Mouse (PS/2)
Memory Address Device 13 Math Coprocessor
-------------- --------------------- 14 Hard Disk controller
A000-BFFF EGA Graphics Adapter
A000-C7FF VGA Graphics Adapter
B000-BFFF Mono Graphics Adapter
B800-BFFF Color Graphics Adapter
E000-FFFF AT BIOS
6.0 TECHNICAL SUPPORT
===============================================================================
6.1 CONTACTING CIRRUS LOGIC'S TECHNICAL SUPPORT
Cirrus Logic's CS89XX Technical Application Support can be reached at:
Telephone :(800) 888-5016 (from inside U.S. and Canada)
:(512) 442-7555 (from outside the U.S. and Canada)
Fax :(512) 912-3871
Email :ethernet@crystal.cirrus.com
WWW :http://www.cirrus.com
6.2 INFORMATION REQUIRED BEFORE CONTACTING TECHNICAL SUPPORT
Before contacting Cirrus Logic for technical support, be prepared to provide as
Much of the following information as possible.
1.) Adapter type (CRD8900, CDB8900, CDB8920, etc.)
2.) Adapter configuration
* IO Base, Memory Base, IO or memory mode enabled, IRQ, DMA channel
* Plug and Play enabled/disabled (CS8920-based adapters only)
* Configured for media auto-detect or specific media type (which type).
3.) PC System's Configuration
* Plug and Play system (yes/no)
* BIOS (make and version)
* System make and model
* CPU (type and speed)
* System RAM
* SCSI Adapter
4.) Software
* CS89XX driver and version
* Your network operating system and version
* Your system's OS version
* Version of all protocol support files
5.) Any Error Message displayed.
6.3 OBTAINING THE LATEST DRIVER VERSION
You can obtain the latest CS89XX drivers and support software from Cirrus Logic's
Web site. You can also contact Cirrus Logic's Technical Support (email:
ethernet@crystal.cirrus.com) and request that you be registered for automatic
software-update notification.
Cirrus Logic maintains a web page at http://www.cirrus.com with the
latest drivers and technical publications.
6.4 Current maintainer
In February 2000 the maintenance of this driver was assumed by Andrew
Morton <akpm@zip.com.au>
6.5 Kernel module parameters
For use in embedded environments with no cs89x0 EEPROM, the kernel boot
parameter `cs89x0_media=' has been implemented. Usage is:
cs89x0_media=rj45 or
cs89x0_media=aui or
cs89x0_media=bnc

352
Documentation/networking/cxgb.txt Normal file
View File

@@ -0,0 +1,352 @@
Chelsio N210 10Gb Ethernet Network Controller
Driver Release Notes for Linux
Version 2.1.1
June 20, 2005
CONTENTS
========
INTRODUCTION
FEATURES
PERFORMANCE
DRIVER MESSAGES
KNOWN ISSUES
SUPPORT
INTRODUCTION
============
This document describes the Linux driver for Chelsio 10Gb Ethernet Network
Controller. This driver supports the Chelsio N210 NIC and is backward
compatible with the Chelsio N110 model 10Gb NICs.
FEATURES
========
Adaptive Interrupts (adaptive-rx)
---------------------------------
This feature provides an adaptive algorithm that adjusts the interrupt
coalescing parameters, allowing the driver to dynamically adapt the latency
settings to achieve the highest performance during various types of network
load.
The interface used to control this feature is ethtool. Please see the
ethtool manpage for additional usage information.
By default, adaptive-rx is disabled.
To enable adaptive-rx:
ethtool -C <interface> adaptive-rx on
To disable adaptive-rx, use ethtool:
ethtool -C <interface> adaptive-rx off
After disabling adaptive-rx, the timer latency value will be set to 50us.
You may set the timer latency after disabling adaptive-rx:
ethtool -C <interface> rx-usecs <microseconds>
An example to set the timer latency value to 100us on eth0:
ethtool -C eth0 rx-usecs 100
You may also provide a timer latency value while disabling adaptive-rx:
ethtool -C <interface> adaptive-rx off rx-usecs <microseconds>
If adaptive-rx is disabled and a timer latency value is specified, the timer
will be set to the specified value until changed by the user or until
adaptive-rx is enabled.
To view the status of the adaptive-rx and timer latency values:
ethtool -c <interface>
TCP Segmentation Offloading (TSO) Support
-----------------------------------------
This feature, also known as "large send", enables a system's protocol stack
to offload portions of outbound TCP processing to a network interface card
thereby reducing system CPU utilization and enhancing performance.
The interface used to control this feature is ethtool version 1.8 or higher.
Please see the ethtool manpage for additional usage information.
By default, TSO is enabled.
To disable TSO:
ethtool -K <interface> tso off
To enable TSO:
ethtool -K <interface> tso on
To view the status of TSO:
ethtool -k <interface>
PERFORMANCE
===========
The following information is provided as an example of how to change system
parameters for "performance tuning" an what value to use. You may or may not
want to change these system parameters, depending on your server/workstation
application. Doing so is not warranted in any way by Chelsio Communications,
and is done at "YOUR OWN RISK". Chelsio will not be held responsible for loss
of data or damage to equipment.
Your distribution may have a different way of doing things, or you may prefer
a different method. These commands are shown only to provide an example of
what to do and are by no means definitive.
Making any of the following system changes will only last until you reboot
your system. You may want to write a script that runs at boot-up which
includes the optimal settings for your system.
Setting PCI Latency Timer:
setpci -d 1425:* 0x0c.l=0x0000F800
Disabling TCP timestamp:
sysctl -w net.ipv4.tcp_timestamps=0
Disabling SACK:
sysctl -w net.ipv4.tcp_sack=0
Setting large number of incoming connection requests:
sysctl -w net.ipv4.tcp_max_syn_backlog=3000
Setting maximum receive socket buffer size:
sysctl -w net.core.rmem_max=1024000
Setting maximum send socket buffer size:
sysctl -w net.core.wmem_max=1024000
Set smp_affinity (on a multiprocessor system) to a single CPU:
echo 1 > /proc/irq/<interrupt_number>/smp_affinity
Setting default receive socket buffer size:
sysctl -w net.core.rmem_default=524287
Setting default send socket buffer size:
sysctl -w net.core.wmem_default=524287
Setting maximum option memory buffers:
sysctl -w net.core.optmem_max=524287
Setting maximum backlog (# of unprocessed packets before kernel drops):
sysctl -w net.core.netdev_max_backlog=300000
Setting TCP read buffers (min/default/max):
sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000"
Setting TCP write buffers (min/pressure/max):
sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000"
Setting TCP buffer space (min/pressure/max):
sysctl -w net.ipv4.tcp_mem="10000000 10000000 10000000"
TCP window size for single connections:
The receive buffer (RX_WINDOW) size must be at least as large as the
Bandwidth-Delay Product of the communication link between the sender and
receiver. Due to the variations of RTT, you may want to increase the buffer
size up to 2 times the Bandwidth-Delay Product. Reference page 289 of
"TCP/IP Illustrated, Volume 1, The Protocols" by W. Richard Stevens.
At 10Gb speeds, use the following formula:
RX_WINDOW >= 1.25MBytes * RTT(in milliseconds)
Example for RTT with 100us: RX_WINDOW = (1,250,000 * 0.1) = 125,000
RX_WINDOW sizes of 256KB - 512KB should be sufficient.
Setting the min, max, and default receive buffer (RX_WINDOW) size:
sysctl -w net.ipv4.tcp_rmem="<min> <default> <max>"
TCP window size for multiple connections:
The receive buffer (RX_WINDOW) size may be calculated the same as single
connections, but should be divided by the number of connections. The
smaller window prevents congestion and facilitates better pacing,
especially if/when MAC level flow control does not work well or when it is
not supported on the machine. Experimentation may be necessary to attain
the correct value. This method is provided as a starting point for the
correct receive buffer size.
Setting the min, max, and default receive buffer (RX_WINDOW) size is
performed in the same manner as single connection.
DRIVER MESSAGES
===============
The following messages are the most common messages logged by syslog. These
may be found in /var/log/messages.
Driver up:
Chelsio Network Driver - version 2.1.1
NIC detected:
eth#: Chelsio N210 1x10GBaseX NIC (rev #), PCIX 133MHz/64-bit
Link up:
eth#: link is up at 10 Gbps, full duplex
Link down:
eth#: link is down
KNOWN ISSUES
============
These issues have been identified during testing. The following information
is provided as a workaround to the problem. In some cases, this problem is
inherent to Linux or to a particular Linux Distribution and/or hardware
platform.
1. Large number of TCP retransmits on a multiprocessor (SMP) system.
On a system with multiple CPUs, the interrupt (IRQ) for the network
controller may be bound to more than one CPU. This will cause TCP
retransmits if the packet data were to be split across different CPUs
and re-assembled in a different order than expected.
To eliminate the TCP retransmits, set smp_affinity on the particular
interrupt to a single CPU. You can locate the interrupt (IRQ) used on
the N110/N210 by using ifconfig:
ifconfig <dev_name> | grep Interrupt
Set the smp_affinity to a single CPU:
echo 1 > /proc/irq/<interrupt_number>/smp_affinity
It is highly suggested that you do not run the irqbalance daemon on your
system, as this will change any smp_affinity setting you have applied.
The irqbalance daemon runs on a 10 second interval and binds interrupts
to the least loaded CPU determined by the daemon. To disable this daemon:
chkconfig --level 2345 irqbalance off
By default, some Linux distributions enable the kernel feature,
irqbalance, which performs the same function as the daemon. To disable
this feature, add the following line to your bootloader:
noirqbalance
Example using the Grub bootloader:
title Red Hat Enterprise Linux AS (2.4.21-27.ELsmp)
root (hd0,0)
kernel /vmlinuz-2.4.21-27.ELsmp ro root=/dev/hda3 noirqbalance
initrd /initrd-2.4.21-27.ELsmp.img
2. After running insmod, the driver is loaded and the incorrect network
interface is brought up without running ifup.
When using 2.4.x kernels, including RHEL kernels, the Linux kernel
invokes a script named "hotplug". This script is primarily used to
automatically bring up USB devices when they are plugged in, however,
the script also attempts to automatically bring up a network interface
after loading the kernel module. The hotplug script does this by scanning
the ifcfg-eth# config files in /etc/sysconfig/network-scripts, looking
for HWADDR=<mac_address>.
If the hotplug script does not find the HWADDRR within any of the
ifcfg-eth# files, it will bring up the device with the next available
interface name. If this interface is already configured for a different
network card, your new interface will have incorrect IP address and
network settings.
To solve this issue, you can add the HWADDR=<mac_address> key to the
interface config file of your network controller.
To disable this "hotplug" feature, you may add the driver (module name)
to the "blacklist" file located in /etc/hotplug. It has been noted that
this does not work for network devices because the net.agent script
does not use the blacklist file. Simply remove, or rename, the net.agent
script located in /etc/hotplug to disable this feature.
3. Transport Protocol (TP) hangs when running heavy multi-connection traffic
on an AMD Opteron system with HyperTransport PCI-X Tunnel chipset.
If your AMD Opteron system uses the AMD-8131 HyperTransport PCI-X Tunnel
chipset, you may experience the "133-Mhz Mode Split Completion Data
Corruption" bug identified by AMD while using a 133Mhz PCI-X card on the
bus PCI-X bus.
AMD states, "Under highly specific conditions, the AMD-8131 PCI-X Tunnel
can provide stale data via split completion cycles to a PCI-X card that
is operating at 133 Mhz", causing data corruption.
AMD's provides three workarounds for this problem, however, Chelsio
recommends the first option for best performance with this bug:
For 133Mhz secondary bus operation, limit the transaction length and
the number of outstanding transactions, via BIOS configuration
programming of the PCI-X card, to the following:
Data Length (bytes): 1k
Total allowed outstanding transactions: 2
Please refer to AMD 8131-HT/PCI-X Errata 26310 Rev 3.08 August 2004,
section 56, "133-MHz Mode Split Completion Data Corruption" for more
details with this bug and workarounds suggested by AMD.
It may be possible to work outside AMD's recommended PCI-X settings, try
increasing the Data Length to 2k bytes for increased performance. If you
have issues with these settings, please revert to the "safe" settings
and duplicate the problem before submitting a bug or asking for support.
NOTE: The default setting on most systems is 8 outstanding transactions
and 2k bytes data length.
4. On multiprocessor systems, it has been noted that an application which
is handling 10Gb networking can switch between CPUs causing degraded
and/or unstable performance.
If running on an SMP system and taking performance measurements, it
is suggested you either run the latest netperf-2.4.0+ or use a binding
tool such as Tim Hockin's procstate utilities (runon)
<http://www.hockin.org/~thockin/procstate/>.
Binding netserver and netperf (or other applications) to particular
CPUs will have a significant difference in performance measurements.
You may need to experiment which CPU to bind the application to in
order to achieve the best performance for your system.
If you are developing an application designed for 10Gb networking,
please keep in mind you may want to look at kernel functions
sched_setaffinity & sched_getaffinity to bind your application.
If you are just running user-space applications such as ftp, telnet,
etc., you may want to try the runon tool provided by Tim Hockin's
procstate utility. You could also try binding the interface to a
particular CPU: runon 0 ifup eth0
SUPPORT
=======
If you have problems with the software or hardware, please contact our
customer support team via email at support@chelsio.com or check our website
at http://www.chelsio.com
===============================================================================
Chelsio Communications
370 San Aleso Ave.
Suite 100
Sunnyvale, CA 94085
http://www.chelsio.com
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License, version 2, as
published by the Free Software Foundation.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
Copyright (c) 2003-2005 Chelsio Communications. All rights reserved.
===============================================================================

110
Documentation/networking/dccp.txt Normal file
View File

@@ -0,0 +1,110 @@
DCCP protocol
============
Contents
========
- Introduction
- Missing features
- Socket options
- Notes
Introduction
============
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
based protocol designed to solve issues present in UDP and TCP particularly
for real time and multimedia traffic.
It has a base protocol and pluggable congestion control IDs (CCIDs).
It is at proposed standard RFC status and the homepage for DCCP as a protocol
is at:
http://www.read.cs.ucla.edu/dccp/
Missing features
================
The DCCP implementation does not currently have all the features that are in
the RFC.
The known bugs are at:
http://linux-net.osdl.org/index.php/TODO#DCCP
Socket options
==============
DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
the socket will fall back to 0 (which means that no meaningful service code
is present). Connecting sockets set at most one service option; for
listening sockets, multiple service codes can be specified.
DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
always cover the entire packet and that only fully covered application data is
accepted by the receiver. Hence, when using this feature on the sender, it must
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_SEND_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.
Values in the range 1..15 indicate that packets with minimally such a
coverage value are also acceptable. The higher the number, the more
restrictive this setting (see [RFC 4340, sec. 9.2.1]).
Sysctl variables
================
Several DCCP default parameters can be managed by the following sysctls
(sysctl net.dccp.default or /proc/sys/net/dccp/default):
request_retries
The number of active connection initiation retries (the number of
Requests minus one) before timing out. In addition, it also governs
the behaviour of the other, passive side: this variable also sets
the number of times DCCP repeats sending a Response when the initial
handshake does not progress from RESPOND to OPEN (i.e. when no Ack
is received after the initial Request). This value should be greater
than 0, suggested is less than 10. Analogue of tcp_syn_retries.
retries1
How often a DCCP Response is retransmitted until the listening DCCP
side considers its connecting peer dead. Analogue of tcp_retries1.
retries2
The number of times a general DCCP packet is retransmitted. This has
importance for retransmitted acknowledgments and feature negotiation,
data packets are never retransmitted. Analogue of tcp_retries2.
send_ndp = 1
Whether or not to send NDP count options (sec. 7.7.2).
send_ackvec = 1
Whether or not to send Ack Vector options (sec. 11.5).
ack_ratio = 2
The default Ack Ratio (sec. 11.3) to use.
tx_ccid = 2
Default CCID for the sender-receiver half-connection.
rx_ccid = 2
Default CCID for the receiver-sender half-connection.
seq_window = 100
The initial sequence window (sec. 7.5.2).
tx_qlen = 5
The size of the transmit buffer in packets. A value of 0 corresponds
to an unbounded transmit buffer.
Notes
=====
DCCP does not travel through NAT successfully at present on many boxes. This is
because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
support for DCCP has been added.

178
Documentation/networking/de4x5.txt Normal file
View File

@@ -0,0 +1,178 @@
Originally, this driver was written for the Digital Equipment
Corporation series of EtherWORKS Ethernet cards:
DE425 TP/COAX EISA
DE434 TP PCI
DE435 TP/COAX/AUI PCI
DE450 TP/COAX/AUI PCI
DE500 10/100 PCI Fasternet
but it will now attempt to support all cards which conform to the
Digital Semiconductor SROM Specification. The driver currently
recognises the following chips:
DC21040 (no SROM)
DC21041[A]
DC21140[A]
DC21142
DC21143
So far the driver is known to work with the following cards:
KINGSTON
Linksys
ZNYX342
SMC8432
SMC9332 (w/new SROM)
ZNYX31[45]
ZNYX346 10/100 4 port (can act as a 10/100 bridge!)
The driver has been tested on a relatively busy network using the DE425,
DE434, DE435 and DE500 cards and benchmarked with 'ttcp': it transferred
16M of data to a DECstation 5000/200 as follows:
TCP UDP
TX RX TX RX
DE425 1030k 997k 1170k 1128k
DE434 1063k 995k 1170k 1125k
DE435 1063k 995k 1170k 1125k
DE500 1063k 998k 1170k 1125k in 10Mb/s mode
All values are typical (in kBytes/sec) from a sample of 4 for each
measurement. Their error is +/-20k on a quiet (private) network and also
depend on what load the CPU has.
=========================================================================
The ability to load this driver as a loadable module has been included
and used extensively during the driver development (to save those long
reboot sequences). Loadable module support under PCI and EISA has been
achieved by letting the driver autoprobe as if it were compiled into the
kernel. Do make sure you're not sharing interrupts with anything that
cannot accommodate interrupt sharing!
To utilise this ability, you have to do 8 things:
0) have a copy of the loadable modules code installed on your system.
1) copy de4x5.c from the /linux/drivers/net directory to your favourite
temporary directory.
2) for fixed autoprobes (not recommended), edit the source code near
line 5594 to reflect the I/O address you're using, or assign these when
loading by:
insmod de4x5 io=0xghh where g = bus number
hh = device number
NB: autoprobing for modules is now supported by default. You may just
use:
insmod de4x5
to load all available boards. For a specific board, still use
the 'io=?' above.
3) compile de4x5.c, but include -DMODULE in the command line to ensure
that the correct bits are compiled (see end of source code).
4) if you are wanting to add a new card, goto 5. Otherwise, recompile a
kernel with the de4x5 configuration turned off and reboot.
5) insmod de4x5 [io=0xghh]
6) run the net startup bits for your new eth?? interface(s) manually
(usually /etc/rc.inet[12] at boot time).
7) enjoy!
To unload a module, turn off the associated interface(s)
'ifconfig eth?? down' then 'rmmod de4x5'.
Automedia detection is included so that in principle you can disconnect
from, e.g. TP, reconnect to BNC and things will still work (after a
pause whilst the driver figures out where its media went). My tests
using ping showed that it appears to work....
By default, the driver will now autodetect any DECchip based card.
Should you have a need to restrict the driver to DIGITAL only cards, you
can compile with a DEC_ONLY define, or if loading as a module, use the
'dec_only=1' parameter.
I've changed the timing routines to use the kernel timer and scheduling
functions so that the hangs and other assorted problems that occurred
while autosensing the media should be gone. A bonus for the DC21040
auto media sense algorithm is that it can now use one that is more in
line with the rest (the DC21040 chip doesn't have a hardware timer).
The downside is the 1 'jiffies' (10ms) resolution.
IEEE 802.3u MII interface code has been added in anticipation that some
products may use it in the future.
The SMC9332 card has a non-compliant SROM which needs fixing - I have
patched this driver to detect it because the SROM format used complies
to a previous DEC-STD format.
I have removed the buffer copies needed for receive on Intels. I cannot
remove them for Alphas since the Tulip hardware only does longword
aligned DMA transfers and the Alphas get alignment traps with non
longword aligned data copies (which makes them really slow). No comment.
I have added SROM decoding routines to make this driver work with any
card that supports the Digital Semiconductor SROM spec. This will help
all cards running the dc2114x series chips in particular. Cards using
the dc2104x chips should run correctly with the basic driver. I'm in
debt to <mjacob@feral.com> for the testing and feedback that helped get
this feature working. So far we have tested KINGSTON, SMC8432, SMC9332
(with the latest SROM complying with the SROM spec V3: their first was
broken), ZNYX342 and LinkSys. ZNYX314 (dual 21041 MAC) and ZNYX 315
(quad 21041 MAC) cards also appear to work despite their incorrectly
wired IRQs.
I have added a temporary fix for interrupt problems when some SCSI cards
share the same interrupt as the DECchip based cards. The problem occurs
because the SCSI card wants to grab the interrupt as a fast interrupt
(runs the service routine with interrupts turned off) vs. this card
which really needs to run the service routine with interrupts turned on.
This driver will now add the interrupt service routine as a fast
interrupt if it is bounced from the slow interrupt. THIS IS NOT A
RECOMMENDED WAY TO RUN THE DRIVER and has been done for a limited time
until people sort out their compatibility issues and the kernel
interrupt service code is fixed. YOU SHOULD SEPARATE OUT THE FAST
INTERRUPT CARDS FROM THE SLOW INTERRUPT CARDS to ensure that they do not
run on the same interrupt. PCMCIA/CardBus is another can of worms...
Finally, I think I have really fixed the module loading problem with
more than one DECchip based card. As a side effect, I don't mess with
the device structure any more which means that if more than 1 card in
2.0.x is installed (4 in 2.1.x), the user will have to edit
linux/drivers/net/Space.c to make room for them. Hence, module loading
is the preferred way to use this driver, since it doesn't have this
limitation.
Where SROM media detection is used and full duplex is specified in the
SROM, the feature is ignored unless lp->params.fdx is set at compile
time OR during a module load (insmod de4x5 args='eth??:fdx' [see
below]). This is because there is no way to automatically detect full
duplex links except through autonegotiation. When I include the
autonegotiation feature in the SROM autoconf code, this detection will
occur automatically for that case.
Command line arguments are now allowed, similar to passing arguments
through LILO. This will allow a per adapter board set up of full duplex
and media. The only lexical constraints are: the board name (dev->name)
appears in the list before its parameters. The list of parameters ends
either at the end of the parameter list or with another board name. The
following parameters are allowed:
fdx for full duplex
autosense to set the media/speed; with the following
sub-parameters:
TP, TP_NW, BNC, AUI, BNC_AUI, 100Mb, 10Mb, AUTO
Case sensitivity is important for the sub-parameters. They *must* be
upper case. Examples:
insmod de4x5 args='eth1:fdx autosense=BNC eth0:autosense=100Mb'.
For a compiled in driver, in linux/drivers/net/CONFIG, place e.g.
DE4X5_OPTS = -DDE4X5_PARM='"eth0:fdx autosense=AUI eth2:autosense=TP"'
Yes, I know full duplex isn't permissible on BNC or AUI; they're just
examples. By default, full duplex is turned off and AUTO is the default
autosense setting. In reality, I expect only the full duplex option to
be used. Note the use of single quotes in the two examples above and the
lack of commas to separate items.

232
Documentation/networking/decnet.txt Normal file
View File

@@ -0,0 +1,232 @@
Linux DECnet Networking Layer Information
===========================================
1) Other documentation....
o Project Home Pages
http://www.chygwyn.com/DECnet/ - 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)
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_ROUTE_FWMARK is optional
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
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
network protocols.
As soon as your network card is brought into the UP state, DECnet should
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
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.
If you do st a DECnet address on the command line, it has only one purpose
which is that its added to the addresses on the loopback device.
With 2.4 kernels, DECnet would only recognise addresses as local if they
were added to the loopback device. In 2.5, any local interface address
can be used to loop back to the local machine. Of course this does not
prevent you adding further addresses to the loopback device if you
want to.
N.B. Since the address list of an interface determines the addresses for
which "hello" messages are sent, if you don't set an address on the loopback
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:
decnet=1,2
the two numbers are the node address 1,2 = 1.2 For 2.2.xx kernels
and early 2.3.xx kernels, you must use a comma when specifying the
DECnet address like this. For more recent 2.3.xx kernels, you may
use almost any character except space, although a `.` would be the most
obvious choice :-)
There used to be a third number specifying the node type. This option
has gone away in favour of a per interface node type. This is now set
using /proc/sys/net/decnet/conf/<dev>/forwarding. This file can be
set with a single digit, 0=EndNode, 1=L1 Router and 2=L2 Router.
There are also equivalent options for modules. The node address can
also be set through the /proc/sys/net/decnet/ files, as can other system
parameters.
Currently the only supported devices are ethernet and ip_gre. The
ethernet address of your ethernet card has to be set according to the DECnet
address of the node in order for it to be autoconfigured (and then appear in
/proc/net/decnet_dev). There is a utility available at the above
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:
MACADDR=AA:00:04:00:03:04
or something similar, to /etc/sysconfig/network-scripts/ifcfg-eth0 or
wherever your network card's configuration lives. Setting the MAC address
of your ethernet card to an address starting with "hi-ord" will cause a
DECnet address which matches to be added to the interface (which you can
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:
echo -n "eth0" >/proc/sys/net/decnet/default_device
If you don't set the default device, then it will default to the first
ethernet card which has been autoconfigured as described above. You can
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
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
package in the same way as IPv4/6 configuration is performed.
Documentation for iproute2 is included with the package, although there is
as yet no specific section on DECnet, most of the features apply to both
IP and DECnet, albeit with DECnet addresses instead of IP addresses and
a reduced functionality.
If you want to configure a DECnet router you'll need the iproute2 package
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.
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 ?
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 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.
- If the previous two steps are satisfied, and the Ethernet card is up,
you should find that it is listed in /proc/net/decnet_dev and also
that it appears as a directory in /proc/sys/net/decnet/conf/. The
loopback device (lo) should also appear and is required to communicate
within a node.
- If you have any DECnet routers on your network, they should appear
in /proc/net/decnet_neigh, otherwise this file will only contain the
entry for the node itself (if it doesn't check to see if lo is up).
- If you want to send to any node which is not listed in the
/proc/net/decnet_neigh file, you'll need to set the default device
to point to an Ethernet card with connection to a router. This is
again done with the /proc/sys/net/decnet/default_device file.
- Try starting a simple server and client, like the dnping/dnmirror
over the loopback interface. With luck they should communicate.
For this step and those after, you'll need the DECnet library
which can be obtained from the above ftp sites as well as the
actual utilities themselves.
- If this seems to work, then try talking to a node on your local
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
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
information (_most_ of which _is_ _essential_) includes:
- What kernel version are you running ?
- What version of the patch are you running ?
- How far though the above set of tests can you get ?
- What is in the /proc/decnet* files and /proc/sys/net/decnet/* files ?
- Which services are you running ?
- Which client caused the problem ?
- 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
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
A quick FAQ on ethernet MAC addresses to explain how Linux and DECnet
interact and how to get the best performance from your hardware.
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
an ethernet card to listen to. If the ethernet card supports it, the
filtering operation will be done in hardware, if not the extra unwanted packets
received will be discarded by the host computer. In the latter case,
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
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
then your computer will be doing more work than required. Some cards
will simply set themselves into promiscuous mode in order to receive
packets from the DECnet specified addresses. So if you have one of these
cards its better to set the MAC address of the card as described above
to gain the best efficiency. Better still is to use a card which supports
NAPI as well.
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
list that you can join, details are at:
http://sourceforge.net/mail/?group_id=4993
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.
DECnet is a trademark of Compaq. This software is not a product of
Compaq. We acknowledge the help of people at Compaq in providing extra
documentation above and beyond what was previously publicly available.
Steve Whitehouse <SteveW@ACM.org>

92
Documentation/networking/depca.txt Normal file
View File

@@ -0,0 +1,92 @@
DE10x
=====
Memory Addresses:
SW1 SW2 SW3 SW4
64K on on on on d0000 dbfff
off on on on c0000 cbfff
off off on on e0000 ebfff
32K on on off on d8000 dbfff
off on off on c8000 cbfff
off off off on e8000 ebfff
DBR ROM on on dc000 dffff
off on cc000 cffff
off off ec000 effff
Note that the 2K mode is set by SW3/SW4 on/off or off/off. Address
assignment is through the RBSA register.
I/O Address:
SW5
0x300 on
0x200 off
Remote Boot:
SW6
Disable on
Enable off
Remote Boot Timeout:
SW7
2.5min on
30s off
IRQ:
SW8 SW9 SW10 SW11 SW12
2 on off off off off
3 off on off off off
4 off off on off off
5 off off off on off
7 off off off off on
DE20x
=====
Memory Size:
SW3 SW4
64K on on
32K off on
2K on off
2K off off
Start Addresses:
SW1 SW2 SW3 SW4
64K on on on on c0000 cffff
on off on on d0000 dffff
off on on on e0000 effff
32K on on off off c8000 cffff
on off off off d8000 dffff
off on off off e8000 effff
Illegal off off - - - -
I/O Address:
SW5
0x300 on
0x200 off
Remote Boot:
SW6
Disable on
Enable off
Remote Boot Timeout:
SW7
2.5min on
30s off
IRQ:
SW8 SW9 SW10 SW11 SW12
5 on off off off off
9 off on off off off
10 off off on off off
11 off off off on off
15 off off off off on

52
Documentation/networking/dgrs.txt Normal file
View File

@@ -0,0 +1,52 @@
The Digi International RightSwitch SE-X (dgrs) Device Driver
This is a Linux driver for the Digi International RightSwitch SE-X
EISA and PCI boards. These are 4 (EISA) or 6 (PCI) port Ethernet
switches and a NIC combined into a single board. This driver can
be compiled into the kernel statically or as a loadable module.
There is also a companion management tool, called "xrightswitch".
The management tool lets you watch the performance graphically,
as well as set the SNMP agent IP and IPX addresses, IEEE Spanning
Tree, and Aging time. These can also be set from the command line
when the driver is loaded. The driver command line options are:
debug=NNN Debug printing level
dma=0/1 Disable/Enable DMA on PCI card
spantree=0/1 Disable/Enable IEEE spanning tree
hashexpire=NNN Change address aging time (default 300 seconds)
ipaddr=A,B,C,D Set SNMP agent IP address i.e. 199,86,8,221
iptrap=A,B,C,D Set SNMP agent IP trap address i.e. 199,86,8,221
ipxnet=NNN Set SNMP agent IPX network number
nicmode=0/1 Disable/Enable multiple NIC mode
There is also a tool for setting up input and output packet filters
on each port, called "dgrsfilt".
Both the management tool and the filtering tool are available
separately from the following FTP site:
ftp://ftp.dgii.com/drivers/rightswitch/linux/
When nicmode=1, the board and driver operate as 4 or 6 individual
NIC ports (eth0...eth5) instead of as a switch. All switching
functions are disabled. In the future, the board firmware may include
a routing cache when in this mode.
Copyright 1995-1996 Digi International Inc.
This software may be used and distributed according to the terms
of the GNU General Public License, incorporated herein by reference.
For information on purchasing a RightSwitch SE-4 or SE-6
board, please contact Digi's sales department at 1-612-912-3444
or 1-800-DIGIBRD. Outside the U.S., please check our Web page at:
http://www.dgii.com
for sales offices worldwide. Tech support is also available through
the channels listed on the Web site, although as long as I am
employed on networking products at Digi I will be happy to provide
any bug fixes that may be needed.
-Rick Richardson, rick@dgii.com

281
Documentation/networking/dl2k.txt Normal file
View File

@@ -0,0 +1,281 @@
D-Link DL2000-based Gigabit Ethernet Adapter Installation
for Linux
May 23, 2002
Contents
========
- Compatibility List
- Quick Install
- Compiling the Driver
- Installing the Driver
- Option parameter
- Configuration Script Sample
- Troubleshooting
Compatibility List
=================
Adapter Support:
D-Link DGE-550T Gigabit Ethernet Adapter.
D-Link DGE-550SX Gigabit Ethernet Adapter.
D-Link DL2000-based Gigabit Ethernet Adapter.
The driver support Linux kernel 2.4.7 later. We had tested it
on the environments below.
. Red Hat v6.2 (update kernel to 2.4.7)
. Red Hat v7.0 (update kernel to 2.4.7)
. Red Hat v7.1 (kernel 2.4.7)
. Red Hat v7.2 (kernel 2.4.7-10)
Quick Install
=============
Install linux driver as following command:
1. make all
2. insmod dl2k.ko
3. ifconfig eth0 up 10.xxx.xxx.xxx netmask 255.0.0.0
^^^^^^^^^^^^^^^\ ^^^^^^^^\
IP NETMASK
Now eth0 should active, you can test it by "ping" or get more information by
"ifconfig". If tested ok, continue the next step.
4. cp dl2k.ko /lib/modules/`uname -r`/kernel/drivers/net
5. Add the following line to /etc/modprobe.conf:
alias eth0 dl2k
6. Run "netconfig" or "netconf" to create configuration script ifcfg-eth0
located at /etc/sysconfig/network-scripts or create it manually.
[see - Configuration Script Sample]
7. Driver will automatically load and configure at next boot time.
Compiling the Driver
====================
In Linux, NIC drivers are most commonly configured as loadable modules.
The approach of building a monolithic kernel has become obsolete. The driver
can be compiled as part of a monolithic kernel, but is strongly discouraged.
The remainder of this section assumes the driver is built as a loadable module.
In the Linux environment, it is a good idea to rebuild the driver from the
source instead of relying on a precompiled version. This approach provides
better reliability since a precompiled driver might depend on libraries or
kernel features that are not present in a given Linux installation.
The 3 files necessary to build Linux device driver are dl2k.c, dl2k.h and
Makefile. To compile, the Linux installation must include the gcc compiler,
the kernel source, and the kernel headers. The Linux driver supports Linux
Kernels 2.4.7. Copy the files to a directory and enter the following command
to compile and link the driver:
CD-ROM drive
------------
[root@XXX /] mkdir cdrom
[root@XXX /] mount -r -t iso9660 -o conv=auto /dev/cdrom /cdrom
[root@XXX /] cd root
[root@XXX /root] mkdir dl2k
[root@XXX /root] cd dl2k
[root@XXX dl2k] cp /cdrom/linux/dl2k.tgz /root/dl2k
[root@XXX dl2k] tar xfvz dl2k.tgz
[root@XXX dl2k] make all
Floppy disc drive
-----------------
[root@XXX /] cd root
[root@XXX /root] mkdir dl2k
[root@XXX /root] cd dl2k
[root@XXX dl2k] mcopy a:/linux/dl2k.tgz /root/dl2k
[root@XXX dl2k] tar xfvz dl2k.tgz
[root@XXX dl2k] make all
Installing the Driver
=====================
Manual Installation
-------------------
Once the driver has been compiled, it must be loaded, enabled, and bound
to a protocol stack in order to establish network connectivity. To load a
module enter the command:
insmod dl2k.o
or
insmod dl2k.o <optional parameter> ; add parameter
===============================================================
example: insmod dl2k.o media=100mbps_hd
or insmod dl2k.o media=3
or insmod dl2k.o media=3,2 ; for 2 cards
===============================================================
Please reference the list of the command line parameters supported by
the Linux device driver below.
The insmod command only loads the driver and gives it a name of the form
eth0, eth1, etc. To bring the NIC into an operational state,
it is necessary to issue the following command:
ifconfig eth0 up
Finally, to bind the driver to the active protocol (e.g., TCP/IP with
Linux), enter the following command:
ifup eth0
Note that this is meaningful only if the system can find a configuration
script that contains the necessary network information. A sample will be
given in the next paragraph.
The commands to unload a driver are as follows:
ifdown eth0
ifconfig eth0 down
rmmod dl2k.o
The following are the commands to list the currently loaded modules and
to see the current network configuration.
lsmod
ifconfig
Automated Installation
----------------------
This section describes how to install the driver such that it is
automatically loaded and configured at boot time. The following description
is based on a Red Hat 6.0/7.0 distribution, but it can easily be ported to
other distributions as well.
Red Hat v6.x/v7.x
-----------------
1. Copy dl2k.o to the network modules directory, typically
/lib/modules/2.x.x-xx/net or /lib/modules/2.x.x/kernel/drivers/net.
2. Locate the boot module configuration file, most commonly modprobe.conf
or modules.conf (for 2.4) in the /etc directory. Add the following lines:
alias ethx dl2k
options dl2k <optional parameters>
where ethx will be eth0 if the NIC is the only ethernet adapter, eth1 if
one other ethernet adapter is installed, etc. Refer to the table in the
previous section for the list of optional parameters.
3. Locate the network configuration scripts, normally the
/etc/sysconfig/network-scripts directory, and create a configuration
script named ifcfg-ethx that contains network information.
4. Note that for most Linux distributions, Red Hat included, a configuration
utility with a graphical user interface is provided to perform steps 2
and 3 above.
Parameter Description
=====================
You can install this driver without any additional parameter. However, if you
are going to have extensive functions then it is necessary to set extra
parameter. Below is a list of the command line parameters supported by the
Linux device
driver.
mtu=packet_size - Specifies the maximum packet size. default
is 1500.
media=media_type - Specifies the media type the NIC operates at.
autosense Autosensing active media.
10mbps_hd 10Mbps half duplex.
10mbps_fd 10Mbps full duplex.
100mbps_hd 100Mbps half duplex.
100mbps_fd 100Mbps full duplex.
1000mbps_fd 1000Mbps full duplex.
1000mbps_hd 1000Mbps half duplex.
0 Autosensing active media.
1 10Mbps half duplex.
2 10Mbps full duplex.
3 100Mbps half duplex.
4 100Mbps full duplex.
5 1000Mbps half duplex.
6 1000Mbps full duplex.
By default, the NIC operates at autosense.
1000mbps_fd and 1000mbps_hd types are only
available for fiber adapter.
vlan=n - Specifies the VLAN ID. If vlan=0, the
Virtual Local Area Network (VLAN) function is
disable.
jumbo=[0|1] - Specifies the jumbo frame support. If jumbo=1,
the NIC accept jumbo frames. By default, this
function is disabled.
Jumbo frame usually improve the performance
int gigabit.
This feature need jumbo frame compatible
remote.
rx_coalesce=m - Number of rx frame handled each interrupt.
rx_timeout=n - Rx DMA wait time for an interrupt.
If set rx_coalesce > 0, hardware only assert
an interrupt for m frames. Hardware won't
assert rx interrupt until m frames received or
reach timeout of n * 640 nano seconds.
Set proper rx_coalesce and rx_timeout can
reduce congestion collapse and overload which
has been a bottleneck for high speed network.
For example, rx_coalesce=10 rx_timeout=800.
that is, hardware assert only 1 interrupt
for 10 frames received or timeout of 512 us.
tx_coalesce=n - Number of tx frame handled each interrupt.
Set n > 1 can reduce the interrupts
congestion usually lower performance of
high speed network card. Default is 16.
tx_flow=[1|0] - Specifies the Tx flow control. If tx_flow=0,
the Tx flow control disable else driver
autodetect.
rx_flow=[1|0] - Specifies the Rx flow control. If rx_flow=0,
the Rx flow control enable else driver
autodetect.
Configuration Script Sample
===========================
Here is a sample of a simple configuration script:
DEVICE=eth0
USERCTL=no
ONBOOT=yes
POOTPROTO=none
BROADCAST=207.200.5.255
NETWORK=207.200.5.0
NETMASK=255.255.255.0
IPADDR=207.200.5.2
Troubleshooting
===============
Q1. Source files contain ^ M behind every line.
Make sure all files are Unix file format (no LF). Try the following
shell command to convert files.
cat dl2k.c | col -b > dl2k.tmp
mv dl2k.tmp dl2k.c
OR
cat dl2k.c | tr -d "\r" > dl2k.tmp
mv dl2k.tmp dl2k.c
Q2: Could not find header files (*.h) ?
To compile the driver, you need kernel header files. After
installing the kernel source, the header files are usually located in
/usr/src/linux/include, which is the default include directory configured
in Makefile. For some distributions, there is a copy of header files in
/usr/src/include/linux and /usr/src/include/asm, that you can change the
INCLUDEDIR in Makefile to /usr/include without installing kernel source.
Note that RH 7.0 didn't provide correct header files in /usr/include,
including those files will make a wrong version driver.

65
Documentation/networking/dmfe.txt Normal file
View File

@@ -0,0 +1,65 @@
Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver for Linux.
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version 2
of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
This driver provides kernel support for Davicom DM9102(A)/DM9132/DM9801 ethernet cards ( CNET
10/100 ethernet cards uses Davicom chipset too, so this driver supports CNET cards too ).If you
didn't compile this driver as a module, it will automatically load itself on boot and print a
line similar to :
dmfe: Davicom DM9xxx net driver, version 1.36.4 (2002-01-17)
If you compiled this driver as a module, you have to load it on boot.You can load it with command :
insmod dmfe
This way it will autodetect the device mode.This is the suggested way to load the module.Or you can pass
a mode= setting to module while loading, like :
insmod dmfe mode=0 # Force 10M Half Duplex
insmod dmfe mode=1 # Force 100M Half Duplex
insmod dmfe mode=4 # Force 10M Full Duplex
insmod dmfe mode=5 # Force 100M Full Duplex
Next you should configure your network interface with a command similar to :
ifconfig eth0 172.22.3.18
^^^^^^^^^^^
Your IP Address
Then you may have to modify the default routing table with command :
route add default eth0
Now your ethernet card should be up and running.
TODO:
Implement pci_driver::suspend() and pci_driver::resume() power management methods.
Check on 64 bit boxes.
Check and fix on big endian boxes.
Test and make sure PCI latency is now correct for all cases.
Authors:
Sten Wang <sten_wang@davicom.com.tw > : Original Author
Tobias Ringstrom <tori@unhappy.mine.nu> : Current Maintainer
Contributors:
Marcelo Tosatti <marcelo@conectiva.com.br>
Alan Cox <alan@redhat.com>
Jeff Garzik <jgarzik@pobox.com>
Vojtech Pavlik <vojtech@suse.cz>

91
Documentation/networking/driver.txt Normal file
View File

@@ -0,0 +1,91 @@
Document about softnet driver issues
Transmit path guidelines:
1) The hard_start_xmit method must never return '1' under any
normal circumstances. It is considered a hard error unless
there is no way your device can tell ahead of time when it's
transmit function will become busy.
Instead it must maintain the queue properly. For example,
for a driver implementing scatter-gather this means:
static int drv_hard_start_xmit(struct sk_buff *skb,
struct net_device *dev)
{
struct drv *dp = dev->priv;
lock_tx(dp);
...
/* This is a hard error log it. */
if (TX_BUFFS_AVAIL(dp) <= (skb_shinfo(skb)->nr_frags + 1)) {
netif_stop_queue(dev);
unlock_tx(dp);
printk(KERN_ERR PFX "%s: BUG! Tx Ring full when queue awake!\n",
dev->name);
return 1;
}
... queue packet to card ...
... update tx consumer index ...
if (TX_BUFFS_AVAIL(dp) <= (MAX_SKB_FRAGS + 1))
netif_stop_queue(dev);
...
unlock_tx(dp);
...
}
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))
netif_wake_queue(dp->dev);
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:
if (TX_BUFFS_AVAIL(dp) == 0)
and:
if (netif_queue_stopped(dp->dev) &&
TX_BUFFS_AVAIL(dp) > 0)
netif_wake_queue(dp->dev);
2) Do not forget to update netdev->trans_start to jiffies after
each new tx packet is given to the hardware.
3) Do not forget that once you return 0 from your hard_start_xmit
method, it is your driver's responsibility to free up the SKB
and in some finite amount of time.
For example, this means that it is not allowed for your TX
mitigation scheme to let TX packets "hang out" in the TX
ring unreclaimed forever if no new TX packets are sent.
This error can deadlock sockets waiting for send buffer room
to be freed up.
If you return 1 from the hard_start_xmit method, you must not keep
any reference to that SKB and you must not attempt to free it up.
Probing guidelines:
1) Any hardware layer address you obtain for your device should
be verified. For example, for ethernet check it with
linux/etherdevice.h:is_valid_ether_addr()
Close/stop guidelines:
1) After the dev->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
any reset commands.
2) The dev->stop routine will be called by unregister_netdevice
if device is still UP.

206
Documentation/networking/e100.txt Normal file
View File

@@ -0,0 +1,206 @@
Linux* Base Driver for the Intel(R) PRO/100 Family of Adapters
==============================================================
November 15, 2005
Contents
========
- In This Release
- Identifying Your Adapter
- Building and Installation
- Driver Configuration Parameters
- Additional Configurations
- Known Issues
- Support
In This Release
===============
This file describes the Linux* Base Driver for the Intel(R) PRO/100 Family of
Adapters. This driver includes support for Itanium(R)2-based systems.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel PRO/100 adapter.
The following features are now available in supported kernels:
- Native VLANs
- Channel Bonding (teaming)
- SNMP
Channel Bonding documentation can be found in the Linux kernel source:
/Documentation/networking/bonding.txt
Identifying Your Adapter
========================
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
http://support.intel.com/support/network/adapter/pro100/21397.htm
For the latest Intel network drivers for Linux, refer to the following
website. In the search field, enter your adapter name or type, or use the
networking link on the left to search for your adapter:
http://downloadfinder.intel.com/scripts-df/support_intel.asp
Driver Configuration Parameters
===============================
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
Rx Descriptors: Number of receive descriptors. A receive descriptor is a data
structure that describes a receive buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to write
data from the controller to host memory. In the 3.x.x driver the valid range
for this parameter is 64-256. The default value is 64. This parameter can be
changed using the command:
ethtool -G eth? rx n, where n is the number of desired rx descriptors.
Tx Descriptors: Number of transmit descriptors. A transmit descriptor is a data
structure that describes a transmit buffer and its attributes to the network
controller. The data in the descriptor is used by the controller to read
data from the host memory to the controller. In the 3.x.x driver the valid
range for this parameter is 64-256. The default value is 64. This parameter
can be changed using the command:
ethtool -G eth? tx n, where n is the number of desired tx descriptors.
Speed/Duplex: The driver auto-negotiates the link speed and duplex settings by
default. Ethtool can be used as follows to force speed/duplex.
ethtool -s eth? autoneg off speed {10|100} duplex {full|half}
NOTE: setting the speed/duplex to incorrect values will cause the link to
fail.
Event Log Message Level: The driver uses the message level flag to log events
to syslog. The message level can be set at driver load time. It can also be
set using the command:
ethtool -s eth? msglvl n
Additional Configurations
=========================
Configuring the Driver on Different Distributions
-------------------------------------------------
Configuring a network driver to load properly when the system is started is
distribution dependent. Typically, the configuration process involves adding
an alias line to /etc/modules.conf or /etc/modprobe.conf as well as editing
other system startup scripts and/or configuration files. Many popular Linux
distributions ship with tools to make these changes for you. To learn the
proper way to configure a network device for your system, refer to your
distribution documentation. If during this process you are asked for the
driver or module name, the name for the Linux Base Driver for the Intel
PRO/100 Family of Adapters is e100.
As an example, if you install the e100 driver for two PRO/100 adapters
(eth0 and eth1), add the following to modules.conf or modprobe.conf:
alias eth0 e100
alias eth1 e100
Viewing Link Messages
---------------------
In order to see link messages and other Intel driver information on your
console, you must set the dmesg level up to six. This can be done by
entering the following on the command line before loading the e100 driver:
dmesg -n 8
If you wish to see all messages issued by the driver, including debug
messages, set the dmesg level to eight.
NOTE: This setting is not saved across reboots.
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. Ethtool
version 1.6 or later is required for this functionality.
The latest release of ethtool can be found from
http://sourceforge.net/projects/gkernel.
NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
for a more complete ethtool feature set can be enabled by upgrading
ethtool to ethtool-1.8.1.
Enabling Wake on LAN* (WoL)
---------------------------
WoL is provided through the Ethtool* utility. Ethtool is included with Red
Hat* 8.0. For other Linux distributions, download and install Ethtool from
the following website: http://sourceforge.net/projects/gkernel.
For instructions on enabling WoL with Ethtool, refer to the Ethtool man page.
WoL will be enabled on the system during the next shut down or reboot. For
this driver version, in order to enable WoL, the e100 driver must be
loaded when shutting down or rebooting the system.
NAPI
----
NAPI (Rx polling mode) is supported in the e100 driver.
See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have
one system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces
will respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP
filtering by
(1) entering: echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5), or
(2) installing the interfaces in separate broadcast domains (either
in different switches or in a switch partitioned to VLANs).
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related to the
issue to e1000-devel@lists.sourceforge.net.
License
=======
This software program is released under the terms of a license agreement
between you ('Licensee') and Intel. Do not use or load this software or any
associated materials (collectively, the 'Software') until you have carefully
read the full terms and conditions of the file COPYING located in this software
package. By loading or using the Software, you agree to the terms of this
Agreement. If you do not agree with the terms of this Agreement, do not install
or use the Software.
* Other names and brands may be claimed as the property of others.

652
Documentation/networking/e1000.txt Normal file
View File

@@ -0,0 +1,652 @@
Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters
===============================================================
September 26, 2006
Contents
========
- In This Release
- Identifying Your Adapter
- Building and Installation
- Command Line Parameters
- Speed and Duplex Configuration
- Additional Configurations
- Known Issues
- Support
In This Release
===============
This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family
of Adapters. This driver includes support for Itanium(R)2-based systems.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel PRO/1000 adapter. All hardware requirements listed
apply to use with Linux.
The following features are now available in supported kernels:
- Native VLANs
- Channel Bonding (teaming)
- SNMP
Channel Bonding documentation can be found in the Linux kernel source:
/Documentation/networking/bonding.txt
The driver information previously displayed in the /proc filesystem is not
supported in this release. Alternatively, you can use ethtool (version 1.6
or later), lspci, and ifconfig to obtain the same information.
Instructions on updating ethtool can be found in the section "Additional
Configurations" later in this document.
NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100
support.
Identifying Your Adapter
========================
For more information on how to identify your adapter, go to the Adapter &
Driver ID Guide at:
http://support.intel.com/support/network/adapter/pro100/21397.htm
For the latest Intel network drivers for Linux, refer to the following
website. In the search field, enter your adapter name or type, or use the
networking link on the left to search for your adapter:
http://downloadfinder.intel.com/scripts-df/support_intel.asp
Command Line Parameters
=======================
If the driver is built as a module, the following optional parameters
are used by entering them on the command line with the modprobe command
using this syntax:
modprobe e1000 [<option>=<VAL1>,<VAL2>,...]
For example, with two PRO/1000 PCI adapters, entering:
modprobe e1000 TxDescriptors=80,128
loads the e1000 driver with 80 TX descriptors for the first adapter and
128 TX descriptors for the second adapter.
The default value for each parameter is generally the recommended setting,
unless otherwise noted.
NOTES: For more information about the AutoNeg, Duplex, and Speed
parameters, see the "Speed and Duplex Configuration" section in
this document.
For more information about the InterruptThrottleRate,
RxIntDelay, TxIntDelay, RxAbsIntDelay, and TxAbsIntDelay
parameters, see the application note at:
http://www.intel.com/design/network/applnots/ap450.htm
A descriptor describes a data buffer and attributes related to
the data buffer. This information is accessed by the hardware.
AutoNeg
-------
(Supported only on adapters with copper connections)
Valid Range: 0x01-0x0F, 0x20-0x2F
Default Value: 0x2F
This parameter is a bit-mask that specifies the speed and duplex settings
advertised by the adapter. When this parameter is used, the Speed and
Duplex parameters must not be specified.
NOTE: Refer to the Speed and Duplex section of this readme for more
information on the AutoNeg parameter.
Duplex
------
(Supported only on adapters with copper connections)
Valid Range: 0-2 (0=auto-negotiate, 1=half, 2=full)
Default Value: 0
This defines the direction in which data is allowed to flow. Can be
either one or two-directional. If both Duplex and the link partner are
set to auto-negotiate, the board auto-detects the correct duplex. If the
link partner is forced (either full or half), Duplex defaults to half-
duplex.
FlowControl
-----------
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
Default Value: Reads flow control settings from the EEPROM
This parameter controls the automatic generation(Tx) and response(Rx)
to Ethernet PAUSE frames.
InterruptThrottleRate
---------------------
(not supported on Intel(R) 82542, 82543 or 82544-based adapters)
Valid Range: 0,1,3,100-100000 (0=off, 1=dynamic, 3=dynamic conservative)
Default Value: 3
The driver can limit the amount of interrupts per second that the adapter
will generate for incoming packets. It does this by writing a value to the
adapter that is based on the maximum amount of interrupts that the adapter
will generate per second.
Setting InterruptThrottleRate to a value greater or equal to 100
will program the adapter to send out a maximum of that many interrupts
per second, even if more packets have come in. This reduces interrupt
load on the system and can lower CPU utilization under heavy load,
but will increase latency as packets are not processed as quickly.
The default behaviour of the driver previously assumed a static
InterruptThrottleRate value of 8000, providing a good fallback value for
all traffic types,but lacking in small packet performance and latency.
The hardware can handle many more small packets per second however, and
for this reason an adaptive interrupt moderation algorithm was implemented.
Since 7.3.x, the driver has two adaptive modes (setting 1 or 3) in which
it dynamically adjusts the InterruptThrottleRate value based on the traffic
that it receives. After determining the type of incoming traffic in the last
timeframe, it will adjust the InterruptThrottleRate to an appropriate value
for that traffic.
The algorithm classifies the incoming traffic every interval into
classes. Once the class is determined, the InterruptThrottleRate value is
adjusted to suit that traffic type the best. There are three classes defined:
"Bulk traffic", for large amounts of packets of normal size; "Low latency",
for small amounts of traffic and/or a significant percentage of small
packets; and "Lowest latency", for almost completely small packets or
minimal traffic.
In dynamic conservative mode, the InterruptThrottleRate value is set to 4000
for traffic that falls in class "Bulk traffic". If traffic falls in the "Low
latency" or "Lowest latency" class, the InterruptThrottleRate is increased
stepwise to 20000. This default mode is suitable for most applications.
For situations where low latency is vital such as cluster or
grid computing, the algorithm can reduce latency even more when
InterruptThrottleRate is set to mode 1. In this mode, which operates
the same as mode 3, the InterruptThrottleRate will be increased stepwise to
70000 for traffic in class "Lowest latency".
Setting InterruptThrottleRate to 0 turns off any interrupt moderation
and may improve small packet latency, but is generally not suitable
for bulk throughput traffic.
NOTE: InterruptThrottleRate takes precedence over the TxAbsIntDelay and
RxAbsIntDelay parameters. In other words, minimizing the receive
and/or transmit absolute delays does not force the controller to
generate more interrupts than what the Interrupt Throttle Rate
allows.
CAUTION: If you are using the Intel(R) PRO/1000 CT Network Connection
(controller 82547), setting InterruptThrottleRate to a value
greater than 75,000, may hang (stop transmitting) adapters
under certain network conditions. If this occurs a NETDEV
WATCHDOG message is logged in the system event log. In
addition, the controller is automatically reset, restoring
the network connection. To eliminate the potential for the
hang, ensure that InterruptThrottleRate is set no greater
than 75,000 and is not set to 0.
NOTE: When e1000 is loaded with default settings and multiple adapters
are in use simultaneously, the CPU utilization may increase non-
linearly. In order to limit the CPU utilization without impacting
the overall throughput, we recommend that you load the driver as
follows:
modprobe e1000 InterruptThrottleRate=3000,3000,3000
This sets the InterruptThrottleRate to 3000 interrupts/sec for
the first, second, and third instances of the driver. The range
of 2000 to 3000 interrupts per second works on a majority of
systems and is a good starting point, but the optimal value will
be platform-specific. If CPU utilization is not a concern, use
RX_POLLING (NAPI) and default driver settings.
RxDescriptors
-------------
Valid Range: 80-256 for 82542 and 82543-based adapters
80-4096 for all other supported adapters
Default Value: 256
This value specifies the number of receive buffer descriptors allocated
by the driver. Increasing this value allows the driver to buffer more
incoming packets, at the expense of increased system memory utilization.
Each descriptor is 16 bytes. A receive buffer is also allocated for each
descriptor and can be either 2048, 4096, 8192, or 16384 bytes, depending
on the MTU setting. The maximum MTU size is 16110.
NOTE: MTU designates the frame size. It only needs to be set for Jumbo
Frames. Depending on the available system resources, the request
for a higher number of receive descriptors may be denied. In this
case, use a lower number.
RxIntDelay
----------
Valid Range: 0-65535 (0=off)
Default Value: 0
This value delays the generation of receive interrupts in units of 1.024
microseconds. Receive interrupt reduction can improve CPU efficiency if
properly tuned for specific network traffic. Increasing this value adds
extra latency to frame reception and can end up decreasing the throughput
of TCP traffic. If the system is reporting dropped receives, this value
may be set too high, causing the driver to run out of available receive
descriptors.
CAUTION: When setting RxIntDelay to a value other than 0, adapters may
hang (stop transmitting) under certain network conditions. If
this occurs a NETDEV WATCHDOG message is logged in the system
event log. In addition, the controller is automatically reset,
restoring the network connection. To eliminate the potential
for the hang ensure that RxIntDelay is set to 0.
RxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
Valid Range: 0-65535 (0=off)
Default Value: 128
This value, in units of 1.024 microseconds, limits the delay in which a
receive interrupt is generated. Useful only if RxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is received within the set amount of time. Proper tuning,
along with RxIntDelay, may improve traffic throughput in specific network
conditions.
Speed
-----
(This parameter is supported only on adapters with copper connections.)
Valid Settings: 0, 10, 100, 1000
Default Value: 0 (auto-negotiate at all supported speeds)
Speed forces the line speed to the specified value in megabits per second
(Mbps). If this parameter is not specified or is set to 0 and the link
partner is set to auto-negotiate, the board will auto-detect the correct
speed. Duplex should also be set when Speed is set to either 10 or 100.
TxDescriptors
-------------
Valid Range: 80-256 for 82542 and 82543-based adapters
80-4096 for all other supported adapters
Default Value: 256
This value is the number of transmit descriptors allocated by the driver.
Increasing this value allows the driver to queue more transmits. Each
descriptor is 16 bytes.
NOTE: Depending on the available system resources, the request for a
higher number of transmit descriptors may be denied. In this case,
use a lower number.
TxIntDelay
----------
Valid Range: 0-65535 (0=off)
Default Value: 64
This value delays the generation of transmit interrupts in units of
1.024 microseconds. Transmit interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic. If the
system is reporting dropped transmits, this value may be set too high
causing the driver to run out of available transmit descriptors.
TxAbsIntDelay
-------------
(This parameter is supported only on 82540, 82545 and later adapters.)
Valid Range: 0-65535 (0=off)
Default Value: 64
This value, in units of 1.024 microseconds, limits the delay in which a
transmit interrupt is generated. Useful only if TxIntDelay is non-zero,
this value ensures that an interrupt is generated after the initial
packet is sent on the wire within the set amount of time. Proper tuning,
along with TxIntDelay, may improve traffic throughput in specific
network conditions.
XsumRX
------
(This parameter is NOT supported on the 82542-based adapter.)
Valid Range: 0-1
Default Value: 1
A value of '1' indicates that the driver should enable IP checksum
offload for received packets (both UDP and TCP) to the adapter hardware.
Speed and Duplex Configuration
==============================
Three keywords are used to control the speed and duplex configuration.
These keywords are Speed, Duplex, and AutoNeg.
If the board uses a fiber interface, these keywords are ignored, and the
fiber interface board only links at 1000 Mbps full-duplex.
For copper-based boards, the keywords interact as follows:
The default operation is auto-negotiate. The board advertises all
supported speed and duplex combinations, and it links at the highest
common speed and duplex mode IF the link partner is set to auto-negotiate.
If Speed = 1000, limited auto-negotiation is enabled and only 1000 Mbps
is advertised (The 1000BaseT spec requires auto-negotiation.)
If Speed = 10 or 100, then both Speed and Duplex should be set. Auto-
negotiation is disabled, and the AutoNeg parameter is ignored. Partner
SHOULD also be forced.
The AutoNeg parameter is used when more control is required over the
auto-negotiation process. It should be used when you wish to control which
speed and duplex combinations are advertised during the auto-negotiation
process.
The parameter may be specified as either a decimal or hexadecimal value as
determined by the bitmap below.
Bit position 7 6 5 4 3 2 1 0
Decimal Value 128 64 32 16 8 4 2 1
Hex value 80 40 20 10 8 4 2 1
Speed (Mbps) N/A N/A 1000 N/A 100 100 10 10
Duplex Full Full Half Full Half
Some examples of using AutoNeg:
modprobe e1000 AutoNeg=0x01 (Restricts autonegotiation to 10 Half)
modprobe e1000 AutoNeg=1 (Same as above)
modprobe e1000 AutoNeg=0x02 (Restricts autonegotiation to 10 Full)
modprobe e1000 AutoNeg=0x03 (Restricts autonegotiation to 10 Half or 10 Full)
modprobe e1000 AutoNeg=0x04 (Restricts autonegotiation to 100 Half)
modprobe e1000 AutoNeg=0x05 (Restricts autonegotiation to 10 Half or 100
Half)
modprobe e1000 AutoNeg=0x020 (Restricts autonegotiation to 1000 Full)
modprobe e1000 AutoNeg=32 (Same as above)
Note that when this parameter is used, Speed and Duplex must not be specified.
If the link partner is forced to a specific speed and duplex, then this
parameter should not be used. Instead, use the Speed and Duplex parameters
previously mentioned to force the adapter to the same speed and duplex.
Additional Configurations
=========================
Configuring the Driver on Different Distributions
-------------------------------------------------
Configuring a network driver to load properly when the system is started
is distribution dependent. Typically, the configuration process involves
adding an alias line to /etc/modules.conf or /etc/modprobe.conf as well
as editing other system startup scripts and/or configuration files. Many
popular Linux distributions ship with tools to make these changes for you.
To learn the proper way to configure a network device for your system,
refer to your distribution documentation. If during this process you are
asked for the driver or module name, the name for the Linux Base Driver
for the Intel(R) PRO/1000 Family of Adapters is e1000.
As an example, if you install the e1000 driver for two PRO/1000 adapters
(eth0 and eth1) and set the speed and duplex to 10full and 100half, add
the following to modules.conf or or modprobe.conf:
alias eth0 e1000
alias eth1 e1000
options e1000 Speed=10,100 Duplex=2,1
Viewing Link Messages
---------------------
Link messages will not be displayed to the console if the distribution is
restricting system messages. In order to see network driver link messages
on your console, set dmesg to eight by entering the following:
dmesg -n 8
NOTE: This setting is not saved across reboots.
Jumbo Frames
------------
Jumbo Frames support is enabled by changing the MTU to a value larger than
the default of 1500. Use the ifconfig command to increase the MTU size.
For example:
ifconfig eth<x> mtu 9000 up
This setting is not saved across reboots. It can be made permanent if
you add:
MTU=9000
to the file /etc/sysconfig/network-scripts/ifcfg-eth<x>. This example
applies to the Red Hat distributions; other distributions may store this
setting in a different location.
Notes:
- To enable Jumbo Frames, increase the MTU size on the interface beyond
1500.
- The maximum MTU setting for Jumbo Frames is 16110. This value coincides
with the maximum Jumbo Frames size of 16128.
- Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or
loss of link.
- Some Intel gigabit adapters that support Jumbo Frames have a frame size
limit of 9238 bytes, with a corresponding MTU size limit of 9216 bytes.
The adapters with this limitation are based on the Intel(R) 82571EB,
82572EI, 82573L and 80003ES2LAN controller. These correspond to the
following product names:
Intel(R) PRO/1000 PT Server Adapter
Intel(R) PRO/1000 PT Desktop Adapter
Intel(R) PRO/1000 PT Network Connection
Intel(R) PRO/1000 PT Dual Port Server Adapter
Intel(R) PRO/1000 PT Dual Port Network Connection
Intel(R) PRO/1000 PF Server Adapter
Intel(R) PRO/1000 PF Network Connection
Intel(R) PRO/1000 PF Dual Port Server Adapter
Intel(R) PRO/1000 PB Server Connection
Intel(R) PRO/1000 PL Network Connection
Intel(R) PRO/1000 EB Network Connection with I/O Acceleration
Intel(R) PRO/1000 EB Backplane Connection with I/O Acceleration
Intel(R) PRO/1000 PT Quad Port Server Adapter
- Adapters based on the Intel(R) 82542 and 82573V/E controller do not
support Jumbo Frames. These correspond to the following product names:
Intel(R) PRO/1000 Gigabit Server Adapter
Intel(R) PRO/1000 PM Network Connection
- The following adapters do not support Jumbo Frames:
Intel(R) 82562V 10/100 Network Connection
Intel(R) 82566DM Gigabit Network Connection
Intel(R) 82566DC Gigabit Network Connection
Intel(R) 82566MM Gigabit Network Connection
Intel(R) 82566MC Gigabit Network Connection
Intel(R) 82562GT 10/100 Network Connection
Intel(R) 82562G 10/100 Network Connection
Ethtool
-------
The driver utilizes the ethtool interface for driver configuration and
diagnostics, as well as displaying statistical information. Ethtool
version 1.6 or later is required for this functionality.
The latest release of ethtool can be found from
http://sourceforge.net/projects/gkernel.
NOTE: Ethtool 1.6 only supports a limited set of ethtool options. Support
for a more complete ethtool feature set can be enabled by upgrading
ethtool to ethtool-1.8.1.
Enabling Wake on LAN* (WoL)
---------------------------
WoL is configured through the Ethtool* utility. Ethtool is included with
all versions of Red Hat after Red Hat 7.2. For other Linux distributions,
download and install Ethtool from the following website:
http://sourceforge.net/projects/gkernel.
For instructions on enabling WoL with Ethtool, refer to the website listed
above.
WoL will be enabled on the system during the next shut down or reboot.
For this driver version, in order to enable WoL, the e1000 driver must be
loaded when shutting down or rebooting the system.
Wake On LAN is only supported on port A for the following devices:
Intel(R) PRO/1000 PT Dual Port Network Connection
Intel(R) PRO/1000 PT Dual Port Server Connection
Intel(R) PRO/1000 PT Dual Port Server Adapter
Intel(R) PRO/1000 PF Dual Port Server Adapter
Intel(R) PRO/1000 PT Quad Port Server Adapter
NAPI
----
NAPI (Rx polling mode) is supported in the e1000 driver. NAPI is enabled
or disabled based on the configuration of the kernel. To override
the default, use the following compile-time flags.
To enable NAPI, compile the driver module, passing in a configuration option:
make CFLAGS_EXTRA=-DE1000_NAPI install
To disable NAPI, compile the driver module, passing in a configuration option:
make CFLAGS_EXTRA=-DE1000_NO_NAPI install
See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI.
Known Issues
============
Dropped Receive Packets on Half-duplex 10/100 Networks
------------------------------------------------------
If you have an Intel PCI Express adapter running at 10mbps or 100mbps, half-
duplex, you may observe occasional dropped receive packets. There are no
workarounds for this problem in this network configuration. The network must
be updated to operate in full-duplex, and/or 1000mbps only.
Jumbo Frames System Requirement
-------------------------------
Memory allocation failures have been observed on Linux systems with 64 MB
of RAM or less that are running Jumbo Frames. If you are using Jumbo
Frames, your system may require more than the advertised minimum
requirement of 64 MB of system memory.
Performance Degradation with Jumbo Frames
-----------------------------------------
Degradation in throughput performance may be observed in some Jumbo frames
environments. If this is observed, increasing the application's socket
buffer size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values
may help. See the specific application manual and
/usr/src/linux*/Documentation/
networking/ip-sysctl.txt for more details.
Jumbo Frames on Foundry BigIron 8000 switch
-------------------------------------------
There is a known issue using Jumbo frames when connected to a Foundry
BigIron 8000 switch. This is a 3rd party limitation. If you experience
loss of packets, lower the MTU size.
Allocating Rx Buffers when Using Jumbo Frames
---------------------------------------------
Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if
the available memory is heavily fragmented. This issue may be seen with PCI-X
adapters or with packet split disabled. This can be reduced or eliminated
by changing the amount of available memory for receive buffer allocation, by
increasing /proc/sys/vm/min_free_kbytes.
Multiple Interfaces on Same Ethernet Broadcast Network
------------------------------------------------------
Due to the default ARP behavior on Linux, it is not possible to have
one system on two IP networks in the same Ethernet broadcast domain
(non-partitioned switch) behave as expected. All Ethernet interfaces
will respond to IP traffic for any IP address assigned to the system.
This results in unbalanced receive traffic.
If you have multiple interfaces in a server, either turn on ARP
filtering by entering:
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(this only works if your kernel's version is higher than 2.4.5),
NOTE: This setting is not saved across reboots. The configuration
change can be made permanent by adding the line:
net.ipv4.conf.all.arp_filter = 1
to the file /etc/sysctl.conf
or,
install the interfaces in separate broadcast domains (either in
different switches or in a switch partitioned to VLANs).
82541/82547 can't link or are slow to link with some link partners
-----------------------------------------------------------------
There is a known compatibility issue with 82541/82547 and some
low-end switches where the link will not be established, or will
be slow to establish. In particular, these switches are known to
be incompatible with 82541/82547:
Planex FXG-08TE
I-O Data ETG-SH8
To workaround this issue, the driver can be compiled with an override
of the PHY's master/slave setting. Forcing master or forcing slave
mode will improve time-to-link.
# make CFLAGS_EXTRA=-DE1000_MASTER_SLAVE=<n>
Where <n> is:
0 = Hardware default
1 = Master mode
2 = Slave mode
3 = Auto master/slave
Disable rx flow control with ethtool
------------------------------------
In order to disable receive flow control using ethtool, you must turn
off auto-negotiation on the same command line.
For example:
ethtool -A eth? autoneg off rx off
Unplugging network cable while ethtool -p is running
----------------------------------------------------
In kernel versions 2.5.50 and later (including 2.6 kernel), unplugging
the network cable while ethtool -p is running will cause the system to
become unresponsive to keyboard commands, except for control-alt-delete.
Restarting the system appears to be the only remedy.
Support
=======
For general information, go to the Intel support website at:
http://support.intel.com
or the Intel Wired Networking project hosted by Sourceforge at:
http://sourceforge.net/projects/e1000
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related
to the issue to e1000-devel@lists.sf.net

528
Documentation/networking/eql.txt Normal file
View File

@@ -0,0 +1,528 @@
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
that lets you load-balance IP serial links (SLIP or uncompressed PPP)
to increase your bandwidth. It will not reduce your latency (i.e. ping
times) except in the case where you already have lots of traffic on
your link, in which it will help them out. This driver has been tested
with the 1.1.75 kernel, and is known to have patched cleanly with
1.1.86. Some testing with 1.1.92 has been done with the v1.1 patch
which was only created to patch cleanly in the very latest kernel
source trees. (Yes, it worked fine.)
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,
and have a ISP that is flexible, it is now possible to bind modems
together to work as one point-to-point link to increase your
bandwidth. All without having to have a special black box on either
side.
The eql driver has only been tested with the Livingston PortMaster-2e
terminal server. I do not know if other terminal servers support load-
balancing, but I do know that the PortMaster does it, and does it
almost as well as the eql driver seems to do it (-- Unfortunately, in
my testing so far, the Livingston PortMaster 2e's load-balancing is a
good 1 to 2 KB/s slower than the test machine working with a 28.8 Kbps
and 14.4 Kbps connection. However, I am not sure that it really is
the PortMaster, or if it's Linux's TCP drivers. I'm told that Linux's
TCP implementation is pretty fast though.--)
I suggest to ISPs out there that it would probably be fair to charge
a load-balancing client 75% of the cost of the second line and 50% of
the cost of the third line etc...
Hey, we can all dream you know...
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
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:
______________________________________________________________________
-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:
______________________________________________________________________
cd /usr/src
patch </usr/local/src/eql-1.1/eql-1.1.patch
______________________________________________________________________
2.2. Building The Kernel
After patching the kernel, run make config and configure the kernel
for your hardware.
After configuration, make and install according to your habit.
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
so quickly."--) . How you configure it for other "connection"
managers is up to you. Most other connection managers that I've seen
don't do a very good job when it comes to handling more than one
connection.
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:
______________________________________________________________________
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:
______________________________________________________________________
route add default eql
______________________________________________________________________
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
an enslaved device "dies", it is automatically taken out of the queue.
I haven't found a good reason to write it yet... other than for
completeness, but that isn't a good motivator is it?--)
The syntax for enslaving a device is "eql_enslave <master-name>
<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.--)
______________________________________________________________________
eql_emancipate eql sl0
eql_emancipate eql ppp0
eql_emancipate eql sl1
______________________________________________________________________
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
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
______________________________________________________________________
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
DSLIP. I did find a good tip from LinuxNET:Billy for PPP performance:
make sure you have asyncmap set to something so that control
characters are not escaped.
I tried to fix up a PPP script/system for redialing lost PPP
connections for use with the eql driver the weekend of Feb 25-26 '95
(Hereafter known as the 8-hour PPP Hate Festival). Perhaps later this
year.
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
up of the driver was tuned to handle slaves with wildly different
bits-per-second "priorities".
All testing I have done was with two 28.8 V.FC modems, one connecting
at 28800 bps or slower, and the other connecting at 14400 bps all the
time.
One version of the scheduler was able to push 5.3 K/s through the
28800 and 14400 connections, but when the priorities on the links were
very wide apart (57600 vs. 14400) the "faster" modem received all
traffic and the "slower" modem starved.
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
cleanly in newer kernels because of the removal of the old "slave-
balancing" driver config option.
o 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
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
to bundle multiple SLIP connections into what appears to be a
single connection. This allows one to improve dial-up network
connectivity gradually, without having to buy expensive DSU/CSU
hardware and services.
I have done some testing of this software, with two goals in
mind: first, to ensure it actually works as described and
second, as a method of exercising my device driver.
The following performance measurements were derived from a set
of SLIP connections run between two Linux systems (1.1.84) using
a 486DX2/66 with a Cyclom-8Ys and a 486SLC/40 with a Cyclom-16Y.
(Ports 0,1,2,3 were used. A later configuration will distribute
port selection across the different Cirrus chips on the boards.)
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:
bits/sec seconds
345600 8.3
234600 12.3
172800 16.7
153600 18.8
76800 37.6
57600 50.2
38400 75.3
28800 100.4
19200 150.6
9600 301.3
A single line running at the lower speeds and with large packets
comes to within 2% of this. Performance is limited for the higher
speeds (as predicted by the Cirrus databook) to an aggregate of
about 160 kbits/sec. The next round of testing will distribute
the load across two or more Cirrus chips.
The good news is that one gets nearly the full advantage of the
second, third, and fourth line's bandwidth. (The bad news is
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
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,
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. :)

46
Documentation/networking/ewrk3.txt Normal file
View File

@@ -0,0 +1,46 @@
The EtherWORKS 3 driver in this distribution is designed to work with all
kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools'
subdirectory to allow set up of the card, similar to the MSDOS
'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that
subdirectory to make the tools).
The supported cards are DE203, DE204 and DE205. All other cards are NOT
supported - refer to 'depca.c' for running the LANCE based network cards and
'de4x5.c' for the DIGITAL Semiconductor PCI chip based adapters from
Digital.
The ability to load this driver as a loadable module has been included and
used extensively during the driver development (to save those long reboot
sequences). To utilise this ability, you have to do 8 things:
0) have a copy of the loadable modules code installed on your system.
1) copy ewrk3.c from the /linux/drivers/net directory to your favourite
temporary directory.
2) edit the source code near line 1898 to reflect the I/O address and
IRQ you're using.
3) compile ewrk3.c, but include -DMODULE in the command line to ensure
that the correct bits are compiled (see end of source code).
4) if you are wanting to add a new card, goto 5. Otherwise, recompile a
kernel with the ewrk3 configuration turned off and reboot.
5) insmod ewrk3.o
[Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y]
[Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2]
6) run the net startup bits for your new eth?? interface manually
(usually /etc/rc.inet[12] at boot time).
7) enjoy!
Note that autoprobing is not allowed in loadable modules - the system is
already up and running and you're messing with interrupts.
To unload a module, turn off the associated interface
'ifconfig eth?? down' then 'rmmod ewrk3'.
The performance we've achieved so far has been measured through the 'ttcp'
tool at 975kB/s. This measures the total TCP stack performance which
includes the card, so don't expect to get much nearer the 1.25MB/s
theoretical Ethernet rate.
Enjoy!
Dave

145
Documentation/networking/fib_trie.txt Normal file
View File

@@ -0,0 +1,145 @@
LC-trie implementation notes.
Node types
----------
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.
trie node or tnode
An internal node, holding an array of child (leaf or tnode) pointers,
indexed through a subset of the key. See Level Compression.
A few concepts explained
------------------------
Bits (tnode)
The number of bits in the key segment used for indexing into the
child array - the "child index". See Level Compression.
Pos (tnode)
The position (in the key) of the key segment used for indexing into
the child array. See Path Compression.
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"
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
deviations. These "skipped bits" constitute Path Compression.
Note that the search algorithm will simply skip over these bits when
searching, making it necessary to save the keys in the leaves to
verify that they actually do match the key we are searching for.
Level Compression / child arrays
the trie is kept level balanced moving, under certain conditions, the
children of a full child (see "full_children") up one level, so that
instead of a pure binary tree, each internal node ("tnode") may
contain an arbitrarily large array of links to several children.
Conversely, a tnode with a mostly empty child array (see empty_children)
may be "halved", having some of its children moved downwards one level,
in order to avoid ever-increasing child arrays.
empty_children
the number of positions in the child array of a given tnode that are
NULL.
full_children
the number of children of a given tnode that aren't path compressed.
(in other words, they aren't NULL or leaves and their "pos" is equal
to this tnode's "pos"+"bits").
(The word "full" here is used more in the sense of "complete" than
as the opposite of "empty", which might be a tad confusing.)
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.
fib_find_node()
A good start for understanding this code. This function implements a
straightforward trie lookup.
fib_insert_node()
Inserts a new leaf node in the trie. This is bit more complicated than
fib_find_node(). Inserting a new node means we might have to run the
level compression algorithm on part of the trie.
trie_leaf_remove()
Looks up a key, deletes it and runs the level compression algorithm.
trie_rebalance()
The key function for the dynamic trie after any change in the trie
it is run to optimize and reorganize. Tt will walk the trie upwards
towards the root from a given tnode, doing a resize() at each step
to implement level compression.
resize()
Analyzes a tnode and optimizes the child array size by either inflating
or shrinking it repeatedly until it fulfills the criteria for optimal
level compression. This part follows the original paper pretty closely
and there may be some room for experimentation here.
inflate()
Doubles the size of the child array within a tnode. Used by resize().
halve()
Halves the size of the child array within a tnode - the inverse of
inflate(). Used by resize();
fn_trie_insert(), fn_trie_delete(), fn_trie_select_default()
The route manipulation functions. Should conform pretty closely to the
corresponding functions in fib_hash.
fn_trie_flush()
This walks the full trie (using nextleaf()) and searches for empty
leaves which have to be removed.
fn_trie_dump()
Dumps the routing table ordered by prefix length. This is somewhat
slower than the corresponding fib_hash function, as we have to walk the
entire trie for each prefix length. In comparison, fib_hash is organized
as one "zone"/hash per prefix length.
Locking
-------
fib_lock is used for an RW-lock in the same way that this is done in fib_hash.
However, the functions are somewhat separated for other possible locking
scenarios. It might conceivably be possible to run trie_rebalance via RCU
to avoid read_lock in the fn_trie_lookup() function.
Main lookup mechanism
---------------------
fn_trie_lookup() is the main lookup function.
The lookup is in its simplest form just like fib_find_node(). We descend the
trie, key segment by key segment, until we find a leaf. check_leaf() does
the fib_semantic_match in the leaf's sorted prefix hlist.
If we find a match, we are done.
If we don't find a match, we enter prefix matching mode. The prefix length,
starting out at the same as the key length, is reduced one step at a time,
and we backtrack upwards through the trie trying to find a longest matching
prefix. The goal is always to reach a leaf and get a positive result from the
fib_semantic_match mechanism.
Inside each tnode, the search for longest matching prefix consists of searching
through the child array, chopping off (zeroing) the least significant "1" of
the child index until we find a match or the child index consists of nothing but
zeros.
At this point we backtrack (t->stats.backtrack++) up the trie, continuing to
chop off part of the key in order to find the longest matching prefix.
At this point we will repeatedly descend subtries to look for a match, and there
are some optimizations available that can provide us with "shortcuts" to avoid
descending into dead ends. Look for "HL_OPTIMIZE" sections in the code.
To alleviate any doubts about the correctness of the route selection process,
a new netlink operation has been added. Look for NETLINK_FIB_LOOKUP, which
gives userland access to fib_lookup().

42
Documentation/networking/filter.txt Normal file
View File

@@ -0,0 +1,42 @@
filter.txt: Linux Socket Filtering
Written by: Jay Schulist <jschlst@samba.org>
Introduction
============
Linux Socket Filtering is derived from the Berkeley
Packet Filter. There are some distinct differences between
the BSD and Linux Kernel Filtering.
Linux Socket Filtering (LSF) allows a user-space program to
attach a filter onto any socket and allow or disallow certain
types of data to come through the socket. LSF follows exactly
the same filter code structure as the BSD Berkeley Packet Filter
(BPF), so referring to the BSD bpf.4 manpage is very helpful in
creating filters.
LSF is much simpler than BPF. One does not have to worry about
devices or anything like that. You simply create your filter
code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
if your filter code passes the kernel check on it, you then
immediately begin filtering data on that socket.
You can also detach filters from your socket via the
SO_DETACH_FILTER ioctl. This will probably not be used much
since when you close a socket that has a filter on it the
filter is automagically removed. The other less common case
may be adding a different filter on the same socket where you had another
filter that is still running: the kernel takes care of removing
the old one and placing your new one in its place, assuming your
filter has passed the checks, otherwise if it fails the old filter
will remain on that socket.
Examples
========
Ioctls-
setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.

66
Documentation/networking/fore200e.txt Normal file
View File

@@ -0,0 +1,66 @@
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
written by Uwe Dannowski.
The driver simultaneously supports PCA-200E and SBA-200E adapters on
i386, alpha (untested), powerpc, sparc and sparc64 archs.
The intent is to enable the use of different models of FORE adapters at the
same time, by hosts that have several bus interfaces (such as PCI+SBUS,
PCI+MCA or PCI+EISA).
Only PCI and SBUS devices are currently supported by the driver, but support
for other bus interfaces such as EISA should not be too hard to add (this may
be more tricky for the MCA bus, though, as FORE made some MCA-specific
modifications to the adapter's AALI interface).
Firmware Copyright Notice
-------------------------
Please read the fore200e_firmware_copyright file present
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 supplied firmware images should work with all adapters.
However, if you encounter problems (the firmware doesn't start or the driver
is unable to read the PROM data), you may consider trying another firmware
version. Alternative binary firmware images can be found somewhere on the
ForeThought CD-ROM supplied with your adapter by FORE Systems.
You can also get the latest firmware images from FORE Systems at
http://www.fore.com. Register TACTics Online and go to
the 'software updates' pages. The firmware binaries are part of
the various ForeThought software distributions.
Notice that different versions of the PCA-200E firmware exist, depending
on the endianess of the host architecture. The driver is shipped with
both little and big endian PCA firmware images.
Name and location of the new firmware images can be set at kernel
configuration time:
1. Copy the new firmware binary files (with .bin, .bin1 or .bin2 suffix)
to some directory, such as linux/drivers/atm.
2. Reconfigure your kernel to set the new firmware name and location.
Expected pathnames are absolute or relative to the drivers/atm directory.
3. Rebuild and re-install your kernel or your module.
Feedback
--------
Feedback is welcome. Please send success stories/bug reports/
patches/improvement/comments/flames to <lizzi@cnam.fr>.

39
Documentation/networking/framerelay.txt Normal file
View File

@@ -0,0 +1,39 @@
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
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'...
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,
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
Sangoma makes more firmware modules available, it can be updated to provide
them as well.
Configuration of the FRAD makes use of another net-tools program, 'fradcfg'.
This program makes use of a configuration file (which dlcicfg can also read)
to specify the types of boards to be configured as FRADs, as well as perform
any board specific configuration. The Sangoma module of fradcfg loads the
FR firmware into the card, sets the irq/port/memory information, and provides
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
/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
pre-2.0.4 and later.

117
Documentation/networking/gen_stats.txt Normal file
View File

@@ -0,0 +1,117 @@
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;
...
};
Update statistics:
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) < 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.
my_dumping_routine(struct sk_buff *skb, ...)
{
if (gnet_stats_start_copy_compat(skb, TCA_STATS2, TCA_STATS,
TCA_XSTATS, &mystruct->lock, &dump) < 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
was called.
Locking:
--------
Locks are taken before writing and released once all statistics have
been written. Locks are always released in case of an error. You
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.
As usual, such a TLV needs to be 32 bit aligned and therefore the
length needs to be appropriately set, etc. The estimator interval
and ewma log need to be converted to the appropriate values.
tc_estimator.c::tc_setup_estimator() is advisable to be used as the
conversion routine. It does a few clever things. It takes a time
interval in microsecs, a time constant also in microsecs and a struct
tc_estimator to be populated. The returned tc_estimator can be
transported to the kernel. Transfer such a structure in a TLV of type
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:
int ret = gen_new_estimator(my_basicstats,my_rate_est_stats,
mystats_lock, attr_with_tcestimator_struct);
if ret == 0
success
else
failed
From now on, every time you dump my_rate_est_stats it will contain
up-to-date info.
Once you are done, call gen_kill_estimator(my_basicstats,
my_rate_est_stats) Make sure that my_basicstats and my_rate_est_stats
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>

132
Documentation/networking/generic-hdlc.txt Normal file
View File

@@ -0,0 +1,132 @@
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 (uses syncppp.c).
5. X.25 (uses X.25 routines).
Generic HDLC is a protocol driver only - it needs a low-level driver
for your particular hardware.
Ethernet device emulation (using HDLC or Frame-Relay PVC) is compatible
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:
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:
sethdlc hdlc0 clock int rate 128000
sethdlc hdlc0 cisco interval 10 timeout 25
or
sethdlc hdlc0 rs232 clock ext
sethdlc hdlc0 fr lmi ansi
sethdlc hdlc0 create 99
ifconfig hdlc0 up
ifconfig pvc0 localIP pointopoint remoteIP
In Frame Relay mode, ifconfig master hdlc device up (without assigning
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)
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
* 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
Frame-Relay only:
* create n | delete n - adds / deletes PVC interface with DLCI #n.
Newly created interface will be named pvc0, pvc1 etc.
* create ether n | delete ether n - adds a device for Ethernet-bridged
frames. The device will be named pvceth0, pvceth1 etc.
Board-specific issues
---------------------
n2.o and c101.o need parameters to work:
insmod n2 hw=io,irq,ram,ports[:io,irq,...]
example:
insmod n2 hw=0x300,10,0xD0000,01
or
insmod c101 hw=irq,ram[:irq,...]
example:
insmod c101 hw=9,0xdc000
If built into the kernel, these drivers need kernel (command line) parameters:
n2.hw=io,irq,ram,ports:...
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):
sethdlc hdlc0 private
The hardware driver has to be build with #define DEBUG_RINGS.
Attaching this info to bug reports would be helpful. Anyway, let me know
if you have problems using this.
For patches and other info look at:
<http://www.kernel.org/pub/linux/utils/net/hdlc/>.

3
Documentation/networking/generic_netlink.txt Normal file
View File

@@ -0,0 +1,3 @@
A wiki document on how to use Generic Netlink can be found here:
* http://linux-net.osdl.org/index.php/Generic_Netlink_HOWTO

72
Documentation/networking/gianfar.txt Normal file
View File

@@ -0,0 +1,72 @@
The Gianfar Ethernet Driver
Sysfs File description
Author: Andy Fleming <afleming@freescale.com>
Updated: 2005-07-28
SYSFS
Several of the features of the gianfar driver are controlled
through sysfs files. These are:
bd_stash:
To stash RX Buffer Descriptors in the L2, echo 'on' or '1' to
bd_stash, echo 'off' or '0' to disable
rx_stash_len:
To stash the first n bytes of the packet in L2, echo the number
of bytes to buf_stash_len. echo 0 to disable.
WARNING: You could really screw these up if you set them too low or high!
fifo_threshold:
To change the number of bytes the controller needs in the
fifo before it starts transmission, echo the number of bytes to
fifo_thresh. Range should be 0-511.
fifo_starve:
When the FIFO has less than this many bytes during a transmit, it
enters starve mode, and increases the priority of TX memory
transactions. To change, echo the number of bytes to
fifo_starve. Range should be 0-511.
fifo_starve_off:
Once in starve mode, the FIFO remains there until it has this
many bytes. To change, echo the number of bytes to
fifo_starve_off. Range should be 0-511.
CHECKSUM OFFLOADING
The eTSEC controller (first included in parts from late 2005 like
the 8548) has the ability to perform TCP, UDP, and IP checksums
in hardware. The Linux kernel only offloads the TCP and UDP
checksums (and always performs the pseudo header checksums), so
the driver only supports checksumming for TCP/IP and UDP/IP
packets. Use ethtool to enable or disable this feature for RX
and TX.
VLAN
In order to use VLAN, please consult Linux documentation on
configuring VLANs. The gianfar driver supports hardware insertion and
extraction of VLAN headers, but not filtering. Filtering will be
done by the kernel.
MULTICASTING
The gianfar driver supports using the group hash table on the
TSEC (and the extended hash table on the eTSEC) for multicast
filtering. On the eTSEC, the exact-match MAC registers are used
before the hash tables. See Linux documentation on how to join
multicast groups.
PADDING
The gianfar driver supports padding received frames with 2 bytes
to align the IP header to a 16-byte boundary, when supported by
hardware.
ETHTOOL
The gianfar driver supports the use of ethtool for many
configuration options. You must run ethtool only on currently
open interfaces. See ethtool documentation for details.

1103
Documentation/networking/ifenslave.c Normal file
View File

File diff suppressed because it is too large Load Diff

1023
Documentation/networking/ip-sysctl.txt Normal file
View File

File diff suppressed because it is too large Load Diff

29
Documentation/networking/ip_dynaddr.txt Normal file
View File

@@ -0,0 +1,29 @@
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:
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
internal host does retransmission) until a packet from outside is
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
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:
# echo 1 > /proc/sys/net/ipv4/ip_dynaddr
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>

78
Documentation/networking/ipddp.txt Normal file
View File

@@ -0,0 +1,78 @@
Text file for ipddp.c:
AppleTalk-IP Decapsulation and AppleTalk-IP Encapsulation
This text file is written by Jay Schulist <jschlst@samba.org>
Introduction
------------
AppleTalk-IP (IPDDP) is the method computers connected to AppleTalk
networks can use to communicate via IP. AppleTalk-IP is simply IP datagrams
inside AppleTalk packets.
Through this driver you can either allow your Linux box to communicate
IP over an AppleTalk network or you can provide IP gatewaying functions
for your AppleTalk users.
You can currently encapsulate or decapsulate AppleTalk-IP on LocalTalk,
EtherTalk and PPPTalk. The only limit on the protocol is that of what
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
select ONE of the two options; IP to AppleTalk-IP encapsulation support or
AppleTalk-IP to IP decapsulation support. If you compile the driver
statically you will only be able to use the driver for the function you have
enabled in the kernel. If you compile the driver as a module you can
select what mode you want it to run in via a module loading param.
ipddp_mode=1 for AppleTalk-IP encapsulation and ipddp_mode=2 for
AppleTalk-IP to IP decapsulation.
Basic instructions for user space tools
=======================================
To enable AppleTalk-IP decapsulation/encapsulation you will need the
proper tools. You can get the tools for decapsulation from
http://spacs1.spacs.k12.wi.us/~jschlst/index.html and for encapsulation
from http://www.maths.unm.edu/~bradford/ltpc.html
I will briefly describe the operation of the tools, but you will
need to consult the supporting documentation for each set of tools.
Decapsulation - You will need to download a software package called
MacGate. In this distribution there will be a tool called MacRoute
which enables you to add routes to the kernel for your Macs by hand.
Also the tool MacRegGateWay is included to register the
proper IP Gateway and IP addresses for your machine. Included in this
distribution is a patch to netatalk-1.4b2+asun2.0a17.2 (available from
ftp.u.washington.edu/pub/user-supported/asun/) this patch is optional
but it allows automatic adding and deleting of routes for Macs. (Handy
for locations with large Mac installations)
Encapsulation - You will need to download a software daemon called ipddpd.
This software expects there to be an AppleTalk-IP gateway on the network.
You will also need to add the proper routes to route your Linux box's IP
traffic out the ipddp interface.
Common Uses of ipddp.c
----------------------
Of course AppleTalk-IP decapsulation and encapsulation, but specifically
decapsulation is being used most for connecting LocalTalk networks to
IP networks. Although it has been used on EtherTalk networks to allow
Macs that are only able to tunnel IP over EtherTalk.
Encapsulation has been used to allow a Linux box stuck on a LocalTalk
network to use IP. It should work equally well if you are stuck on an
EtherTalk only network.
Further Assistance
-------------------
You can contact me (Jay Schulist <jschlst@samba.org>) with any
questions regarding decapsulation or encapsulation. Bradford W. Johnson
<johns393@maroon.tc.umn.edu> originally wrote the ipddp.c driver for IP
encapsulation in AppleTalk.

158
Documentation/networking/iphase.txt Normal file
View File

@@ -0,0 +1,158 @@
READ ME FISRT
ATM (i)Chip IA Linux Driver Source
--------------------------------------------------------------------------------
Read This Before You Begin!
--------------------------------------------------------------------------------
Description
-----------
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
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.
- 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
http://www.iphase.com/site/iphase-web/?epi_menuItemID=e196f04b4b3b40502f150882e21046a0
for details.
- Only x86 platforms are supported.
- SMP is supported.
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.
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
menuconfig" or "make xconfig".
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:
cat /proc/atm/devices
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 )
You can also check the system log file /var/log/messages for messages
related to the ATM driver.
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:
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)
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
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
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
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.
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.
OUTSTANDING ISSUES
------------------
Contact Information
-------------------
Customer Support:
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
World Wide Web: http://www.iphase.com
Anonymous FTP: ftp.iphase.com

143
Documentation/networking/ipvs-sysctl.txt Normal file
View File

@@ -0,0 +1,143 @@
/proc/sys/net/ipv4/vs/* Variables:
am_droprate - INTEGER
default 10
It sets the always mode drop rate, which is used in the mode 3
of the drop_rate defense.
amemthresh - INTEGER
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.
cache_bypass - BOOLEAN
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.
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
Only available when IPVS is compiled with the CONFIG_IPVS_DEBUG
Higher debugging levels include the messages for lower debugging
levels, so setting debug level 2, includes level 0, 1 and 2
messages. Thus, logging becomes more and more verbose the higher
the level.
drop_entry - INTEGER
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 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)
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.
expire_nodest_conn - BOOLEAN
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.
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
When set to a non-zero value, the load balancer will expire
persistent templates when the destination server is quiescent.
This may be useful, when a user makes a destination server
quiescent by setting its weight to 0 and it is desired that
subsequent otherwise persistent connections are sent to a
different destination server. By default new persistent
connections are allowed to quiescent destination servers.
If this feature is enabled, the load balancer will expire the
persistence template if it is to be used to schedule a new
connection and the destination server is quiescent.
nat_icmp_send - BOOLEAN
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.
secure_tcp - INTEGER
0 - disabled (default)
The secure_tcp defense is to use a more complicated state
transition table and some possible short timeouts of each
state. In the VS/NAT, it delays the entering the ESTABLISHED
until the real server starts to send data and ACK packet
(after 3-way handshake).
The value definition is the same as that of drop_entry or
drop_packet.
sync_threshold - INTEGER
default 3
It sets synchronization threshold, which is the minimum number
of incoming packets that a connection needs to receive before
the connection will be synchronized. A connection will be
synchronized, every time the number of its incoming packets
modulus 50 equals the threshold. The range of the threshold is
from 0 to 49.

10
Documentation/networking/irda.txt Normal file
View File

@@ -0,0 +1,10 @@
To use the IrDA protocols within Linux you will need to get a suitable copy
of the IrDA Utilities. More detailed information about these and associated
programs can be found on http://irda.sourceforge.net/
For more information about how to use the IrDA protocol stack, see the
Linux Infrared HOWTO by Werner Heuser <wehe@tuxmobil.org>:
<http://www.tuxmobil.org/Infrared-HOWTO/Infrared-HOWTO.html>
There is an active mailing list for discussing Linux-IrDA matters called
irda-users@lists.sourceforge.net

212
Documentation/networking/ixgb.txt Normal file
View File

@@ -0,0 +1,212 @@
Linux* Base Driver for the Intel(R) PRO/10GbE Family of Adapters
================================================================
November 17, 2004
Contents
========
- In This Release
- Identifying Your Adapter
- Command Line Parameters
- Improving Performance
- Support
In This Release
===============
This file describes the Linux* Base Driver for the Intel(R) PRO/10GbE Family
of Adapters, version 1.0.x.
For questions related to hardware requirements, refer to the documentation
supplied with your Intel PRO/10GbE adapter. All hardware requirements listed
apply to use with Linux.
Identifying Your Adapter
========================
To verify your Intel adapter is supported, find the board ID number on the
adapter. Look for a label that has a barcode and a number in the format
A12345-001.
Use the above information and the Adapter & Driver ID Guide at:
http://support.intel.com/support/network/adapter/pro100/21397.htm
For the latest Intel network drivers for Linux, go to:
http://downloadfinder.intel.com/scripts-df/support_intel.asp
Command Line Parameters
=======================
If the driver is built as a module, the following optional parameters are
used by entering them on the command line with the modprobe or insmod command
using this syntax:
modprobe ixgb [<option>=<VAL1>,<VAL2>,...]
insmod ixgb [<option>=<VAL1>,<VAL2>,...]
For example, with two PRO/10GbE PCI adapters, entering:
insmod ixgb TxDescriptors=80,128
loads the ixgb driver with 80 TX resources for the first adapter and 128 TX
resources for the second adapter.
The default value for each parameter is generally the recommended setting,
unless otherwise noted. Also, if the driver is statically built into the
kernel, the driver is loaded with the default values for all the parameters.
Ethtool can be used to change some of the parameters at runtime.
FlowControl
Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx)
Default: Read from the EEPROM
If EEPROM is not detected, default is 3
This parameter controls the automatic generation(Tx) and response(Rx) to
Ethernet PAUSE frames.
RxDescriptors
Valid Range: 64-512
Default Value: 512
This value is the number of receive descriptors allocated by the driver.
Increasing this value allows the driver to buffer more incoming packets.
Each descriptor is 16 bytes. A receive buffer is also allocated for
each descriptor and can be either 2048, 4056, 8192, or 16384 bytes,
depending on the MTU setting. When the MTU size is 1500 or less, the
receive buffer size is 2048 bytes. When the MTU is greater than 1500 the
receive buffer size will be either 4056, 8192, or 16384 bytes. The
maximum MTU size is 16114.
RxIntDelay
Valid Range: 0-65535 (0=off)
Default Value: 6
This value delays the generation of receive interrupts in units of
0.8192 microseconds. Receive interrupt reduction can improve CPU
efficiency if properly tuned for specific network traffic. Increasing
this value adds extra latency to frame reception and can end up
decreasing the throughput of TCP traffic. If the system is reporting
dropped receives, this value may be set too high, causing the driver to
run out of available receive descriptors.
TxDescriptors
Valid Range: 64-4096
Default Value: 256
This value is the number of transmit descriptors allocated by the driver.
Increasing this value allows the driver to queue more transmits. Each
descriptor is 16 bytes.
XsumRX
Valid Range: 0-1
Default Value: 1
A value of '1' indicates that the driver should enable IP checksum
offload for received packets (both UDP and TCP) to the adapter hardware.
XsumTX
Valid Range: 0-1
Default Value: 1
A value of '1' indicates that the driver should enable IP checksum
offload for transmitted packets (both UDP and TCP) to the adapter
hardware.
Improving Performance
=====================
With the Intel PRO/10 GbE adapter, the default Linux configuration will very
likely limit the total available throughput artificially. There is a set of
things that when applied together increase the ability of Linux to transmit
and receive data. The following enhancements were originally acquired from
settings published at http://www.spec.org/web99 for various submitted results
using Linux.
NOTE: These changes are only suggestions, and serve as a starting point for
tuning your network performance.
The changes are made in three major ways, listed in order of greatest effect:
- Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen
parameter.
- Use sysctl to modify /proc parameters (essentially kernel tuning)
- Use setpci to modify the MMRBC field in PCI-X configuration space to increase
transmit burst lengths on the bus.
NOTE: setpci modifies the adapter's configuration registers to allow it to read
up to 4k bytes at a time (for transmits). However, for some systems the
behavior after modifying this register may be undefined (possibly errors of some
kind). A power-cycle, hard reset or explicitly setting the e6 register back to
22 (setpci -d 8086:1048 e6.b=22) may be required to get back to a stable
configuration.
- COPY these lines and paste them into ixgb_perf.sh:
#!/bin/bash
echo "configuring network performance , edit this file to change the interface"
# set mmrbc to 4k reads, modify only Intel 10GbE device IDs
setpci -d 8086:1048 e6.b=2e
# set the MTU (max transmission unit) - it requires your switch and clients to change too!
# set the txqueuelen
# your ixgb adapter should be loaded as eth1 for this to work, change if needed
ifconfig eth1 mtu 9000 txqueuelen 1000 up
# call the sysctl utility to modify /proc/sys entries
sysctl -p ./sysctl_ixgb.conf
- END ixgb_perf.sh
- COPY these lines and paste them into sysctl_ixgb.conf:
# some of the defaults may be different for your kernel
# call this file with sysctl -p <this file>
# these are just suggested values that worked well to increase throughput in
# several network benchmark tests, your mileage may vary
### IPV4 specific settings
net.ipv4.tcp_timestamps = 0 # turns TCP timestamp support off, default 1, reduces CPU use
net.ipv4.tcp_sack = 0 # turn SACK support off, default on
# on systems with a VERY fast bus -> memory interface this is the big gainer
net.ipv4.tcp_rmem = 10000000 10000000 10000000 # sets min/default/max TCP read buffer, default 4096 87380 174760
net.ipv4.tcp_wmem = 10000000 10000000 10000000 # sets min/pressure/max TCP write buffer, default 4096 16384 131072
net.ipv4.tcp_mem = 10000000 10000000 10000000 # sets min/pressure/max TCP buffer space, default 31744 32256 32768
### CORE settings (mostly for socket and UDP effect)
net.core.rmem_max = 524287 # maximum receive socket buffer size, default 131071
net.core.wmem_max = 524287 # maximum send socket buffer size, default 131071
net.core.rmem_default = 524287 # default receive socket buffer size, default 65535
net.core.wmem_default = 524287 # default send socket buffer size, default 65535
net.core.optmem_max = 524287 # maximum amount of option memory buffers, default 10240
net.core.netdev_max_backlog = 300000 # number of unprocessed input packets before kernel starts dropping them, default 300
- END sysctl_ixgb.conf
Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface
your ixgb driver is using.
NOTE: Unless these scripts are added to the boot process, these changes will
only last only until the next system reboot.
Resolving Slow UDP Traffic
--------------------------
If your server does not seem to be able to receive UDP traffic as fast as it
can receive TCP traffic, it could be because Linux, by default, does not set
the network stack buffers as large as they need to be to support high UDP
transfer rates. One way to alleviate this problem is to allow more memory to
be used by the IP stack to store incoming data.
For instance, use the commands:
sysctl -w net.core.rmem_max=262143
and
sysctl -w net.core.rmem_default=262143
to increase the read buffer memory max and default to 262143 (256k - 1) from
defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables
will increase the amount of memory used by the network stack for receives, and
can be increased significantly more if necessary for your application.
Support
=======
For general information and support, go to the Intel support website at:
http://support.intel.com
If an issue is identified with the released source code on the supported
kernel with a supported adapter, email the specific information related to
the issue to linux.nics@intel.com.

263
Documentation/networking/lapb-module.txt Normal file
View File

@@ -0,0 +1,263 @@
The Linux LAPB Module Interface 1.3
Jonathan Naylor 29.12.96
Changed (Henner Eisen, 2000-10-29): int return value for data_indication()
The LAPB module will be a separately compiled module for use by any parts of
the Linux operating system that require a LAPB service. This document
defines the interfaces to, and the services provided by this module. The
term module in this context does not imply that the LAPB module is a
separately loadable module, although it may be. The term module is used in
its more standard meaning.
The interface to the LAPB module consists of functions to the module,
callbacks from the module to indicate important state changes, and
structures for getting and setting information about the module.
Structures
----------
Probably the most important structure is the skbuff structure for holding
received and transmitted data, however it is beyond the scope of this
document.
The two LAPB specific structures are the LAPB initialisation structure and
the LAPB parameter structure. These will be defined in a standard header
file, <linux/lapb.h>. The header file <net/lapb.h> is internal to the LAPB
module and is not for use.
LAPB Initialisation Structure
-----------------------------
This structure is used only once, in the call to lapb_register (see below).
It contains information about the device driver that requires the services
of the LAPB module.
struct lapb_register_struct {
void (*connect_confirmation)(int token, int reason);
void (*connect_indication)(int token, int reason);
void (*disconnect_confirmation)(int token, int reason);
void (*disconnect_indication)(int token, int reason);
int (*data_indication)(int token, struct sk_buff *skb);
void (*data_transmit)(int token, struct sk_buff *skb);
};
Each member of this structure corresponds to a function in the device driver
that is called when a particular event in the LAPB module occurs. These will
be described in detail below. If a callback is not required (!!) then a NULL
may be substituted.
LAPB Parameter Structure
------------------------
This structure is used with the lapb_getparms and lapb_setparms functions
(see below). They are used to allow the device driver to get and set the
operational parameters of the LAPB implementation for a given connection.
struct lapb_parms_struct {
unsigned int t1;
unsigned int t1timer;
unsigned int t2;
unsigned int t2timer;
unsigned int n2;
unsigned int n2count;
unsigned int window;
unsigned int state;
unsigned int mode;
};
T1 and T2 are protocol timing parameters and are given in units of 100ms. N2
is the maximum number of tries on the link before it is declared a failure.
The window size is the maximum number of outstanding data packets allowed to
be unacknowledged by the remote end, the value of the window is between 1
and 7 for a standard LAPB link, and between 1 and 127 for an extended LAPB
link.
The mode variable is a bit field used for setting (at present) three values.
The bit fields have the following meanings:
Bit Meaning
0 LAPB operation (0=LAPB_STANDARD 1=LAPB_EXTENDED).
1 [SM]LP operation (0=LAPB_SLP 1=LAPB=MLP).
2 DTE/DCE operation (0=LAPB_DTE 1=LAPB_DCE)
3-31 Reserved, must be 0.
Extended LAPB operation indicates the use of extended sequence numbers and
consequently larger window sizes, the default is standard LAPB operation.
MLP operation is the same as SLP operation except that the addresses used by
LAPB are different to indicate the mode of operation, the default is Single
Link Procedure. The difference between DCE and DTE operation is (i) the
addresses used for commands and responses, and (ii) when the DCE is not
connected, it sends DM without polls set, every T1. The upper case constant
names will be defined in the public LAPB header file.
Functions
---------
The LAPB module provides a number of function entry points.
int lapb_register(void *token, struct lapb_register_struct);
This must be called before the LAPB module may be used. If the call is
successful then LAPB_OK is returned. The token must be a unique identifier
generated by the device driver to allow for the unique identification of the
instance of the LAPB link. It is returned by the LAPB module in all of the
callbacks, and is used by the device driver in all calls to the LAPB module.
For multiple LAPB links in a single device driver, multiple calls to
lapb_register must be made. The format of the lapb_register_struct is given
above. The return values are:
LAPB_OK LAPB registered successfully.
LAPB_BADTOKEN Token is already registered.
LAPB_NOMEM Out of memory
int lapb_unregister(void *token);
This releases all the resources associated with a LAPB link. Any current
LAPB link will be abandoned without further messages being passed. After
this call, the value of token is no longer valid for any calls to the LAPB
function. The valid return values are:
LAPB_OK LAPB unregistered successfully.
LAPB_BADTOKEN Invalid/unknown LAPB token.
int lapb_getparms(void *token, struct lapb_parms_struct *parms);
This allows the device driver to get the values of the current LAPB
variables, the lapb_parms_struct is described above. The valid return values
are:
LAPB_OK LAPB getparms was successful.
LAPB_BADTOKEN Invalid/unknown LAPB token.
int lapb_setparms(void *token, struct lapb_parms_struct *parms);
This allows the device driver to set the values of the current LAPB
variables, the lapb_parms_struct is described above. The values of t1timer,
t2timer and n2count are ignored, likewise changing the mode bits when
connected will be ignored. An error implies that none of the values have
been changed. The valid return values are:
LAPB_OK LAPB getparms was successful.
LAPB_BADTOKEN Invalid/unknown LAPB token.
LAPB_INVALUE One of the values was out of its allowable range.
int lapb_connect_request(void *token);
Initiate a connect using the current parameter settings. The valid return
values are:
LAPB_OK LAPB is starting to connect.
LAPB_BADTOKEN Invalid/unknown LAPB token.
LAPB_CONNECTED LAPB module is already connected.
int lapb_disconnect_request(void *token);
Initiate a disconnect. The valid return values are:
LAPB_OK LAPB is starting to disconnect.
LAPB_BADTOKEN Invalid/unknown LAPB token.
LAPB_NOTCONNECTED LAPB module is not connected.
int lapb_data_request(void *token, struct sk_buff *skb);
Queue data with the LAPB module for transmitting over the link. If the call
is successful then the skbuff is owned by the LAPB module and may not be
used by the device driver again. The valid return values are:
LAPB_OK LAPB has accepted the data.
LAPB_BADTOKEN Invalid/unknown LAPB token.
LAPB_NOTCONNECTED LAPB module is not connected.
int lapb_data_received(void *token, struct sk_buff *skb);
Queue data with the LAPB module which has been received from the device. It
is expected that the data passed to the LAPB module has skb->data pointing
to the beginning of the LAPB data. If the call is successful then the skbuff
is owned by the LAPB module and may not be used by the device driver again.
The valid return values are:
LAPB_OK LAPB has accepted the data.
LAPB_BADTOKEN Invalid/unknown LAPB token.
Callbacks
---------
These callbacks are functions provided by the device driver for the LAPB
module to call when an event occurs. They are registered with the LAPB
module with lapb_register (see above) in the structure lapb_register_struct
(see above).
void (*connect_confirmation)(void *token, int reason);
This is called by the LAPB module when a connection is established after
being requested by a call to lapb_connect_request (see above). The reason is
always LAPB_OK.
void (*connect_indication)(void *token, int reason);
This is called by the LAPB module when the link is established by the remote
system. The value of reason is always LAPB_OK.
void (*disconnect_confirmation)(void *token, int reason);
This is called by the LAPB module when an event occurs after the device
driver has called lapb_disconnect_request (see above). The reason indicates
what has happened. In all cases the LAPB link can be regarded as being
terminated. The values for reason are:
LAPB_OK The LAPB link was terminated normally.
LAPB_NOTCONNECTED The remote system was not connected.
LAPB_TIMEDOUT No response was received in N2 tries from the remote
system.
void (*disconnect_indication)(void *token, int reason);
This is called by the LAPB module when the link is terminated by the remote
system or another event has occurred to terminate the link. This may be
returned in response to a lapb_connect_request (see above) if the remote
system refused the request. The values for reason are:
LAPB_OK The LAPB link was terminated normally by the remote
system.
LAPB_REFUSED The remote system refused the connect request.
LAPB_NOTCONNECTED The remote system was not connected.
LAPB_TIMEDOUT No response was received in N2 tries from the remote
system.
int (*data_indication)(void *token, struct sk_buff *skb);
This is called by the LAPB module when data has been received from the
remote system that should be passed onto the next layer in the protocol
stack. The skbuff becomes the property of the device driver and the LAPB
module will not perform any more actions on it. The skb->data pointer will
be pointing to the first byte of data after the LAPB header.
This method should return NET_RX_DROP (as defined in the header
file include/linux/netdevice.h) if and only if the frame was dropped
before it could be delivered to the upper layer.
void (*data_transmit)(void *token, struct sk_buff *skb);
This is called by the LAPB module when data is to be transmitted to the
remote system by the device driver. The skbuff becomes the property of the
device driver and the LAPB module will not perform any more actions on it.
The skb->data pointer will be pointing to the first byte of the LAPB header.

131
Documentation/networking/ltpc.txt Normal file
View File

@@ -0,0 +1,131 @@
This is the ALPHA version of the ltpc driver.
In order to use it, you will need at least version 1.3.3 of the
netatalk package, and the Apple or Farallon LocalTalk PC card.
There are a number of different LocalTalk cards for the PC; this
driver applies only to the one with the 65c02 processor chip on it.
To include it in the kernel, select the CONFIG_LTPC switch in the
configuration dialog. You can also compile it as a module.
While the driver will attempt to autoprobe the I/O port address, IRQ
line, and DMA channel of the card, this does not always work. For
this reason, you should be prepared to supply these parameters
yourself. (see "Card Configuration" below for how to determine or
change the settings on your card)
When the driver is compiled into the kernel, you can add a line such
as the following to your /etc/lilo.conf:
append="ltpc=0x240,9,1"
where the parameters (in order) are the port address, IRQ, and DMA
channel. The second and third values can be omitted, in which case
the driver will try to determine them itself.
If you load the driver as a module, you can pass the parameters "io=",
"irq=", and "dma=" on the command line with insmod or modprobe, or add
them as options in /etc/modprobe.conf:
alias lt0 ltpc # autoload the module when the interface is configured
options ltpc io=0x240 irq=9 dma=1
Before starting up the netatalk demons (perhaps in rc.local), you
need to add a line such as:
/sbin/ifconfig lt0 127.0.0.42
The address is unimportant - however, the card needs to be configured
with ifconfig so that Netatalk can find it.
The appropriate netatalk configuration depends on whether you are
attached to a network that includes AppleTalk routers or not. If,
like me, you are simply connecting to your home Macintoshes and
printers, you need to set up netatalk to "seed". The way I do this
is to have the lines
dummy -seed -phase 2 -net 2000 -addr 2000.26 -zone "1033"
lt0 -seed -phase 1 -net 1033 -addr 1033.27 -zone "1033"
in my atalkd.conf. What is going on here is that I need to fool
netatalk into thinking that there are two AppleTalk interfaces
present; otherwise, it refuses to seed. This is a hack, and a more
permanent solution would be to alter the netatalk code. Also, make
sure you have the correct name for the dummy interface - If it's
compiled as a module, you will need to refer to it as "dummy0" or some
such.
If you are attached to an extended AppleTalk network, with routers on
it, then you don't need to fool around with this -- the appropriate
line in atalkd.conf is
lt0 -phase 1
--------------------------------------
Card Configuration:
The interrupts and so forth are configured via the dipswitch on the
board. Set the switches so as not to conflict with other hardware.
Interrupts -- set at most one. If none are set, the driver uses
polled mode. Because the card was developed in the XT era, the
original documentation refers to IRQ2. Since you'll be running
this on an AT (or later) class machine, that really means IRQ9.
SW1 IRQ 4
SW2 IRQ 3
SW3 IRQ 9 (2 in original card documentation only applies to XT)
DMA -- choose DMA 1 or 3, and set both corresponding switches.
SW4 DMA 3
SW5 DMA 1
SW6 DMA 3
SW7 DMA 1
I/O address -- choose one.
SW8 220 / 240
--------------------------------------
IP:
Yes, it is possible to do IP over LocalTalk. However, you can't just
treat the LocalTalk device like an ordinary Ethernet device, even if
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
kernel driver and userspace tools needed.
--------------------------------------
BUGS:
IRQ autoprobing often doesn't work on a cold boot. To get around
this, either compile the driver as a module, or pass the parameters
for the card to the kernel as described above.
Also, as usual, autoprobing is not recommended when you use the driver
as a module. (though it usually works at boot time, at least)
Polled mode is *really* slow sometimes, but this seems to depend on
the configuration of the network.
It may theoretically be possible to use two LTPC cards in the same
machine, but this is unsupported, so if you really want to do this,
you'll probably have to hack the initialization code a bit.
______________________________________
THANKS:
Thanks to Alan Cox for helpful discussions early on in this
work, and to Denis Hainsworth for doing the bleeding-edge testing.
-- Bradford Johnson <bradford@math.umn.edu>
-- Updated 11/09/1998 by David Huggins-Daines <dhd@debian.org>

63
Documentation/networking/multicast.txt Normal file
View File

@@ -0,0 +1,63 @@
Behaviour of Cards Under Multicast
==================================
This is how they currently behave, not what the hardware can do--for example,
the Lance driver doesn't use its filter, even though the code for loading
it is in the DEC Lance-based driver.
The following are requirements for multicasting
-----------------------------------------------
AppleTalk Multicast hardware filtering not important but
avoid cards only doing promisc
IP-Multicast Multicast hardware filters really help
IP-MRoute AllMulti hardware filters are of no help
Board Multicast AllMulti Promisc Filter
------------------------------------------------------------------------
3c501 YES YES YES Software
3c503 YES YES YES Hardware
3c505 YES NO YES Hardware
3c507 NO NO NO N/A
3c509 YES YES YES Software
3c59x YES YES YES Software
ac3200 YES YES YES Hardware
apricot YES PROMISC YES Hardware
arcnet NO NO NO N/A
at1700 PROMISC PROMISC YES Software
atp PROMISC PROMISC YES Software
cs89x0 YES YES YES Software
de4x5 YES YES YES Hardware
de600 NO NO NO N/A
de620 PROMISC PROMISC YES Software
depca YES PROMISC YES Hardware
dmfe YES YES YES Software(*)
e2100 YES YES YES Hardware
eepro YES PROMISC YES Hardware
eexpress NO NO NO N/A
ewrk3 YES PROMISC YES Hardware
hp-plus YES YES YES Hardware
hp YES YES YES Hardware
hp100 YES YES YES Hardware
ibmtr NO NO NO N/A
ioc3-eth YES YES YES Hardware
lance YES YES YES Software(#)
ne YES YES YES Hardware
ni52 <------------------ Buggy ------------------>
ni65 YES YES YES Software(#)
seeq NO NO NO N/A
sgiseek <------------------ Buggy ------------------>
smc-ultra YES YES YES Hardware
sunlance YES YES YES Hardware
tulip YES YES YES Hardware
wavelan YES PROMISC YES Hardware
wd YES YES YES Hardware
xirc2ps_cs YES YES YES Hardware
znet YES YES YES Software
PROMISC = This multicast mode is in fact promiscuous mode. Avoid using
cards who go PROMISC on any multicast in a multicast kernel.
(#) = Hardware multicast support is not used yet.
(*) = Hardware support for Davicom 9132 chipset only.

16
Documentation/networking/ncsa-telnet Normal file
View File

@@ -0,0 +1,16 @@
NCSA telnet doesn't work with path MTU discovery enabled. This is due to a
bug in NCSA that also stops it working with other modern networking code
such as Solaris.
The following information is courtesy of
Marek <marekm@i17linuxb.ists.pwr.wroc.pl>
There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
remember the exact pathname, and this site is very slow from here).
It may or may not be faster for you to get it from
ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
(source is in v230704s.zip). I have tested it with 1.3.79 (with
path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
to work. I don't know if anyone is working on this code - this
version is over a year old. Too bad - it's faster and often more
stable than these windoze telnets, and runs on almost anything...

321
Documentation/networking/net-modules.txt Normal file
View File

@@ -0,0 +1,321 @@
Wed 2-Aug-95 <matti.aarnio@utu.fi>
Linux network driver modules
Do not mistake this for "README.modules" at the top-level
directory! That document tells about modules in general, while
this one tells only about network device driver modules.
This is a potpourri of INSMOD-time(*) configuration options
(if such exists) and their default values of various modules
in the Linux network drivers collection.
Some modules have also hidden (= non-documented) tunable values.
The choice of not documenting them is based on general belief, that
the less the user needs to know, the better. (There are things that
driver developers can use, others should not confuse themselves.)
In many cases it is highly preferred that insmod:ing is done
ONLY with defining an explicit address for the card, AND BY
NOT USING AUTO-PROBING!
Now most cards have some explicitly defined base address that they
are compiled with (to avoid auto-probing, among other things).
If that compiled value does not match your actual configuration,
do use the "io=0xXXX" -parameter for the insmod, and give there
a value matching your environment.
If you are adventurous, you can ask the driver to autoprobe
by using the "io=0" parameter, however it is a potentially dangerous
thing to do in a live system. (If you don't know where the
card is located, you can try autoprobing, and after possible
crash recovery, insmod with proper IO-address..)
--------------------------
(*) "INSMOD-time" means when you load module with
/sbin/insmod you can feed it optional parameters.
See "man insmod".
--------------------------
8390 based Network Modules (Paul Gortmaker, Nov 12, 1995)
--------------------------
(Includes: smc-ultra, ne, wd, 3c503, hp, hp-plus, e2100 and ac3200)
The 8390 series of network drivers now support multiple card systems without
reloading the same module multiple times (memory efficient!) This is done by
specifying multiple comma separated values, such as:
insmod 3c503.o io=0x280,0x300,0x330,0x350 xcvr=0,1,0,1
The above would have the one module controlling four 3c503 cards, with card 2
and 4 using external transceivers. The "insmod" manual describes the usage
of comma separated value lists.
It is *STRONGLY RECOMMENDED* that you supply "io=" instead of autoprobing.
If an "io=" argument is not supplied, then the ISA drivers will complain
about autoprobing being not recommended, and begrudgingly autoprobe for
a *SINGLE CARD ONLY* -- if you want to use multiple cards you *have* to
supply an "io=0xNNN,0xQQQ,..." argument.
The ne module is an exception to the above. A NE2000 is essentially an
8390 chip, some bus glue and some RAM. Because of this, the ne probe is
more invasive than the rest, and so at boot we make sure the ne probe is
done last of all the 8390 cards (so that it won't trip over other 8390 based
cards) With modules we can't ensure that all other non-ne 8390 cards have
already been found. Because of this, the ne module REQUIRES an "io=0xNNN"
argument passed in via insmod. It will refuse to autoprobe.
It is also worth noting that auto-IRQ probably isn't as reliable during
the flurry of interrupt activity on a running machine. Cards such as the
ne2000 that can't get the IRQ setting from an EEPROM or configuration
register are probably best supplied with an "irq=M" argument as well.
----------------------------------------------------------------------
Card/Module List - Configurable Parameters and Default Values
----------------------------------------------------------------------
3c501.c:
io = 0x280 IO base address
irq = 5 IRQ
(Probes ports: 0x280, 0x300)
3c503.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ software selected by driver using autoIRQ)
xcvr = 0 (Use xcvr=1 to select external transceiver.)
(Probes ports: 0x300, 0x310, 0x330, 0x350, 0x250, 0x280, 0x2A0, 0x2E0)
3c505.c:
io = 0
irq = 0
dma = 6 (not autoprobed)
(Probes ports: 0x300, 0x280, 0x310)
3c507.c:
io = 0x300
irq = 0
(Probes ports: 0x300, 0x320, 0x340, 0x280)
3c509.c:
io = 0
irq = 0
( Module load-time probing Works reliably only on EISA, ISA ID-PROBE
IS NOT RELIABLE! Compile this driver statically into kernel for
now, if you need it auto-probing on an ISA-bus machine. )
8390.c:
(No public options, several other modules need this one)
a2065.c:
Since this is a Zorro board, it supports full autoprobing, even for
multiple boards. (m68k/Amiga)
ac3200.c:
io = 0 (Checks 0x1000 to 0x8fff in 0x1000 intervals)
irq = 0 (Read from config register)
(EISA probing..)
apricot.c:
io = 0x300 (Can't be altered!)
irq = 10
arcnet.c:
io = 0
irqnum = 0
shmem = 0
num = 0
DO SET THESE MANUALLY AT INSMOD!
(When probing, looks at the following possible addresses:
Suggested ones:
0x300, 0x2E0, 0x2F0, 0x2D0
Other ones:
0x200, 0x210, 0x220, 0x230, 0x240, 0x250, 0x260, 0x270,
0x280, 0x290, 0x2A0, 0x2B0, 0x2C0,
0x310, 0x320, 0x330, 0x340, 0x350, 0x360, 0x370,
0x380, 0x390, 0x3A0, 0x3E0, 0x3F0 )
ariadne.c:
Since this is a Zorro board, it supports full autoprobing, even for
multiple boards. (m68k/Amiga)
at1700.c:
io = 0x260
irq = 0
(Probes ports: 0x260, 0x280, 0x2A0, 0x240, 0x340, 0x320, 0x380, 0x300)
atari_bionet.c:
Supports full autoprobing. (m68k/Atari)
atari_pamsnet.c:
Supports full autoprobing. (m68k/Atari)
atarilance.c:
Supports full autoprobing. (m68k/Atari)
atp.c: *Not modularized*
(Probes ports: 0x378, 0x278, 0x3BC;
fixed IRQs: 5 and 7 )
cops.c:
io = 0x240
irq = 5
nodeid = 0 (AutoSelect = 0, NodeID 1-254 is hand selected.)
(Probes ports: 0x240, 0x340, 0x200, 0x210, 0x220, 0x230, 0x260,
0x2A0, 0x300, 0x310, 0x320, 0x330, 0x350, 0x360)
de4x5.c:
io = 0x000b
irq = 10
is_not_dec = 0 -- For non-DEC card using DEC 21040/21041/21140 chip, set this to 1
(EISA, and PCI probing)
de600.c:
de600_debug = 0
(On port 0x378, irq 7 -- lpt1; compile time configurable)
de620.c:
bnc = 0, utp = 0 <-- Force media by setting either.
io = 0x378 (also compile-time configurable)
irq = 7
depca.c:
io = 0x200
irq = 7
(Probes ports: ISA: 0x300, 0x200;
EISA: 0x0c00 )
dummy.c:
No options
e2100.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ software selected by driver)
mem = 0 (Override default shared memory start of 0xd0000)
xcvr = 0 (Use xcvr=1 to select external transceiver.)
(Probes ports: 0x300, 0x280, 0x380, 0x220)
eepro.c:
io = 0x200
irq = 0
(Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340, 0x360)
eexpress.c:
io = 0x300
irq = 0 (IRQ value read from EEPROM)
(Probes ports: 0x300, 0x270, 0x320, 0x340)
eql.c:
(No parameters)
ewrk3.c:
io = 0x300
irq = 5
(With module no autoprobing!
On EISA-bus does EISA probing.
Static linkage probes ports on ISA bus:
0x100, 0x120, 0x140, 0x160, 0x180, 0x1A0, 0x1C0,
0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0,
0x300, 0x340, 0x360, 0x380, 0x3A0, 0x3C0)
hp-plus.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ read from configuration register)
(Probes ports: 0x200, 0x240, 0x280, 0x2C0, 0x300, 0x320, 0x340)
hp.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ software selected by driver using autoIRQ)
(Probes ports: 0x300, 0x320, 0x340, 0x280, 0x2C0, 0x200, 0x240)
hp100.c:
hp100_port = 0 (IO-base address)
(Does EISA-probing, if on EISA-slot;
On ISA-bus probes all ports from 0x100 thru to 0x3E0
in increments of 0x020)
hydra.c:
Since this is a Zorro board, it supports full autoprobing, even for
multiple boards. (m68k/Amiga)
ibmtr.c:
io = 0xa20, 0xa24 (autoprobed by default)
irq = 0 (driver cannot select irq - read from hardware)
mem = 0 (shared memory base set at 0xd0000 and not yet
able to override thru mem= parameter.)
lance.c: *Not modularized*
(PCI, and ISA probing; "CONFIG_PCI" needed for PCI support)
(Probes ISA ports: 0x300, 0x320, 0x340, 0x360)
loopback.c: *Static kernel component*
ne.c:
io = 0 (Explicitly *requires* an "io=0xNNN" value)
irq = 0 (Tries to determine configured IRQ via autoIRQ)
(Probes ports: 0x300, 0x280, 0x320, 0x340, 0x360)
net_init.c: *Static kernel component*
ni52.c: *Not modularized*
(Probes ports: 0x300, 0x280, 0x360, 0x320, 0x340
mems: 0xD0000, 0xD2000, 0xC8000, 0xCA000,
0xD4000, 0xD6000, 0xD8000 )
ni65.c: *Not modularized* **16MB MEMORY BARRIER BUG**
(Probes ports: 0x300, 0x320, 0x340, 0x360)
pi2.c: *Not modularized* (well, NON-STANDARD modularization!)
Only one card supported at this time.
(Probes ports: 0x380, 0x300, 0x320, 0x340, 0x360, 0x3A0)
plip.c:
io = 0
irq = 0 (by default, uses IRQ 5 for port at 0x3bc, IRQ 7
for port at 0x378, and IRQ 2 for port at 0x278)
(Probes ports: 0x278, 0x378, 0x3bc)
ppp.c:
No options (ppp-2.2+ has some, this is based on non-dynamic
version from ppp-2.1.2d)
seeq8005.c: *Not modularized*
(Probes ports: 0x300, 0x320, 0x340, 0x360)
skeleton.c: *Skeleton*
slhc.c:
No configuration parameters
slip.c:
slip_maxdev = 256 (default value from SL_NRUNIT on slip.h)
smc-ultra.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ val. read from EEPROM)
(Probes ports: 0x200, 0x220, 0x240, 0x280, 0x300, 0x340, 0x380)
tulip.c: *Partial modularization*
(init-time memory allocation makes problems..)
tunnel.c:
No insmod parameters
wavelan.c:
io = 0x390 (Settable, but change not recommended)
irq = 0 (Not honoured, if changed..)
wd.c:
io = 0 (It will complain if you don't supply an "io=0xNNN")
irq = 0 (IRQ val. read from EEPROM, ancient cards use autoIRQ)
mem = 0 (Force shared-memory on address 0xC8000, or whatever..)
mem_end = 0 (Force non-std. mem. size via supplying mem_end val.)
(eg. for 32k WD8003EBT, use mem=0xd0000 mem_end=0xd8000)
(Probes ports: 0x300, 0x280, 0x380, 0x240)
znet.c: *Not modularized*
(Only one device on Zenith Z-Note (notebook?) systems,
configuration information from (EE)PROM)

57
Documentation/networking/netconsole.txt Normal file
View File

@@ -0,0 +1,57 @@
started by Ingo Molnar <mingo@redhat.com>, 2001.09.17
2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003
Please send bug reports to Matt Mackall <mpm@selenic.com>
This module logs kernel printk messages over UDP allowing debugging of
problem where disk logging fails and serial consoles are impractical.
It can be used either built-in or as a module. As a built-in,
netconsole initializes immediately after NIC cards and will bring up
the specified interface as soon as possible. While this doesn't allow
capture of early kernel panics, it does capture most of the boot
process.
It takes a string configuration parameter "netconsole" in the
following format:
netconsole=[src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr]
where
src-port source for UDP packets (defaults to 6665)
src-ip source IP to use (interface address)
dev network interface (eth0)
tgt-port port for logging agent (6666)
tgt-ip IP address for logging agent
tgt-macaddr ethernet MAC address for logging agent (broadcast)
Examples:
linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc
or
insmod netconsole netconsole=@/,@10.0.0.2/
Built-in netconsole starts immediately after the TCP stack is
initialized and attempts to bring up the supplied dev at the supplied
address.
The remote host can run either 'netcat -u -l -p <port>' or syslogd.
WARNING: the default target ethernet setting uses the broadcast
ethernet address to send packets, which can cause increased load on
other systems on the same ethernet segment.
NOTE: the network device (eth1 in the above case) can run any kind
of other network traffic, netconsole is not intrusive. Netconsole
might cause slight delays in other traffic if the volume of kernel
messages is high, but should have no other impact.
Netconsole was designed to be as instantaneous as possible, to
enable the logging of even the most critical kernel bugs. It works
from IRQ contexts as well, and does not enable interrupts while
sending packets. Due to these unique needs, configuration cannot
be more automatic, and some fundamental limitations will remain:
only IP networks, UDP packets and ethernet devices are supported.

77
Documentation/networking/netdevices.txt Normal file
View File

@@ -0,0 +1,77 @@
Network Devices, the Kernel, and You!
Introduction
============
The following is a random collection of documentation regarding
network devices.
struct net_device allocation rules
==================================
Network device structures need to persist even after module is unloaded and
must be allocated with kmalloc. If device has registered successfully,
it will be freed on last use by free_netdev. This is required to handle the
pathologic case cleanly (example: rmmod mydriver </sys/class/net/myeth/mtu )
There are routines in net_init.c to handle the common cases of
alloc_etherdev, alloc_netdev. These reserve extra space for driver
private data which gets freed when the network device is freed. If
separately allocated data is attached to the network device
(dev->priv) then it is up to the module exit handler to free that.
struct net_device synchronization rules
=======================================
dev->open:
Synchronization: rtnl_lock() semaphore.
Context: process
dev->stop:
Synchronization: rtnl_lock() semaphore.
Context: process
Note1: netif_running() is guaranteed false
Note2: dev->poll() is guaranteed to be stopped
dev->do_ioctl:
Synchronization: rtnl_lock() semaphore.
Context: process
dev->get_stats:
Synchronization: dev_base_lock rwlock.
Context: nominally process, but don't sleep inside an rwlock
dev->hard_start_xmit:
Synchronization: netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev->features this will be
called without holding netif_tx_lock. In this case the driver
has to lock by itself when needed. It is recommended to use a try lock
for this and return -1 when the spin lock fails.
The locking there should also properly protect against
set_multicast_list
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed false
Interrupts must be enabled when calling hard_start_xmit.
(Interrupts must also be enabled when enabling the BH handler.)
Return codes:
o NETDEV_TX_OK everything ok.
o NETDEV_TX_BUSY Cannot transmit packet, try later
Usually a bug, means queue start/stop flow control is broken in
the driver. Note: the driver must NOT put the skb in its DMA ring.
o NETDEV_TX_LOCKED Locking failed, please retry quickly.
Only valid when NETIF_F_LLTX is set.
dev->tx_timeout:
Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
dev->set_multicast_list:
Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
dev->poll:
Synchronization: __LINK_STATE_RX_SCHED bit in dev->state. See
dev_close code and comments in net/core/dev.c for more info.
Context: softirq

79
Documentation/networking/netif-msg.txt Normal file
View File

@@ -0,0 +1,79 @@
________________
NETIF Msg Level
The design of the network interface message level setting.
History
The design of the debugging message interface was guided and
constrained by backwards compatibility previous practice. It is useful
to understand the history and evolution in order to understand current
practice and relate it to older driver source code.
From the beginning of Linux, each network device driver has had a local
integer variable that controls the debug message level. The message
level ranged from 0 to 7, and monotonically increased in verbosity.
The message level was not precisely defined past level 3, but were
always implemented within +-1 of the specified level. Drivers tended
to shed the more verbose level messages as they matured.
0 Minimal messages, only essential information on fatal errors.
1 Standard messages, initialization status. No run-time messages
2 Special media selection messages, generally timer-driver.
3 Interface starts and stops, including normal status messages
4 Tx and Rx frame error messages, and abnormal driver operation
5 Tx packet queue information, interrupt events.
6 Status on each completed Tx packet and received Rx packets
7 Initial contents of Tx and Rx packets
Initially this message level variable was uniquely named in each driver
e.g. "lance_debug", so that a kernel symbolic debugger could locate and
modify the setting. When kernel modules became common, the variables
were consistently renamed to "debug" and allowed to be set as a module
parameter.
This approach worked well. However there is always a demand for
additional features. Over the years the following emerged as
reasonable and easily implemented enhancements
Using an ioctl() call to modify the level.
Per-interface rather than per-driver message level setting.
More selective control over the type of messages emitted.
The netif_msg recommendation adds these features with only a minor
complexity and code size increase.
The recommendation is the following points
Retaining the per-driver integer variable "debug" as a module
parameter with a default level of '1'.
Adding a per-interface private variable named "msg_enable". The
variable is a bit map rather than a level, and is initialized as
1 << debug
Or more precisely
debug < 0 ? 0 : 1 << min(sizeof(int)-1, debug)
Messages should changes from
if (debug > 1)
printk(MSG_DEBUG "%s: ...
to
if (np->msg_enable & NETIF_MSG_LINK)
printk(MSG_DEBUG "%s: ...
The set of message levels is named
Old level Name Bit position
0 NETIF_MSG_DRV 0x0001
1 NETIF_MSG_PROBE 0x0002
2 NETIF_MSG_LINK 0x0004
2 NETIF_MSG_TIMER 0x0004
3 NETIF_MSG_IFDOWN 0x0008
3 NETIF_MSG_IFUP 0x0008
4 NETIF_MSG_RX_ERR 0x0010
4 NETIF_MSG_TX_ERR 0x0010
5 NETIF_MSG_TX_QUEUED 0x0020
5 NETIF_MSG_INTR 0x0020
6 NETIF_MSG_TX_DONE 0x0040
6 NETIF_MSG_RX_STATUS 0x0040
7 NETIF_MSG_PKTDATA 0x0080

79
Documentation/networking/olympic.txt Normal file
View File

@@ -0,0 +1,79 @@
IBM PCI Pit/Pit-Phy/Olympic CHIPSET BASED TOKEN RING CARDS README
Release 0.2.0 - Release
June 8th 1999 Peter De Schrijver & Mike Phillips
Release 0.9.C - Release
April 18th 2001 Mike Phillips
Thanks:
Erik De Cock, Adrian Bridgett and Frank Fiene for their
patience and testing.
Donald Champion for the cardbus support
Kyle Lucke for the dma api changes.
Jonathon Bitner for hardware support.
Everybody on linux-tr for their continued support.
Options:
The driver accepts four options: ringspeed, pkt_buf_sz,
message_level and network_monitor.
These options can be specified differently for each card found.
ringspeed: Has one of three settings 0 (default), 4 or 16. 0 will
make the card autosense the ringspeed and join at the appropriate speed,
this will be the default option for most people. 4 or 16 allow you to
explicitly force the card to operate at a certain speed. The card will fail
if you try to insert it at the wrong speed. (Although some hubs will allow
this so be *very* careful). The main purpose for explicitly setting the ring
speed is for when the card is first on the ring. In autosense mode, if the card
cannot detect any active monitors on the ring it will not open, so you must
re-init the card at the appropriate speed. Unfortunately at present the only
way of doing this is rmmod and insmod which is a bit tough if it is compiled
in the kernel.
pkt_buf_sz: This is this initial receive buffer allocation size. This will
default to 4096 if no value is entered. You may increase performance of the
driver by setting this to a value larger than the network packet size, although
the driver now re-sizes buffers based on MTU settings as well.
message_level: Controls level of messages created by the driver. Defaults to 0:
which only displays start-up and critical messages. Presently any non-zero
value will display all soft messages as well. NB This does not turn
debugging messages on, that must be done by modified the source code.
network_monitor: Any non-zero value will provide a quasi network monitoring
mode. All unexpected MAC frames (beaconing etc.) will be received
by the driver and the source and destination addresses printed.
Also an entry will be added in /proc/net called olympic_tr%d, where tr%d
is the registered device name, i.e tr0, tr1, etc. This displays low
level information about the configuration of the ring and the adapter.
This feature has been designed for network administrators to assist in
the diagnosis of network / ring problems. (This used to OLYMPIC_NETWORK_MONITOR,
but has now changed to allow each adapter to be configured differently and
to alleviate the necessity to re-compile olympic to turn the option on).
Multi-card:
The driver will detect multiple cards and will work with shared interrupts,
each card is assigned the next token ring device, i.e. tr0 , tr1, tr2. The
driver should also happily reside in the system with other drivers. It has
been tested with ibmtr.c running, and I personally have had one Olicom PCI
card and two IBM olympic cards (all on the same interrupt), all running
together.
Variable MTU size:
The driver can handle a MTU size upto either 4500 or 18000 depending upon
ring speed. The driver also changes the size of the receive buffers as part
of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring
position = 296,000 bytes of memory space, plus of course anything
necessary for the tx sk_buff's. Remember this is per card, so if you are
building routers, gateway's etc, you could start to use a lot of memory
real fast.
6/8/99 Peter De Schrijver and Mike Phillips

161
Documentation/networking/operstates.txt Normal file
View File

@@ -0,0 +1,161 @@
1. Introduction
Linux distinguishes between administrative and operational state of an
interface. Administrative state is the result of "ip link set dev
<dev> up or down" and reflects whether the administrator wants to use
the device for traffic.
However, an interface is not usable just because the admin enabled it
- ethernet requires to be plugged into the switch and, depending on
a site's networking policy and configuration, an 802.1X authentication
to be performed before user data can be transferred. Operational state
shows the ability of an interface to transmit this user data.
Thanks to 802.1X, userspace must be granted the possibility to
influence operational state. To accommodate this, operational state is
split into two parts: Two flags that can be set by the driver only, and
a RFC2863 compatible state that is derived from these flags, a policy,
and changeable from userspace under certain rules.
2. Querying from userspace
Both admin and operational state can be queried via the netlink
operation RTM_GETLINK. It is also possible to subscribe to RTMGRP_LINK
to be notified of updates. This is important for setting from userspace.
These values contain interface state:
ifinfomsg::if_flags & IFF_UP:
Interface is admin up
ifinfomsg::if_flags & IFF_RUNNING:
Interface is in RFC2863 operational state UP or UNKNOWN. This is for
backward compatibility, routing daemons, dhcp clients can use this
flag to determine whether they should use the interface.
ifinfomsg::if_flags & IFF_LOWER_UP:
Driver has signaled netif_carrier_on()
ifinfomsg::if_flags & IFF_DORMANT:
Driver has signaled netif_dormant_on()
These interface flags can also be queried without netlink using the
SIOCGIFFLAGS ioctl.
TLV IFLA_OPERSTATE
contains RFC2863 state of the interface in numeric representation:
IF_OPER_UNKNOWN (0):
Interface is in unknown state, neither driver nor userspace has set
operational state. Interface must be considered for user data as
setting operational state has not been implemented in every driver.
IF_OPER_NOTPRESENT (1):
Unused in current kernel (notpresent interfaces normally disappear),
just a numerical placeholder.
IF_OPER_DOWN (2):
Interface is unable to transfer data on L1, f.e. ethernet is not
plugged or interface is ADMIN down.
IF_OPER_LOWERLAYERDOWN (3):
Interfaces stacked on an interface that is IF_OPER_DOWN show this
state (f.e. VLAN).
IF_OPER_TESTING (4):
Unused in current kernel.
IF_OPER_DORMANT (5):
Interface is L1 up, but waiting for an external event, f.e. for a
protocol to establish. (802.1X)
IF_OPER_UP (6):
Interface is operational up and can be used.
This TLV can also be queried via sysfs.
TLV IFLA_LINKMODE
contains link policy. This is needed for userspace interaction
described below.
This TLV can also be queried via sysfs.
3. Kernel driver API
Kernel drivers have access to two flags that map to IFF_LOWER_UP and
IFF_DORMANT. These flags can be set from everywhere, even from
interrupts. It is guaranteed that only the driver has write access,
however, if different layers of the driver manipulate the same flag,
the driver has to provide the synchronisation needed.
__LINK_STATE_NOCARRIER, maps to !IFF_LOWER_UP:
The driver uses netif_carrier_on() to clear and netif_carrier_off() to
set this flag. On netif_carrier_off(), the scheduler stops sending
packets. The name 'carrier' and the inversion are historical, think of
it as lower layer.
netif_carrier_ok() can be used to query that bit.
__LINK_STATE_DORMANT, maps to IFF_DORMANT:
Set by the driver to express that the device cannot yet be used
because some driver controlled protocol establishment has to
complete. Corresponding functions are netif_dormant_on() to set the
flag, netif_dormant_off() to clear it and netif_dormant() to query.
On device allocation, networking core sets the flags equivalent to
netif_carrier_ok() and !netif_dormant().
Whenever the driver CHANGES one of these flags, a workqueue event is
scheduled to translate the flag combination to IFLA_OPERSTATE as
follows:
!netif_carrier_ok():
IF_OPER_LOWERLAYERDOWN if the interface is stacked, IF_OPER_DOWN
otherwise. Kernel can recognise stacked interfaces because their
ifindex != iflink.
netif_carrier_ok() && netif_dormant():
IF_OPER_DORMANT
netif_carrier_ok() && !netif_dormant():
IF_OPER_UP if userspace interaction is disabled. Otherwise
IF_OPER_DORMANT with the possibility for userspace to initiate the
IF_OPER_UP transition afterwards.
4. Setting from userspace
Applications have to use the netlink interface to influence the
RFC2863 operational state of an interface. Setting IFLA_LINKMODE to 1
via RTM_SETLINK instructs the kernel that an interface should go to
IF_OPER_DORMANT instead of IF_OPER_UP when the combination
netif_carrier_ok() && !netif_dormant() is set by the
driver. Afterwards, the userspace application can set IFLA_OPERSTATE
to IF_OPER_DORMANT or IF_OPER_UP as long as the driver does not set
netif_carrier_off() or netif_dormant_on(). Changes made by userspace
are multicasted on the netlink group RTMGRP_LINK.
So basically a 802.1X supplicant interacts with the kernel like this:
-subscribe to RTMGRP_LINK
-set IFLA_LINKMODE to 1 via RTM_SETLINK
-query RTM_GETLINK once to get initial state
-if initial flags are not (IFF_LOWER_UP && !IFF_DORMANT), wait until
netlink multicast signals this state
-do 802.1X, eventually abort if flags go down again
-send RTM_SETLINK to set operstate to IF_OPER_UP if authentication
succeeds, IF_OPER_DORMANT otherwise
-see how operstate and IFF_RUNNING is echoed via netlink multicast
-set interface back to IF_OPER_DORMANT if 802.1X reauthentication
fails
-restart if kernel changes IFF_LOWER_UP or IFF_DORMANT flag
if supplicant goes down, bring back IFLA_LINKMODE to 0 and
IFLA_OPERSTATE to a sane value.
A routing daemon or dhcp client just needs to care for IFF_RUNNING or
waiting for operstate to go IF_OPER_UP/IF_OPER_UNKNOWN before
considering the interface / querying a DHCP address.
For technical questions and/or comments please e-mail to Stefan Rompf
(stefan at loplof.de).

399
Documentation/networking/packet_mmap.txt Normal file
View File

@@ -0,0 +1,399 @@
--------------------------------------------------------------------------------
+ ABSTRACT
--------------------------------------------------------------------------------
This file documents the CONFIG_PACKET_MMAP option available with the PACKET
socket interface on 2.4 and 2.6 kernels. This type of sockets is used for
capture network traffic with utilities like tcpdump or any other that uses
the libpcap library.
You can find the latest version of this document at
http://pusa.uv.es/~ulisses/packet_mmap/
Please send me your comments to
Ulisses Alonso Camar<61> <uaca@i.hate.spam.alumni.uv.es>
-------------------------------------------------------------------------------
+ Why use PACKET_MMAP
--------------------------------------------------------------------------------
In Linux 2.4/2.6 if PACKET_MMAP is not enabled, the capture process is very
inefficient. It uses very limited buffers and requires one system call
to capture each packet, it requires two if you want to get packet's
timestamp (like libpcap always does).
In the other hand PACKET_MMAP is very efficient. PACKET_MMAP provides a size
configurable circular buffer mapped in user space. This way reading packets just
needs to wait for them, most of the time there is no need to issue a single
system call. By using a shared buffer between the kernel and the user
also has the benefit of minimizing packet copies.
It's fine to use PACKET_MMAP to improve the performance of the capture process,
but it isn't everything. At least, if you are capturing at high speeds (this
is relative to the cpu speed), you should check if the device driver of your
network interface card supports some sort of interrupt load mitigation or
(even better) if it supports NAPI, also make sure it is enabled.
--------------------------------------------------------------------------------
+ How to use CONFIG_PACKET_MMAP
--------------------------------------------------------------------------------
From the user standpoint, you should use the higher level libpcap library, which
is a de facto standard, portable across nearly all operating systems
including Win32.
Said that, at time of this writing, official libpcap 0.8.1 is out and doesn't include
support for PACKET_MMAP, and also probably the libpcap included in your distribution.
I'm aware of two implementations of PACKET_MMAP in libpcap:
http://pusa.uv.es/~ulisses/packet_mmap/ (by Simon Patarin, based on libpcap 0.6.2)
http://public.lanl.gov/cpw/ (by Phil Wood, based on lastest libpcap)
The rest of this document is intended for people who want to understand
the low level details or want to improve libpcap by including PACKET_MMAP
support.
--------------------------------------------------------------------------------
+ How to use CONFIG_PACKET_MMAP directly
--------------------------------------------------------------------------------
From the system calls stand point, the use of PACKET_MMAP involves
the following process:
[setup] socket() -------> creation of the capture socket
setsockopt() ---> allocation of the circular buffer (ring)
mmap() ---------> mapping of the allocated buffer to the
user process
[capture] poll() ---------> to wait for incoming packets
[shutdown] close() --------> destruction of the capture socket and
deallocation of all associated
resources.
socket creation and destruction is straight forward, and is done
the same way with or without PACKET_MMAP:
int fd;
fd= socket(PF_PACKET, mode, htons(ETH_P_ALL))
where mode is SOCK_RAW for the raw interface were link level
information can be captured or SOCK_DGRAM for the cooked
interface where link level information capture is not
supported and a link level pseudo-header is provided
by the kernel.
The destruction of the socket and all associated resources
is done by a simple call to close(fd).
Next I will describe PACKET_MMAP settings and it's constraints,
also the mapping of the circular buffer in the user process and
the use of this buffer.
--------------------------------------------------------------------------------
+ PACKET_MMAP settings
--------------------------------------------------------------------------------
To setup PACKET_MMAP from user level code is done with a call like
setsockopt(fd, SOL_PACKET, PACKET_RX_RING, (void *) &req, sizeof(req))
The most significant argument in the previous call is the req parameter,
this parameter must to have the following structure:
struct tpacket_req
{
unsigned int tp_block_size; /* Minimal size of contiguous block */
unsigned int tp_block_nr; /* Number of blocks */
unsigned int tp_frame_size; /* Size of frame */
unsigned int tp_frame_nr; /* Total number of frames */
};
This structure is defined in /usr/include/linux/if_packet.h and establishes a
circular buffer (ring) of unswappable memory mapped in the capture process.
Being mapped in the capture process allows reading the captured frames and
related meta-information like timestamps without requiring a system call.
Captured frames are grouped in blocks. Each block is a physically contiguous
region of memory and holds tp_block_size/tp_frame_size frames. The total number
of blocks is tp_block_nr. Note that tp_frame_nr is a redundant parameter because
frames_per_block = tp_block_size/tp_frame_size
indeed, packet_set_ring checks that the following condition is true
frames_per_block * tp_block_nr == tp_frame_nr
Lets see an example, with the following values:
tp_block_size= 4096
tp_frame_size= 2048
tp_block_nr = 4
tp_frame_nr = 8
we will get the following buffer structure:
block #1 block #2
+---------+---------+ +---------+---------+
| frame 1 | frame 2 | | frame 3 | frame 4 |
+---------+---------+ +---------+---------+
block #3 block #4
+---------+---------+ +---------+---------+
| frame 5 | frame 6 | | frame 7 | frame 8 |
+---------+---------+ +---------+---------+
A frame can be of any size with the only condition it can fit in a block. A block
can only hold an integer number of frames, or in other words, a frame cannot
be spawned accross two blocks, so there are some details you have to take into
account when choosing the frame_size. See "Mapping and use of the circular
buffer (ring)".
--------------------------------------------------------------------------------
+ PACKET_MMAP setting constraints
--------------------------------------------------------------------------------
In kernel versions prior to 2.4.26 (for the 2.4 branch) and 2.6.5 (2.6 branch),
the PACKET_MMAP buffer could hold only 32768 frames in a 32 bit architecture or
16384 in a 64 bit architecture. For information on these kernel versions
see http://pusa.uv.es/~ulisses/packet_mmap/packet_mmap.pre-2.4.26_2.6.5.txt
Block size limit
------------------
As stated earlier, each block is a contiguous physical region of memory. These
memory regions are allocated with calls to the __get_free_pages() function. As
the name indicates, this function allocates pages of memory, and the second
argument is "order" or a power of two number of pages, that is
(for PAGE_SIZE == 4096) order=0 ==> 4096 bytes, order=1 ==> 8192 bytes,
order=2 ==> 16384 bytes, etc. The maximum size of a
region allocated by __get_free_pages is determined by the MAX_ORDER macro. More
precisely the limit can be calculated as:
PAGE_SIZE << MAX_ORDER
In a i386 architecture PAGE_SIZE is 4096 bytes
In a 2.4/i386 kernel MAX_ORDER is 10
In a 2.6/i386 kernel MAX_ORDER is 11
So get_free_pages can allocate as much as 4MB or 8MB in a 2.4/2.6 kernel
respectively, with an i386 architecture.
User space programs can include /usr/include/sys/user.h and
/usr/include/linux/mmzone.h to get PAGE_SIZE MAX_ORDER declarations.
The pagesize can also be determined dynamically with the getpagesize (2)
system call.
Block number limit
--------------------
To understand the constraints of PACKET_MMAP, we have to see the structure
used to hold the pointers to each block.
Currently, this structure is a dynamically allocated vector with kmalloc
called pg_vec, its size limits the number of blocks that can be allocated.
+---+---+---+---+
| x | x | x | x |
+---+---+---+---+
| | | |
| | | v
| | v block #4
| v block #3
v block #2
block #1
kmalloc allocates any number of bytes of physically contiguous memory from
a pool of pre-determined sizes. This pool of memory is maintained by the slab
allocator which is at the end the responsible for doing the allocation and
hence which imposes the maximum memory that kmalloc can allocate.
In a 2.4/2.6 kernel and the i386 architecture, the limit is 131072 bytes. The
predetermined sizes that kmalloc uses can be checked in the "size-<bytes>"
entries of /proc/slabinfo
In a 32 bit architecture, pointers are 4 bytes long, so the total number of
pointers to blocks is
131072/4 = 32768 blocks
PACKET_MMAP buffer size calculator
------------------------------------
Definitions:
<size-max> : is the maximum size of allocable with kmalloc (see /proc/slabinfo)
<pointer size>: depends on the architecture -- sizeof(void *)
<page size> : depends on the architecture -- PAGE_SIZE or getpagesize (2)
<max-order> : is the value defined with MAX_ORDER
<frame size> : it's an upper bound of frame's capture size (more on this later)
from these definitions we will derive
<block number> = <size-max>/<pointer size>
<block size> = <pagesize> << <max-order>
so, the max buffer size is
<block number> * <block size>
and, the number of frames be
<block number> * <block size> / <frame size>
Suppose the following parameters, which apply for 2.6 kernel and an
i386 architecture:
<size-max> = 131072 bytes
<pointer size> = 4 bytes
<pagesize> = 4096 bytes
<max-order> = 11
and a value for <frame size> of 2048 bytes. These parameters will yield
<block number> = 131072/4 = 32768 blocks
<block size> = 4096 << 11 = 8 MiB.
and hence the buffer will have a 262144 MiB size. So it can hold
262144 MiB / 2048 bytes = 134217728 frames
Actually, this buffer size is not possible with an i386 architecture.
Remember that the memory is allocated in kernel space, in the case of
an i386 kernel's memory size is limited to 1GiB.
All memory allocations are not freed until the socket is closed. The memory
allocations are done with GFP_KERNEL priority, this basically means that
the allocation can wait and swap other process' memory in order to allocate
the necessary memory, so normally limits can be reached.
Other constraints
-------------------
If you check the source code you will see that what I draw here as a frame
is not only the link level frame. At the beginning of each frame there is a
header called struct tpacket_hdr used in PACKET_MMAP to hold link level's frame
meta information like timestamp. So what we draw here a frame it's really
the following (from include/linux/if_packet.h):
/*
Frame structure:
- Start. Frame must be aligned to TPACKET_ALIGNMENT=16
- struct tpacket_hdr
- pad to TPACKET_ALIGNMENT=16
- struct sockaddr_ll
- Gap, chosen so that packet data (Start+tp_net) aligns to
TPACKET_ALIGNMENT=16
- Start+tp_mac: [ Optional MAC header ]
- Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16.
- Pad to align to TPACKET_ALIGNMENT=16
*/
The following are conditions that are checked in packet_set_ring
tp_block_size must be a multiple of PAGE_SIZE (1)
tp_frame_size must be greater than TPACKET_HDRLEN (obvious)
tp_frame_size must be a multiple of TPACKET_ALIGNMENT
tp_frame_nr must be exactly frames_per_block*tp_block_nr
Note that tp_block_size should be chosen to be a power of two or there will
be a waste of memory.
--------------------------------------------------------------------------------
+ Mapping and use of the circular buffer (ring)
--------------------------------------------------------------------------------
The mapping of the buffer in the user process is done with the conventional
mmap function. Even the circular buffer is compound of several physically
discontiguous blocks of memory, they are contiguous to the user space, hence
just one call to mmap is needed:
mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
If tp_frame_size is a divisor of tp_block_size frames will be
contiguosly spaced by tp_frame_size bytes. If not, each
tp_block_size/tp_frame_size frames there will be a gap between
the frames. This is because a frame cannot be spawn across two
blocks.
At the beginning of each frame there is an status field (see
struct tpacket_hdr). If this field is 0 means that the frame is ready
to be used for the kernel, If not, there is a frame the user can read
and the following flags apply:
from include/linux/if_packet.h
#define TP_STATUS_COPY 2
#define TP_STATUS_LOSING 4
#define TP_STATUS_CSUMNOTREADY 8
TP_STATUS_COPY : This flag indicates that the frame (and associated
meta information) has been truncated because it's
larger than tp_frame_size. This packet can be
read entirely with recvfrom().
In order to make this work it must to be
enabled previously with setsockopt() and
the PACKET_COPY_THRESH option.
The number of frames than can be buffered to
be read with recvfrom is limited like a normal socket.
See the SO_RCVBUF option in the socket (7) man page.
TP_STATUS_LOSING : indicates there were packet drops from last time
statistics where checked with getsockopt() and
the PACKET_STATISTICS option.
TP_STATUS_CSUMNOTREADY: currently it's used for outgoing IP packets which
it's checksum will be done in hardware. So while
reading the packet we should not try to check the
checksum.
for convenience there are also the following defines:
#define TP_STATUS_KERNEL 0
#define TP_STATUS_USER 1
The kernel initializes all frames to TP_STATUS_KERNEL, when the kernel
receives a packet it puts in the buffer and updates the status with
at least the TP_STATUS_USER flag. Then the user can read the packet,
once the packet is read the user must zero the status field, so the kernel
can use again that frame buffer.
The user can use poll (any other variant should apply too) to check if new
packets are in the ring:
struct pollfd pfd;
pfd.fd = fd;
pfd.revents = 0;
pfd.events = POLLIN|POLLRDNORM|POLLERR;
if (status == TP_STATUS_KERNEL)
retval = poll(&pfd, 1, timeout);
It doesn't incur in a race condition to first check the status value and
then poll for frames.
--------------------------------------------------------------------------------
+ THANKS
--------------------------------------------------------------------------------
Jesse Brandeburg, for fixing my grammathical/spelling errors

293
Documentation/networking/phy.txt Normal file
View File

@@ -0,0 +1,293 @@
-------
PHY Abstraction Layer
(Updated 2006-11-30)
Purpose
Most network devices consist of set of registers which provide an interface
to a MAC layer, which communicates with the physical connection through a
PHY. The PHY concerns itself with negotiating link parameters with the link
partner on the other side of the network connection (typically, an ethernet
cable), and provides a register interface to allow drivers to determine what
settings were chosen, and to configure what settings are allowed.
While these devices are distinct from the network devices, and conform to a
standard layout for the registers, it has been common practice to integrate
the PHY management code with the network driver. This has resulted in large
amounts of redundant code. Also, on embedded systems with multiple (and
sometimes quite different) ethernet controllers connected to the same
management bus, it is difficult to ensure safe use of the bus.
Since the PHYs are devices, and the management busses through which they are
accessed are, in fact, busses, the PHY Abstraction Layer treats them as such.
In doing so, it has these goals:
1) Increase code-reuse
2) Increase overall code-maintainability
3) Speed development time for new network drivers, and for new systems
Basically, this layer is meant to provide an interface to PHY devices which
allows network driver writers to write as little code as possible, while
still providing a full feature set.
The MDIO bus
Most network devices are connected to a PHY by means of a management bus.
Different devices use different busses (though some share common interfaces).
In order to take advantage of the PAL, each bus interface needs to be
registered as a distinct device.
1) read and write functions must be implemented. Their prototypes are:
int write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
int read(struct mii_bus *bus, int mii_id, int regnum);
mii_id is the address on the bus for the PHY, and regnum is the register
number. These functions are guaranteed not to be called from interrupt
time, so it is safe for them to block, waiting for an interrupt to signal
the operation is complete
2) A reset function is necessary. This is used to return the bus to an
initialized state.
3) A probe function is needed. This function should set up anything the bus
driver needs, setup the mii_bus structure, and register with the PAL using
mdiobus_register. Similarly, there's a remove function to undo all of
that (use mdiobus_unregister).
4) Like any driver, the device_driver structure must be configured, and init
exit functions are used to register the driver.
5) The bus must also be declared somewhere as a device, and registered.
As an example for how one driver implemented an mdio bus driver, see
drivers/net/gianfar_mii.c and arch/ppc/syslib/mpc85xx_devices.c
Connecting to a PHY
Sometime during startup, the network driver needs to establish a connection
between the PHY device, and the network device. At this time, the PHY's bus
and drivers need to all have been loaded, so it is ready for the connection.
At this point, there are several ways to connect to the PHY:
1) The PAL handles everything, and only calls the network driver when
the link state changes, so it can react.
2) The PAL handles everything except interrupts (usually because the
controller has the interrupt registers).
3) The PAL handles everything, but checks in with the driver every second,
allowing the network driver to react first to any changes before the PAL
does.
4) The PAL serves only as a library of functions, with the network device
manually calling functions to update status, and configure the PHY
Letting the PHY Abstraction Layer do Everything
If you choose option 1 (The hope is that every driver can, but to still be
useful to drivers that can't), connecting to the PHY is simple:
First, you need a function to react to changes in the link state. This
function follows this protocol:
static void adjust_link(struct net_device *dev);
Next, you need to know the device name of the PHY connected to this device.
The name will look something like, "phy0:0", where the first number is the
bus id, and the second is the PHY's address on that bus. Typically,
the bus is responsible for making its ID unique.
Now, to connect, just call this function:
phydev = phy_connect(dev, phy_name, &adjust_link, flags, interface);
phydev is a pointer to the phy_device structure which represents the PHY. If
phy_connect is successful, it will return the pointer. dev, here, is the
pointer to your net_device. Once done, this function will have started the
PHY's software state machine, and registered for the PHY's interrupt, if it
has one. The phydev structure will be populated with information about the
current state, though the PHY will not yet be truly operational at this
point.
flags is a u32 which can optionally contain phy-specific flags.
This is useful if the system has put hardware restrictions on
the PHY/controller, of which the PHY needs to be aware.
interface is a u32 which specifies the connection type used
between the controller and the PHY. Examples are GMII, MII,
RGMII, and SGMII. For a full list, see include/linux/phy.h
Now just make sure that phydev->supported and phydev->advertising have any
values pruned from them which don't make sense for your controller (a 10/100
controller may be connected to a gigabit capable PHY, so you would need to
mask off SUPPORTED_1000baseT*). See include/linux/ethtool.h for definitions
for these bitfields. Note that you should not SET any bits, or the PHY may
get put into an unsupported state.
Lastly, once the controller is ready to handle network traffic, you call
phy_start(phydev). This tells the PAL that you are ready, and configures the
PHY to connect to the network. If you want to handle your own interrupts,
just set phydev->irq to PHY_IGNORE_INTERRUPT before you call phy_start.
Similarly, if you don't want to use interrupts, set phydev->irq to PHY_POLL.
When you want to disconnect from the network (even if just briefly), you call
phy_stop(phydev).
Keeping Close Tabs on the PAL
It is possible that the PAL's built-in state machine needs a little help to
keep your network device and the PHY properly in sync. If so, you can
register a helper function when connecting to the PHY, which will be called
every second before the state machine reacts to any changes. To do this, you
need to manually call phy_attach() and phy_prepare_link(), and then call
phy_start_machine() with the second argument set to point to your special
handler.
Currently there are no examples of how to use this functionality, and testing
on it has been limited because the author does not have any drivers which use
it (they all use option 1). So Caveat Emptor.
Doing it all yourself
There's a remote chance that the PAL's built-in state machine cannot track
the complex interactions between the PHY and your network device. If this is
so, you can simply call phy_attach(), and not call phy_start_machine or
phy_prepare_link(). This will mean that phydev->state is entirely yours to
handle (phy_start and phy_stop toggle between some of the states, so you
might need to avoid them).
An effort has been made to make sure that useful functionality can be
accessed without the state-machine running, and most of these functions are
descended from functions which did not interact with a complex state-machine.
However, again, no effort has been made so far to test running without the
state machine, so tryer beware.
Here is a brief rundown of the functions:
int phy_read(struct phy_device *phydev, u16 regnum);
int phy_write(struct phy_device *phydev, u16 regnum, u16 val);
Simple read/write primitives. They invoke the bus's read/write function
pointers.
void phy_print_status(struct phy_device *phydev);
A convenience function to print out the PHY status neatly.
int phy_clear_interrupt(struct phy_device *phydev);
int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
Clear the PHY's interrupt, and configure which ones are allowed,
respectively. Currently only supports all on, or all off.
int phy_enable_interrupts(struct phy_device *phydev);
int phy_disable_interrupts(struct phy_device *phydev);
Functions which enable/disable PHY interrupts, clearing them
before and after, respectively.
int phy_start_interrupts(struct phy_device *phydev);
int phy_stop_interrupts(struct phy_device *phydev);
Requests the IRQ for the PHY interrupts, then enables them for
start, or disables then frees them for stop.
struct phy_device * phy_attach(struct net_device *dev, const char *phy_id,
u32 flags, phy_interface_t interface);
Attaches a network device to a particular PHY, binding the PHY to a generic
driver if none was found during bus initialization. Passes in
any phy-specific flags as needed.
int phy_start_aneg(struct phy_device *phydev);
Using variables inside the phydev structure, either configures advertising
and resets autonegotiation, or disables autonegotiation, and configures
forced settings.
static inline int phy_read_status(struct phy_device *phydev);
Fills the phydev structure with up-to-date information about the current
settings in the PHY.
void phy_sanitize_settings(struct phy_device *phydev)
Resolves differences between currently desired settings, and
supported settings for the given PHY device. Does not make
the changes in the hardware, though.
int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
Ethtool convenience functions.
int phy_mii_ioctl(struct phy_device *phydev,
struct mii_ioctl_data *mii_data, int cmd);
The MII ioctl. Note that this function will completely screw up the state
machine if you write registers like BMCR, BMSR, ADVERTISE, etc. Best to
use this only to write registers which are not standard, and don't set off
a renegotiation.
PHY Device Drivers
With the PHY Abstraction Layer, adding support for new PHYs is
quite easy. In some cases, no work is required at all! However,
many PHYs require a little hand-holding to get up-and-running.
Generic PHY driver
If the desired PHY doesn't have any errata, quirks, or special
features you want to support, then it may be best to not add
support, and let the PHY Abstraction Layer's Generic PHY Driver
do all of the work.
Writing a PHY driver
If you do need to write a PHY driver, the first thing to do is
make sure it can be matched with an appropriate PHY device.
This is done during bus initialization by reading the device's
UID (stored in registers 2 and 3), then comparing it to each
driver's phy_id field by ANDing it with each driver's
phy_id_mask field. Also, it needs a name. Here's an example:
static struct phy_driver dm9161_driver = {
.phy_id = 0x0181b880,
.name = "Davicom DM9161E",
.phy_id_mask = 0x0ffffff0,
...
}
Next, you need to specify what features (speed, duplex, autoneg,
etc) your PHY device and driver support. Most PHYs support
PHY_BASIC_FEATURES, but you can look in include/mii.h for other
features.
Each driver consists of a number of function pointers:
config_init: configures PHY into a sane state after a reset.
For instance, a Davicom PHY requires descrambling disabled.
probe: Does any setup needed by the driver
suspend/resume: power management
config_aneg: Changes the speed/duplex/negotiation settings
read_status: Reads the current speed/duplex/negotiation settings
ack_interrupt: Clear a pending interrupt
config_intr: Enable or disable interrupts
remove: Does any driver take-down
Of these, only config_aneg and read_status are required to be
assigned by the driver code. The rest are optional. Also, it is
preferred to use the generic phy driver's versions of these two
functions if at all possible: genphy_read_status and
genphy_config_aneg. If this is not possible, it is likely that
you only need to perform some actions before and after invoking
these functions, and so your functions will wrap the generic
ones.
Feel free to look at the Marvell, Cicada, and Davicom drivers in
drivers/net/phy/ for examples (the lxt and qsemi drivers have
not been tested as of this writing)

248
Documentation/networking/pktgen.txt Normal file
View File

@@ -0,0 +1,248 @@
HOWTO for the linux packet generator
------------------------------------
Date: 041221
Enable CONFIG_NET_PKTGEN to compile and build pktgen.o either in kernel
or as module. Module is preferred. insmod pktgen if needed. Once running
pktgen creates a thread on each CPU where each thread has affinity to its CPU.
Monitoring and controlling is done via /proc. Easiest to select a suitable
a sample script and configure.
On a dual CPU:
ps aux | grep pkt
root 129 0.3 0.0 0 0 ? SW 2003 523:20 [pktgen/0]
root 130 0.3 0.0 0 0 ? SW 2003 509:50 [pktgen/1]
For monitoring and control pktgen creates:
/proc/net/pktgen/pgctrl
/proc/net/pktgen/kpktgend_X
/proc/net/pktgen/ethX
Viewing threads
===============
/proc/net/pktgen/kpktgend_0
Name: kpktgend_0 max_before_softirq: 10000
Running:
Stopped: eth1
Result: OK: max_before_softirq=10000
Most important the devices assigned to thread. Note! A device can only belong
to one thread.
Viewing devices
===============
Parm section holds configured info. Current hold running stats.
Result is printed after run or after interruption. Example:
/proc/net/pktgen/eth1
Params: count 10000000 min_pkt_size: 60 max_pkt_size: 60
frags: 0 delay: 0 clone_skb: 1000000 ifname: eth1
flows: 0 flowlen: 0
dst_min: 10.10.11.2 dst_max:
src_min: src_max:
src_mac: 00:00:00:00:00:00 dst_mac: 00:04:23:AC:FD:82
udp_src_min: 9 udp_src_max: 9 udp_dst_min: 9 udp_dst_max: 9
src_mac_count: 0 dst_mac_count: 0
Flags:
Current:
pkts-sofar: 10000000 errors: 39664
started: 1103053986245187us stopped: 1103053999346329us idle: 880401us
seq_num: 10000011 cur_dst_mac_offset: 0 cur_src_mac_offset: 0
cur_saddr: 0x10a0a0a cur_daddr: 0x20b0a0a
cur_udp_dst: 9 cur_udp_src: 9
flows: 0
Result: OK: 13101142(c12220741+d880401) usec, 10000000 (60byte,0frags)
763292pps 390Mb/sec (390805504bps) errors: 39664
Configuring threads and devices
================================
This is done via the /proc interface easiest done via pgset in the scripts
Examples:
pgset "clone_skb 1" sets the number of copies of the same packet
pgset "clone_skb 0" use single SKB for all transmits
pgset "pkt_size 9014" sets packet size to 9014
pgset "frags 5" packet will consist of 5 fragments
pgset "count 200000" sets number of packets to send, set to zero
for continuous sends until explicitly stopped.
pgset "delay 5000" adds delay to hard_start_xmit(). nanoseconds
pgset "dst 10.0.0.1" sets IP destination address
(BEWARE! This generator is very aggressive!)
pgset "dst_min 10.0.0.1" Same as dst
pgset "dst_max 10.0.0.254" Set the maximum destination IP.
pgset "src_min 10.0.0.1" Set the minimum (or only) source IP.
pgset "src_max 10.0.0.254" Set the maximum source IP.
pgset "dst6 fec0::1" IPV6 destination address
pgset "src6 fec0::2" IPV6 source address
pgset "dstmac 00:00:00:00:00:00" sets MAC destination address
pgset "srcmac 00:00:00:00:00:00" sets MAC source address
pgset "src_mac_count 1" Sets the number of MACs we'll range through.
The 'minimum' MAC is what you set with srcmac.
pgset "dst_mac_count 1" Sets the number of MACs we'll range through.
The 'minimum' MAC is what you set with dstmac.
pgset "flag [name]" Set a flag to determine behaviour. Current flags
are: IPSRC_RND #IP Source is random (between min/max),
IPDST_RND, UDPSRC_RND,
UDPDST_RND, MACSRC_RND, MACDST_RND
MPLS_RND, VID_RND, SVID_RND
pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then
cycle through the port range.
pgset "udp_src_max 9" set UDP source port max.
pgset "udp_dst_min 9" set UDP destination port min, If < udp_dst_max, then
cycle through the port range.
pgset "udp_dst_max 9" set UDP destination port max.
pgset "mpls 0001000a,0002000a,0000000a" set MPLS labels (in this example
outer label=16,middle label=32,
inner label=0 (IPv4 NULL)) Note that
there must be no spaces between the
arguments. Leading zeros are required.
Do not set the bottom of stack bit,
that's done automatically. If you do
set the bottom of stack bit, that
indicates that you want to randomly
generate that address and the flag
MPLS_RND will be turned on. You
can have any mix of random and fixed
labels in the label stack.
pgset "mpls 0" turn off mpls (or any invalid argument works too!)
pgset "vlan_id 77" set VLAN ID 0-4095
pgset "vlan_p 3" set priority bit 0-7 (default 0)
pgset "vlan_cfi 0" set canonical format identifier 0-1 (default 0)
pgset "svlan_id 22" set SVLAN ID 0-4095
pgset "svlan_p 3" set priority bit 0-7 (default 0)
pgset "svlan_cfi 0" set canonical format identifier 0-1 (default 0)
pgset "vlan_id 9999" > 4095 remove vlan and svlan tags
pgset "svlan 9999" > 4095 remove svlan tag
pgset "tos XX" set former IPv4 TOS field (e.g. "tos 28" for AF11 no ECN, default 00)
pgset "traffic_class XX" set former IPv6 TRAFFIC CLASS (e.g. "traffic_class B8" for EF no ECN, default 00)
pgset stop aborts injection. Also, ^C aborts generator.
Example scripts
===============
A collection of small tutorial scripts for pktgen is in examples dir.
pktgen.conf-1-1 # 1 CPU 1 dev
pktgen.conf-1-2 # 1 CPU 2 dev
pktgen.conf-2-1 # 2 CPU's 1 dev
pktgen.conf-2-2 # 2 CPU's 2 dev
pktgen.conf-1-1-rdos # 1 CPU 1 dev w. route DoS
pktgen.conf-1-1-ip6 # 1 CPU 1 dev ipv6
pktgen.conf-1-1-ip6-rdos # 1 CPU 1 dev ipv6 w. route DoS
pktgen.conf-1-1-flows # 1 CPU 1 dev multiple flows.
Run in shell: ./pktgen.conf-X-Y It does all the setup including sending.
Interrupt affinity
===================
Note when adding devices to a specific CPU there good idea to also assign
/proc/irq/XX/smp_affinity so the TX-interrupts gets bound to the same CPU.
as this reduces cache bouncing when freeing skb's.
Current commands and configuration options
==========================================
** Pgcontrol commands:
start
stop
** Thread commands:
add_device
rem_device_all
max_before_softirq
** Device commands:
count
clone_skb
debug
frags
delay
src_mac_count
dst_mac_count
pkt_size
min_pkt_size
max_pkt_size
mpls
udp_src_min
udp_src_max
udp_dst_min
udp_dst_max
flag
IPSRC_RND
TXSIZE_RND
IPDST_RND
UDPSRC_RND
UDPDST_RND
MACSRC_RND
MACDST_RND
dst_min
dst_max
src_min
src_max
dst_mac
src_mac
clear_counters
dst6
src6
flows
flowlen
References:
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/
Paper from Linux-Kongress in Erlangen 2004.
ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/pktgen_paper.pdf
Thanks to:
Grant Grundler for testing on IA-64 and parisc, Harald Welte, Lennert Buytenhek
Stephen Hemminger, Andi Kleen, Dave Miller and many others.
Good luck with the linux net-development.

150
Documentation/networking/policy-routing.txt Normal file
View File

@@ -0,0 +1,150 @@
Classes
-------
"Class" is a complete routing table in common sense.
I.e. it is tree of nodes (destination prefix, tos, metric)
with attached information: gateway, device etc.
This tree is looked up as specified in RFC1812 5.2.4.3
1. Basic match
2. Longest match
3. Weak TOS.
4. Metric. (should not be in kernel space, but they are)
5. Additional pruning rules. (not in kernel space).
We have two special type of nodes:
REJECT - abort route lookup and return an error value.
THROW - abort route lookup in this class.
Currently the number of classes is limited to 255
(0 is reserved for "not specified class")
Three classes are builtin:
RT_CLASS_LOCAL=255 - local interface addresses,
broadcasts, nat addresses.
RT_CLASS_MAIN=254 - all normal routes are put there
by default.
RT_CLASS_DEFAULT=253 - if ip_fib_model==1, then
normal default routes are put there, if ip_fib_model==2
all gateway routes are put there.
Rules
-----
Rule is a record of (src prefix, src interface, tos, dst prefix)
with attached information.
Rule types:
RTP_ROUTE - lookup in attached class
RTP_NAT - lookup in attached class and if a match is found,
translate packet source address.
RTP_MASQUERADE - lookup in attached class and if a match is found,
masquerade packet as sourced by us.
RTP_DROP - silently drop the packet.
RTP_REJECT - drop the packet and send ICMP NET UNREACHABLE.
RTP_PROHIBIT - drop the packet and send ICMP COMM. ADM. PROHIBITED.
Rule flags:
RTRF_LOG - log route creations.
RTRF_VALVE - One way route (used with masquerading)
Default setup:
root@amber:/pub/ip-routing # iproute -r
Kernel routing policy rules
Pref Source Destination TOS Iface Cl
0 default default 00 * 255
254 default default 00 * 254
255 default default 00 * 253
Lookup algorithm
----------------
We scan rules list, and if a rule is matched, apply it.
If a route is found, return it.
If it is not found or a THROW node was matched, continue
to scan rules.
Applications
------------
1. Just ignore classes. All the routes are put into MAIN class
(and/or into DEFAULT class).
HOWTO: iproute add PREFIX [ tos TOS ] [ gw GW ] [ dev DEV ]
[ metric METRIC ] [ reject ] ... (look at iproute utility)
or use route utility from current net-tools.
2. Opposite case. Just forget all that you know about routing
tables. Every rule is supplied with its own gateway, device
info. record. This approach is not appropriate for automated
route maintenance, but it is ideal for manual configuration.
HOWTO: iproute addrule [ from PREFIX ] [ to PREFIX ] [ tos TOS ]
[ dev INPUTDEV] [ pref PREFERENCE ] route [ gw GATEWAY ]
[ dev OUTDEV ] .....
Warning: As of now the size of the routing table in this
approach is limited to 256. If someone likes this model, I'll
relax this limitation.
3. OSPF classes (see RFC1583, RFC1812 E.3.3)
Very clean, stable and robust algorithm for OSPF routing
domains. Unfortunately, it is not widely used in the Internet.
Proposed setup:
255 local addresses
254 interface routes
253 ASE routes with external metric
252 ASE routes with internal metric
251 inter-area routes
250 intra-area routes for 1st area
249 intra-area routes for 2nd area
etc.
Rules:
iproute addrule class 253
iproute addrule class 252
iproute addrule class 251
iproute addrule to a-prefix-for-1st-area class 250
iproute addrule to another-prefix-for-1st-area class 250
...
iproute addrule to a-prefix-for-2nd-area class 249
...
Area classes must be terminated with reject record.
iproute add default reject class 250
iproute add default reject class 249
...
4. The Variant Router Requirements Algorithm (RFC1812 E.3.2)
Create 16 classes for different TOS values.
It is a funny, but pretty useless algorithm.
I listed it just to show the power of new routing code.
5. All the variety of combinations......
GATED
-----
Gated does not understand classes, but it will work
happily in MAIN+DEFAULT. All policy routes can be set
and maintained manually.
IMPORTANT NOTE
--------------
route.c has a compilation time switch CONFIG_IP_LOCAL_RT_POLICY.
If it is set, locally originated packets are routed
using all the policy list. This is not very convenient and
pretty ambiguous when used with NAT and masquerading.
I set it to FALSE by default.
Alexey Kuznetov
kuznet@ms2.inr.ac.ru

432
Documentation/networking/ppp_generic.txt Normal file
View File

@@ -0,0 +1,432 @@
PPP Generic Driver and Channel Interface
----------------------------------------
Paul Mackerras
paulus@samba.org
7 Feb 2002
The generic PPP driver in linux-2.4 provides an implementation of the
functionality which is of use in any PPP implementation, including:
* the network interface unit (ppp0 etc.)
* the interface to the networking code
* PPP multilink: splitting datagrams between multiple links, and
ordering and combining received fragments
* the interface to pppd, via a /dev/ppp character device
* packet compression and decompression
* TCP/IP header compression and decompression
* detecting network traffic for demand dialling and for idle timeouts
* simple packet filtering
For sending and receiving PPP frames, the generic PPP driver calls on
the services of PPP `channels'. A PPP channel encapsulates a
mechanism for transporting PPP frames from one machine to another. A
PPP channel implementation can be arbitrarily complex internally but
has a very simple interface with the generic PPP code: it merely has
to be able to send PPP frames, receive PPP frames, and optionally
handle ioctl requests. Currently there are PPP channel
implementations for asynchronous serial ports, synchronous serial
ports, and for PPP over ethernet.
This architecture makes it possible to implement PPP multilink in a
natural and straightforward way, by allowing more than one channel to
be linked to each ppp network interface unit. The generic layer is
responsible for splitting datagrams on transmit and recombining them
on receive.
PPP channel API
---------------
See include/linux/ppp_channel.h for the declaration of the types and
functions used to communicate between the generic PPP layer and PPP
channels.
Each channel has to provide two functions to the generic PPP layer,
via the ppp_channel.ops pointer:
* start_xmit() is called by the generic layer when it has a frame to
send. The channel has the option of rejecting the frame for
flow-control reasons. In this case, start_xmit() should return 0
and the channel should call the ppp_output_wakeup() function at a
later time when it can accept frames again, and the generic layer
will then attempt to retransmit the rejected frame(s). If the frame
is accepted, the start_xmit() function should return 1.
* ioctl() provides an interface which can be used by a user-space
program to control aspects of the channel's behaviour. This
procedure will be called when a user-space program does an ioctl
system call on an instance of /dev/ppp which is bound to the
channel. (Usually it would only be pppd which would do this.)
The generic PPP layer provides seven functions to channels:
* ppp_register_channel() is called when a channel has been created, to
notify the PPP generic layer of its presence. For example, setting
a serial port to the PPPDISC line discipline causes the ppp_async
channel code to call this function.
* ppp_unregister_channel() is called when a channel is to be
destroyed. For example, the ppp_async channel code calls this when
a hangup is detected on the serial port.
* ppp_output_wakeup() is called by a channel when it has previously
rejected a call to its start_xmit function, and can now accept more
packets.
* ppp_input() is called by a channel when it has received a complete
PPP frame.
* ppp_input_error() is called by a channel when it has detected that a
frame has been lost or dropped (for example, because of a FCS (frame
check sequence) error).
* ppp_channel_index() returns the channel index assigned by the PPP
generic layer to this channel. The channel should provide some way
(e.g. an ioctl) to transmit this back to user-space, as user-space
will need it to attach an instance of /dev/ppp to this channel.
* ppp_unit_number() returns the unit number of the ppp network
interface to which this channel is connected, or -1 if the channel
is not connected.
Connecting a channel to the ppp generic layer is initiated from the
channel code, rather than from the generic layer. The channel is
expected to have some way for a user-level process to control it
independently of the ppp generic layer. For example, with the
ppp_async channel, this is provided by the file descriptor to the
serial port.
Generally a user-level process will initialize the underlying
communications medium and prepare it to do PPP. For example, with an
async tty, this can involve setting the tty speed and modes, issuing
modem commands, and then going through some sort of dialog with the
remote system to invoke PPP service there. We refer to this process
as `discovery'. Then the user-level process tells the medium to
become a PPP channel and register itself with the generic PPP layer.
The channel then has to report the channel number assigned to it back
to the user-level process. From that point, the PPP negotiation code
in the PPP daemon (pppd) can take over and perform the PPP
negotiation, accessing the channel through the /dev/ppp interface.
At the interface to the PPP generic layer, PPP frames are stored in
skbuff structures and start with the two-byte PPP protocol number.
The frame does *not* include the 0xff `address' byte or the 0x03
`control' byte that are optionally used in async PPP. Nor is there
any escaping of control characters, nor are there any FCS or framing
characters included. That is all the responsibility of the channel
code, if it is needed for the particular medium. That is, the skbuffs
presented to the start_xmit() function contain only the 2-byte
protocol number and the data, and the skbuffs presented to ppp_input()
must be in the same format.
The channel must provide an instance of a ppp_channel struct to
represent the channel. The channel is free to use the `private' field
however it wishes. The channel should initialize the `mtu' and
`hdrlen' fields before calling ppp_register_channel() and not change
them until after ppp_unregister_channel() returns. The `mtu' field
represents the maximum size of the data part of the PPP frames, that
is, it does not include the 2-byte protocol number.
If the channel needs some headroom in the skbuffs presented to it for
transmission (i.e., some space free in the skbuff data area before the
start of the PPP frame), it should set the `hdrlen' field of the
ppp_channel struct to the amount of headroom required. The generic
PPP layer will attempt to provide that much headroom but the channel
should still check if there is sufficient headroom and copy the skbuff
if there isn't.
On the input side, channels should ideally provide at least 2 bytes of
headroom in the skbuffs presented to ppp_input(). The generic PPP
code does not require this but will be more efficient if this is done.
Buffering and flow control
--------------------------
The generic PPP layer has been designed to minimize the amount of data
that it buffers in the transmit direction. It maintains a queue of
transmit packets for the PPP unit (network interface device) plus a
queue of transmit packets for each attached channel. Normally the
transmit queue for the unit will contain at most one packet; the
exceptions are when pppd sends packets by writing to /dev/ppp, and
when the core networking code calls the generic layer's start_xmit()
function with the queue stopped, i.e. when the generic layer has
called netif_stop_queue(), which only happens on a transmit timeout.
The start_xmit function always accepts and queues the packet which it
is asked to transmit.
Transmit packets are dequeued from the PPP unit transmit queue and
then subjected to TCP/IP header compression and packet compression
(Deflate or BSD-Compress compression), as appropriate. After this
point the packets can no longer be reordered, as the decompression
algorithms rely on receiving compressed packets in the same order that
they were generated.
If multilink is not in use, this packet is then passed to the attached
channel's start_xmit() function. If the channel refuses to take
the packet, the generic layer saves it for later transmission. The
generic layer will call the channel's start_xmit() function again
when the channel calls ppp_output_wakeup() or when the core
networking code calls the generic layer's start_xmit() function
again. The generic layer contains no timeout and retransmission
logic; it relies on the core networking code for that.
If multilink is in use, the generic layer divides the packet into one
or more fragments and puts a multilink header on each fragment. It
decides how many fragments to use based on the length of the packet
and the number of channels which are potentially able to accept a
fragment at the moment. A channel is potentially able to accept a
fragment if it doesn't have any fragments currently queued up for it
to transmit. The channel may still refuse a fragment; in this case
the fragment is queued up for the channel to transmit later. This
scheme has the effect that more fragments are given to higher-
bandwidth channels. It also means that under light load, the generic
layer will tend to fragment large packets across all the channels,
thus reducing latency, while under heavy load, packets will tend to be
transmitted as single fragments, thus reducing the overhead of
fragmentation.
SMP safety
----------
The PPP generic layer has been designed to be SMP-safe. Locks are
used around accesses to the internal data structures where necessary
to ensure their integrity. As part of this, the generic layer
requires that the channels adhere to certain requirements and in turn
provides certain guarantees to the channels. Essentially the channels
are required to provide the appropriate locking on the ppp_channel
structures that form the basis of the communication between the
channel and the generic layer. This is because the channel provides
the storage for the ppp_channel structure, and so the channel is
required to provide the guarantee that this storage exists and is
valid at the appropriate times.
The generic layer requires these guarantees from the channel:
* The ppp_channel object must exist from the time that
ppp_register_channel() is called until after the call to
ppp_unregister_channel() returns.
* No thread may be in a call to any of ppp_input(), ppp_input_error(),
ppp_output_wakeup(), ppp_channel_index() or ppp_unit_number() for a
channel at the time that ppp_unregister_channel() is called for that
channel.
* ppp_register_channel() and ppp_unregister_channel() must be called
from process context, not interrupt or softirq/BH context.
* The remaining generic layer functions may be called at softirq/BH
level but must not be called from a hardware interrupt handler.
* The generic layer may call the channel start_xmit() function at
softirq/BH level but will not call it at interrupt level. Thus the
start_xmit() function may not block.
* The generic layer will only call the channel ioctl() function in
process context.
The generic layer provides these guarantees to the channels:
* The generic layer will not call the start_xmit() function for a
channel while any thread is already executing in that function for
that channel.
* The generic layer will not call the ioctl() function for a channel
while any thread is already executing in that function for that
channel.
* By the time a call to ppp_unregister_channel() returns, no thread
will be executing in a call from the generic layer to that channel's
start_xmit() or ioctl() function, and the generic layer will not
call either of those functions subsequently.
Interface to pppd
-----------------
The PPP generic layer exports a character device interface called
/dev/ppp. This is used by pppd to control PPP interface units and
channels. Although there is only one /dev/ppp, each open instance of
/dev/ppp acts independently and can be attached either to a PPP unit
or a PPP channel. This is achieved using the file->private_data field
to point to a separate object for each open instance of /dev/ppp. In
this way an effect similar to Solaris' clone open is obtained,
allowing us to control an arbitrary number of PPP interfaces and
channels without having to fill up /dev with hundreds of device names.
When /dev/ppp is opened, a new instance is created which is initially
unattached. Using an ioctl call, it can then be attached to an
existing unit, attached to a newly-created unit, or attached to an
existing channel. An instance attached to a unit can be used to send
and receive PPP control frames, using the read() and write() system
calls, along with poll() if necessary. Similarly, an instance
attached to a channel can be used to send and receive PPP frames on
that channel.
In multilink terms, the unit represents the bundle, while the channels
represent the individual physical links. Thus, a PPP frame sent by a
write to the unit (i.e., to an instance of /dev/ppp attached to the
unit) will be subject to bundle-level compression and to fragmentation
across the individual links (if multilink is in use). In contrast, a
PPP frame sent by a write to the channel will be sent as-is on that
channel, without any multilink header.
A channel is not initially attached to any unit. In this state it can
be used for PPP negotiation but not for the transfer of data packets.
It can then be connected to a PPP unit with an ioctl call, which
makes it available to send and receive data packets for that unit.
The ioctl calls which are available on an instance of /dev/ppp depend
on whether it is unattached, attached to a PPP interface, or attached
to a PPP channel. The ioctl calls which are available on an
unattached instance are:
* PPPIOCNEWUNIT creates a new PPP interface and makes this /dev/ppp
instance the "owner" of the interface. The argument should point to
an int which is the desired unit number if >= 0, or -1 to assign the
lowest unused unit number. Being the owner of the interface means
that the interface will be shut down if this instance of /dev/ppp is
closed.
* PPPIOCATTACH attaches this instance to an existing PPP interface.
The argument should point to an int containing the unit number.
This does not make this instance the owner of the PPP interface.
* PPPIOCATTCHAN attaches this instance to an existing PPP channel.
The argument should point to an int containing the channel number.
The ioctl calls available on an instance of /dev/ppp attached to a
channel are:
* PPPIOCDETACH detaches the instance from the channel. This ioctl is
deprecated since the same effect can be achieved by closing the
instance. In order to prevent possible races this ioctl will fail
with an EINVAL error if more than one file descriptor refers to this
instance (i.e. as a result of dup(), dup2() or fork()).
* PPPIOCCONNECT connects this channel to a PPP interface. The
argument should point to an int containing the interface unit
number. It will return an EINVAL error if the channel is already
connected to an interface, or ENXIO if the requested interface does
not exist.
* PPPIOCDISCONN disconnects this channel from the PPP interface that
it is connected to. It will return an EINVAL error if the channel
is not connected to an interface.
* All other ioctl commands are passed to the channel ioctl() function.
The ioctl calls that are available on an instance that is attached to
an interface unit are:
* PPPIOCSMRU sets the MRU (maximum receive unit) for the interface.
The argument should point to an int containing the new MRU value.
* PPPIOCSFLAGS sets flags which control the operation of the
interface. The argument should be a pointer to an int containing
the new flags value. The bits in the flags value that can be set
are:
SC_COMP_TCP enable transmit TCP header compression
SC_NO_TCP_CCID disable connection-id compression for
TCP header compression
SC_REJ_COMP_TCP disable receive TCP header decompression
SC_CCP_OPEN Compression Control Protocol (CCP) is
open, so inspect CCP packets
SC_CCP_UP CCP is up, may (de)compress packets
SC_LOOP_TRAFFIC send IP traffic to pppd
SC_MULTILINK enable PPP multilink fragmentation on
transmitted packets
SC_MP_SHORTSEQ expect short multilink sequence
numbers on received multilink fragments
SC_MP_XSHORTSEQ transmit short multilink sequence nos.
The values of these flags are defined in <linux/if_ppp.h>. Note
that the values of the SC_MULTILINK, SC_MP_SHORTSEQ and
SC_MP_XSHORTSEQ bits are ignored if the CONFIG_PPP_MULTILINK option
is not selected.
* PPPIOCGFLAGS returns the value of the status/control flags for the
interface unit. The argument should point to an int where the ioctl
will store the flags value. As well as the values listed above for
PPPIOCSFLAGS, the following bits may be set in the returned value:
SC_COMP_RUN CCP compressor is running
SC_DECOMP_RUN CCP decompressor is running
SC_DC_ERROR CCP decompressor detected non-fatal error
SC_DC_FERROR CCP decompressor detected fatal error
* PPPIOCSCOMPRESS sets the parameters for packet compression or
decompression. The argument should point to a ppp_option_data
structure (defined in <linux/if_ppp.h>), which contains a
pointer/length pair which should describe a block of memory
containing a CCP option specifying a compression method and its
parameters. The ppp_option_data struct also contains a `transmit'
field. If this is 0, the ioctl will affect the receive path,
otherwise the transmit path.
* PPPIOCGUNIT returns, in the int pointed to by the argument, the unit
number of this interface unit.
* PPPIOCSDEBUG sets the debug flags for the interface to the value in
the int pointed to by the argument. Only the least significant bit
is used; if this is 1 the generic layer will print some debug
messages during its operation. This is only intended for debugging
the generic PPP layer code; it is generally not helpful for working
out why a PPP connection is failing.
* PPPIOCGDEBUG returns the debug flags for the interface in the int
pointed to by the argument.
* PPPIOCGIDLE returns the time, in seconds, since the last data
packets were sent and received. The argument should point to a
ppp_idle structure (defined in <linux/ppp_defs.h>). If the
CONFIG_PPP_FILTER option is enabled, the set of packets which reset
the transmit and receive idle timers is restricted to those which
pass the `active' packet filter.
* PPPIOCSMAXCID sets the maximum connection-ID parameter (and thus the
number of connection slots) for the TCP header compressor and
decompressor. The lower 16 bits of the int pointed to by the
argument specify the maximum connection-ID for the compressor. If
the upper 16 bits of that int are non-zero, they specify the maximum
connection-ID for the decompressor, otherwise the decompressor's
maximum connection-ID is set to 15.
* PPPIOCSNPMODE sets the network-protocol mode for a given network
protocol. The argument should point to an npioctl struct (defined
in <linux/if_ppp.h>). The `protocol' field gives the PPP protocol
number for the protocol to be affected, and the `mode' field
specifies what to do with packets for that protocol:
NPMODE_PASS normal operation, transmit and receive packets
NPMODE_DROP silently drop packets for this protocol
NPMODE_ERROR drop packets and return an error on transmit
NPMODE_QUEUE queue up packets for transmit, drop received
packets
At present NPMODE_ERROR and NPMODE_QUEUE have the same effect as
NPMODE_DROP.
* PPPIOCGNPMODE returns the network-protocol mode for a given
protocol. The argument should point to an npioctl struct with the
`protocol' field set to the PPP protocol number for the protocol of
interest. On return the `mode' field will be set to the network-
protocol mode for that protocol.
* PPPIOCSPASS and PPPIOCSACTIVE set the `pass' and `active' packet
filters. These ioctls are only available if the CONFIG_PPP_FILTER
option is selected. The argument should point to a sock_fprog
structure (defined in <linux/filter.h>) containing the compiled BPF
instructions for the filter. Packets are dropped if they fail the
`pass' filter; otherwise, if they fail the `active' filter they are
passed but they do not reset the transmit or receive idle timer.
* PPPIOCSMRRU enables or disables multilink processing for received
packets and sets the multilink MRRU (maximum reconstructed receive
unit). The argument should point to an int containing the new MRRU
value. If the MRRU value is 0, processing of received multilink
fragments is disabled. This ioctl is only available if the
CONFIG_PPP_MULTILINK option is selected.
Last modified: 7-feb-2002

47
Documentation/networking/proc_net_tcp.txt Normal file
View File

@@ -0,0 +1,47 @@
This document describes the interfaces /proc/net/tcp and /proc/net/tcp6.
These /proc interfaces provide information about currently active TCP
connections, and are implemented by tcp_get_info() in net/ipv4/tcp_ipv4.c and
tcp6_get_info() in net/ipv6/tcp_ipv6.c, respectively.
It will first list all listening TCP sockets, and next list all established
TCP connections. A typical entry of /proc/net/tcp would look like this (split
up into 3 parts because of the length of the line):
46: 010310AC:9C4C 030310AC:1770 01
| | | | | |--> connection state
| | | | |------> remote TCP port number
| | | |-------------> remote IPv4 address
| | |--------------------> local TCP port number
| |---------------------------> local IPv4 address
|----------------------------------> number of entry
00000150:00000000 01:00000019 00000000
| | | | |--> number of unrecovered RTO timeouts
| | | |----------> number of jiffies until timer expires
| | |----------------> timer_active (see below)
| |----------------------> receive-queue
|-------------------------------> transmit-queue
1000 0 54165785 4 cd1e6040 25 4 27 3 -1
| | | | | | | | | |--> slow start size threshold,
| | | | | | | | | or -1 if the threshold
| | | | | | | | | is >= 0xFFFF
| | | | | | | | |----> sending congestion window
| | | | | | | |-------> (ack.quick<<1)|ack.pingpong
| | | | | | |---------> Predicted tick of soft clock
| | | | | | (delayed ACK control data)
| | | | | |------------> retransmit timeout
| | | | |------------------> location of socket in memory
| | | |-----------------------> socket reference count
| | |-----------------------------> inode
| |----------------------------------> unanswered 0-window probes
|---------------------------------------------> uid
timer_active:
0 no timer is pending
1 retransmit-timer is pending
2 another timer (e.g. delayed ack or keepalive) is pending
3 this is a socket in TIME_WAIT state. Not all fields will contain
data (or even exist)
4 zero window probe timer is pending

58
Documentation/networking/pt.txt Normal file
View File

@@ -0,0 +1,58 @@
This is the README for the Gracilis Packetwin device driver, version 0.5
ALPHA for Linux 1.3.43.
These files will allow you to talk to the PackeTwin (now know as PT) and
connect through it just like a pair of TNCs. To do this you will also
require the AX.25 code in the kernel enabled.
There are four files in this archive; this readme, a patch file, a .c file
and finally a .h file. The two program files need to be put into the
drivers/net directory in the Linux source tree, for me this is the
directory /usr/src/linux/drivers/net. The patch file needs to be patched in
at the top of the Linux source tree (/usr/src/linux in my case).
You will most probably have to edit the pt.c file to suit your own setup,
this should just involve changing some of the defines at the top of the file.
Please note that if you run an external modem you must specify a speed of 0.
The program is currently setup to run a 4800 baud external modem on port A
and a Kantronics DE-9600 daughter board on port B so if you have this (or
something similar) then you're right.
To compile in the driver, put the files in the correct place and patch in
the diff. You will have to re-configure the kernel again before you
recompile it.
The driver is not real good at the moment for finding the card. You can
'help' it by changing the order of the potential addresses in the structure
found in the pt_init() function so the address of where the card is is put
first.
After compiling, you have to get them going, they are pretty well like any
other net device and just need ifconfig to get them going.
As an example, here is my /etc/rc.net
--------------------------
#
# Configure the PackeTwin, port A.
/sbin/ifconfig pt0a 44.136.8.87 hw ax25 vk2xlz mtu 512
/sbin/ifconfig pt0a 44.136.8.87 broadcast 44.136.8.255 netmask 255.255.255.0
/sbin/route add -net 44.136.8.0 netmask 255.255.255.0 dev pt0a
/sbin/route add -net 44.0.0.0 netmask 255.0.0.0 gw 44.136.8.68 dev pt0a
/sbin/route add -net 138.25.16.0 netmask 255.255.240.0 dev pt0a
/sbin/route add -host 44.136.8.255 dev pt0a
#
# Configure the PackeTwin, port B.
/sbin/ifconfig pt0b 44.136.8.87 hw ax25 vk2xlz-1 mtu 512
/sbin/ifconfig pt0b 44.136.8.87 broadcast 44.255.255.255 netmask 255.0.0.0
/sbin/route add -host 44.136.8.216 dev pt0b
/sbin/route add -host 44.136.8.95 dev pt0b
/sbin/route add -host 44.255.255.255 dev pt0b
This version of the driver comes under the GNU GPL. If you have one of my
previous (non-GPL) versions of the driver, please update to this one.
I hope that this all works well for you. I would be pleased to hear how
many people use the driver and if it does its job.
- Craig vk2xlz <csmall@small.dropbear.id.au>

150
Documentation/networking/ray_cs.txt Normal file
View File

@@ -0,0 +1,150 @@
September 21, 1999
Copyright (c) 1998 Corey Thomas (corey@world.std.com)
This file is the documentation for the Raylink Wireless LAN card driver for
Linux. The Raylink wireless LAN card is a PCMCIA card which provides IEEE
802.11 compatible wireless network connectivity at 1 and 2 megabits/second.
See http://www.raytheon.com/micro/raylink/ for more information on the Raylink
card. This driver is in early development and does have bugs. See the known
bugs and limitations at the end of this document for more information.
This driver also works with WebGear's Aviator 2.4 and Aviator Pro
wireless LAN cards.
As of kernel 2.3.18, the ray_cs driver is part of the Linux kernel
source. My web page for the development of ray_cs is at
http://world.std.com/~corey/raylink.html and I can be emailed at
corey@world.std.com
The kernel driver is based on ray_cs-1.62.tgz
The driver at my web page is intended to be used as an add on to
David Hinds pcmcia package. All the command line parameters are
available when compiled as a module. When built into the kernel, only
the essid= string parameter is available via the kernel command line.
This will change after the method of sorting out parameters for all
the PCMCIA drivers is agreed upon. If you must have a built in driver
with nondefault parameters, they can be edited in
/usr/src/linux/drivers/net/pcmcia/ray_cs.c. Searching for module_param
will find them all.
Information on card services is available at:
http://pcmcia-cs.sourceforge.net/
Card services user programs are still required for PCMCIA devices.
pcmcia-cs-3.1.1 or greater is required for the kernel version of
the driver.
Currently, ray_cs is not part of David Hinds card services package,
so the following magic is required.
At the end of the /etc/pcmcia/config.opts file, add the line:
source ./ray_cs.opts
This will make card services read the ray_cs.opts file
when starting. Create the file /etc/pcmcia/ray_cs.opts containing the
following:
#### start of /etc/pcmcia/ray_cs.opts ###################
# Configuration options for Raylink Wireless LAN PCMCIA card
device "ray_cs"
class "network" module "misc/ray_cs"
card "RayLink PC Card WLAN Adapter"
manfid 0x01a6, 0x0000
bind "ray_cs"
module "misc/ray_cs" opts ""
#### end of /etc/pcmcia/ray_cs.opts #####################
To join an existing network with
different parameters, contact the network administrator for the
configuration information, and edit /etc/pcmcia/ray_cs.opts.
Add the parameters below between the empty quotes.
Parameters for ray_cs driver which may be specified in ray_cs.opts:
bc integer 0 = normal mode (802.11 timing)
1 = slow down inter frame timing to allow
operation with older breezecom access
points.
beacon_period integer beacon period in Kilo-microseconds
legal values = must be integer multiple
of hop dwell
default = 256
country integer 1 = USA (default)
2 = Europe
3 = Japan
4 = Korea
5 = Spain
6 = France
7 = Israel
8 = Australia
essid string ESS ID - network name to join
string with maximum length of 32 chars
default value = "ADHOC_ESSID"
hop_dwell integer hop dwell time in Kilo-microseconds
legal values = 16,32,64,128(default),256
irq_mask integer linux standard 16 bit value 1bit/IRQ
lsb is IRQ 0, bit 1 is IRQ 1 etc.
Used to restrict choice of IRQ's to use.
Recommended method for controlling
interrupts is in /etc/pcmcia/config.opts
net_type integer 0 (default) = adhoc network,
1 = infrastructure
phy_addr string string containing new MAC address in
hex, must start with x eg
x00008f123456
psm integer 0 = continuously active
1 = power save mode (not useful yet)
pc_debug integer (0-5) larger values for more verbose
logging. Replaces ray_debug.
ray_debug integer Replaced with pc_debug
ray_mem_speed integer defaults to 500
sniffer integer 0 = not sniffer (default)
1 = sniffer which can be used to record all
network traffic using tcpdump or similar,
but no normal network use is allowed.
translate integer 0 = no translation (encapsulate frames)
1 = translation (RFC1042/802.1)
More on sniffer mode:
tcpdump does not understand 802.11 headers, so it can't
interpret the contents, but it can record to a file. This is only
useful for debugging 802.11 lowlevel protocols that are not visible to
linux. If you want to watch ftp xfers, or do similar things, you
don't need to use sniffer mode. Also, some packet types are never
sent up by the card, so you will never see them (ack, rts, cts, probe
etc.) There is a simple program (showcap) included in the ray_cs
package which parses the 802.11 headers.
Known Problems and missing features
Does not work with non x86
Does not work with SMP
Support for defragmenting frames is not yet debugged, and in
fact is known to not work. I have never encountered a net set
up to fragment, but still, it should be fixed.
The ioctl support is incomplete. The hardware address cannot be set
using ifconfig yet. If a different hardware address is needed, it may
be set using the phy_addr parameter in ray_cs.opts. This requires
a card insertion to take effect.

46
Documentation/networking/routing.txt Normal file
View File

@@ -0,0 +1,46 @@
The directory ftp.inr.ac.ru:/ip-routing contains:
- iproute.c - "professional" routing table maintenance utility.
- rdisc.tar.gz - rdisc daemon, ported from Sun.
STRONGLY RECOMMENDED FOR ALL HOSTS.
- routing.tgz - original Mike McLagan's route by source patch.
Currently it is obsolete.
- gated.dif-ss<NEWEST>.gz - gated-R3_6Alpha_2 fixes.
Look at README.gated
- mrouted-3.8.dif.gz - mrouted-3.8 fixes.
- rtmon.c - trivial debugging utility: reads and stores netlink.
NEWS for user.
- Policy based routing. Routing decisions are made on the basis
not only of destination address, but also source address,
TOS and incoming interface.
- Complete set of IP level control messages.
Now Linux is the only OS in the world complying to RFC requirements.
Great win 8)
- New interface addressing paradigm.
Assignment of address ranges to interface,
multiple prefixes etc. etc.
Do not bother, it is compatible with the old one. Moreover:
- You don't need to do "route add aaa.bbb.ccc... eth0" anymore,
it is done automatically.
- "Abstract" UNIX sockets and security enhancements.
This is necessary to use TIRPC and TLI emulation library.
NEWS for hacker.
- New destination cache. Flexible, robust and just beautiful.
- Network stack is reordered, simplified, optimized, a lot of bugs fixed.
(well, and new bugs were introduced, but I haven't seen them yet 8))
It is difficult to describe all the changes, look into source.
If you see this file, then this patch works 8)
Alexey Kuznetsov.
kuznet@ms2.inr.ac.ru

153
Documentation/networking/s2io.txt Normal file
View File

@@ -0,0 +1,153 @@
Release notes for Neterion's (Formerly S2io) Xframe I/II PCI-X 10GbE driver.
Contents
=======
- 1. Introduction
- 2. Identifying the adapter/interface
- 3. Features supported
- 4. Command line parameters
- 5. Performance suggestions
- 6. Available Downloads
1. Introduction:
This Linux driver supports Neterion's Xframe I PCI-X 1.0 and
Xframe II PCI-X 2.0 adapters. It supports several features
such as jumbo frames, MSI/MSI-X, checksum offloads, TSO, UFO and so on.
See below for complete list of features.
All features are supported for both IPv4 and IPv6.
2. Identifying the adapter/interface:
a. Insert the adapter(s) in your system.
b. Build and load driver
# insmod s2io.ko
c. View log messages
# dmesg | tail -40
You will see messages similar to:
eth3: Neterion Xframe I 10GbE adapter (rev 3), Version 2.0.9.1, Intr type INTA
eth4: Neterion Xframe II 10GbE adapter (rev 2), Version 2.0.9.1, Intr type INTA
eth4: Device is on 64 bit 133MHz PCIX(M1) bus
The above messages identify the adapter type(Xframe I/II), adapter revision,
driver version, interface name(eth3, eth4), Interrupt type(INTA, MSI, MSI-X).
In case of Xframe II, the PCI/PCI-X bus width and frequency are displayed
as well.
To associate an interface with a physical adapter use "ethtool -p <ethX>".
The corresponding adapter's LED will blink multiple times.
3. Features supported:
a. Jumbo frames. Xframe I/II supports MTU upto 9600 bytes,
modifiable using ifconfig command.
b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit
and receive, TSO.
c. Multi-buffer receive mode. Scattering of packet across multiple
buffers. Currently driver supports 2-buffer mode which yields
significant performance improvement on certain platforms(SGI Altix,
IBM xSeries).
d. MSI/MSI-X. Can be enabled on platforms which support this feature
(IA64, Xeon) resulting in noticeable performance improvement(upto 7%
on certain platforms).
e. NAPI. Compile-time option(CONFIG_S2IO_NAPI) for better Rx interrupt
moderation.
f. Statistics. Comprehensive MAC-level and software statistics displayed
using "ethtool -S" option.
g. Multi-FIFO/Ring. Supports up to 8 transmit queues and receive rings,
with multiple steering options.
4. Command line parameters
a. tx_fifo_num
Number of transmit queues
Valid range: 1-8
Default: 1
b. rx_ring_num
Number of receive rings
Valid range: 1-8
Default: 1
c. tx_fifo_len
Size of each transmit queue
Valid range: Total length of all queues should not exceed 8192
Default: 4096
d. rx_ring_sz
Size of each receive ring(in 4K blocks)
Valid range: Limited by memory on system
Default: 30
e. intr_type
Specifies interrupt type. Possible values 1(INTA), 2(MSI), 3(MSI-X)
Valid range: 1-3
Default: 1
5. Performance suggestions
General:
a. Set MTU to maximum(9000 for switch setup, 9600 in back-to-back configuration)
b. Set TCP windows size to optimal value.
For instance, for MTU=1500 a value of 210K has been observed to result in
good performance.
# sysctl -w net.ipv4.tcp_rmem="210000 210000 210000"
# sysctl -w net.ipv4.tcp_wmem="210000 210000 210000"
For MTU=9000, TCP window size of 10 MB is recommended.
# sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000"
# sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000"
Transmit performance:
a. By default, the driver respects BIOS settings for PCI bus parameters.
However, you may want to experiment with PCI bus parameters
max-split-transactions(MOST) and MMRBC (use setpci command).
A MOST value of 2 has been found optimal for Opterons and 3 for Itanium.
It could be different for your hardware.
Set MMRBC to 4K**.
For example you can set
For opteron
#setpci -d 17d5:* 62=1d
For Itanium
#setpci -d 17d5:* 62=3d
For detailed description of the PCI registers, please see Xframe User Guide.
b. Ensure Transmit Checksum offload is enabled. Use ethtool to set/verify this
parameter.
c. Turn on TSO(using "ethtool -K")
# ethtool -K <ethX> tso on
Receive performance:
a. By default, the driver respects BIOS settings for PCI bus parameters.
However, you may want to set PCI latency timer to 248.
#setpci -d 17d5:* LATENCY_TIMER=f8
For detailed description of the PCI registers, please see Xframe User Guide.
b. Use 2-buffer mode. This results in large performance boost on
certain platforms(eg. SGI Altix, IBM xSeries).
c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to
set/verify this option.
d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network
device support ---> Ethernet (10000 Mbit) ---> S2IO 10Gbe Xframe NIC) to
bring down CPU utilization.
** For AMD opteron platforms with 8131 chipset, MMRBC=1 and MOST=1 are
recommended as safe parameters.
For more information, please review the AMD8131 errata at
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26310.pdf
6. Available Downloads
Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up
to date, also the latest "s2io" code (including support for 2.4 kernels) is
available via "Support" link on the Neterion site: http://www.neterion.com.
For Xframe User Guide (Programming manual), visit ftp site ns1.s2io.com,
user: linuxdocs password: HALdocs
7. Support
For further support please contact either your 10GbE Xframe NIC vendor (IBM,
HP, SGI etc.) or click on the "Support" link on the Neterion site:
http://www.neterion.com.

38
Documentation/networking/sctp.txt Normal file
View File

@@ -0,0 +1,38 @@
Linux Kernel SCTP
This is the current BETA release of the Linux Kernel SCTP reference
implementation.
SCTP (Stream Control Transmission Protocol) is a IP based, message oriented,
reliable transport protocol, with congestion control, support for
transparent multi-homing, and multiple ordered streams of messages.
RFC2960 defines the core protocol. The IETF SIGTRAN working group originally
developed the SCTP protocol and later handed the protocol over to the
Transport Area (TSVWG) working group for the continued evolvement of SCTP as a
general purpose transport.
See the IETF website (http://www.ietf.org) for further documents on SCTP.
See http://www.ietf.org/rfc/rfc2960.txt
The initial project goal is to create an Linux kernel reference implementation
of SCTP that is RFC 2960 compliant and provides an programming interface
referred to as the UDP-style API of the Sockets Extensions for SCTP, as
proposed in IETF Internet-Drafts.
Caveats:
-lksctp can be built as statically or as a module. However, be aware that
module removal of lksctp is not yet a safe activity.
-There is tentative support for IPv6, but most work has gone towards
implementation and testing lksctp on IPv4.
For more information, please visit the lksctp project website:
http://www.sf.net/projects/lksctp
Or contact the lksctp developers through the mailing list:
<lksctp-developers@lists.sourceforge.net>

14
Documentation/networking/secid.txt Normal file
View File

@@ -0,0 +1,14 @@
flowi structure:
The secid member in the flow structure is used in LSMs (e.g. SELinux) to indicate
the label of the flow. This label of the flow is currently used in selecting
matching labeled xfrm(s).
If this is an outbound flow, the label is derived from the socket, if any, or
the incoming packet this flow is being generated as a response to (e.g. tcp
resets, timewait ack, etc.). It is also conceivable that the label could be
derived from other sources such as process context, device, etc., in special
cases, as may be appropriate.
If this is an inbound flow, the label is derived from the IPSec security
associations, if any, used by the packet.

48
Documentation/networking/shaper.txt Normal file
View File

@@ -0,0 +1,48 @@
Traffic Shaper For Linux
This is the current BETA release of the traffic shaper for Linux. It works
within the following limits:
o Minimum shaping speed is currently about 9600 baud (it can only
shape down to 1 byte per clock tick)
o Maximum is about 256K, it will go above this but get a bit blocky.
o If you ifconfig the master device that a shaper is attached to down
then your machine will follow.
o The shaper must be a module.
Setup:
A shaper device is configured using the shapeconfig program.
Typically you will do something like this
shapecfg attach shaper0 eth1
shapecfg speed shaper0 64000
ifconfig shaper0 myhost netmask 255.255.255.240 broadcast 1.2.3.4.255 up
route add -net some.network netmask a.b.c.d dev shaper0
The shaper should have the same IP address as the device it is attached to
for normal use.
Gotchas:
The shaper shapes transmitted traffic. It's rather impossible to
shape received traffic except at the end (or a router) transmitting it.
Gated/routed/rwhod/mrouted all see the shaper as an additional device
and will treat it as such unless patched. Note that for mrouted you can run
mrouted tunnels via a traffic shaper to control bandwidth usage.
The shaper is device/route based. This makes it very easy to use
with any setup BUT less flexible. You may need to use iproute2 to set up
multiple route tables to get the flexibility.
There is no "borrowing" or "sharing" scheme. This is a simple
traffic limiter. We implement Van Jacobson and Sally Floyd's CBQ
architecture into Linux 2.2. This is the preferred solution. Shaper is
for simple or back compatible setups.
Alan

568
Documentation/networking/sk98lin.txt Normal file
View File

@@ -0,0 +1,568 @@
(C)Copyright 1999-2004 Marvell(R).
All rights reserved
===========================================================================
sk98lin.txt created 13-Feb-2004
Readme File for sk98lin v6.23
Marvell Yukon/SysKonnect SK-98xx Gigabit Ethernet Adapter family driver for LINUX
This file contains
1 Overview
2 Required Files
3 Installation
3.1 Driver Installation
3.2 Inclusion of adapter at system start
4 Driver Parameters
4.1 Per-Port Parameters
4.2 Adapter Parameters
5 Large Frame Support
6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
7 Troubleshooting
===========================================================================
1 Overview
===========
The sk98lin driver supports the Marvell Yukon and SysKonnect
SK-98xx/SK-95xx compliant Gigabit Ethernet Adapter on Linux. It has
been tested with Linux on Intel/x86 machines.
***
2 Required Files
=================
The linux kernel source.
No additional files required.
***
3 Installation
===============
It is recommended to download the latest version of the driver from the
SysKonnect web site www.syskonnect.com. If you have downloaded the latest
driver, the Linux kernel has to be patched before the driver can be
installed. For details on how to patch a Linux kernel, refer to the
patch.txt file.
3.1 Driver Installation
------------------------
The following steps describe the actions that are required to install
the driver and to start it manually. These steps should be carried
out for the initial driver setup. Once confirmed to be ok, they can
be included in the system start.
NOTE 1: To perform the following tasks you need 'root' access.
NOTE 2: In case of problems, please read the section "Troubleshooting"
below.
The driver can either be integrated into the kernel or it can be compiled
as a module. Select the appropriate option during the kernel
configuration.
Compile/use the driver as a module
----------------------------------
To compile the driver, go to the directory /usr/src/linux and
execute the command "make menuconfig" or "make xconfig" and proceed as
follows:
To integrate the driver permanently into the kernel, proceed as follows:
1. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
2. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support"
with (*)
3. Build a new kernel when the configuration of the above options is
finished.
4. Install the new kernel.
5. Reboot your system.
To use the driver as a module, proceed as follows:
1. Enable 'loadable module support' in the kernel.
2. For automatic driver start, enable the 'Kernel module loader'.
3. Select the menu "Network device support" and then "Ethernet(1000Mbit)"
4. Mark "Marvell Yukon Chipset / SysKonnect SK-98xx family support"
with (M)
5. Execute the command "make modules".
6. Execute the command "make modules_install".
The appropriate modules will be installed.
7. Reboot your system.
Load the module manually
------------------------
To load the module manually, proceed as follows:
1. Enter "modprobe sk98lin".
2. If a Marvell Yukon or SysKonnect SK-98xx adapter is installed in
your computer and you have a /proc file system, execute the command:
"ls /proc/net/sk98lin/"
This should produce an output containing a line with the following
format:
eth0 eth1 ...
which indicates that your adapter has been found and initialized.
NOTE 1: If you have more than one Marvell Yukon or SysKonnect SK-98xx
adapter installed, the adapters will be listed as 'eth0',
'eth1', 'eth2', etc.
For each adapter, repeat steps 3 and 4 below.
NOTE 2: If you have other Ethernet adapters installed, your Marvell
Yukon or SysKonnect SK-98xx adapter will be mapped to the
next available number, e.g. 'eth1'. The mapping is executed
automatically.
The module installation message (displayed either in a system
log file or on the console) prints a line for each adapter
found containing the corresponding 'ethX'.
3. Select an IP address and assign it to the respective adapter by
entering:
ifconfig eth0 <ip-address>
With this command, the adapter is connected to the Ethernet.
SK-98xx Gigabit Ethernet Server Adapters: The yellow LED on the adapter
is now active, the link status LED of the primary port is active and
the link status LED of the secondary port (on dual port adapters) is
blinking (if the ports are connected to a switch or hub).
SK-98xx V2.0 Gigabit Ethernet Adapters: The link status LED is active.
In addition, you will receive a status message on the console stating
"ethX: network connection up using port Y" and showing the selected
connection parameters (x stands for the ethernet device number
(0,1,2, etc), y stands for the port name (A or B)).
NOTE: If you are in doubt about IP addresses, ask your network
administrator for assistance.
4. Your adapter should now be fully operational.
Use 'ping <otherstation>' to verify the connection to other computers
on your network.
5. To check the adapter configuration view /proc/net/sk98lin/[devicename].
For example by executing:
"cat /proc/net/sk98lin/eth0"
Unload the module
-----------------
To stop and unload the driver modules, proceed as follows:
1. Execute the command "ifconfig eth0 down".
2. Execute the command "rmmod sk98lin".
3.2 Inclusion of adapter at system start
-----------------------------------------
Since a large number of different Linux distributions are
available, we are unable to describe a general installation procedure
for the driver module.
Because the driver is now integrated in the kernel, installation should
be easy, using the standard mechanism of your distribution.
Refer to the distribution's manual for installation of ethernet adapters.
***
4 Driver Parameters
====================
Parameters can be set at the command line after the module has been
loaded with the command 'modprobe'.
In some distributions, the configuration tools are able to pass parameters
to the driver module.
If you use the kernel module loader, you can set driver parameters
in the file /etc/modprobe.conf (or /etc/modules.conf in 2.4 or earlier).
To set the driver parameters in this file, proceed as follows:
1. Insert a line of the form :
options sk98lin ...
For "...", the same syntax is required as described for the command
line parameters of modprobe below.
2. To activate the new parameters, either reboot your computer
or
unload and reload the driver.
The syntax of the driver parameters is:
modprobe sk98lin parameter=value1[,value2[,value3...]]
where value1 refers to the first adapter, value2 to the second etc.
NOTE: All parameters are case sensitive. Write them exactly as shown
below.
Example:
Suppose you have two adapters. You want to set auto-negotiation
on the first adapter to ON and on the second adapter to OFF.
You also want to set DuplexCapabilities on the first adapter
to FULL, and on the second adapter to HALF.
Then, you must enter:
modprobe sk98lin AutoNeg_A=On,Off DupCap_A=Full,Half
NOTE: The number of adapters that can be configured this way is
limited in the driver (file skge.c, constant SK_MAX_CARD_PARAM).
The current limit is 16. If you happen to install
more adapters, adjust this and recompile.
4.1 Per-Port Parameters
------------------------
These settings are available for each port on the adapter.
In the following description, '?' stands for the port for
which you set the parameter (A or B).
Speed
-----
Parameter: Speed_?
Values: 10, 100, 1000, Auto
Default: Auto
This parameter is used to set the speed capabilities. It is only valid
for the SK-98xx V2.0 copper adapters.
Usually, the speed is negotiated between the two ports during link
establishment. If this fails, a port can be forced to a specific setting
with this parameter.
Auto-Negotiation
----------------
Parameter: AutoNeg_?
Values: On, Off, Sense
Default: On
The "Sense"-mode automatically detects whether the link partner supports
auto-negotiation or not.
Duplex Capabilities
-------------------
Parameter: DupCap_?
Values: Half, Full, Both
Default: Both
This parameters is only relevant if auto-negotiation for this port is
not set to "Sense". If auto-negotiation is set to "On", all three values
are possible. If it is set to "Off", only "Full" and "Half" are allowed.
This parameter is useful if your link partner does not support all
possible combinations.
Flow Control
------------
Parameter: FlowCtrl_?
Values: Sym, SymOrRem, LocSend, None
Default: SymOrRem
This parameter can be used to set the flow control capabilities the
port reports during auto-negotiation. It can be set for each port
individually.
Possible modes:
-- Sym = Symmetric: both link partners are allowed to send
PAUSE frames
-- SymOrRem = SymmetricOrRemote: both or only remote partner
are allowed to send PAUSE frames
-- LocSend = LocalSend: only local link partner is allowed
to send PAUSE frames
-- None = no link partner is allowed to send PAUSE frames
NOTE: This parameter is ignored if auto-negotiation is set to "Off".
Role in Master-Slave-Negotiation (1000Base-T only)
--------------------------------------------------
Parameter: Role_?
Values: Auto, Master, Slave
Default: Auto
This parameter is only valid for the SK-9821 and SK-9822 adapters.
For two 1000Base-T ports to communicate, one must take the role of the
master (providing timing information), while the other must be the
slave. Usually, this is negotiated between the two ports during link
establishment. If this fails, a port can be forced to a specific setting
with this parameter.
4.2 Adapter Parameters
-----------------------
Connection Type (SK-98xx V2.0 copper adapters only)
---------------
Parameter: ConType
Values: Auto, 100FD, 100HD, 10FD, 10HD
Default: Auto
The parameter 'ConType' is a combination of all five per-port parameters
within one single parameter. This simplifies the configuration of both ports
of an adapter card! The different values of this variable reflect the most
meaningful combinations of port parameters.
The following table shows the values of 'ConType' and the corresponding
combinations of the per-port parameters:
ConType | DupCap AutoNeg FlowCtrl Role Speed
----------+------------------------------------------------------
Auto | Both On SymOrRem Auto Auto
100FD | Full Off None Auto (ignored) 100
100HD | Half Off None Auto (ignored) 100
10FD | Full Off None Auto (ignored) 10
10HD | Half Off None Auto (ignored) 10
Stating any other port parameter together with this 'ConType' variable
will result in a merged configuration of those settings. This due to
the fact, that the per-port parameters (e.g. Speed_? ) have a higher
priority than the combined variable 'ConType'.
NOTE: This parameter is always used on both ports of the adapter card.
Interrupt Moderation
--------------------
Parameter: Moderation
Values: None, Static, Dynamic
Default: None
Interrupt moderation is employed to limit the maximum number of interrupts
the driver has to serve. That is, one or more interrupts (which indicate any
transmit or receive packet to be processed) are queued until the driver
processes them. When queued interrupts are to be served, is determined by the
'IntsPerSec' parameter, which is explained later below.
Possible modes:
-- None - No interrupt moderation is applied on the adapter card.
Therefore, each transmit or receive interrupt is served immediately
as soon as it appears on the interrupt line of the adapter card.
-- Static - Interrupt moderation is applied on the adapter card.
All transmit and receive interrupts are queued until a complete
moderation interval ends. If such a moderation interval ends, all
queued interrupts are processed in one big bunch without any delay.
The term 'static' reflects the fact, that interrupt moderation is
always enabled, regardless how much network load is currently
passing via a particular interface. In addition, the duration of
the moderation interval has a fixed length that never changes while
the driver is operational.
-- Dynamic - Interrupt moderation might be applied on the adapter card,
depending on the load of the system. If the driver detects that the
system load is too high, the driver tries to shield the system against
too much network load by enabling interrupt moderation. If - at a later
time - the CPU utilization decreases again (or if the network load is
negligible) the interrupt moderation will automatically be disabled.
Interrupt moderation should be used when the driver has to handle one or more
interfaces with a high network load, which - as a consequence - leads also to a
high CPU utilization. When moderation is applied in such high network load
situations, CPU load might be reduced by 20-30%.
NOTE: The drawback of using interrupt moderation is an increase of the round-
trip-time (RTT), due to the queueing and serving of interrupts at dedicated
moderation times.
Interrupts per second
---------------------
Parameter: IntsPerSec
Values: 30...40000 (interrupts per second)
Default: 2000
This parameter is only used if either static or dynamic interrupt moderation
is used on a network adapter card. Using this parameter if no moderation is
applied will lead to no action performed.
This parameter determines the length of any interrupt moderation interval.
Assuming that static interrupt moderation is to be used, an 'IntsPerSec'
parameter value of 2000 will lead to an interrupt moderation interval of
500 microseconds.
NOTE: The duration of the moderation interval is to be chosen with care.
At first glance, selecting a very long duration (e.g. only 100 interrupts per
second) seems to be meaningful, but the increase of packet-processing delay
is tremendous. On the other hand, selecting a very short moderation time might
compensate the use of any moderation being applied.
Preferred Port
--------------
Parameter: PrefPort
Values: A, B
Default: A
This is used to force the preferred port to A or B (on dual-port network
adapters). The preferred port is the one that is used if both are detected
as fully functional.
RLMT Mode (Redundant Link Management Technology)
------------------------------------------------
Parameter: RlmtMode
Values: CheckLinkState,CheckLocalPort, CheckSeg, DualNet
Default: CheckLinkState
RLMT monitors the status of the port. If the link of the active port
fails, RLMT switches immediately to the standby link. The virtual link is
maintained as long as at least one 'physical' link is up.
Possible modes:
-- CheckLinkState - Check link state only: RLMT uses the link state
reported by the adapter hardware for each individual port to
determine whether a port can be used for all network traffic or
not.
-- CheckLocalPort - In this mode, RLMT monitors the network path
between the two ports of an adapter by regularly exchanging packets
between them. This mode requires a network configuration in which
the two ports are able to "see" each other (i.e. there must not be
any router between the ports).
-- CheckSeg - Check local port and segmentation: This mode supports the
same functions as the CheckLocalPort mode and additionally checks
network segmentation between the ports. Therefore, this mode is only
to be used if Gigabit Ethernet switches are installed on the network
that have been configured to use the Spanning Tree protocol.
-- DualNet - In this mode, ports A and B are used as separate devices.
If you have a dual port adapter, port A will be configured as eth0
and port B as eth1. Both ports can be used independently with
distinct IP addresses. The preferred port setting is not used.
RLMT is turned off.
NOTE: RLMT modes CLP and CLPSS are designed to operate in configurations
where a network path between the ports on one adapter exists.
Moreover, they are not designed to work where adapters are connected
back-to-back.
***
5 Large Frame Support
======================
The driver supports large frames (also called jumbo frames). Using large
frames can result in an improved throughput if transferring large amounts
of data.
To enable large frames, set the MTU (maximum transfer unit) of the
interface to the desired value (up to 9000), execute the following
command:
ifconfig eth0 mtu 9000
This will only work if you have two adapters connected back-to-back
or if you use a switch that supports large frames. When using a switch,
it should be configured to allow large frames and auto-negotiation should
be set to OFF. The setting must be configured on all adapters that can be
reached by the large frames. If one adapter is not set to receive large
frames, it will simply drop them.
You can switch back to the standard ethernet frame size by executing the
following command:
ifconfig eth0 mtu 1500
To permanently configure this setting, add a script with the 'ifconfig'
line to the system startup sequence (named something like "S99sk98lin"
in /etc/rc.d/rc2.d).
***
6 VLAN and Link Aggregation Support (IEEE 802.1, 802.1q, 802.3ad)
==================================================================
The Marvell Yukon/SysKonnect Linux drivers are able to support VLAN and
Link Aggregation according to IEEE standards 802.1, 802.1q, and 802.3ad.
These features are only available after installation of open source
modules available on the Internet:
For VLAN go to: http://www.candelatech.com/~greear/vlan.html
For Link Aggregation go to: http://www.st.rim.or.jp/~yumo
NOTE: SysKonnect GmbH does not offer any support for these open source
modules and does not take the responsibility for any kind of
failures or problems arising in connection with these modules.
NOTE: Configuring Link Aggregation on a SysKonnect dual link adapter may
cause problems when unloading the driver.
7 Troubleshooting
==================
If any problems occur during the installation process, check the
following list:
Problem: The SK-98xx adapter cannot be found by the driver.
Solution: In /proc/pci search for the following entry:
'Ethernet controller: SysKonnect SK-98xx ...'
If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has
been found by the system and should be operational.
If this entry does not exist or if the file '/proc/pci' is not
found, there may be a hardware problem or the PCI support may
not be enabled in your kernel.
The adapter can be checked using the diagnostics program which
is available on the SysKonnect web site:
www.syskonnect.com
Some COMPAQ machines have problems dealing with PCI under Linux.
This problem is described in the 'PCI howto' document
(included in some distributions or available from the
web, e.g. at 'www.linux.org').
Problem: Programs such as 'ifconfig' or 'route' cannot be found or the
error message 'Operation not permitted' is displayed.
Reason: You are not logged in as user 'root'.
Solution: Logout and login as 'root' or change to 'root' via 'su'.
Problem: Upon use of the command 'ping <address>' the message
"ping: sendto: Network is unreachable" is displayed.
Reason: Your route is not set correctly.
Solution: If you are using RedHat, you probably forgot to set up the
route in the 'network configuration'.
Check the existing routes with the 'route' command and check
if an entry for 'eth0' exists, and if so, if it is set correctly.
Problem: The driver can be started, the adapter is connected to the
network, but you cannot receive or transmit any packets;
e.g. 'ping' does not work.
Reason: There is an incorrect route in your routing table.
Solution: Check the routing table with the command 'route' and read the
manual help pages dealing with routes (enter 'man route').
NOTE: Although the 2.2.x kernel versions generate the routing entry
automatically, problems of this kind may occur here as well. We've
come across a situation in which the driver started correctly at
system start, but after the driver has been removed and reloaded,
the route of the adapter's network pointed to the 'dummy0'device
and had to be corrected manually.
Problem: Your computer should act as a router between multiple
IP subnetworks (using multiple adapters), but computers in
other subnetworks cannot be reached.
Reason: Either the router's kernel is not configured for IP forwarding
or the routing table and gateway configuration of at least one
computer is not working.
Problem: Upon driver start, the following error message is displayed:
"eth0: -- ERROR --
Class: internal Software error
Nr: 0xcc
Msg: SkGeInitPort() cannot init running ports"
Reason: You are using a driver compiled for single processor machines
on a multiprocessor machine with SMP (Symmetric MultiProcessor)
kernel.
Solution: Configure your kernel appropriately and recompile the kernel or
the modules.
If your problem is not listed here, please contact SysKonnect's technical
support for help (linux@syskonnect.de).
When contacting our technical support, please ensure that the following
information is available:
- System Manufacturer and HW Informations (CPU, Memory... )
- PCI-Boards in your system
- Distribution
- Kernel version
- Driver version
***
***End of Readme File***

220
Documentation/networking/skfp.txt Normal file
View File

@@ -0,0 +1,220 @@
(C)Copyright 1998-2000 SysKonnect,
===========================================================================
skfp.txt created 11-May-2000
Readme File for skfp.o v2.06
This file contains
(1) OVERVIEW
(2) SUPPORTED ADAPTERS
(3) GENERAL INFORMATION
(4) INSTALLATION
(5) INCLUSION OF THE ADAPTER IN SYSTEM START
(6) TROUBLESHOOTING
(7) FUNCTION OF THE ADAPTER LEDS
(8) HISTORY
===========================================================================
(1) OVERVIEW
============
This README explains how to use the driver 'skfp' for Linux with your
network adapter.
Chapter 2: Contains a list of all network adapters that are supported by
this driver.
Chapter 3: Gives some general information.
Chapter 4: Describes common problems and solutions.
Chapter 5: Shows the changed functionality of the adapter LEDs.
Chapter 6: History of development.
***
(2) SUPPORTED ADAPTERS
======================
The network driver 'skfp' supports the following network adapters:
SysKonnect adapters:
- SK-5521 (SK-NET FDDI-UP)
- SK-5522 (SK-NET FDDI-UP DAS)
- SK-5541 (SK-NET FDDI-FP)
- SK-5543 (SK-NET FDDI-LP)
- SK-5544 (SK-NET FDDI-LP DAS)
- SK-5821 (SK-NET FDDI-UP64)
- SK-5822 (SK-NET FDDI-UP64 DAS)
- SK-5841 (SK-NET FDDI-FP64)
- SK-5843 (SK-NET FDDI-LP64)
- SK-5844 (SK-NET FDDI-LP64 DAS)
Compaq adapters (not tested):
- Netelligent 100 FDDI DAS Fibre SC
- Netelligent 100 FDDI SAS Fibre SC
- Netelligent 100 FDDI DAS UTP
- Netelligent 100 FDDI SAS UTP
- Netelligent 100 FDDI SAS Fibre MIC
***
(3) GENERAL INFORMATION
=======================
From v2.01 on, the driver is integrated in the linux kernel sources.
Therefor, the installation is the same as for any other adapter
supported by the kernel.
Refer to the manual of your distribution about the installation
of network adapters.
Makes my life much easier :-)
***
(4) TROUBLESHOOTING
===================
If you run into problems during installation, check those items:
Problem: The FDDI adapter cannot be found by the driver.
Reason: Look in /proc/pci for the following entry:
'FDDI network controller: SysKonnect SK-FDDI-PCI ...'
If this entry exists, then the FDDI adapter has been
found by the system and should be able to be used.
If this entry does not exist or if the file '/proc/pci'
is not there, then you may have a hardware problem or PCI
support may not be enabled in your kernel.
The adapter can be checked using the diagnostic program
which is available from the SysKonnect web site:
www.syskonnect.de
Some COMPAQ machines have a problem with PCI under
Linux. This is described in the 'PCI howto' document
(included in some distributions or available from the
www, e.g. at 'www.linux.org') and no workaround is available.
Problem: You want to use your computer as a router between
multiple IP subnetworks (using multiple adapters), but
you cannot reach computers in other subnetworks.
Reason: Either the router's kernel is not configured for IP
forwarding or there is a problem with the routing table
and gateway configuration in at least one of the
computers.
If your problem is not listed here, please contact our
technical support for help.
You can send email to:
linux@syskonnect.de
When contacting our technical support,
please ensure that the following information is available:
- System Manufacturer and Model
- Boards in your system
- Distribution
- Kernel version
***
(5) FUNCTION OF THE ADAPTER LEDS
================================
The functionality of the LED's on the FDDI network adapters was
changed in SMT version v2.82. With this new SMT version, the yellow
LED works as a ring operational indicator. An active yellow LED
indicates that the ring is down. The green LED on the adapter now
works as a link indicator where an active GREEN LED indicates that
the respective port has a physical connection.
With versions of SMT prior to v2.82 a ring up was indicated if the
yellow LED was off while the green LED(s) showed the connection
status of the adapter. During a ring down the green LED was off and
the yellow LED was on.
All implementations indicate that a driver is not loaded if
all LEDs are off.
***
(6) HISTORY
===========
v2.06 (20000511) (In-Kernel version)
New features:
- 64 bit support
- new pci dma interface
- in kernel 2.3.99
v2.05 (20000217) (In-Kernel version)
New features:
- Changes for 2.3.45 kernel
v2.04 (20000207) (Standalone version)
New features:
- Added rx/tx byte counter
v2.03 (20000111) (Standalone version)
Problems fixed:
- Fixed printk statements from v2.02
v2.02 (991215) (Standalone version)
Problems fixed:
- Removed unnecessary output
- Fixed path for "printver.sh" in makefile
v2.01 (991122) (In-Kernel version)
New features:
- Integration in Linux kernel sources
- Support for memory mapped I/O.
v2.00 (991112)
New features:
- Full source released under GPL
v1.05 (991023)
Problems fixed:
- Compilation with kernel version 2.2.13 failed
v1.04 (990427)
Changes:
- New SMT module included, changing LED functionality
Problems fixed:
- Synchronization on SMP machines was buggy
v1.03 (990325)
Problems fixed:
- Interrupt routing on SMP machines could be incorrect
v1.02 (990310)
New features:
- Support for kernel versions 2.2.x added
- Kernel patch instead of private duplicate of kernel functions
v1.01 (980812)
Problems fixed:
Connection hangup with telnet
Slow telnet connection
v1.00 beta 01 (980507)
New features:
None.
Problems fixed:
None.
Known limitations:
- tar archive instead of standard package format (rpm).
- FDDI statistic is empty.
- not tested with 2.1.xx kernels
- integration in kernel not tested
- not tested simultaneously with FDDI adapters from other vendors.
- only X86 processors supported.
- SBA (Synchronous Bandwidth Allocator) parameters can
not be configured.
- does not work on some COMPAQ machines. See the PCI howto
document for details about this problem.
- data corruption with kernel versions below 2.0.33.
*** End of information file ***

371
Documentation/networking/slicecom.hun Normal file
View File

@@ -0,0 +1,371 @@
SliceCOM adapter felhasznaloi dokumentacioja - 0.51 verziohoz
Bart<EFBFBD>k Istv<74>n <bartoki@itc.hu>
Utolso modositas: Wed Aug 29 17:26:58 CEST 2001
-----------------------------------------------------------------
Hasznalata:
Forditas:
Code maturity level options
[*] Prompt for development and/or incomplete code/drivers
Network device support
Wan interfaces
<M> MultiGate (COMX) synchronous
<M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
<M> Support for HDLC and syncPPP...
A modulok betoltese:
modprobe comx
modprobe comx-proto-ppp # a Cisco-HDLC es a SyncPPP protokollt is
# ez a modul adja
modprobe comx-hw-munich # a modul betoltodeskor azonnal jelent a
# syslogba a detektalt kartyakrol
Konfiguralas:
# Ezen az interfeszen Cisco-HDLC vonali protokoll fog futni
# Az interfeszhez rendelt idoszeletek: 1,2 (128 kbit/sec-es vonal)
# (a G.703 keretben az elso adatot vivo idoszelet az 1-es)
#
mkdir /proc/comx/comx0.1/
echo slicecom >/proc/comx/comx0.1/boardtype
echo hdlc >/proc/comx/comx0.1/protocol
echo 1 2 >/proc/comx/comx0.1/timeslots
# Ezen az interfeszen SyncPPP vonali protokoll fog futni
# Az interfeszhez rendelt idoszelet: 3 (64 kbit/sec-es vonal)
#
mkdir /proc/comx/comx0.2/
echo slicecom >/proc/comx/comx0.2/boardtype
echo ppp >/proc/comx/comx0.2/protocol
echo 3 >/proc/comx/comx0.2/timeslots
...
ifconfig comx0.1 up
ifconfig comx0.2 up
-----------------------------------------------------------------
A COMX driverek default 20 csomagnyi transmit queue-t rendelnek a halozati
interfeszekhez. WAN halozatokban ennel hosszabbat is szokas hasznalni
(20 es 100 kozott), hogy a vonal kihasznaltsaga nagy terheles eseten jobb
legyen (bar ezzel megno a varhato kesleltetes a csomagok sorban allasa miatt):
# ifconfig comx0 txqueuelen 50
Ezt a beallitasi lehetoseget csak az ujabb disztribuciok ifconfig parancsa
tamogatja (amik mar a 2.2 kernelekhez keszultek, mint a RedHat 6.1 vagy a
Debian 2.2).
A 2.1-es Debian disztribuciohoz a http://www.debian.org/~rcw/2.2/netbase/
cimrol toltheto le ujabb netbase csomag, ami mar ilyet tamogato ifconfig
parancsot tartalmaz. Bovebben a 2.2 kernel hasznalatarol Debian 2.1 alatt:
http://www.debian.org/releases/stable/running-kernel-2.2
-----------------------------------------------------------------
A kartya LED-jeinek jelentese:
piros - eg, ha Remote Alarm-ot kuld a tuloldal
zold - eg, ha a vett jelben megtalalja a keretszinkront
Reszletesebben:
piros: zold: jelentes:
- - nincs keretszinkron (nincs jel, vagy rossz a jel)
- eg "minden rendben"
eg eg a vetel OK, de a tuloldal Remote Alarm-ot kuld
eg - ez nincs ertelmezve, egyelore funkcio nelkul
-----------------------------------------------------------------
Reszletesebb leiras a hardver beallitasi lehetosegeirol:
Az altalanos,- es a protokoll-retegek beallitasi lehetosegeirol a 'comx.txt'
fajlban leirtak SliceCOM kartyanal is ervenyesek, itt csak a hardver-specifikus
beallitasi lehetosegek vannak osszefoglalva:
Konfiguralasi interfesz a /proc/comx/ alatt:
Minden timeslot-csoportnak kulon comx* interfeszt kell letrehozni mkdir-rel:
comx0, comx1, .. stb. Itt beallithato, hogy az adott interfesz hanyadik kartya
melyik timeslotja(i)bol alljon ossze. A Cisco-fele serial3:1 elnevezesek
(serial3:1 = a 3. kartyaban az 1-es idoszelet-csoport) Linuxon aliasing-ot
jelentenenek, ezert mi nem tudunk ilyen elnevezest hasznalni.
Tobb kartya eseten a comx0.1, comx0.2, ... vagy slice0.1, slice0.2 nevek
hasznalhatoak.
Tobb SliceCOM kartya is lehet egy gepben, de sajat interrupt kell mindegyiknek,
nem tud meg megosztott interruptot kezelni.
Az egesz kartyat erinto beallitasok:
Az ioport es irq beallitas nincs: amit a PCI BIOS kioszt a rendszernek,
azt hasznalja a driver.
comx0/boardnum - hanyadik SliceCOM kartya a gepben (a 'termeszetes' PCI
sorrendben ertve: ahogyan a /proc/pci-ban vagy az 'lspci'
kimeneteben megjelenik, altalaban az alaplapi PCI meghajto
aramkorokhoz kozelebb eso kartyak a kisebb sorszamuak)
Default: 0 (0-tol kezdodik a szamolas)
Bar a kovetkezoket csak egy-egy interfeszen allitjuk at, megis az egesz kartya
mukodeset egyszerre allitjak. A megkotes hogy csak UP-ban levo interfeszen
hasznalhatoak, azert van, mert kulonben nem vart eredmenyekre vezetne egy ilyen
paranccsorozat:
echo 0 >boardnum
echo internal >clock_source
echo 1 >boardnum
- Ez a 0-s board clock_source-at allitana at.
Ezek a beallitasok megmaradnak az osszes interfesz torlesekor, de torlodnek
a driver modul ki/betoltesekor.
comx0/clock_source - A Tx orajelforrasa, a Cisco-val hasonlatosra keszult.
Hasznalata:
papaya:# echo line >/proc/comx/comx0/clock_source
papaya:# echo internal >/proc/comx/comx0/clock_source
line - A Tx orajelet a vett adatfolyambol dekodolja, igyekszik
igazodni hozza. Ha nem lat orajelet az inputon, akkor
atall a sajat orajelgeneratorara.
internal - A Tx orajelet a sajat orajelgeneratora szolgaltatja.
Default: line
Normal osszeallitas eseten a tavkozlesi szolgaltato eszkoze
(pl. HDSL modem) adja az orajelet, ezert ez a default.
comx0/framing - A CRC4 ki/be kapcsolasa
A CRC4: 16 PCM keretet (A PCM keret az, amibe a 32 darab 64
kilobites csatorna van bemultiplexalva. Nem osszetevesztendo a HDLC
kerettel.) 2x8 -as csoportokra osztanak, es azokhoz 4-4 bites CRC-t
szamolnak. Elsosorban a vonal minosegenek a monitorozasara szolgal.
papaya:~# echo crc4 >/proc/comx/comx0/framing
papaya:~# echo no-crc4 >/proc/comx/comx0/framing
Default a 'crc4', a MATAV vonalak altalaban igy futnak. De ha nem
egyforma is a beallitas a vonal ket vegen, attol a forgalom altalaban
at tud menni.
comx0/linecode - A vonali kodolas beallitasa
papaya:~# echo hdb3 >/proc/comx/comx0/linecode
papaya:~# echo ami >/proc/comx/comx0/linecode
Default a 'hdb3', a MATAV vonalak igy futnak.
(az AMI kodolas igen ritka E1-es vonalaknal). Ha ez a beallitas nem
egyezik a vonal ket vegen, akkor elofordulhat hogy a keretszinkron
osszejon, de CRC4-hibak es a vonalakon atvitt adatokban is hibak
keletkeznek (amit a HDLC/SyncPPP szinten CRC-hibaval jelez)
comx0/reg - a kartya aramkoreinek, a MUNICH (reg) es a FALC (lbireg)
comx0/lbireg regisztereinek kozvetlen elerese. Hasznalata:
echo >reg 0x04 0x0 - a 4-es regiszterbe 0-t ir
echo >reg 0x104 - printk()-val kiirja a 4-es regiszter
tartalmat a syslogba.
WARNING: ezek csak a fejleszteshez keszultek, sok galibat
lehet veluk okozni!
comx0/loopback - A kartya G.703 jelenek a visszahurkolasara is van lehetoseg:
papaya:# echo none >/proc/comx/comx0/loopback
papaya:# echo local >/proc/comx/comx0/loopback
papaya:# echo remote >/proc/comx/comx0/loopback
none - nincs visszahurkolas, normal mukodes
local - a kartya a sajat maga altal adott jelet kapja vissza
remote - a kartya a kivulrol vett jelet adja kifele
Default: none
-----------------------------------------------------------------
Az interfeszhez (Cisco terminologiaban 'channel-group') kapcsolodo beallitasok:
comx0/timeslots - mely timeslotok (idoszeletek) tartoznak az adott interfeszhez.
papaya:~# cat /proc/comx/comx0/timeslots
1 3 4 5 6
papaya:~#
Egy timeslot megkeresese (hanyas interfeszbe tartozik nalunk):
papaya:~# grep ' 4' /proc/comx/comx*/timeslots
/proc/comx/comx0/timeslots:1 3 4 5 6
papaya:~#
Beallitasa:
papaya:~# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
A timeslotok sorrendje nem szamit, '1 3 2' ugyanaz mint az '1 2 3'.
Beallitashoz az adott interfesznek DOWN-ban kell lennie
(ifconfig comx0 down), de ugyanannak a kartyanak a tobbi interfesze
uzemelhet kozben.
Beallitaskor leellenorzi, hogy az uj timeslotok nem utkoznek-e egy
masik interfesz timeslotjaival. Ha utkoznek, akkor nem allitja at.
Mindig 10-es szamrendszerben tortenik a timeslotok ertelmezese, nehogy
a 08, 09 alaku felirast rosszul ertelmezze.
-----------------------------------------------------------------
Az interfeszek es a kartya allapotanak lekerdezese:
- A ' '-szel kezdodo sorok az eredeti kimenetet, a //-rel kezdodo sorok a
magyarazatot jelzik.
papaya:~$ cat /proc/comx/comx1/status
Interface administrative status is UP, modem status is UP, protocol is UP
Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
(output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
Debug flags: none
RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
buffer overrun: 0, pbuffer overrun: 0
TX errors: underrun: 0
Line keepalive (value: 10) status UP [0]
// Itt kezdodik a hardver-specifikus resz:
Controller status:
No alarms
// Alarm: hibajelzes:
//
// No alarms - minden rendben
//
// LOS - Loss Of Signal - nem erzekel jelet a bemeneten.
// AIS - Alarm Indication Signal - csak egymas utani 1-esek jonnek
// a bemeneten, a tuloldal igy is jelezheti hogy meghibasodott vagy
// nincs inicializalva.
// AUXP - Auxiliary Pattern Indication - 01010101.. sorozat jon a bemeneten.
// LFA - Loss of Frame Alignment - nincs keretszinkron
// RRA - Receive Remote Alarm - a tuloldal el, de hibat jelez.
// LMFA - Loss of CRC4 Multiframe Alignment - nincs CRC4-multikeret-szinkron
// NMF - No Multiframe alignment Found after 400 msec - ilyen alarm a no-crc4
// es crc4 keretezesek eseten nincs, lasd lentebb
//
// Egyeb lehetseges hibajelzesek:
//
// Transmit Line Short - a kartya ugy erzi hogy az adasi kimenete rovidre
// van zarva, ezert kikapcsolta az adast. (nem feltetlenul veszi eszre
// a kulso rovidzarat)
// A veteli oldal csomagjainak lancolt listai, debug celokra:
Rx ring:
rafutott: 0
lastcheck: 50845731, jiffies: 51314281
base: 017b1858
rx_desc_ptr: 0
rx_desc_ptr: 017b1858
hw_curr_ptr: 017b1858
06040000 017b1868 017b1898 c016ff00
06040000 017b1878 017b1e9c c016ff00
46040000 017b1888 017b24a0 c016ff00
06040000 017b1858 017b2aa4 c016ff00
// A kartyat hasznalo tobbi interfesz: a 0-s channel-group a comx1 interfesz,
// es az 1,2,...,16 timeslotok tartoznak hozza:
Interfaces using this board: (channel-group, interface, timeslots)
0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 comx2: 17
2 comx3: 18
3 comx4: 19
4 comx5: 20
5 comx6: 21
6 comx7: 22
7 comx8: 23
8 comx9: 24
9 comx10: 25
10 comx11: 26
11 comx12: 27
12 comx13: 28
13 comx14: 29
14 comx15: 30
15 comx16: 31
// Hany esemenyt kezelt le a driver egy-egy hardver-interrupt kiszolgalasanal:
Interrupt work histogram:
hist[ 0]: 0 hist[ 1]: 2 hist[ 2]: 18574 hist[ 3]: 79
hist[ 4]: 14 hist[ 5]: 1 hist[ 6]: 0 hist[ 7]: 1
hist[ 8]: 0 hist[ 9]: 7
// Hany kikuldendo csomag volt mar a Tx-ringben amikor ujabb lett irva bele:
Tx ring histogram:
hist[ 0]: 2329 hist[ 1]: 0 hist[ 2]: 0 hist[ 3]: 0
// Az E1-interfesz hiba-szamlaloi, az rfc2495-nek megfeleloen:
// (kb. a Cisco routerek "show controllers e1" formatumaban: http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
Data in current interval (91 seconds elapsed):
9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
Data in Interval 1 (15 minutes):
0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in last 4 intervals (1 hour):
0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in last 96 intervals (24 hours):
0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-----------------------------------------------------------------
Nehany kulonlegesebb beallitasi lehetoseg (idovel beepulhetnek majd a driverbe):
Ezekkel sok galibat lehet okozni, nagyon ovatosan kell oket hasznalni!
modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
devices: (lasd page 107 es g706 Annex B)
lbireg[ 0x1b ] |= 0x08
lbireg[ 0x1c ] |= 0xc0
- ilyenkor ertelmezett az NMF - 'No Multiframe alignment Found after
400 msec' alarm.
FALC - a vonali meghajto IC
local loop - a sajat adasomat halljam vissza
remote loop - a kivulrol jovo adast adom vissza
Egy hibakeresesre hasznalhato dolog:
- 1-es timeslot local loop a FALC-ban: echo >lbireg 0x1d 0x21
- local loop kikapcsolasa: echo >lbireg 0x1d 0x00

369
Documentation/networking/slicecom.txt Normal file
View File

@@ -0,0 +1,369 @@
SliceCOM adapter user's documentation - for the 0.51 driver version
Written by Bart<72>k Istv<74>n <bartoki@itc.hu>
English translation: Lakatos Gy<47>rgy <gyuri@itc.hu>
Mon Dec 11 15:28:42 CET 2000
Last modified: Wed Aug 29 17:25:37 CEST 2001
-----------------------------------------------------------------
Usage:
Compiling the kernel:
Code maturity level options
[*] Prompt for development and/or incomplete code/drivers
Network device support
Wan interfaces
<M> MultiGate (COMX) synchronous
<M> Support for MUNICH based boards: SliceCOM, PCICOM (NEW)
<M> Support for HDLC and syncPPP...
Loading the modules:
modprobe comx
modprobe comx-proto-ppp # module for Cisco-HDLC and SyncPPP protocols
modprobe comx-hw-munich # the module logs information by the kernel
# about the detected boards
Configuring the board:
# This interface will use the Cisco-HDLC line protocol,
# the timeslices assigned are 1,2 (128 KiBit line speed)
# (the first data timeslice in the G.703 frame is no. 1)
#
mkdir /proc/comx/comx0.1/
echo slicecom >/proc/comx/comx0.1/boardtype
echo hdlc >/proc/comx/comx0.1/protocol
echo 1 2 >/proc/comx/comx0.1/timeslots
# This interface uses SyncPPP line protocol, the assigned
# is no. 3 (64 KiBit line speed)
#
mkdir /proc/comx/comx0.2/
echo slicecom >/proc/comx/comx0.2/boardtype
echo ppp >/proc/comx/comx0.2/protocol
echo 3 >/proc/comx/comx0.2/timeslots
...
ifconfig comx0.1 up
ifconfig comx0.2 up
-----------------------------------------------------------------
The COMX interfaces use a 10 packet transmit queue by default, however WAN
networks sometimes use bigger values (20 to 100), to utilize the line better
by large traffic (though the line delay increases because of more packets
join the queue).
# ifconfig comx0 txqueuelen 50
This option is only supported by the ifconfig command of the later
distributions, which came with 2.2 kernels, such as RedHat 6.1 or Debian 2.2.
You can download a newer netbase packet from
http://www.debian.org/~rcw/2.2/netbase/ for Debian 2.1, which has a new
ifconfig. You can get further information about using 2.2 kernel with
Debian 2.1 from http://www.debian.org/releases/stable/running-kernel-2.2
-----------------------------------------------------------------
The SliceCom LEDs:
red - on, if the interface is unconfigured, or it gets Remote Alarm-s
green - on, if the board finds frame-sync in the received signal
A bit more detailed:
red: green: meaning:
- - no frame-sync, no signal received, or signal SNAFU.
- on "Everything is OK"
on on Reception is ok, but the remote end sends Remote Alarm
on - The interface is unconfigured
-----------------------------------------------------------------
A more detailed description of the hardware setting options:
The general and the protocol layer options described in the 'comx.txt' file
apply to the SliceCom as well, I only summarize the SliceCom hardware specific
settings below.
The '/proc/comx' configuring interface:
An interface directory should be created for every timeslot group with
'mkdir', e,g: 'comx0', 'comx1' etc. The timeslots can be assigned here to the
specific interface. The Cisco-like naming convention (serial3:1 - first
timeslot group of the 3rd. board) can't be used here, because these mean IP
aliasing in Linux.
You can give any meaningful name to keep the configuration clear;
e.g: 'comx0.1', 'comx0.2', 'comx1.1', comx1.2', if you have two boards
with two interfaces each.
Settings, which apply to the board:
Neither 'io' nor 'irq' settings required, the driver uses the resources
given by the PCI BIOS.
comx0/boardnum - board number of the SliceCom in the PC (using the 'natural'
PCI order) as listed in '/proc/pci' or the output of the
'lspci' command, generally the slots nearer to the motherboard
PCI driver chips have the lower numbers.
Default: 0 (the counting starts with 0)
Though the options below are to be set on a single interface, they apply to the
whole board. The restriction, to use them on 'UP' interfaces, is because the
command sequence below could lead to unpredictable results.
# echo 0 >boardnum
# echo internal >clock_source
# echo 1 >boardnum
The sequence would set the clock source of board 0.
These settings will persist after all the interfaces are cleared, but are
cleared when the driver module is unloaded and loaded again.
comx0/clock_source - source of the transmit clock
Usage:
# echo line >/proc/comx/comx0/clock_source
# echo internal >/proc/comx/comx0/clock_source
line - The Tx clock is being decoded if the input data stream,
if no clock seen on the input, then the board will use it's
own clock generator.
internal - The Tx clock is supplied by the builtin clock generator.
Default: line
Normally, the telecommunication company's end device (the HDSL
modem) provides the Tx clock, that's why 'line' is the default.
comx0/framing - Switching CRC4 off/on
CRC4: 16 PCM frames (The 32 64Kibit channels are multiplexed into a
PCM frame, nothing to do with HDLC frames) are divided into 2x8
groups, each group has a 4 bit CRC.
# echo crc4 >/proc/comx/comx0/framing
# echo no-crc4 >/proc/comx/comx0/framing
Default is 'crc4', the Hungarian MATAV lines behave like this.
The traffic generally passes if this setting on both ends don't match.
comx0/linecode - Setting the line coding
# echo hdb3 >/proc/comx/comx0/linecode
# echo ami >/proc/comx/comx0/linecode
Default a 'hdb3', MATAV lines use this.
(AMI coding is rarely used with E1 lines). Frame sync may occur, if
this setting doesn't match the other end's, but CRC4 and data errors
will come, which will result in CRC errors on HDLC/SyncPPP level.
comx0/reg - direct access to the board's MUNICH (reg) and FALC (lbireg)
comx0/lbireg circuit's registers
# echo >reg 0x04 0x0 - write 0 to register 4
# echo >reg 0x104 - write the contents of register 4 with
printk() to syslog
WARNING! These are only for development purposes, messing with this will
result much trouble!
comx0/loopback - Places a loop to the board's G.703 signals
# echo none >/proc/comx/comx0/loopback
# echo local >/proc/comx/comx0/loopback
# echo remote >/proc/comx/comx0/loopback
none - normal operation, no loop
local - the board receives it's own output
remote - the board sends the received data to the remote side
Default: none
-----------------------------------------------------------------
Interface (channel group in Cisco terms) settings:
comx0/timeslots - which timeslots belong to the given interface
Setting:
# echo '1 5 2 6 7 8' >/proc/comx/comx0/timeslots
# cat /proc/comx/comx0/timeslots
1 2 5 6 7 8
#
Finding a timeslot:
# grep ' 4' /proc/comx/comx*/timeslots
/proc/comx/comx0/timeslots:1 3 4 5 6
#
The timeslots can be in any order, '1 2 3' is the same as '1 3 2'.
The interface has to be DOWN during the setting ('ifconfig comx0
down'), but the other interfaces could operate normally.
The driver checks if the assigned timeslots are vacant, if not, then
the setting won't be applied.
The timeslot values are treated as decimal numbers, not to misunderstand
values of 08, 09 form.
-----------------------------------------------------------------
Checking the interface and board status:
- Lines beginning with ' ' (space) belong to the original output, the lines
which begin with '//' are the comments.
papaya:~$ cat /proc/comx/comx1/status
Interface administrative status is UP, modem status is UP, protocol is UP
Modem status changes: 0, Transmitter status is IDLE, tbusy: 0
Interface load (input): 978376 / 947808 / 951024 bits/s (5s/5m/15m)
(output): 978376 / 947848 / 951024 bits/s (5s/5m/15m)
Debug flags: none
RX errors: len: 22, overrun: 1, crc: 0, aborts: 0
buffer overrun: 0, pbuffer overrun: 0
TX errors: underrun: 0
Line keepalive (value: 10) status UP [0]
// The hardware specific part starts here:
Controller status:
No alarms
// Alarm:
//
// No alarms - Everything OK
//
// LOS - Loss Of Signal - No signal sensed on the input
// AIS - Alarm Indication Signal - The remote side sends '11111111'-s,
// it tells, that there's an error condition, or it's not
// initialised.
// AUXP - Auxiliary Pattern Indication - 01010101.. received.
// LFA - Loss of Frame Alignment - no frame sync received.
// RRA - Receive Remote Alarm - the remote end's OK, but signals error cond.
// LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync.
// NMF - No Multiframe alignment Found after 400 msec - no such alarm using
// no-crc4 or crc4 framing, see below.
//
// Other possible error messages:
//
// Transmit Line Short - the board felt, that it's output is short-circuited,
// so it switched the transmission off. (The board can't definitely tell,
// that it's output is short-circuited.)
// Chained list of the received packets, for debug purposes:
Rx ring:
rafutott: 0
lastcheck: 50845731, jiffies: 51314281
base: 017b1858
rx_desc_ptr: 0
rx_desc_ptr: 017b1858
hw_curr_ptr: 017b1858
06040000 017b1868 017b1898 c016ff00
06040000 017b1878 017b1e9c c016ff00
46040000 017b1888 017b24a0 c016ff00
06040000 017b1858 017b2aa4 c016ff00
// All the interfaces using the board: comx1, using the 1,2,...16 timeslots,
// comx2, using timeslot 17, etc.
Interfaces using this board: (channel-group, interface, timeslots)
0 comx1: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
1 comx2: 17
2 comx3: 18
3 comx4: 19
4 comx5: 20
5 comx6: 21
6 comx7: 22
7 comx8: 23
8 comx9: 24
9 comx10: 25
10 comx11: 26
11 comx12: 27
12 comx13: 28
13 comx14: 29
14 comx15: 30
15 comx16: 31
// The number of events handled by the driver during an interrupt cycle:
Interrupt work histogram:
hist[ 0]: 0 hist[ 1]: 2 hist[ 2]: 18574 hist[ 3]: 79
hist[ 4]: 14 hist[ 5]: 1 hist[ 6]: 0 hist[ 7]: 1
hist[ 8]: 0 hist[ 9]: 7
// The number of packets to send in the Tx ring, when a new one arrived:
Tx ring histogram:
hist[ 0]: 2329 hist[ 1]: 0 hist[ 2]: 0 hist[ 3]: 0
// The error counters of the E1 interface, according to the RFC2495,
// (similar to the Cisco "show controllers e1" command's output:
// http://www.cisco.com/univercd/cc/td/doc/product/software/ios11/rbook/rinterfc.htm#xtocid25669126)
Data in current interval (91 seconds elapsed):
9516 Line Code Violations, 65 Path Code Violations, 2 E-Bit Errors
0 Slip Secs, 2 Fr Loss Secs, 2 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 11 Unavail Secs
Data in Interval 1 (15 minutes):
0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in last 4 intervals (1 hour):
0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Data in last 96 intervals (24 hours):
0 Line Code Violations, 0 Path Code Violations, 0 E-Bit Errors
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
-----------------------------------------------------------------
Some unique options, (may get into the driver later):
Treat them very carefully, these can cause much trouble!
modified CRC-4, for improved interworking of CRC-4 and non-CRC-4
devices: (see page 107 and g706 Annex B)
lbireg[ 0x1b ] |= 0x08
lbireg[ 0x1c ] |= 0xc0
- The NMF - 'No Multiframe alignment Found after 400 msec' alarm
comes into account.
FALC - the line driver chip.
local loop - I hear my transmission back.
remote loop - I echo the remote transmission back.
Something useful for finding errors:
- local loop for timeslot 1 in the FALC chip:
# echo >lbireg 0x1d 0x21
- Switching the loop off:
# echo >lbireg 0x1d 0x00

42
Documentation/networking/smc9.txt Normal file
View File

@@ -0,0 +1,42 @@
SMC 9xxxx Driver
Revision 0.12
3/5/96
Copyright 1996 Erik Stahlman
Released under terms of the GNU General Public License.
This file contains the instructions and caveats for my SMC9xxx driver. You
should not be using the driver without reading this file.
Things to note about installation:
1. The driver should work on all kernels from 1.2.13 until 1.3.71.
(A kernel patch is supplied for 1.3.71 )
2. If you include this into the kernel, you might need to change some
options, such as for forcing IRQ.
3. To compile as a module, run 'make' .
Make will give you the appropriate options for various kernel support.
4. Loading the driver as a module :
use: insmod smc9194.o
optional parameters:
io=xxxx : your base address
irq=xx : your irq
ifport=x : 0 for whatever is default
1 for twisted pair
2 for AUI ( or BNC on some cards )
How to obtain the latest version?
FTP:
ftp://fenris.campus.vt.edu/smc9/smc9-12.tar.gz
ftp://sfbox.vt.edu/filebox/F/fenris/smc9/smc9-12.tar.gz
Contacting me:
erik@mail.vt.edu

66
Documentation/networking/smctr.txt Normal file
View File

@@ -0,0 +1,66 @@
Text File for the SMC TokenCard TokenRing Linux driver (smctr.c).
By Jay Schulist <jschlst@samba.org>
The Linux SMC Token Ring driver works with the SMC TokenCard Elite (8115T)
ISA and SMC TokenCard Elite/A (8115T/A) MCA adapters.
Latest information on this driver can be obtained on the Linux-SNA WWW site.
Please point your browser to: http://www.linux-sna.org
This driver is rather simple to use. Select Y to Token Ring adapter support
in the kernel configuration. A choice for SMC Token Ring adapters will
appear. This drives supports all SMC ISA/MCA adapters. Choose this
option. I personally recommend compiling the driver as a module (M), but if you
you would like to compile it statically answer Y instead.
This driver supports multiple adapters without the need to load multiple copies
of the driver. You should be able to load up to 7 adapters without any kernel
modifications, if you are in need of more please contact the maintainer of this
driver.
Load the driver either by lilo/loadlin or as a module. When a module using the
following command will suffice for most:
# modprobe smctr
smctr.c: v1.00 12/6/99 by jschlst@samba.org
tr0: SMC TokenCard 8115T at Io 0x300, Irq 10, Rom 0xd8000, Ram 0xcc000.
Now just setup the device via ifconfig and set and routes you may have. After
this you are ready to start sending some tokens.
Errata:
1). For anyone wondering where to pick up the SMC adapters please browse
to http://www.smc.com
2). If you are the first/only Token Ring Client on a Token Ring LAN, please
specify the ringspeed with the ringspeed=[4/16] module option. If no
ringspeed is specified the driver will attempt to autodetect the ring
speed and/or if the adapter is the first/only station on the ring take
the appropriate actions.
NOTE: Default ring speed is 16MB UTP.
3). PnP support for this adapter sucks. I recommend hard setting the
IO/MEM/IRQ by the jumpers on the adapter. If this is not possible
load the module with the following io=[ioaddr] mem=[mem_addr]
irq=[irq_num].
The following IRQ, IO, and MEM settings are supported.
IO ports:
0x200, 0x220, 0x240, 0x260, 0x280, 0x2A0, 0x2C0, 0x2E0, 0x300,
0x320, 0x340, 0x360, 0x380.
IRQs:
2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15
Memory addresses:
0xA0000, 0xA4000, 0xA8000, 0xAC000, 0xB0000, 0xB4000,
0xB8000, 0xBC000, 0xC0000, 0xC4000, 0xC8000, 0xCC000,
0xD0000, 0xD4000, 0xD8000, 0xDC000, 0xE0000, 0xE4000,
0xE8000, 0xEC000, 0xF0000, 0xF4000, 0xF8000, 0xFC000
This driver is under the GNU General Public License. Its Firmware image is
included as an initialized C-array and is licensed by SMC to the Linux
users of this driver. However no warranty about its fitness is expressed or
implied by SMC.

106
Documentation/networking/tcp.txt Normal file
View File

@@ -0,0 +1,106 @@
TCP protocol
============
Last updated: 21 June 2005
Contents
========
- Congestion control
- How the new TCP output machine [nyi] works
Congestion control
==================
The following variables are used in the tcp_sock for congestion control:
snd_cwnd The size of the congestion window
snd_ssthresh Slow start threshold. We are in slow start if
snd_cwnd is less than this.
snd_cwnd_cnt A counter used to slow down the rate of increase
once we exceed slow start threshold.
snd_cwnd_clamp This is the maximum size that snd_cwnd can grow to.
snd_cwnd_stamp Timestamp for when congestion window last validated.
snd_cwnd_used Used as a highwater mark for how much of the
congestion window is in use. It is used to adjust
snd_cwnd down when the link is limited by the
application rather than the network.
As of 2.6.13, Linux supports pluggable congestion control algorithms.
A congestion control mechanism can be registered through functions in
tcp_cong.c. The functions used by the congestion control mechanism are
registered via passing a tcp_congestion_ops struct to
tcp_register_congestion_control. As a minimum name, ssthresh,
cong_avoid, min_cwnd must be valid.
Private data for a congestion control mechanism is stored in tp->ca_priv.
tcp_ca(tp) returns a pointer to this space. This is preallocated space - it
is important to check the size of your private data will fit this space, or
alternatively space could be allocated elsewhere and a pointer to it could
be stored here.
There are three kinds of congestion control algorithms currently: The
simplest ones are derived from TCP reno (highspeed, scalable) and just
provide an alternative the congestion window calculation. More complex
ones like BIC try to look at other events to provide better
heuristics. There are also round trip time based algorithms like
Vegas and Westwood+.
Good TCP congestion control is a complex problem because the algorithm
needs to maintain fairness and performance. Please review current
research and RFC's before developing new modules.
The method that is used to determine which congestion control mechanism is
determined by the setting of the sysctl net.ipv4.tcp_congestion_control.
The default congestion control will be the last one registered (LIFO);
so if you built everything as modules. the default will be reno. If you
build with the default's from Kconfig, then BIC will be builtin (not a module)
and it will end up the default.
If you really want a particular default value then you will need
to set it with the sysctl. If you use a sysctl, the module will be autoloaded
if needed and you will get the expected protocol. If you ask for an
unknown congestion method, then the sysctl attempt will fail.
If you remove a tcp congestion control module, then you will get the next
available one. Since reno cannot be built as a module, and cannot be
deleted, it will always be available.
How the new TCP output machine [nyi] works.
===========================================
Data is kept on a single queue. The skb->users flag tells us if the frame is
one that has been queued already. To add a frame we throw it on the end. Ack
walks down the list from the start.
We keep a set of control flags
sk->tcp_pend_event
TCP_PEND_ACK Ack needed
TCP_ACK_NOW Needed now
TCP_WINDOW Window update check
TCP_WINZERO Zero probing
sk->transmit_queue The transmission frame begin
sk->transmit_new First new frame pointer
sk->transmit_end Where to add frames
sk->tcp_last_tx_ack Last ack seen
sk->tcp_dup_ack Dup ack count for fast retransmit
Frames are queued for output by tcp_write. We do our best to send the frames
off immediately if possible, but otherwise queue and compute the body
checksum in the copy.
When a write is done we try to clear any pending events and piggy back them.
If the window is full we queue full sized frames. On the first timeout in
zero window we split this.
On a timer we walk the retransmit list to send any retransmits, update the
backoff timers etc. A change of route table stamp causes a change of header
and recompute. We add any new tcp level headers and refinish the checksum
before sending.

117
Documentation/networking/tlan.txt Normal file
View File

@@ -0,0 +1,117 @@
(C) 1997-1998 Caldera, Inc.
(C) 1998 James Banks
(C) 1999-2001 Torben Mathiasen <tmm@image.dk, torben.mathiasen@compaq.com>
For driver information/updates visit http://opensource.compaq.com
TLAN driver for Linux, version 1.14a
README
I. Supported Devices.
Only PCI devices will work with this driver.
Supported:
Vendor ID Device ID Name
0e11 ae32 Compaq Netelligent 10/100 TX PCI UTP
0e11 ae34 Compaq Netelligent 10 T PCI UTP
0e11 ae35 Compaq Integrated NetFlex 3/P
0e11 ae40 Compaq Netelligent Dual 10/100 TX PCI UTP
0e11 ae43 Compaq Netelligent Integrated 10/100 TX UTP
0e11 b011 Compaq Netelligent 10/100 TX Embedded UTP
0e11 b012 Compaq Netelligent 10 T/2 PCI UTP/Coax
0e11 b030 Compaq Netelligent 10/100 TX UTP
0e11 f130 Compaq NetFlex 3/P
0e11 f150 Compaq NetFlex 3/P
108d 0012 Olicom OC-2325
108d 0013 Olicom OC-2183
108d 0014 Olicom OC-2326
Caveats:
I am not sure if 100BaseTX daughterboards (for those cards which
support such things) will work. I haven't had any solid evidence
either way.
However, if a card supports 100BaseTx without requiring an add
on daughterboard, it should work with 100BaseTx.
The "Netelligent 10 T/2 PCI UTP/Coax" (b012) device is untested,
but I do not expect any problems.
II. Driver Options
1. You can append debug=x to the end of the insmod line to get
debug messages, where x is a bit field where the bits mean
the following:
0x01 Turn on general debugging messages.
0x02 Turn on receive debugging messages.
0x04 Turn on transmit debugging messages.
0x08 Turn on list debugging messages.
2. You can append aui=1 to the end of the insmod line to cause
the adapter to use the AUI interface instead of the 10 Base T
interface. This is also what to do if you want to use the BNC
connector on a TLAN based device. (Setting this option on a
device that does not have an AUI/BNC connector will probably
cause it to not function correctly.)
3. You can set duplex=1 to force half duplex, and duplex=2 to
force full duplex.
4. You can set speed=10 to force 10Mbs operation, and speed=100
to force 100Mbs operation. (I'm not sure what will happen
if a card which only supports 10Mbs is forced into 100Mbs
mode.)
5. You have to use speed=X duplex=Y together now. If you just
do "insmod tlan.o speed=100" the driver will do Auto-Neg.
To force a 10Mbps Half-Duplex link do "insmod tlan.o speed=10
duplex=1".
6. If the driver is built into the kernel, you can use the 3rd
and 4th parameters to set aui and debug respectively. For
example:
ether=0,0,0x1,0x7,eth0
This sets aui to 0x1 and debug to 0x7, assuming eth0 is a
supported TLAN device.
The bits in the third byte are assigned as follows:
0x01 = aui
0x02 = use half duplex
0x04 = use full duplex
0x08 = use 10BaseT
0x10 = use 100BaseTx
You also need to set both speed and duplex settings when forcing
speeds with kernel-parameters.
ether=0,0,0x12,0,eth0 will force link to 100Mbps Half-Duplex.
7. If you have more than one tlan adapter in your system, you can
use the above options on a per adapter basis. To force a 100Mbit/HD
link with your eth1 adapter use:
insmod tlan speed=0,100 duplex=0,1
Now eth0 will use auto-neg and eth1 will be forced to 100Mbit/HD.
Note that the tlan driver supports a maximum of 8 adapters.
III. Things to try if you have problems.
1. Make sure your card's PCI id is among those listed in
section I, above.
2. Make sure routing is correct.
3. Try forcing different speed/duplex settings
There is also a tlan mailing list which you can join by sending "subscribe tlan"
in the body of an email to majordomo@vuser.vu.union.edu.
There is also a tlan website at http://opensource.compaq.com

147
Documentation/networking/tms380tr.txt Normal file
View File

@@ -0,0 +1,147 @@
Text file for the Linux SysKonnect Token Ring ISA/PCI Adapter Driver.
Text file by: Jay Schulist <jschlst@samba.org>
The Linux SysKonnect Token Ring driver works with the SysKonnect TR4/16(+) ISA,
SysKonnect TR4/16(+) PCI, SysKonnect TR4/16 PCI, and older revisions of the
SK NET TR4/16 ISA card.
Latest information on this driver can be obtained on the Linux-SNA WWW site.
Please point your browser to:
http://www.linux-sna.org
Many thanks to Christoph Goos for his excellent work on this driver and
SysKonnect for donating the adapters to Linux-SNA for the testing and
maintenance of this device driver.
Important information to be noted:
1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be
patient.
2. This driver works very well when autoprobing for adapters. Why even
think about those nasty io/int/dma settings of modprobe when the driver
will do it all for you!
This driver is rather simple to use. Select Y to Token Ring adapter support
in the kernel configuration. A choice for SysKonnect Token Ring adapters will
appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this
option. I personally recommend compiling the driver as a module (M), but if you
you would like to compile it statically answer Y instead.
This driver supports multiple adapters without the need to load multiple copies
of the driver. You should be able to load up to 7 adapters without any kernel
modifications, if you are in need of more please contact the maintainer of this
driver.
Load the driver either by lilo/loadlin or as a module. When a module using the
following command will suffice for most:
# modprobe sktr
This will produce output similar to the following: (Output is user specific)
sktr.c: v1.01 08/29/97 by Christoph Goos
tr0: SK NET TR 4/16 PCI found at 0x6100, using IRQ 17.
tr1: SK NET TR 4/16 PCI found at 0x6200, using IRQ 16.
tr2: SK NET TR 4/16 ISA found at 0xa20, using IRQ 10 and DMA 5.
Now just setup the device via ifconfig and set and routes you may have. After
this you are ready to start sending some tokens.
Errata:
For anyone wondering where to pick up the SysKonnect adapters please browse
to http://www.syskonnect.com
This driver is under the GNU General Public License. Its Firmware image is
included as an initialized C-array and is licensed by SysKonnect to the Linux
users of this driver. However no warranty about its fitness is expressed or
implied by SysKonnect.
Below find attached the setting for the SK NET TR 4/16 ISA adapters
-------------------------------------------------------------------
***************************
*** C O N T E N T S ***
***************************
1) Location of DIP-Switch W1
2) Default settings
3) DIP-Switch W1 description
==============================================================
CHAPTER 1 LOCATION OF DIP-SWITCH
==============================================================
U<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
<EFBFBD>U<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ U<><55><EFBFBD><EFBFBD>Ŀ U<><55>Ŀ <20>
<EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U W1 A<><41><EFBFBD><EFBFBD><EFBFBD>U U<><55><EFBFBD>Ŀ <20> <20> <20>
<EFBFBD>U<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ <20> <20> <20> <20> U<><55>ſ
<EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U U<><55><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ A<><41><EFBFBD><EFBFBD>U <20> <20> <20> <20><>
<EFBFBD>U<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ <20> <20> U<><55>Ŀ A<><41><EFBFBD>U A<><41><EFBFBD>U
<EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U <20> TMS380C26 <20> <20> <20> <20>
<EFBFBD>U<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ <20> <20> A<><41><EFBFBD>U AĿ
<EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U <20> <20> <20> <20>
<EFBFBD> A<><41><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U <20> <20>
<EFBFBD> <20> <20>
<EFBFBD> A<>U
<EFBFBD> <20>
<EFBFBD> <20>
<EFBFBD> <20>
<EFBFBD> <20>
A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>A<EFBFBD><EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>A<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U
A<><41><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U A<><41><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>U
==============================================================
CHAPTER 2 DEFAULT SETTINGS
==============================================================
W1 1 2 3 4 5 6 7 8
+------------------------------+
| ON X |
| OFF X X X X X X X |
+------------------------------+
W1.1 = ON Adapter drives address lines SA17..19
W1.2 - 1.5 = OFF BootROM disabled
W1.6 - 1.8 = OFF I/O address 0A20h
==============================================================
CHAPTER 3 DIP SWITCH W1 DESCRIPTION
==============================================================
U<><55><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41>Ŀ ON
<20> 1 <20> 2 <20> 3 <20> 4 <20> 5 <20> 6 <20> 7 <20> 8 <20>
A<><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>A<EFBFBD><41><EFBFBD>U OFF
|AD | BootROM Addr. | I/O |
+-+-+-------+-------+-----+-----+
| | |
| | +------ 6 7 8
| | ON ON ON 1900h
| | ON ON OFF 0900h
| | ON OFF ON 1980h
| | ON OFF OFF 0980h
| | OFF ON ON 1b20h
| | OFF ON OFF 0b20h
| | OFF OFF ON 1a20h
| | OFF OFF OFF 0a20h (+)
| |
| |
| +-------- 2 3 4 5
| OFF x x x disabled (+)
| ON ON ON ON C0000
| ON ON ON OFF C4000
| ON ON OFF ON C8000
| ON ON OFF OFF CC000
| ON OFF ON ON D0000
| ON OFF ON OFF D4000
| ON OFF OFF ON D8000
| ON OFF OFF OFF DC000
|
|
+----- 1
OFF adapter does NOT drive SA<17..19>
ON adapter drives SA<17..19> (+)
(+) means default setting
********************************

150
Documentation/networking/tuntap.txt Normal file
View File

@@ -0,0 +1,150 @@
Universal TUN/TAP device driver.
Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
Linux, Solaris drivers
Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com>
FreeBSD TAP driver
Copyright (c) 1999-2000 Maksim Yevmenkin <m_evmenkin@yahoo.com>
Revision of this document 2002 by Florian Thiel <florian.thiel@gmx.net>
1. Description
TUN/TAP provides packet reception and transmission for user space programs.
It can be seen as a simple Point-to-Point or Ethernet device, which,
instead of receiving packets from physical media, receives them from
user space program and instead of sending packets via physical media
writes them to the user space program.
In order to use the driver a program has to open /dev/net/tun and issue a
corresponding ioctl() to register a network device with the kernel. A network
device will appear as tunXX or tapXX, depending on the options chosen. When
the program closes the file descriptor, the network device and all
corresponding routes will disappear.
Depending on the type of device chosen the userspace program has to read/write
IP packets (with tun) or ethernet frames (with tap). Which one is being used
depends on the flags given with the ioctl().
The package from http://vtun.sourceforge.net/tun contains two simple examples
for how to use tun and tap devices. Both programs work like a bridge between
two network interfaces.
br_select.c - bridge based on select system call.
br_sigio.c - bridge based on async io and SIGIO signal.
However, the best example is VTun http://vtun.sourceforge.net :))
2. Configuration
Create device node:
mkdir /dev/net (if it doesn't exist already)
mknod /dev/net/tun c 10 200
Set permissions:
e.g. chmod 0666 /dev/net/tun
There's no harm in allowing the device to be accessible by non-root users,
since CAP_NET_ADMIN is required for creating network devices or for
connecting to network devices which aren't owned by the user in question.
If you want to create persistent devices and give ownership of them to
unprivileged users, then you need the /dev/net/tun device to be usable by
those users.
Driver module autoloading
Make sure that "Kernel module loader" - module auto-loading
support is enabled in your kernel. The kernel should load it on
first access.
Manual loading
insert the module by hand:
modprobe tun
If you do it the latter way, you have to load the module every time you
need it, if you do it the other way it will be automatically loaded when
/dev/net/tun is being opened.
3. Program interface
3.1 Network device allocation:
char *dev should be the name of the device with a format string (e.g.
"tun%d"), but (as far as I can see) this can be any valid network device name.
Note that the character pointer becomes overwritten with the real device name
(e.g. "tun0")
#include <linux/if.h>
#include <linux/if_tun.h>
int tun_alloc(char *dev)
{
struct ifreq ifr;
int fd, err;
if( (fd = open("/dev/net/tun", O_RDWR)) < 0 )
return tun_alloc_old(dev);
memset(&ifr, 0, sizeof(ifr));
/* Flags: IFF_TUN - TUN device (no Ethernet headers)
* IFF_TAP - TAP device
*
* IFF_NO_PI - Do not provide packet information
*/
ifr.ifr_flags = IFF_TUN;
if( *dev )
strncpy(ifr.ifr_name, dev, IFNAMSIZ);
if( (err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0 ){
close(fd);
return err;
}
strcpy(dev, ifr.ifr_name);
return fd;
}
3.2 Frame format:
If flag IFF_NO_PI is not set each frame format is:
Flags [2 bytes]
Proto [2 bytes]
Raw protocol(IP, IPv6, etc) frame.
Universal TUN/TAP device driver Frequently Asked Question.
1. What platforms are supported by TUN/TAP driver ?
Currently driver has been written for 3 Unices:
Linux kernels 2.2.x, 2.4.x
FreeBSD 3.x, 4.x, 5.x
Solaris 2.6, 7.0, 8.0
2. What is TUN/TAP driver used for?
As mentioned above, main purpose of TUN/TAP driver is tunneling.
It is used by VTun (http://vtun.sourceforge.net).
Another interesting application using TUN/TAP is pipsecd
(http://perso.enst.fr/~beyssac/pipsec/), an userspace IPSec
implementation that can use complete kernel routing (unlike FreeS/WAN).
3. How does Virtual network device actually work ?
Virtual network device can be viewed as a simple Point-to-Point or
Ethernet device, which instead of receiving packets from a physical
media, receives them from user space program and instead of sending
packets via physical media sends them to the user space program.
Let's say that you configured IPX on the tap0, then whenever
the kernel sends an IPX packet to tap0, it is passed to the application
(VTun for example). The application encrypts, compresses and sends it to
the other side over TCP or UDP. The application on the other side decompresses
and decrypts the data received and writes the packet to the TAP device,
the kernel handles the packet like it came from real physical device.
4. What is the difference between TUN driver and TAP driver?
TUN works with IP frames. TAP works with Ethernet frames.
This means that you have to read/write IP packets when you are using tun and
ethernet frames when using tap.
5. What is the difference between BPF and TUN/TAP driver?
BPF is an advanced packet filter. It can be attached to existing
network interface. It does not provide a virtual network interface.
A TUN/TAP driver does provide a virtual network interface and it is possible
to attach BPF to this interface.
6. Does TAP driver support kernel Ethernet bridging?
Yes. Linux and FreeBSD drivers support Ethernet bridging.

281
Documentation/networking/udplite.txt Normal file
View File

@@ -0,0 +1,281 @@
===========================================================================
The UDP-Lite protocol (RFC 3828)
===========================================================================
UDP-Lite is a Standards-Track IETF transport protocol whose characteristic
is a variable-length checksum. This has advantages for transport of multimedia
(video, VoIP) over wireless networks, as partly damaged packets can still be
fed into the codec instead of being discarded due to a failed checksum test.
This file briefly describes the existing kernel support and the socket API.
For in-depth information, you can consult:
o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/
Fom here you can also download some example application source code.
o The UDP-Lite HOWTO on
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt
o The Wireshark UDP-Lite WiKi (with capture files):
http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol
o The Protocol Spec, RFC 3828, http://www.ietf.org/rfc/rfc3828.txt
I) APPLICATIONS
Several applications have been ported successfully to UDP-Lite. Ethereal
(now called wireshark) has UDP-Litev4/v6 support by default. The tarball on
http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz
has source code for several v4/v6 client-server and network testing examples.
Porting applications to UDP-Lite is straightforward: only socket level and
IPPROTO need to be changed; senders additionally set the checksum coverage
length (default = header length = 8). Details are in the next section.
II) PROGRAMMING API
UDP-Lite provides a connectionless, unreliable datagram service and hence
uses the same socket type as UDP. In fact, porting from UDP to UDP-Lite is
very easy: simply add `IPPROTO_UDPLITE' as the last argument of the socket(2)
call so that the statement looks like:
s = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
or, respectively,
s = socket(PF_INET6, SOCK_DGRAM, IPPROTO_UDPLITE);
With just the above change you are able to run UDP-Lite services or connect
to UDP-Lite servers. The kernel will assume that you are not interested in
using partial checksum coverage and so emulate UDP mode (full coverage).
To make use of the partial checksum coverage facilities requires setting a
single socket option, which takes an integer specifying the coverage length:
* Sender checksum coverage: UDPLITE_SEND_CSCOV
For example,
int val = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof(int));
sets the checksum coverage length to 20 bytes (12b data + 8b header).
Of each packet only the first 20 bytes (plus the pseudo-header) will be
checksummed. This is useful for RTP applications which have a 12-byte
base header.
* Receiver checksum coverage: UDPLITE_RECV_CSCOV
This option is the receiver-side analogue. It is truly optional, i.e. not
required to enable traffic with partial checksum coverage. Its function is
that of a traffic filter: when enabled, it instructs the kernel to drop
all packets which have a coverage _less_ than this value. For example, if
RTP and UDP headers are to be protected, a receiver can enforce that only
packets with a minimum coverage of 20 are admitted:
int min = 20;
setsockopt(s, SOL_UDPLITE, UDPLITE_RECV_CSCOV, &min, sizeof(int));
The calls to getsockopt(2) are analogous. Being an extension and not a stand-
alone protocol, all socket options known from UDP can be used in exactly the
same manner as before, e.g. UDP_CORK or UDP_ENCAP.
A detailed discussion of UDP-Lite checksum coverage options is in section IV.
III) HEADER FILES
The socket API requires support through header files in /usr/include:
* /usr/include/netinet/in.h
to define IPPROTO_UDPLITE
* /usr/include/netinet/udplite.h
for UDP-Lite header fields and protocol constants
For testing purposes, the following can serve as a `mini' header file:
#define IPPROTO_UDPLITE 136
#define SOL_UDPLITE 136
#define UDPLITE_SEND_CSCOV 10
#define UDPLITE_RECV_CSCOV 11
Ready-made header files for various distros are in the UDP-Lite tarball.
IV) KERNEL BEHAVIOUR WITH REGARD TO THE VARIOUS SOCKET OPTIONS
To enable debugging messages, the log level need to be set to 8, as most
messages use the KERN_DEBUG level (7).
1) Sender Socket Options
If the sender specifies a value of 0 as coverage length, the module
assumes full coverage, transmits a packet with coverage length of 0
and according checksum. If the sender specifies a coverage < 8 and
different from 0, the kernel assumes 8 as default value. Finally,
if the specified coverage length exceeds the packet length, the packet
length is used instead as coverage length.
2) Receiver Socket Options
The receiver specifies the minimum value of the coverage length it
is willing to accept. A value of 0 here indicates that the receiver
always wants the whole of the packet covered. In this case, all
partially covered packets are dropped and an error is logged.
It is not possible to specify illegal values (<0 and <8); in these
cases the default of 8 is assumed.
All packets arriving with a coverage value less than the specified
threshold are discarded, these events are also logged.
3) Disabling the Checksum Computation
On both sender and receiver, checksumming will always be performed
and can not be disabled using SO_NO_CHECK. Thus
setsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, ... );
will always will be ignored, while the value of
getsockopt(sockfd, SOL_SOCKET, SO_NO_CHECK, &value, ...);
is meaningless (as in TCP). Packets with a zero checksum field are
illegal (cf. RFC 3828, sec. 3.1) will be silently discarded.
4) Fragmentation
The checksum computation respects both buffersize and MTU. The size
of UDP-Lite packets is determined by the size of the send buffer. The
minimum size of the send buffer is 2048 (defined as SOCK_MIN_SNDBUF
in include/net/sock.h), the default value is configurable as
net.core.wmem_default or via setting the SO_SNDBUF socket(7)
option. The maximum upper bound for the send buffer is determined
by net.core.wmem_max.
Given a payload size larger than the send buffer size, UDP-Lite will
split the payload into several individual packets, filling up the
send buffer size in each case.
The precise value also depends on the interface MTU. The interface MTU,
in turn, may trigger IP fragmentation. In this case, the generated
UDP-Lite packet is split into several IP packets, of which only the
first one contains the L4 header.
The send buffer size has implications on the checksum coverage length.
Consider the following example:
Payload: 1536 bytes Send Buffer: 1024 bytes
MTU: 1500 bytes Coverage Length: 856 bytes
UDP-Lite will ship the 1536 bytes in two separate packets:
Packet 1: 1024 payload + 8 byte header + 20 byte IP header = 1052 bytes
Packet 2: 512 payload + 8 byte header + 20 byte IP header = 540 bytes
The coverage packet covers the UDP-Lite header and 848 bytes of the
payload in the first packet, the second packet is fully covered. Note
that for the second packet, the coverage length exceeds the packet
length. The kernel always re-adjusts the coverage length to the packet
length in such cases.
As an example of what happens when one UDP-Lite packet is split into
several tiny fragments, consider the following example.
Payload: 1024 bytes Send buffer size: 1024 bytes
MTU: 300 bytes Coverage length: 575 bytes
+-+-----------+--------------+--------------+--------------+
|8| 272 | 280 | 280 | 280 |
+-+-----------+--------------+--------------+--------------+
280 560 840 1032
^
*****checksum coverage*************
The UDP-Lite module generates one 1032 byte packet (1024 + 8 byte
header). According to the interface MTU, these are split into 4 IP
packets (280 byte IP payload + 20 byte IP header). The kernel module
sums the contents of the entire first two packets, plus 15 bytes of
the last packet before releasing the fragments to the IP module.
To see the analogous case for IPv6 fragmentation, consider a link
MTU of 1280 bytes and a write buffer of 3356 bytes. If the checksum
coverage is less than 1232 bytes (MTU minus IPv6/fragment header
lengths), only the first fragment needs to be considered. When using
larger checksum coverage lengths, each eligible fragment needs to be
checksummed. Suppose we have a checksum coverage of 3062. The buffer
of 3356 bytes will be split into the following fragments:
Fragment 1: 1280 bytes carrying 1232 bytes of UDP-Lite data
Fragment 2: 1280 bytes carrying 1232 bytes of UDP-Lite data
Fragment 3: 948 bytes carrying 900 bytes of UDP-Lite data
The first two fragments have to be checksummed in full, of the last
fragment only 598 (= 3062 - 2*1232) bytes are checksummed.
While it is important that such cases are dealt with correctly, they
are (annoyingly) rare: UDP-Lite is designed for optimising multimedia
performance over wireless (or generally noisy) links and thus smaller
coverage lenghts are likely to be expected.
V) UDP-LITE RUNTIME STATISTICS AND THEIR MEANING
Exceptional and error conditions are logged to syslog at the KERN_DEBUG
level. Live statistics about UDP-Lite are available in /proc/net/snmp
and can (with newer versions of netstat) be viewed using
netstat -svu
This displays UDP-Lite statistics variables, whose meaning is as follows.
InDatagrams: Total number of received datagrams.
NoPorts: Number of packets received to an unknown port.
These cases are counted separately (not as InErrors).
InErrors: Number of erroneous UDP-Lite packets. Errors include:
* internal socket queue receive errors
* packet too short (less than 8 bytes or stated
coverage length exceeds received length)
* xfrm4_policy_check() returned with error
* application has specified larger min. coverage
length than that of incoming packet
* checksum coverage violated
* bad checksum
OutDatagrams: Total number of sent datagrams.
These statistics derive from the UDP MIB (RFC 2013).
VI) IPTABLES
There is packet match support for UDP-Lite as well as support for the LOG target.
If you copy and paste the following line into /etc/protcols,
udplite 136 UDP-Lite # UDP-Lite [RFC 3828]
then
iptables -A INPUT -p udplite -j LOG
will produce logging output to syslog. Dropping and rejecting packets also works.
VII) MAINTAINER ADDRESS
The UDP-Lite patch was developed at
University of Aberdeen
Electronics Research Group
Department of Engineering
Fraser Noble Building
Aberdeen AB24 3UE; UK
The current maintainer is Gerrit Renker, <gerrit@erg.abdn.ac.uk>. Initial
code was developed by William Stanislaus, <william@erg.abdn.ac.uk>.

453
Documentation/networking/vortex.txt Normal file
View File

@@ -0,0 +1,453 @@
Documentation/networking/vortex.txt
Andrew Morton <andrewm@uow.edu.au>
30 April 2000
This document describes the usage and errata of the 3Com "Vortex" device
driver for Linux, 3c59x.c.
The driver was written by Donald Becker <becker@scyld.com>
Don is no longer the prime maintainer of this version of the driver.
Please report problems to one or more of:
Andrew Morton <akpm@osdl.org>
Netdev mailing list <netdev@vger.kernel.org>
Linux kernel mailing list <linux-kernel@vger.kernel.org>
Please note the 'Reporting and Diagnosing Problems' section at the end
of this file.
Since kernel 2.3.99-pre6, this driver incorporates the support for the
3c575-series Cardbus cards which used to be handled by 3c575_cb.c.
This driver supports the following hardware:
3c590 Vortex 10Mbps
3c592 EISA 10Mbps Demon/Vortex
3c597 EISA Fast Demon/Vortex
3c595 Vortex 100baseTx
3c595 Vortex 100baseT4
3c595 Vortex 100base-MII
3c900 Boomerang 10baseT
3c900 Boomerang 10Mbps Combo
3c900 Cyclone 10Mbps TPO
3c900 Cyclone 10Mbps Combo
3c900 Cyclone 10Mbps TPC
3c900B-FL Cyclone 10base-FL
3c905 Boomerang 100baseTx
3c905 Boomerang 100baseT4
3c905B Cyclone 100baseTx
3c905B Cyclone 10/100/BNC
3c905B-FX Cyclone 100baseFx
3c905C Tornado
3c920B-EMB-WNM (ATI Radeon 9100 IGP)
3c980 Cyclone
3c980C Python-T
3cSOHO100-TX Hurricane
3c555 Laptop Hurricane
3c556 Laptop Tornado
3c556B Laptop Hurricane
3c575 [Megahertz] 10/100 LAN CardBus
3c575 Boomerang CardBus
3CCFE575BT Cyclone CardBus
3CCFE575CT Tornado CardBus
3CCFE656 Cyclone CardBus
3CCFEM656B Cyclone+Winmodem CardBus
3CXFEM656C Tornado+Winmodem CardBus
3c450 HomePNA Tornado
3c920 Tornado
3c982 Hydra Dual Port A
3c982 Hydra Dual Port B
3c905B-T4
3c920B-EMB-WNM Tornado
Module parameters
=================
There are several parameters which may be provided to the driver when
its module is loaded. These are usually placed in /etc/modprobe.conf
(/etc/modules.conf in 2.4). Example:
options 3c59x debug=3 rx_copybreak=300
If you are using the PCMCIA tools (cardmgr) then the options may be
placed in /etc/pcmcia/config.opts:
module "3c59x" opts "debug=3 rx_copybreak=300"
The supported parameters are:
debug=N
Where N is a number from 0 to 7. Anything above 3 produces a lot
of output in your system logs. debug=1 is default.
options=N1,N2,N3,...
Each number in the list provides an option to the corresponding
network card. So if you have two 3c905's and you wish to provide
them with option 0x204 you would use:
options=0x204,0x204
The individual options are composed of a number of bitfields which
have the following meanings:
Possible media type settings
0 10baseT
1 10Mbs AUI
2 undefined
3 10base2 (BNC)
4 100base-TX
5 100base-FX
6 MII (Media Independent Interface)
7 Use default setting from EEPROM
8 Autonegotiate
9 External MII
10 Use default setting from EEPROM
When generating a value for the 'options' setting, the above media
selection values may be OR'ed (or added to) the following:
0x8000 Set driver debugging level to 7
0x4000 Set driver debugging level to 2
0x0400 Enable Wake-on-LAN
0x0200 Force full duplex mode.
0x0010 Bus-master enable bit (Old Vortex cards only)
For example:
insmod 3c59x options=0x204
will force full-duplex 100base-TX, rather than allowing the usual
autonegotiation.
global_options=N
Sets the `options' parameter for all 3c59x NICs in the machine.
Entries in the `options' array above will override any setting of
this.
full_duplex=N1,N2,N3...
Similar to bit 9 of 'options'. Forces the corresponding card into
full-duplex mode. Please use this in preference to the `options'
parameter.
In fact, please don't use this at all! You're better off getting
autonegotiation working properly.
global_full_duplex=N1
Sets full duplex mode for all 3c59x NICs in the machine. Entries
in the `full_duplex' array above will override any setting of this.
flow_ctrl=N1,N2,N3...
Use 802.3x MAC-layer flow control. The 3com cards only support the
PAUSE command, which means that they will stop sending packets for a
short period if they receive a PAUSE frame from the link partner.
The driver only allows flow control on a link which is operating in
full duplex mode.
This feature does not appear to work on the 3c905 - only 3c905B and
3c905C have been tested.
The 3com cards appear to only respond to PAUSE frames which are
sent to the reserved destination address of 01:80:c2:00:00:01. They
do not honour PAUSE frames which are sent to the station MAC address.
rx_copybreak=M
The driver preallocates 32 full-sized (1536 byte) network buffers
for receiving. When a packet arrives, the driver has to decide
whether to leave the packet in its full-sized buffer, or to allocate
a smaller buffer and copy the packet across into it.
This is a speed/space tradeoff.
The value of rx_copybreak is used to decide when to make the copy.
If the packet size is less than rx_copybreak, the packet is copied.
The default value for rx_copybreak is 200 bytes.
max_interrupt_work=N
The driver's interrupt service routine can handle many receive and
transmit packets in a single invocation. It does this in a loop.
The value of max_interrupt_work governs how mnay times the interrupt
service routine will loop. The default value is 32 loops. If this
is exceeded the interrupt service routine gives up and generates a
warning message "eth0: Too much work in interrupt".
hw_checksums=N1,N2,N3,...
Recent 3com NICs are able to generate IPv4, TCP and UDP checksums
in hardware. Linux has used the Rx checksumming for a long time.
The "zero copy" patch which is planned for the 2.4 kernel series
allows you to make use of the NIC's DMA scatter/gather and transmit
checksumming as well.
The driver is set up so that, when the zerocopy patch is applied,
all Tornado and Cyclone devices will use S/G and Tx checksums.
This module parameter has been provided so you can override this
decision. If you think that Tx checksums are causing a problem, you
may disable the feature with `hw_checksums=0'.
If you think your NIC should be performing Tx checksumming and the
driver isn't enabling it, you can force the use of hardware Tx
checksumming with `hw_checksums=1'.
The driver drops a message in the logfiles to indicate whether or
not it is using hardware scatter/gather and hardware Tx checksums.
Scatter/gather and hardware checksums provide considerable
performance improvement for the sendfile() system call, but a small
decrease in throughput for send(). There is no effect upon receive
efficiency.
compaq_ioaddr=N
compaq_irq=N
compaq_device_id=N
"Variables to work-around the Compaq PCI BIOS32 problem"....
watchdog=N
Sets the time duration (in milliseconds) after which the kernel
decides that the transmitter has become stuck and needs to be reset.
This is mainly for debugging purposes, although it may be advantageous
to increase this value on LANs which have very high collision rates.
The default value is 5000 (5.0 seconds).
enable_wol=N1,N2,N3,...
Enable Wake-on-LAN support for the relevant interface. Donald
Becker's `ether-wake' application may be used to wake suspended
machines.
Also enables the NIC's power management support.
global_enable_wol=N
Sets enable_wol mode for all 3c59x NICs in the machine. Entries in
the `enable_wol' array above will override any setting of this.
Media selection
---------------
A number of the older NICs such as the 3c590 and 3c900 series have
10base2 and AUI interfaces.
Prior to January, 2001 this driver would autoeselect the 10base2 or AUI
port if it didn't detect activity on the 10baseT port. It would then
get stuck on the 10base2 port and a driver reload was necessary to
switch back to 10baseT. This behaviour could not be prevented with a
module option override.
Later (current) versions of the driver _do_ support locking of the
media type. So if you load the driver module with
modprobe 3c59x options=0
it will permanently select the 10baseT port. Automatic selection of
other media types does not occur.
Transmit error, Tx status register 82
-------------------------------------
This is a common error which is almost always caused by another host on
the same network being in full-duplex mode, while this host is in
half-duplex mode. You need to find that other host and make it run in
half-duplex mode or fix this host to run in full-duplex mode.
As a last resort, you can force the 3c59x driver into full-duplex mode
with
options 3c59x full_duplex=1
but this has to be viewed as a workaround for broken network gear and
should only really be used for equipment which cannot autonegotiate.
Additional resources
--------------------
Details of the device driver implementation are at the top of the source file.
Additional documentation is available at Don Becker's Linux Drivers site:
http://www.scyld.com/vortex.html
Donald Becker's driver development site:
http://www.scyld.com/network.html
Donald's vortex-diag program is useful for inspecting the NIC's state:
http://www.scyld.com/ethercard_diag.html
Donald's mii-diag program may be used for inspecting and manipulating
the NIC's Media Independent Interface subsystem:
http://www.scyld.com/ethercard_diag.html#mii-diag
Donald's wake-on-LAN page:
http://www.scyld.com/wakeonlan.html
3Com's DOS-based application for setting up the NICs EEPROMs:
ftp://ftp.3com.com/pub/nic/3c90x/3c90xx2.exe
Driver updates and a detailed changelog for the modifications which
were made for the 2.3/2,4 series kernel is available at
http://www.zip.com.au/~akpm/linux/#3c59x-bc
Autonegotiation notes
---------------------
The driver uses a one-minute heartbeat for adapting to changes in
the external LAN environment if link is up and 5 seconds if link is down.
This means that when, for example, a machine is unplugged from a hubbed
10baseT LAN plugged into a switched 100baseT LAN, the throughput
will be quite dreadful for up to sixty seconds. Be patient.
Cisco interoperability note from Walter Wong <wcw+@CMU.EDU>:
On a side note, adding HAS_NWAY seems to share a problem with the
Cisco 6509 switch. Specifically, you need to change the spanning
tree parameter for the port the machine is plugged into to 'portfast'
mode. Otherwise, the negotiation fails. This has been an issue
we've noticed for a while but haven't had the time to track down.
Cisco switches (Jeff Busch <jbusch@deja.com>)
My "standard config" for ports to which PC's/servers connect directly:
interface FastEthernet0/N
description machinename
load-interval 30
spanning-tree portfast
If autonegotiation is a problem, you may need to specify "speed
100" and "duplex full" as well (or "speed 10" and "duplex half").
WARNING: DO NOT hook up hubs/switches/bridges to these
specially-configured ports! The switch will become very confused.
Reporting and diagnosing problems
---------------------------------
Maintainers find that accurate and complete problem reports are
invaluable in resolving driver problems. We are frequently not able to
reproduce problems and must rely on your patience and efforts to get to
the bottom of the problem.
If you believe you have a driver problem here are some of the
steps you should take:
- Is it really a driver problem?
Eliminate some variables: try different cards, different
computers, different cables, different ports on the switch/hub,
different versions of the kernel or of the driver, etc.
- OK, it's a driver problem.
You need to generate a report. Typically this is an email to the
maintainer and/or linux-net@vger.kernel.org. The maintainer's
email address will be in the driver source or in the MAINTAINERS file.
- The contents of your report will vary a lot depending upon the
problem. If it's a kernel crash then you should refer to the
REPORTING-BUGS file.
But for most problems it is useful to provide the following:
o Kernel version, driver version
o A copy of the banner message which the driver generates when
it is initialised. For example:
eth0: 3Com PCI 3c905C Tornado at 0xa400, 00:50:da:6a:88:f0, IRQ 19
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
MII transceiver found at address 24, status 782d.
Enabling bus-master transmits and whole-frame receives.
NOTE: You must provide the `debug=2' modprobe option to generate
a full detection message. Please do this:
modprobe 3c59x debug=2
o If it is a PCI device, the relevant output from 'lspci -vx', eg:
00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74)
Subsystem: 3Com Corporation: Unknown device 9200
Flags: bus master, medium devsel, latency 32, IRQ 19
I/O ports at a400 [size=128]
Memory at db000000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
00: b7 10 00 92 07 00 10 02 74 00 00 02 08 20 00 00
10: 01 a4 00 00 00 00 00 db 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b7 10 00 10
30: 00 00 00 00 dc 00 00 00 00 00 00 00 05 01 0a 0a
o A description of the environment: 10baseT? 100baseT?
full/half duplex? switched or hubbed?
o Any additional module parameters which you may be providing to the driver.
o Any kernel logs which are produced. The more the merrier.
If this is a large file and you are sending your report to a
mailing list, mention that you have the logfile, but don't send
it. If you're reporting direct to the maintainer then just send
it.
To ensure that all kernel logs are available, add the
following line to /etc/syslog.conf:
kern.* /var/log/messages
Then restart syslogd with:
/etc/rc.d/init.d/syslog restart
(The above may vary, depending upon which Linux distribution you use).
o If your problem is reproducible then that's great. Try the
following:
1) Increase the debug level. Usually this is done via:
a) modprobe driver debug=7
b) In /etc/modprobe.conf (or /etc/modules.conf for 2.4):
options driver debug=7
2) Recreate the problem with the higher debug level,
send all logs to the maintainer.
3) Download you card's diagnostic tool from Donald
Becker's website <http://www.scyld.com/ethercard_diag.html>.
Download mii-diag.c as well. Build these.
a) Run 'vortex-diag -aaee' and 'mii-diag -v' when the card is
working correctly. Save the output.
b) Run the above commands when the card is malfunctioning. Send
both sets of output.
Finally, please be patient and be prepared to do some work. You may
end up working on this problem for a week or more as the maintainer
asks more questions, asks for more tests, asks for patches to be
applied, etc. At the end of it all, the problem may even remain
unresolved.

622
Documentation/networking/wan-router.txt Normal file
View File

@@ -0,0 +1,622 @@
------------------------------------------------------------------------------
Linux WAN Router Utilities Package
------------------------------------------------------------------------------
Version 2.2.1
Mar 28, 2001
Author: Nenad Corbic <ncorbic@sangoma.com>
Copyright (c) 1995-2001 Sangoma Technologies Inc.
------------------------------------------------------------------------------
INTRODUCTION
Wide Area Networks (WANs) are used to interconnect Local Area Networks (LANs)
and/or stand-alone hosts over vast distances with data transfer rates
significantly higher than those achievable with commonly used dial-up
connections.
Usually an external device called `WAN router' sitting on your local network
or connected to your machine's serial port provides physical connection to
WAN. Although router's job may be as simple as taking your local network
traffic, converting it to WAN format and piping it through the WAN link, these
devices are notoriously expensive, with prices as much as 2 - 5 times higher
then the price of a typical PC box.
Alternatively, considering robustness and multitasking capabilities of Linux,
an internal router can be built (most routers use some sort of stripped down
Unix-like operating system anyway). With a number of relatively inexpensive WAN
interface cards available on the market, a perfectly usable router can be
built for less than half a price of an external router. Yet a Linux box
acting as a router can still be used for other purposes, such as fire-walling,
running FTP, WWW or DNS server, etc.
This kernel module introduces the notion of a WAN Link Driver (WLD) to Linux
operating system and provides generic hardware-independent services for such
drivers. Why can existing Linux network device interface not be used for
this purpose? Well, it can. However, there are a few key differences between
a typical network interface (e.g. Ethernet) and a WAN link.
Many WAN protocols, such as X.25 and frame relay, allow for multiple logical
connections (known as `virtual circuits' in X.25 terminology) over a single
physical link. Each such virtual circuit may (and almost always does) lead
to a different geographical location and, therefore, different network. As a
result, it is the virtual circuit, not the physical link, that represents a
route and, therefore, a network interface in Linux terms.
To further complicate things, virtual circuits are usually volatile in nature
(excluding so called `permanent' virtual circuits or PVCs). With almost no
time required to set up and tear down a virtual circuit, it is highly desirable
to implement on-demand connections in order to minimize network charges. So
unlike a typical network driver, the WAN driver must be able to handle multiple
network interfaces and cope as multiple virtual circuits come into existence
and go away dynamically.
Last, but not least, WAN configuration is much more complex than that of say
Ethernet and may well amount to several dozens of parameters. Some of them
are "link-wide" while others are virtual circuit-specific. The same holds
true for WAN statistics which is by far more extensive and extremely useful
when troubleshooting WAN connections. Extending the ifconfig utility to suit
these needs may be possible, but does not seem quite reasonable. Therefore, a
WAN configuration utility and corresponding application programmer's interface
is needed for this purpose.
Most of these problems are taken care of by this module. Its goal is to
provide a user with more-or-less standard look and feel for all WAN devices and
assist a WAN device driver writer by providing common services, such as:
o User-level interface via /proc file system
o Centralized configuration
o Device management (setup, shutdown, etc.)
o Network interface management (dynamic creation/destruction)
o Protocol encapsulation/decapsulation
To ba able to use the Linux WAN Router you will also need a WAN Tools package
available from
ftp.sangoma.com/pub/linux/current_wanpipe/wanpipe-X.Y.Z.tgz
where vX.Y.Z represent the wanpipe version number.
For technical questions and/or comments please e-mail to ncorbic@sangoma.com.
For general inquiries please contact Sangoma Technologies Inc. by
Hotline: 1-800-388-2475 (USA and Canada, toll free)
Phone: (905) 474-1990 ext: 106
Fax: (905) 474-9223
E-mail: dm@sangoma.com (David Mandelstam)
WWW: http://www.sangoma.com
INSTALLATION
Please read the WanpipeForLinux.pdf manual on how to
install the WANPIPE tools and drivers properly.
After installing wanpipe package: /usr/local/wanrouter/doc.
On the ftp.sangoma.com : /linux/current_wanpipe/doc
COPYRIGHT AND LICENSING INFORMATION
This program is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation; either version 2, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with
this program; if not, write to the Free Software Foundation, Inc., 675 Mass
Ave, Cambridge, MA 02139, USA.
ACKNOWLEDGEMENTS
This product is based on the WANPIPE(tm) Multiprotocol WAN Router developed
by Sangoma Technologies Inc. for Linux 2.0.x and 2.2.x. Success of the WANPIPE
together with the next major release of Linux kernel in summer 1996 commanded
adequate changes to the WANPIPE code to take full advantage of new Linux
features.
Instead of continuing developing proprietary interface tied to Sangoma WAN
cards, we decided to separate all hardware-independent code into a separate
module and defined two levels of interfaces - one for user-level applications
and another for kernel-level WAN drivers. WANPIPE is now implemented as a
WAN driver compliant with the WAN Link Driver interface. Also a general
purpose WAN configuration utility and a set of shell scripts was developed to
support WAN router at the user level.
Many useful ideas concerning hardware-independent interface implementation
were given by Mike McLagan <mike.mclagan@linux.org> and his implementation
of the Frame Relay router and drivers for Sangoma cards (dlci/sdla).
With the new implementation of the APIs being incorporated into the WANPIPE,
a special thank goes to Alan Cox in providing insight into BSD sockets.
Special thanks to all the WANPIPE users who performed field-testing, reported
bugs and made valuable comments and suggestions that help us to improve this
product.
NEW IN THIS RELEASE
o Updated the WANCFG utility
Calls the pppconfig to configure the PPPD
for async connections.
o Added the PPPCONFIG utility
Used to configure the PPPD daemon for the
WANPIPE Async PPP and standard serial port.
The wancfg calls the pppconfig to configure
the pppd.
o Fixed the PCI autodetect feature.
The SLOT 0 was used as an autodetect option
however, some high end PC's slot numbers start
from 0.
o This release has been tested with the new backupd
daemon release.
PRODUCT COMPONENTS AND RELATED FILES
/etc: (or user defined)
wanpipe1.conf default router configuration file
/lib/modules/X.Y.Z/misc:
wanrouter.o router kernel loadable module
af_wanpipe.o wanpipe api socket module
/lib/modules/X.Y.Z/net:
sdladrv.o Sangoma SDLA support module
wanpipe.o Sangoma WANPIPE(tm) driver module
/proc/net/wanrouter
Config reads current router configuration
Status reads current router status
{name} reads WAN driver statistics
/usr/sbin:
wanrouter wanrouter start-up script
wanconfig wanrouter configuration utility
sdladump WANPIPE adapter memory dump utility
fpipemon Monitor for Frame Relay
cpipemon Monitor for Cisco HDLC
ppipemon Monitor for PPP
xpipemon Monitor for X25
wpkbdmon WANPIPE keyboard led monitor/debugger
/usr/local/wanrouter:
README this file
COPYING GNU General Public License
Setup installation script
Filelist distribution definition file
wanrouter.rc meta-configuration file
(used by the Setup and wanrouter script)
/usr/local/wanrouter/doc:
wanpipeForLinux.pdf WAN Router User's Manual
/usr/local/wanrouter/patches:
wanrouter-v2213.gz patch for Linux kernels 2.2.11 up to 2.2.13.
wanrouter-v2214.gz patch for Linux kernel 2.2.14.
wanrouter-v2215.gz patch for Linux kernels 2.2.15 to 2.2.17.
wanrouter-v2218.gz patch for Linux kernels 2.2.18 and up.
wanrouter-v240.gz patch for Linux kernel 2.4.0.
wanrouter-v242.gz patch for Linux kernel 2.4.2 and up.
wanrouter-v2034.gz patch for Linux kernel 2.0.34
wanrouter-v2036.gz patch for Linux kernel 2.0.36 and up.
/usr/local/wanrouter/patches/kdrivers:
Sources of the latest WANPIPE device drivers.
These are used to UPGRADE the linux kernel to the newest
version if the kernel source has already been patched with
WANPIPE drivers.
/usr/local/wanrouter/samples:
interface sample interface configuration file
wanpipe1.cpri CHDLC primary port
wanpipe2.csec CHDLC secondary port
wanpipe1.fr Frame Relay protocol
wanpipe1.ppp PPP protocol )
wanpipe1.asy CHDLC ASYNC protocol
wanpipe1.x25 X25 protocol
wanpipe1.stty Sync TTY driver (Used by Kernel PPPD daemon)
wanpipe1.atty Async TTY driver (Used by Kernel PPPD daemon)
wanrouter.rc sample meta-configuration file
/usr/local/wanrouter/util:
* wan-tools utilities source code
/usr/local/wanrouter/api/x25:
* x25 api sample programs.
/usr/local/wanrouter/api/chdlc:
* chdlc api sample programs.
/usr/local/wanrouter/api/fr:
* fr api sample programs.
/usr/local/wanrouter/config/wancfg:
wancfg WANPIPE GUI configuration program.
Creates wanpipe#.conf files.
/usr/local/wanrouter/config/cfgft1:
cfgft1 GUI CSU/DSU configuration program.
/usr/include/linux:
wanrouter.h router API definitions
wanpipe.h WANPIPE API definitions
sdladrv.h SDLA support module API definitions
sdlasfm.h SDLA firmware module definitions
if_wanpipe.h WANPIPE Socket definitions
if_wanpipe_common.h WANPIPE Socket/Driver common definitions.
sdlapci.h WANPIPE PCI definitions
/usr/src/linux/net/wanrouter:
* wanrouter source code
/var/log:
wanrouter wanrouter start-up log (created by the Setup script)
/var/lock: (or /var/lock/subsys for RedHat)
wanrouter wanrouter lock file (created by the Setup script)
/usr/local/wanrouter/firmware:
fr514.sfm Frame relay firmware for Sangoma S508/S514 card
cdual514.sfm Dual Port Cisco HDLC firmware for Sangoma S508/S514 card
ppp514.sfm PPP Firmware for Sangoma S508 and S514 cards
x25_508.sfm X25 Firmware for Sangoma S508 card.
REVISION HISTORY
1.0.0 December 31, 1996 Initial version
1.0.1 January 30, 1997 Status and statistics can be read via /proc
filesystem entries.
1.0.2 April 30, 1997 Added UDP management via monitors.
1.0.3 June 3, 1997 UDP management for multiple boards using Frame
Relay and PPP
Enabled continuous transmission of Configure
Request Packet for PPP (for 508 only)
Connection Timeout for PPP changed from 900 to 0
Flow Control Problem fixed for Frame Relay
1.0.4 July 10, 1997 S508/FT1 monitoring capability in fpipemon and
ppipemon utilities.
Configurable TTL for UDP packets.
Multicast and Broadcast IP source addresses are
silently discarded.
1.0.5 July 28, 1997 Configurable T391,T392,N391,N392,N393 for Frame
Relay in router.conf.
Configurable Memory Address through router.conf
for Frame Relay, PPP and X.25. (commenting this
out enables auto-detection).
Fixed freeing up received buffers using kfree()
for Frame Relay and X.25.
Protect sdla_peek() by calling save_flags(),
cli() and restore_flags().
Changed number of Trace elements from 32 to 20
Added DLCI specific data monitoring in FPIPEMON.
2.0.0 Nov 07, 1997 Implemented protection of RACE conditions by
critical flags for FRAME RELAY and PPP.
DLCI List interrupt mode implemented.
IPX support in FRAME RELAY and PPP.
IPX Server Support (MARS)
More driver specific stats included in FPIPEMON
and PIPEMON.
2.0.1 Nov 28, 1997 Bug Fixes for version 2.0.0.
Protection of "enable_irq()" while
"disable_irq()" has been enabled from any other
routine (for Frame Relay, PPP and X25).
Added additional Stats for Fpipemon and Ppipemon
Improved Load Sharing for multiple boards
2.0.2 Dec 09, 1997 Support for PAP and CHAP for ppp has been
implemented.
2.0.3 Aug 15, 1998 New release supporting Cisco HDLC, CIR for Frame
relay, Dynamic IP assignment for PPP and Inverse
Arp support for Frame-relay. Man Pages are
included for better support and a new utility
for configuring FT1 cards.
2.0.4 Dec 09, 1998 Dual Port support for Cisco HDLC.
Support for HDLC (LAPB) API.
Supports BiSync Streaming code for S502E
and S503 cards.
Support for Streaming HDLC API.
Provides a BSD socket interface for
creating applications using BiSync
streaming.
2.0.5 Aug 04, 1999 CHDLC initializatin bug fix.
PPP interrupt driven driver:
Fix to the PPP line hangup problem.
New PPP firmware
Added comments to the startup SYSTEM ERROR messages
Xpipemon debugging application for the X25 protocol
New USER_MANUAL.txt
Fixed the odd boundary 4byte writes to the board.
BiSync Streaming code has been taken out.
Available as a patch.
Streaming HDLC API has been taken out.
Available as a patch.
2.0.6 Aug 17, 1999 Increased debugging in statup scripts
Fixed installation bugs from 2.0.5
Kernel patch works for both 2.2.10 and 2.2.11 kernels.
There is no functional difference between the two packages
2.0.7 Aug 26, 1999 o Merged X25API code into WANPIPE.
o Fixed a memory leak for X25API
o Updated the X25API code for 2.2.X kernels.
o Improved NEM handling.
2.1.0 Oct 25, 1999 o New code for S514 PCI Card
o New CHDLC and Frame Relay drivers
o PPP and X25 are not supported in this release
2.1.1 Nov 30, 1999 o PPP support for S514 PCI Cards
2.1.3 Apr 06, 2000 o Socket based x25api
o Socket based chdlc api
o Socket based fr api
o Dual Port Receive only CHDLC support.
o Asynchronous CHDLC support (Secondary Port)
o cfgft1 GUI csu/dsu configurator
o wancfg GUI configuration file
configurator.
o Architectual directory changes.
beta-2.1.4 Jul 2000 o Dynamic interface configuration:
Network interfaces reflect the state
of protocol layer. If the protocol becomes
disconnected, driver will bring down
the interface. Once the protocol reconnects
the interface will be brought up.
Note: This option is turned off by default.
o Dynamic wanrouter setup using 'wanconfig':
wanconfig utility can be used to
shutdown,restart,start or reconfigure
a virtual circuit dynamically.
Frame Relay: Each DLCI can be:
created,stopped,restarted and reconfigured
dynamically using wanconfig.
ex: wanconfig card wanpipe1 dev wp1_fr16 up
o Wanrouter startup via command line arguments:
wanconfig also supports wanrouter startup via command line
arguments. Thus, there is no need to create a wanpipe#.conf
configuration file.
o Socket based x25api update/bug fixes.
Added support for LCN numbers greater than 255.
Option to pass up modem messages.
Provided a PCI IRQ check, so a single S514
card is guaranteed to have a non-sharing interrupt.
o Fixes to the wancfg utility.
o New FT1 debugging support via *pipemon utilities.
o Frame Relay ARP support Enabled.
beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix.
o Added the Multi-Port PPP
Updated utilities for the Multi-Port PPP.
2.1.4 Aut 2000
o In X25API:
Maximum packet an application can send
to the driver has been extended to 4096 bytes.
Fixed the x25 startup bug. Enable
communications only after all interfaces
come up. HIGH SVC/PVC is used to calculate
the number of channels.
Enable protocol only after all interfaces
are enabled.
o Added an extra state to the FT1 config, kernel module.
o Updated the pipemon debuggers.
o Blocked the Multi-Port PPP from running on kernels
2.2.16 or greater, due to syncppp kernel module
change.
beta1-2.1.5 Nov 15 2000
o Fixed the MultiPort PPP Support for kernels 2.2.16 and above.
2.2.X kernels only
o Secured the driver UDP debugging calls
- All illegal network debugging calls are reported to
the log.
- Defined a set of allowed commands, all other denied.
o Cpipemon
- Added set FT1 commands to the cpipemon. Thus CSU/DSU
configuration can be performed using cpipemon.
All systems that cannot run cfgft1 GUI utility should
use cpipemon to configure the on board CSU/DSU.
o Keyboard Led Monitor/Debugger
- A new utility /usr/sbin/wpkbdmon uses keyboard leds
to convey operational statistic information of the
Sangoma WANPIPE cards.
NUM_LOCK = Line State (On=connected, Off=disconnected)
CAPS_LOCK = Tx data (On=transmitting, Off=no tx data)
SCROLL_LOCK = Rx data (On=receiving, Off=no rx data
o Hardware probe on module load and dynamic device allocation
- During WANPIPE module load, all Sangoma cards are probed
and found information is printed in the /var/log/messages.
- If no cards are found, the module load fails.
- Appropriate number of devices are dynamically loaded
based on the number of Sangoma cards found.
Note: The kernel configuration option
CONFIG_WANPIPE_CARDS has been taken out.
o Fixed the Frame Relay and Chdlc network interfaces so they are
compatible with libpcap libraries. Meaning, tcpdump, snort,
ethereal, and all other packet sniffers and debuggers work on
all WANPIPE network interfaces.
- Set the network interface encoding type to ARPHRD_PPP.
This tell the sniffers that data obtained from the
network interface is in pure IP format.
Fix for 2.2.X kernels only.
o True interface encoding option for Frame Relay and CHDLC
- The above fix sets the network interface encoding
type to ARPHRD_PPP, however some customers use
the encoding interface type to determine the
protocol running. Therefore, the TURE ENCODING
option will set the interface type back to the
original value.
NOTE: If this option is used with Frame Relay and CHDLC
libpcap library support will be broken.
i.e. tcpdump will not work.
Fix for 2.2.x Kernels only.
o Ethernet Bridgind over Frame Relay
- The Frame Relay bridging has been developed by
Kristian Hoffmann and Mark Wells.
- The Linux kernel bridge is used to send ethernet
data over the frame relay links.
For 2.2.X Kernels only.
o Added extensive 2.0.X support. Most new features of
2.1.5 for protocols Frame Relay, PPP and CHDLC are
supported under 2.0.X kernels.
beta1-2.2.0 Dec 30 2000
o Updated drivers for 2.4.X kernels.
o Updated drivers for SMP support.
o X25API is now able to share PCI interrupts.
o Took out a general polling routine that was used
only by X25API.
o Added appropriate locks to the dynamic reconfiguration
code.
o Fixed a bug in the keyboard debug monitor.
beta2-2.2.0 Jan 8 2001
o Patches for 2.4.0 kernel
o Patches for 2.2.18 kernel
o Minor updates to PPP and CHLDC drivers.
Note: No functional difference.
beta3-2.2.9 Jan 10 2001
o I missed the 2.2.18 kernel patches in beta2-2.2.0
release. They are included in this release.
Stable Release
2.2.0 Feb 01 2001
o Bug fix in wancfg GUI configurator.
The edit function didn't work properly.
bata1-2.2.1 Feb 09 2001
o WANPIPE TTY Driver emulation.
Two modes of operation Sync and Async.
Sync: Using the PPPD daemon, kernel SyncPPP layer
and the Wanpipe sync TTY driver: a PPP protocol
connection can be established via Sangoma adapter, over
a T1 leased line.
The 2.4.0 kernel PPP layer supports MULTILINK
protocol, that can be used to bundle any number of Sangoma
adapters (T1 lines) into one, under a single IP address.
Thus, efficiently obtaining multiple T1 throughput.
NOTE: The remote side must also implement MULTILINK PPP
protocol.
Async:Using the PPPD daemon, kernel AsyncPPP layer
and the WANPIPE async TTY driver: a PPP protocol
connection can be established via Sangoma adapter and
a modem, over a telephone line.
Thus, the WANPIPE async TTY driver simulates a serial
TTY driver that would normally be used to interface the
MODEM to the linux kernel.
o WANPIPE PPP Backup Utility
This utility will monitor the state of the PPP T1 line.
In case of failure, a dial up connection will be established
via pppd daemon, ether via a serial tty driver (serial port),
or a WANPIPE async TTY driver (in case serial port is unavailable).
Furthermore, while in dial up mode, the primary PPP T1 link
will be monitored for signs of life.
If the PPP T1 link comes back to life, the dial up connection
will be shutdown and T1 line re-established.
o New Setup installation script.
Option to UPGRADE device drivers if the kernel source has
already been patched with WANPIPE.
Option to COMPILE WANPIPE modules against the currently
running kernel, thus no need for manual kernel and module
re-compilation.
o Updates and Bug Fixes to wancfg utility.
bata2-2.2.1 Feb 20 2001
o Bug fixes to the CHDLC device drivers.
The driver had compilation problems under kernels
2.2.14 or lower.
o Bug fixes to the Setup installation script.
The device drivers compilation options didn't work
properly.
o Update to the wpbackupd daemon.
Optimized the cross-over times, between the primary
link and the backup dialup.
beta3-2.2.1 Mar 02 2001
o Patches for 2.4.2 kernel.
o Bug fixes to util/ make files.
o Bug fixes to the Setup installation script.
o Took out the backupd support and made it into
as separate package.
beta4-2.2.1 Mar 12 2001
o Fix to the Frame Relay Device driver.
IPSAC sends a packet of zero length
header to the frame relay driver. The
driver tries to push its own 2 byte header
into the packet, which causes the driver to
crash.
o Fix the WANPIPE re-configuration code.
Bug was found by trying to run the cfgft1 while the
interface was already running.
o Updates to cfgft1.
Writes a wanpipe#.cfgft1 configuration file
once the CSU/DSU is configured. This file can
holds the current CSU/DSU configuration.
>>>>>> END OF README <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

73
Documentation/networking/wavelan.txt Normal file
View File

@@ -0,0 +1,73 @@
The Wavelan drivers saga
------------------------
By Jean Tourrilhes <jt@hpl.hp.com>
The Wavelan is a Radio network adapter designed by
Lucent. Under this generic name is hidden quite a variety of hardware,
and many Linux driver to support it.
The get the full story on Wireless LANs, please consult :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/
"wavelan" driver (old ISA Wavelan)
----------------
o Config : Network device -> Wireless LAN -> AT&T WaveLAN
o Location : .../drivers/net/wavelan*
o in-line doc : .../drivers/net/wavelan.p.h
o on-line doc :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
This is the driver for the ISA version of the first generation
of the Wavelan, now discontinued. The device is 2 Mb/s, composed of a
Intel 82586 controller and a Lucent Modem, and is NOT 802.11 compliant.
The driver has been tested with the following hardware :
o Wavelan ISA 915 MHz (full length ISA card)
o Wavelan ISA 915 MHz 2.0 (half length ISA card)
o Wavelan ISA 2.4 GHz (full length ISA card, fixed frequency)
o Wavelan ISA 2.4 GHz 2.0 (half length ISA card, frequency selectable)
o Above cards with the optional DES encryption feature
"wavelan_cs" driver (old Pcmcia Wavelan)
-------------------
o Config : Network device -> PCMCIA network ->
Pcmcia Wireless LAN -> AT&T/Lucent WaveLAN
o Location : .../drivers/net/pcmcia/wavelan*
o in-line doc : .../drivers/net/pcmcia/wavelan_cs.h
o on-line doc :
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html
This is the driver for the PCMCIA version of the first
generation of the Wavelan, now discontinued. The device is 2 Mb/s,
composed of a Intel 82593 controller (totally different from the 82586)
and a Lucent Modem, and NOT 802.11 compatible.
The driver has been tested with the following hardware :
o Wavelan Pcmcia 915 MHz 2.0 (Pcmcia card + separate
modem/antenna block)
o Wavelan Pcmcia 2.4 GHz 2.0 (Pcmcia card + separate
modem/antenna block)
"wvlan_cs" driver (Wavelan IEEE, GPL)
-----------------
o Config : Not yet in kernel
o Location : Pcmcia package 3.1.10+
o on-line doc : http://www.fasta.fh-dortmund.de/users/andy/wvlan/
This is the driver for the current generation of Wavelan IEEE,
which is 802.11 compatible. Depending on version, it is 2 Mb/s or 11
Mb/s, with or without encryption, all implemented in Lucent specific
DSP (the Hermes).
This is a GPL full source PCMCIA driver (ISA is just a Pcmcia
card with ISA-Pcmcia bridge).
"wavelan2_cs" driver (Wavelan IEEE, binary)
--------------------
o Config : Not yet in kernel
o Location : ftp://sourceforge.org/pcmcia/contrib/
This driver support exactly the same hardware as the previous
driver, the main difference is that it is based on a binary library
and supported by Lucent.
I hope it clears the confusion ;-)
Jean

123
Documentation/networking/x25-iface.txt Normal file
View File

@@ -0,0 +1,123 @@
X.25 Device Driver Interface 1.1
Jonathan Naylor 26.12.96
This is a description of the messages to be passed between the X.25 Packet
Layer and the X.25 device driver. They are designed to allow for the easy
setting of the LAPB mode from within the Packet Layer.
The X.25 device driver will be coded normally as per the Linux device driver
standards. Most X.25 device drivers will be moderately similar to the
already existing Ethernet device drivers. However unlike those drivers, the
X.25 device driver has a state associated with it, and this information
needs to be passed to and from the Packet Layer for proper operation.
All messages are held in sk_buff's just like real data to be transmitted
over the LAPB link. The first byte of the skbuff indicates the meaning of
the rest of the skbuff, if any more information does exist.
Packet Layer to Device Driver
-----------------------------
First Byte = 0x00
This indicates that the rest of the skbuff contains data to be transmitted
over the LAPB link. The LAPB link should already exist before any data is
passed down.
First Byte = 0x01
Establish the LAPB link. If the link is already established then the connect
confirmation message should be returned as soon as possible.
First Byte = 0x02
Terminate the LAPB link. If it is already disconnected then the disconnect
confirmation message should be returned as soon as possible.
First Byte = 0x03
LAPB parameters. To be defined.
Device Driver to Packet Layer
-----------------------------
First Byte = 0x00
This indicates that the rest of the skbuff contains data that has been
received over the LAPB link.
First Byte = 0x01
LAPB link has been established. The same message is used for both a LAPB
link connect_confirmation and a connect_indication.
First Byte = 0x02
LAPB link has been terminated. This same message is used for both a LAPB
link disconnect_confirmation and a disconnect_indication.
First Byte = 0x03
LAPB parameters. To be defined.
Possible Problems
=================
(Henner Eisen, 2000-10-28)
The X.25 packet layer protocol depends on a reliable datalink service.
The LAPB protocol provides such reliable service. But this reliability
is not preserved by the Linux network device driver interface:
- With Linux 2.4.x (and above) SMP kernels, packet ordering is not
preserved. Even if a device driver calls netif_rx(skb1) and later
netif_rx(skb2), skb2 might be delivered to the network layer
earlier that skb1.
- Data passed upstream by means of netif_rx() might be dropped by the
kernel if the backlog queue is congested.
The X.25 packet layer protocol will detect this and reset the virtual
call in question. But many upper layer protocols are not designed to
handle such N-Reset events gracefully. And frequent N-Reset events
will always degrade performance.
Thus, driver authors should make netif_rx() as reliable as possible:
SMP re-ordering will not occur if the driver's interrupt handler is
always executed on the same CPU. Thus,
- Driver authors should use irq affinity for the interrupt handler.
The probability of packet loss due to backlog congestion can be
reduced by the following measures or a combination thereof:
(1) Drivers for kernel versions 2.4.x and above should always check the
return value of netif_rx(). If it returns NET_RX_DROP, the
driver's LAPB protocol must not confirm reception of the frame
to the peer.
This will reliably suppress packet loss. The LAPB protocol will
automatically cause the peer to re-transmit the dropped packet
later.
The lapb module interface was modified to support this. Its
data_indication() method should now transparently pass the
netif_rx() return value to the (lapb mopdule) caller.
(2) Drivers for kernel versions 2.2.x should always check the global
variable netdev_dropping when a new frame is received. The driver
should only call netif_rx() if netdev_dropping is zero. Otherwise
the driver should not confirm delivery of the frame and drop it.
Alternatively, the driver can queue the frame internally and call
netif_rx() later when netif_dropping is 0 again. In that case, delivery
confirmation should also be deferred such that the internal queue
cannot grow to much.
This will not reliably avoid packet loss, but the probability
of packet loss in netif_rx() path will be significantly reduced.
(3) Additionally, driver authors might consider to support
CONFIG_NET_HW_FLOWCONTROL. This allows the driver to be woken up
when a previously congested backlog queue becomes empty again.
The driver could uses this for flow-controlling the peer by means
of the LAPB protocol's flow-control service.

44
Documentation/networking/x25.txt Normal file
View File

@@ -0,0 +1,44 @@
Linux X.25 Project
As my third year dissertation at University I have taken it upon myself to
write an X.25 implementation for Linux. My aim is to provide a complete X.25
Packet Layer and a LAPB module to allow for "normal" X.25 to be run using
Linux. There are two sorts of X.25 cards available, intelligent ones that
implement LAPB on the card itself, and unintelligent ones that simply do
framing, bit-stuffing and checksumming. These both need to be handled by the
system.
I therefore decided to write the implementation such that as far as the
Packet Layer is concerned, the link layer was being performed by a lower
layer of the Linux kernel and therefore it did not concern itself with
implementation of LAPB. Therefore the LAPB modules would be called by
unintelligent X.25 card drivers and not by intelligent ones, this would
provide a uniform device driver interface, and simplify configuration.
To confuse matters a little, an 802.2 LLC implementation for Linux is being
written which will allow X.25 to be run over an Ethernet (or Token Ring) and
conform with the JNT "Pink Book", this will have a different interface to
the Packet Layer but there will be no confusion since the class of device
being served by the LLC will be completely separate from LAPB. The LLC
implementation is being done as part of another protocol project (SNA) and
by a different author.
Just when you thought that it could not become more confusing, another
option appeared, XOT. This allows X.25 Packet Layer frames to operate over
the Internet using TCP/IP as a reliable link layer. RFC1613 specifies the
format and behaviour of the protocol. If time permits this option will also
be actively considered.
A linux-x25 mailing list has been created at vger.kernel.org to support the
development and use of Linux X.25. It is early days yet, but interested
parties are welcome to subscribe to it. Just send a message to
majordomo@vger.kernel.org with the following in the message body:
subscribe linux-x25
end
The contents of the Subject line are ignored.
Jonathan
g4klx@g4klx.demon.co.uk

169
Documentation/networking/xfrm_sync.txt Normal file
View File

@@ -0,0 +1,169 @@
The sync patches work is based on initial patches from
Krisztian <hidden@balabit.hu> and others and additional patches
from Jamal <hadi@cyberus.ca>.
The end goal for syncing is to be able to insert attributes + generate
events so that the an SA can be safely moved from one machine to another
for HA purposes.
The idea is to synchronize the SA so that the takeover machine can do
the processing of the SA as accurate as possible if it has access to it.
We already have the ability to generate SA add/del/upd events.
These patches add ability to sync and have accurate lifetime byte (to
ensure proper decay of SAs) and replay counters to avoid replay attacks
with as minimal loss at failover time.
This way a backup stays as closely uptodate as an active member.
Because the above items change for every packet the SA receives,
it is possible for a lot of the events to be generated.
For this reason, we also add a nagle-like algorithm to restrict
the events. i.e we are going to set thresholds to say "let me
know if the replay sequence threshold is reached or 10 secs have passed"
These thresholds are set system-wide via sysctls or can be updated
per SA.
The identified items that need to be synchronized are:
- the lifetime byte counter
note that: lifetime time limit is not important if you assume the failover
machine is known ahead of time since the decay of the time countdown
is not driven by packet arrival.
- the replay sequence for both inbound and outbound
1) Message Structure
----------------------
nlmsghdr:aevent_id:optional-TLVs.
The netlink message types are:
XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
A XFRM_MSG_GETAE does not have TLVs.
A XFRM_MSG_NEWAE will have at least two TLVs (as is
discussed further below).
aevent_id structure looks like:
struct xfrm_aevent_id {
struct xfrm_usersa_id sa_id;
xfrm_address_t saddr;
__u32 flags;
__u32 reqid;
};
The unique SA is identified by the combination of xfrm_usersa_id,
reqid and saddr.
flags are used to indicate different things. The possible
flags are:
XFRM_AE_RTHR=1, /* replay threshold*/
XFRM_AE_RVAL=2, /* replay value */
XFRM_AE_LVAL=4, /* lifetime value */
XFRM_AE_ETHR=8, /* expiry timer threshold */
XFRM_AE_CR=16, /* Event cause is replay update */
XFRM_AE_CE=32, /* Event cause is timer expiry */
XFRM_AE_CU=64, /* Event cause is policy update */
How these flags are used is dependent on the direction of the
message (kernel<->user) as well the cause (config, query or event).
This is described below in the different messages.
The pid will be set appropriately in netlink to recognize direction
(0 to the kernel and pid = processid that created the event
when going from kernel to user space)
A program needs to subscribe to multicast group XFRMNLGRP_AEVENTS
to get notified of these events.
2) TLVS reflect the different parameters:
-----------------------------------------
a) byte value (XFRMA_LTIME_VAL)
This TLV carries the running/current counter for byte lifetime since
last event.
b)replay value (XFRMA_REPLAY_VAL)
This TLV carries the running/current counter for replay sequence since
last event.
c)replay threshold (XFRMA_REPLAY_THRESH)
This TLV carries the threshold being used by the kernel to trigger events
when the replay sequence is exceeded.
d) expiry timer (XFRMA_ETIMER_THRESH)
This is a timer value in milliseconds which is used as the nagle
value to rate limit the events.
3) Default configurations for the parameters:
----------------------------------------------
By default these events should be turned off unless there is
at least one listener registered to listen to the multicast
group XFRMNLGRP_AEVENTS.
Programs installing SAs will need to specify the two thresholds, however,
in order to not change existing applications such as racoon
we also provide default threshold values for these different parameters
in case they are not specified.
the two sysctls/proc entries are:
a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
used to provide default values for the XFRMA_ETIMER_THRESH in incremental
units of time of 100ms. The default is 10 (1 second)
b) /proc/sys/net/core/sysctl_xfrm_aevent_rseqth
used to provide default values for XFRMA_REPLAY_THRESH parameter
in incremental packet count. The default is two packets.
4) Message types
----------------
a) XFRM_MSG_GETAE issued by user-->kernel.
XFRM_MSG_GETAE does not carry any TLVs.
The response is a XFRM_MSG_NEWAE which is formatted based on what
XFRM_MSG_GETAE queried for.
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
b) XFRM_MSG_NEWAE is issued by either user space to configure
or kernel to announce events or respond to a XFRM_MSG_GETAE.
i) user --> kernel to configure a specific SA.
any of the values or threshold parameters can be updated by passing the
appropriate TLV.
A response is issued back to the sender in user space to indicate success
or failure.
In the case of success, additionally an event with
XFRM_MSG_NEWAE is also issued to any listeners as described in iii).
ii) kernel->user direction as a response to XFRM_MSG_GETAE
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
The threshold TLVs will be included if explicitly requested in
the XFRM_MSG_GETAE message.
iii) kernel->user to report as event if someone sets any values or
thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above).
In such a case XFRM_AE_CU flag is set to inform the user that
the change happened as a result of an update.
The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
iv) kernel->user to report event when replay threshold or a timeout
is exceeded.
In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout
happened) is set to inform the user what happened.
Note the two flags are mutually exclusive.
The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
Exceptions to threshold settings
--------------------------------
If you have an SA that is getting hit by traffic in bursts such that
there is a period where the timer threshold expires with no packets
seen, then an odd behavior is seen as follows:
The first packet arrival after a timer expiry will trigger a timeout
aevent; i.e we dont wait for a timeout period or a packet threshold
to be reached. This is done for simplicity and efficiency reasons.
-JHS

657
Documentation/networking/z8530drv.txt Normal file
View File

@@ -0,0 +1,657 @@
This is a subset of the documentation. To use this driver you MUST have the
full package from:
Internet:
=========
1. ftp://ftp.ccac.rwth-aachen.de/pub/jr/z8530drv-utils_3.0-3.tar.gz
2. ftp://ftp.pspt.fi/pub/ham/linux/ax25/z8530drv-utils_3.0-3.tar.gz
Please note that the information in this document may be hopelessly outdated.
A new version of the documentation, along with links to other important
Linux Kernel AX.25 documentation and programs, is available on
http://yaina.de/jreuter
-----------------------------------------------------------------------------
SCC.C - Linux driver for Z8530 based HDLC cards for AX.25
********************************************************************
(c) 1993,2000 by Joerg Reuter DL1BKE <jreuter@yaina.de>
portions (c) 1993 Guido ten Dolle PE1NNZ
for the complete copyright notice see >> Copying.Z8530DRV <<
********************************************************************
1. Initialization of the driver
===============================
To use the driver, 3 steps must be performed:
1. if compiled as module: loading the module
2. Setup of hardware, MODEM and KISS parameters with sccinit
3. Attach each channel to the Linux kernel AX.25 with "ifconfig"
Unlike the versions below 2.4 this driver is a real network device
driver. If you want to run xNOS instead of our fine kernel AX.25
use a 2.x version (available from above sites) or read the
AX.25-HOWTO on how to emulate a KISS TNC on network device drivers.
1.1 Loading the module
======================
(If you're going to compile the driver as a part of the kernel image,
skip this chapter and continue with 1.2)
Before you can use a module, you'll have to load it with
insmod scc.o
please read 'man insmod' that comes with module-init-tools.
You should include the insmod in one of the /etc/rc.d/rc.* files,
and don't forget to insert a call of sccinit after that. It
will read your /etc/z8530drv.conf.
1.2. /etc/z8530drv.conf
=======================
To setup all parameters you must run /sbin/sccinit from one
of your rc.*-files. This has to be done BEFORE you can
"ifconfig" an interface. Sccinit reads the file /etc/z8530drv.conf
and sets the hardware, MODEM and KISS parameters. A sample file is
delivered with this package. Change it to your needs.
The file itself consists of two main sections.
1.2.1 configuration of hardware parameters
==========================================
The hardware setup section defines the following parameters for each
Z8530:
chip 1
data_a 0x300 # data port A
ctrl_a 0x304 # control port A
data_b 0x301 # data port B
ctrl_b 0x305 # control port B
irq 5 # IRQ No. 5
pclock 4915200 # clock
board BAYCOM # hardware type
escc no # enhanced SCC chip? (8580/85180/85280)
vector 0 # latch for interrupt vector
special no # address of special function register
option 0 # option to set via sfr
chip - this is just a delimiter to make sccinit a bit simpler to
program. A parameter has no effect.
data_a - the address of the data port A of this Z8530 (needed)
ctrl_a - the address of the control port A (needed)
data_b - the address of the data port B (needed)
ctrl_b - the address of the control port B (needed)
irq - the used IRQ for this chip. Different chips can use different
IRQs or the same. If they share an interrupt, it needs to be
specified within one chip-definition only.
pclock - the clock at the PCLK pin of the Z8530 (option, 4915200 is
default), measured in Hertz
board - the "type" of the board:
SCC type value
---------------------------------
PA0HZP SCC card PA0HZP
EAGLE card EAGLE
PC100 card PC100
PRIMUS-PC (DG9BL) card PRIMUS
BayCom (U)SCC card BAYCOM
escc - if you want support for ESCC chips (8580, 85180, 85280), set
this to "yes" (option, defaults to "no")
vector - address of the vector latch (aka "intack port") for PA0HZP
cards. There can be only one vector latch for all chips!
(option, defaults to 0)
special - address of the special function register on several cards.
(option, defaults to 0)
option - The value you write into that register (option, default is 0)
You can specify up to four chips (8 channels). If this is not enough,
just change
#define MAXSCC 4
to a higher value.
Example for the BAYCOM USCC:
----------------------------
chip 1
data_a 0x300 # data port A
ctrl_a 0x304 # control port A
data_b 0x301 # data port B
ctrl_b 0x305 # control port B
irq 5 # IRQ No. 5 (#)
board BAYCOM # hardware type (*)
#
# SCC chip 2
#
chip 2
data_a 0x302
ctrl_a 0x306
data_b 0x303
ctrl_b 0x307
board BAYCOM
An example for a PA0HZP card:
-----------------------------
chip 1
data_a 0x153
data_b 0x151
ctrl_a 0x152
ctrl_b 0x150
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
#
#
#
chip 2
data_a 0x157
data_b 0x155
ctrl_a 0x156
ctrl_b 0x154
irq 9
pclock 4915200
board PA0HZP
vector 0x168
escc no
A DRSI would should probably work with this:
--------------------------------------------
(actually: two DRSI cards...)
chip 1
data_a 0x303
data_b 0x301
ctrl_a 0x302
ctrl_b 0x300
irq 7
pclock 4915200
board DRSI
escc no
#
#
#
chip 2
data_a 0x313
data_b 0x311
ctrl_a 0x312
ctrl_b 0x310
irq 7
pclock 4915200
board DRSI
escc no
Note that you cannot use the on-board baudrate generator off DRSI
cards. Use "mode dpll" for clock source (see below).
This is based on information provided by Mike Bilow (and verified
by Paul Helay)
The utility "gencfg"
--------------------
If you only know the parameters for the PE1CHL driver for DOS,
run gencfg. It will generate the correct port addresses (I hope).
Its parameters are exactly the same as the ones you use with
the "attach scc" command in net, except that the string "init" must
not appear. Example:
gencfg 2 0x150 4 2 0 1 0x168 9 4915200
will print a skeleton z8530drv.conf for the OptoSCC to stdout.
gencfg 2 0x300 2 4 5 -4 0 7 4915200 0x10
does the same for the BAYCOM USCC card. In my opinion it is much easier
to edit scc_config.h...
1.2.2 channel configuration
===========================
The channel definition is divided into three sub sections for each
channel:
An example for scc0:
# DEVICE
device scc0 # the device for the following params
# MODEM / BUFFERS
speed 1200 # the default baudrate
clock dpll # clock source:
# dpll = normal half duplex operation
# external = MODEM provides own Rx/Tx clock
# divider = use full duplex divider if
# installed (1)
mode nrzi # HDLC encoding mode
# nrzi = 1k2 MODEM, G3RUH 9k6 MODEM
# nrz = DF9IC 9k6 MODEM
#
bufsize 384 # size of buffers. Note that this must include
# the AX.25 header, not only the data field!
# (optional, defaults to 384)
# KISS (Layer 1)
txdelay 36 # (see chapter 1.4)
persist 64
slot 8
tail 8
fulldup 0
wait 12
min 3
maxkey 7
idle 3
maxdef 120
group 0
txoff off
softdcd on
slip off
The order WITHIN these sections is unimportant. The order OF these
sections IS important. The MODEM parameters are set with the first
recognized KISS parameter...
Please note that you can initialize the board only once after boot
(or insmod). You can change all parameters but "mode" and "clock"
later with the Sccparam program or through KISS. Just to avoid
security holes...
(1) this divider is usually mounted on the SCC-PBC (PA0HZP) or not
present at all (BayCom). It feeds back the output of the DPLL
(digital pll) as transmit clock. Using this mode without a divider
installed will normally result in keying the transceiver until
maxkey expires --- of course without sending anything (useful).
2. Attachment of a channel by your AX.25 software
=================================================
2.1 Kernel AX.25
================
To set up an AX.25 device you can simply type:
ifconfig scc0 44.128.1.1 hw ax25 dl0tha-7
This will create a network interface with the IP number 44.128.20.107
and the callsign "dl0tha". If you do not have any IP number (yet) you
can use any of the 44.128.0.0 network. Note that you do not need
axattach. The purpose of axattach (like slattach) is to create a KISS
network device linked to a TTY. Please read the documentation of the
ax25-utils and the AX.25-HOWTO to learn how to set the parameters of
the kernel AX.25.
2.2 NOS, NET and TFKISS
=======================
Since the TTY driver (aka KISS TNC emulation) is gone you need
to emulate the old behaviour. The cost of using these programs is
that you probably need to compile the kernel AX.25, regardless of whether
you actually use it or not. First setup your /etc/ax25/axports,
for example:
9k6 dl0tha-9 9600 255 4 9600 baud port (scc3)
axlink dl0tha-15 38400 255 4 Link to NOS
Now "ifconfig" the scc device:
ifconfig scc3 44.128.1.1 hw ax25 dl0tha-9
You can now axattach a pseudo-TTY:
axattach /dev/ptys0 axlink
and start your NOS and attach /dev/ptys0 there. The problem is that
NOS is reachable only via digipeating through the kernel AX.25
(disastrous on a DAMA controlled channel). To solve this problem,
configure "rxecho" to echo the incoming frames from "9k6" to "axlink"
and outgoing frames from "axlink" to "9k6" and start:
rxecho
Or simply use "kissbridge" coming with z8530drv-utils:
ifconfig scc3 hw ax25 dl0tha-9
kissbridge scc3 /dev/ptys0
3. Adjustment and Display of parameters
=======================================
3.1 Displaying SCC Parameters:
==============================
Once a SCC channel has been attached, the parameter settings and
some statistic information can be shown using the param program:
dl1bke-u:~$ sccstat scc0
Parameters:
speed : 1200 baud
txdelay : 36
persist : 255
slottime : 0
txtail : 8
fulldup : 1
waittime : 12
mintime : 3 sec
maxkeyup : 7 sec
idletime : 3 sec
maxdefer : 120 sec
group : 0x00
txoff : off
softdcd : on
SLIP : off
Status:
HDLC Z8530 Interrupts Buffers
-----------------------------------------------------------------------
Sent : 273 RxOver : 0 RxInts : 125074 Size : 384
Received : 1095 TxUnder: 0 TxInts : 4684 NoSpace : 0
RxErrors : 1591 ExInts : 11776
TxErrors : 0 SpInts : 1503
Tx State : idle
The status info shown is:
Sent - number of frames transmitted
Received - number of frames received
RxErrors - number of receive errors (CRC, ABORT)
TxErrors - number of discarded Tx frames (due to various reasons)
Tx State - status of the Tx interrupt handler: idle/busy/active/tail (2)
RxOver - number of receiver overruns
TxUnder - number of transmitter underruns
RxInts - number of receiver interrupts
TxInts - number of transmitter interrupts
EpInts - number of receiver special condition interrupts
SpInts - number of external/status interrupts
Size - maximum size of an AX.25 frame (*with* AX.25 headers!)
NoSpace - number of times a buffer could not get allocated
An overrun is abnormal. If lots of these occur, the product of
baudrate and number of interfaces is too high for the processing
power of your computer. NoSpace errors are unlikely to be caused by the
driver or the kernel AX.25.
3.2 Setting Parameters
======================
The setting of parameters of the emulated KISS TNC is done in the
same way in the SCC driver. You can change parameters by using
the kissparms program from the ax25-utils package or use the program
"sccparam":
sccparam <device> <paramname> <decimal-|hexadecimal value>
You can change the following parameters:
param : value
------------------------
speed : 1200
txdelay : 36
persist : 255
slottime : 0
txtail : 8
fulldup : 1
waittime : 12
mintime : 3
maxkeyup : 7
idletime : 3
maxdefer : 120
group : 0x00
txoff : off
softdcd : on
SLIP : off
The parameters have the following meaning:
speed:
The baudrate on this channel in bits/sec
Example: sccparam /dev/scc3 speed 9600
txdelay:
The delay (in units of 10 ms) after keying of the
transmitter, until the first byte is sent. This is usually
called "TXDELAY" in a TNC. When 0 is specified, the driver
will just wait until the CTS signal is asserted. This
assumes the presence of a timer or other circuitry in the
MODEM and/or transmitter, that asserts CTS when the
transmitter is ready for data.
A normal value of this parameter is 30-36.
Example: sccparam /dev/scc0 txd 20
persist:
This is the probability that the transmitter will be keyed
when the channel is found to be free. It is a value from 0
to 255, and the probability is (value+1)/256. The value
should be somewhere near 50-60, and should be lowered when
the channel is used more heavily.
Example: sccparam /dev/scc2 persist 20
slottime:
This is the time between samples of the channel. It is
expressed in units of 10 ms. About 200-300 ms (value 20-30)
seems to be a good value.
Example: sccparam /dev/scc0 slot 20
tail:
The time the transmitter will remain keyed after the last
byte of a packet has been transferred to the SCC. This is
necessary because the CRC and a flag still have to leave the
SCC before the transmitter is keyed down. The value depends
on the baudrate selected. A few character times should be
sufficient, e.g. 40ms at 1200 baud. (value 4)
The value of this parameter is in 10 ms units.
Example: sccparam /dev/scc2 4
full:
The full-duplex mode switch. This can be one of the following
values:
0: The interface will operate in CSMA mode (the normal
half-duplex packet radio operation)
1: Fullduplex mode, i.e. the transmitter will be keyed at
any time, without checking the received carrier. It
will be unkeyed when there are no packets to be sent.
2: Like 1, but the transmitter will remain keyed, also
when there are no packets to be sent. Flags will be
sent in that case, until a timeout (parameter 10)
occurs.
Example: sccparam /dev/scc0 fulldup off
wait:
The initial waittime before any transmit attempt, after the
frame has been queue for transmit. This is the length of
the first slot in CSMA mode. In full duplex modes it is
set to 0 for maximum performance.
The value of this parameter is in 10 ms units.
Example: sccparam /dev/scc1 wait 4
maxkey:
The maximal time the transmitter will be keyed to send
packets, in seconds. This can be useful on busy CSMA
channels, to avoid "getting a bad reputation" when you are
generating a lot of traffic. After the specified time has
elapsed, no new frame will be started. Instead, the trans-
mitter will be switched off for a specified time (parameter
min), and then the selected algorithm for keyup will be
started again.
The value 0 as well as "off" will disable this feature,
and allow infinite transmission time.
Example: sccparam /dev/scc0 maxk 20
min:
This is the time the transmitter will be switched off when
the maximum transmission time is exceeded.
Example: sccparam /dev/scc3 min 10
idle
This parameter specifies the maximum idle time in full duplex
2 mode, in seconds. When no frames have been sent for this
time, the transmitter will be keyed down. A value of 0 is
has same result as the fullduplex mode 1. This parameter
can be disabled.
Example: sccparam /dev/scc2 idle off # transmit forever
maxdefer
This is the maximum time (in seconds) to wait for a free channel
to send. When this timer expires the transmitter will be keyed
IMMEDIATELY. If you love to get trouble with other users you
should set this to a very low value ;-)
Example: sccparam /dev/scc0 maxdefer 240 # 2 minutes
txoff:
When this parameter has the value 0, the transmission of packets
is enable. Otherwise it is disabled.
Example: sccparam /dev/scc2 txoff on
group:
It is possible to build special radio equipment to use more than
one frequency on the same band, e.g. using several receivers and
only one transmitter that can be switched between frequencies.
Also, you can connect several radios that are active on the same
band. In these cases, it is not possible, or not a good idea, to
transmit on more than one frequency. The SCC driver provides a
method to lock transmitters on different interfaces, using the
"param <interface> group <x>" command. This will only work when
you are using CSMA mode (parameter full = 0).
The number <x> must be 0 if you want no group restrictions, and
can be computed as follows to create restricted groups:
<x> is the sum of some OCTAL numbers:
200 This transmitter will only be keyed when all other
transmitters in the group are off.
100 This transmitter will only be keyed when the carrier
detect of all other interfaces in the group is off.
0xx A byte that can be used to define different groups.
Interfaces are in the same group, when the logical AND
between their xx values is nonzero.
Examples:
When 2 interfaces use group 201, their transmitters will never be
keyed at the same time.
When 2 interfaces use group 101, the transmitters will only key
when both channels are clear at the same time. When group 301,
the transmitters will not be keyed at the same time.
Don't forget to convert the octal numbers into decimal before
you set the parameter.
Example: (to be written)
softdcd:
use a software dcd instead of the real one... Useful for a very
slow squelch.
Example: sccparam /dev/scc0 soft on
4. Problems
===========
If you have tx-problems with your BayCom USCC card please check
the manufacturer of the 8530. SGS chips have a slightly
different timing. Try Zilog... A solution is to write to register 8
instead to the data port, but this won't work with the ESCC chips.
*SIGH!*
A very common problem is that the PTT locks until the maxkeyup timer
expires, although interrupts and clock source are correct. In most
cases compiling the driver with CONFIG_SCC_DELAY (set with
make config) solves the problems. For more hints read the (pseudo) FAQ
and the documentation coming with z8530drv-utils.
I got reports that the driver has problems on some 386-based systems.
(i.e. Amstrad) Those systems have a bogus AT bus timing which will
lead to delayed answers on interrupts. You can recognize these
problems by looking at the output of Sccstat for the suspected
port. If it shows under- and overruns you own such a system.
Delayed processing of received data: This depends on
- the kernel version
- kernel profiling compiled or not
- a high interrupt load
- a high load of the machine --- running X, Xmorph, XV and Povray,
while compiling the kernel... hmm ... even with 32 MB RAM ... ;-)
Or running a named for the whole .ampr.org domain on an 8 MB
box...
- using information from rxecho or kissbridge.
Kernel panics: please read /linux/README and find out if it
really occurred within the scc driver.
If you cannot solve a problem, send me
- a description of the problem,
- information on your hardware (computer system, scc board, modem)
- your kernel version
- the output of cat /proc/net/z8530
4. Thor RLC100
==============
Mysteriously this board seems not to work with the driver. Anyone
got it up-and-running?
Many thanks to Linus Torvalds and Alan Cox for including the driver
in the Linux standard distribution and their support.
Joerg Reuter ampr-net: dl1bke@db0pra.ampr.org
AX-25 : DL1BKE @ DB0ABH.#BAY.DEU.EU
Internet: jreuter@yaina.de
WWW : http://yaina.de/jreuter