LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity
LDP/LDP/guide/docbook/Linux-Networking/Token-Ring.xml

1220 lines
57 KiB
XML
Raw Blame History

<sect1 id="Token-Ring">
<title>Token-Ring</title>
<para>
The Token Ring architecture is defined in IEEE 802.5. IBM has further defined
the standard to include particular types of devices and cables. Token Ring uses
a logical ring topology and a physical star topology. The hubs for Token Rung
are called multistation access units, or MAUs.
</para>
<para>
The Token Ring standard supports either 4 Mbps or 16 Mbps speeds. Cable can be
STP, UTP, or fiber. One popular wiring scheme uses Category 5 cable. There are
also a varity of cable types defined by IBM (referred to as Type 1 through
Type 9). Distances between nodes can range from 45 meters for UTP to a kilometer
or more for fiber optic cable.
</para>
<para>
Token Ring networks use a token-passing access scheme. A token data frame is
passed from one computer to the net around the ring. Each computer can
transmit data only when it has the token. This access method provides equal
access to the network for all nodes, and handles heavy loads better than
Ethernet's contention-based method.
</para>
<para>
The nodes in a Token Ring network monitor each other for reliablity. The
first computer in the network becomes an Active Monitor, and the others
are Passive Monitors. Each computer monitors its nearest upstream
neighbour. When an error occurs, the computer broadcasts a beacon packet
indicating the error.
</para>
<para>
The NICs in all computers respond to the beacon by running self-tests, and
removing themselves from the network if necessary. Node in the network can
also automatically remove packets sent to a computer that is having a
problem. This makes Token Ring a reliable choice for networking.
</para>
This section is designed to help you get up and running using a Token Ring
adaptor to access the network. Generally speaking Section 3 will tell you
which driver you need based on the adaptor card you have.
-----------------------------------------------------------------------------
2. Hardware requirements
Make sure that you have a Token Ring card that is supported from the list
below. Many PCI,ISA and even the odd MCA cards are now supported. Check
[http://www.linuxtr.net] http://www.linuxtr.net for the latest information.
Cards that are reported to work:
3COM
<EFBFBD><EFBFBD>*<2A>3C389 PCMCIA
<EFBFBD><EFBFBD>*<2A>3C619, 3C619B or 3C619C Token Link
<EFBFBD><EFBFBD>*<2A>3C319 Velocity ISA
<EFBFBD><EFBFBD>*<2A>3C359 Velocity XL - PCI
<EFBFBD><EFBFBD>*<2A>3C339 Velocity PCI
IBM
<EFBFBD><EFBFBD>*<2A>PCI. PCI Token Ring Adapter; PCI Wake on Lan Token Ring Adapter; 16/4
Token Ring PCI Adapter 2, Wake on Lan, and Wake on Lan Special; High
Speed 100/16/4 Token Ring Adapter, Token Ring 16/4 Management Adapter.
<EFBFBD><EFBFBD>*<2A>Cardbus. 16/4 Token Ring Adapter
<EFBFBD><EFBFBD>*<2A>LanStreamer. PCI: Auto LanStreamer, Triple Lanstreamer; MCA: LanStreamer
MC16, Lanstreamer MC32, AutoLanstreamer MC32, Dual Lanstreamer MC32
<EFBFBD><EFBFBD>*<2A>ISA. Auto 16/4 Token Ring Adapter, 16/4 Token Ring Adapter, Turbo 16/4
Token Ring Adapter, Auto Wake Token Ring Adapter.
<EFBFBD><EFBFBD>*<2A>PCMCIA. Turbo 16/4 PC Card, Turbo 16/4 PC Card 2, Auto 16/4 Credit Card
Adapter, 16/4 Credit Card Adapter, 16/4 Credit Card Adapter II
<EFBFBD><EFBFBD>*<2A>Tropic MCA. 16/4 Token Ring Adapter/A, Auto 16/4 Token Ring Adapter
Olicom
<EFBFBD><EFBFBD>*<2A>RapidFire 3139, 3140, 3141, and 3540
<EFBFBD><EFBFBD>*<2A>OC 3136
<EFBFBD><EFBFBD>*<2A>OC 3137
<EFBFBD><EFBFBD>*<2A>OC 3118
<EFBFBD><EFBFBD>*<2A>OC 3129
Madge
<EFBFBD><EFBFBD>*<2A>51-02 Smart 16/4 PCI
<EFBFBD><EFBFBD>*<2A>20-03 16/4 Cardbus Adapter Mk2
<EFBFBD><EFBFBD>*<2A>51-04 Smart 16/4 PCI Ringnode Mk3
<EFBFBD><EFBFBD>*<2A>51-09 Smart 16/4 Fiber PCI Ringnode
<EFBFBD><EFBFBD>*<2A>51-07 Smart 100/16/4 PCI-HS Ringnode
<EFBFBD><EFBFBD>*<2A>51-05 Smart 100/16/4 PCI Ringnode
<EFBFBD><EFBFBD>*<2A>20-01 Smart 16/4 PCMCIA
<EFBFBD><EFBFBD>*<2A>60-07 Presto PCI 2000
<EFBFBD><EFBFBD>*<2A>60-06 Presto PCI Plus
<EFBFBD><EFBFBD>*<2A>60-05 Presto PCI
<EFBFBD><EFBFBD>*<2A>53-05 Smart Mk4 PCI Adapter (low profile)
<EFBFBD><EFBFBD>*<2A>31-40 Rapidfire 3140V2 16/4 PCI Adapter
SysKonnect
<EFBFBD><EFBFBD>*<2A>TR4/16(+) SK-4190 ISA
<EFBFBD><EFBFBD>*<2A>TR4/16(+) SK-4590 PCI
<EFBFBD><EFBFBD>*<2A>TR4/16(+) SK-4591 PCI
SMC
<EFBFBD><EFBFBD>*<2A>Tokencard Elite (8115T)
<EFBFBD><EFBFBD>*<2A>Tokencard Elite/A MCA (8115T/A)
Intel
<EFBFBD><EFBFBD>*<2A>TokenExpress PRO
<EFBFBD><EFBFBD>*<2A>TokenExpress 16/4
Cards that may cause problems:
Token-Ring Network 16/4 Adapter II. This adapter will NOT work. Do not
confuse this card with the IBM Token Ring adapter II (4mbit) which does. It
is a DMA/Busmaster adapter for ISA.
3Com TokenLink Velocity ISA. You may or may not get this one to work. I have
had reports of people running it without problems, and others who get errors
left and right.
-----------------------------------------------------------------------------
3. Which driver should I use?
The realm of Token Ring drivers on Linux has expanded quite a bit in last
couple of years. It's not just ibmtr anymore! So as a result this map will
tell you given a card which driver you should try and the recommended minimum
kernel version (if any).
3COM
<EFBFBD><EFBFBD>*<2A>3C389 PCMCIA -- ibmtr_cs
<EFBFBD><EFBFBD>*<2A>3C619, 3C619B or 3C619C Token Link -- ibmtr
<EFBFBD><EFBFBD>*<2A>3C319 Velocity ISA -- try ibmtr
<EFBFBD><EFBFBD>*<2A>3C359 Velocity XL - PCI -- driver available from [http://www.linuxtr.net]
http://www.linuxtr.net
<EFBFBD><EFBFBD>*<2A>3C339 Velocity PCI -- tms380tr
IBM
<EFBFBD><EFBFBD>*<2A>PCI Token Ring Adaptor -- olympic
<EFBFBD><EFBFBD>*<2A>PCI Wake on Lan Token Ring Adaptor -- olympic
<EFBFBD><EFBFBD>*<2A>16/4 Token Ring PCI Adaptor 2, Wake On Lan, and Wake on Lan Special --
olympic
<EFBFBD><EFBFBD>*<2A>High Speed 100/16/4 Token Ring -- olympic
<EFBFBD><EFBFBD>*<2A>Turbo 16/4 ISA adapter -- ibmtr
<EFBFBD><EFBFBD>*<2A>Token Ring Auto 16/4 ISA adapter -- ibmtr
<EFBFBD><EFBFBD>*<2A>Token Ring Auto 16/4 adapter /A -- ibmtr
<EFBFBD><EFBFBD>*<2A>Token Ring 16/4 adapter /A -- ibmtr
<EFBFBD><EFBFBD>*<2A>Token Ring adapter /A -- ibmtr
<EFBFBD><EFBFBD>*<2A>Token Ring adapter II (4 Megabit only) -- ibmtr
<EFBFBD><EFBFBD>*<2A>16/4 ISA Token Ring card (16bit) -- ibmtr
<EFBFBD><EFBFBD>*<2A>16/4 ISA Token Ring card (8bit) -- ibmtr
<EFBFBD><EFBFBD>*<2A>All LANStreamer -- lanstreamer
<EFBFBD><EFBFBD>*<2A>PCMCIA - Turbo 16/4 -- ibmtr_cs
<EFBFBD><EFBFBD>*<2A>PCMCIA - 16/4 -- ibmtr_cs
<EFBFBD><EFBFBD>*<2A>Cardbus - 16/4 - olympic, kernel v.2.4.3 or greater
Olicom
<EFBFBD><EFBFBD>*<2A>RapidFire 3139, 3140, 3141, and 3540
<EFBFBD><EFBFBD>*<2A>OC 3136
<EFBFBD><EFBFBD>*<2A>OC 3137
<EFBFBD><EFBFBD>*<2A>OC 3118
<EFBFBD><EFBFBD>*<2A>OC 3129
For these Olicom cards, see their website [http://www.olicom.com] http://
www.olicom.com for drivers. You will need a 2.2.x series kernel.
Madge
<EFBFBD><EFBFBD>*<2A>51-02 Smart 16/4 PCI
<EFBFBD><EFBFBD>*<2A>20-03 16/4 Cardbus Adapter Mk2
<EFBFBD><EFBFBD>*<2A>51-04 Smart 16/4 PCI Ringnode Mk3
<EFBFBD><EFBFBD>*<2A>51-09 Smart 16/4 Fiber PCI Ringnode
<EFBFBD><EFBFBD>*<2A>51-07 Smart 100/16/4 PCI-HS Ringnode
<EFBFBD><EFBFBD>*<2A>51-05 Smart 100/16/4 PCI Ringnode
<EFBFBD><EFBFBD>*<2A>20-01 Smart 16/4 PCMCIA
<EFBFBD><EFBFBD>*<2A>60-07 Presto PCI 2000
<EFBFBD><EFBFBD>*<2A>60-06 Presto PCI Plus
<EFBFBD><EFBFBD>*<2A>60-05 Presto PCI
For these Madge cards you'll want to visit their site [http://www.madge.com]
http://www.madge.com for drivers and get the 2.31 Madge drivers. You will
need either a 2.0.36 or 2.2.5 as a minimum.
2.41 drivers:
<EFBFBD><EFBFBD>*<2A>51-05 Smart Mk4 PCI Adapter
<EFBFBD><EFBFBD>*<2A>53-05 Smart Mk4 PCI Adapter (low profile)
<EFBFBD><EFBFBD>*<2A>31-40 Rapidfire 3140V2 16/4 PCI Adapter
<EFBFBD><EFBFBD>*<2A>20-03 Smart 16/4 Cardbus Mk2
<EFBFBD><EFBFBD>*<2A>51-04 Smart 16/4 PCI Ringnode Mk3
<EFBFBD><EFBFBD>*<2A>60-07 Presto PCI 2000
<EFBFBD><EFBFBD>*<2A>60-06 Presto PCI Plus
<EFBFBD><EFBFBD>*<2A>60-05 Presto PCI
According to the Madge README file the 2.41 driver has been tested on
uniprocessor and SMP kernel versions: 2.0.36, 2.2.5-15 ,2.2.10, 2.2.12-20,
2.4.2-2.
Other Madge cards are reportedly based on the Texas Instruments tms380
chipset and thus as of the 2.3.26 kernel you can try the tms380tr driver.
SysKonnect
<EFBFBD><EFBFBD>*<2A>TR4/16(+) SK-4190 ISA
<EFBFBD><EFBFBD>*<2A>TR4/16(+) SK-4590 PCI
<EFBFBD><EFBFBD>*<2A>TR4/16(+) SK-4591 PCI
In the 2.2.x series of kernels try sktr. In the 2.3.x and greater series try
the tms380tr driver.
SMC
<EFBFBD><EFBFBD>*<2A>Tokencard Elite (8115T)
<EFBFBD><EFBFBD>*<2A>Tokencard Elite/A MCA (8115T/A)
Driver is included as part of the 2.3.38+ kernel.
Intel
<EFBFBD><EFBFBD>*<2A>TokenExpress PRO
<EFBFBD><EFBFBD>*<2A>TokenExpress 16/4
Support for these cards is currently under development. Check [http://
www.linuxtr.net] http://www.linuxtr.net for status.
-----------------------------------------------------------------------------
3.1. Drivers/Adapter Specifics
Here we'll describe the different options and configurations available for
each of the available drivers.
-----------------------------------------------------------------------------
3.1.1. Kernel Module Aliases and Parameters
Most drivers accept arguments in the form of module paramters (with the
exception of the special case of PCMCIA, which is fully described below).
Kernel modules are specified in the file /etc/conf.modules or /etc/
modules.conf depending upon which version of modutils you've got.
You can directly modify this file or use the tools builtin to your specific
distribution. These distribution specific tools are beyond the scope of this
document, but you can always directly modify the modules.conf file by hand to
get things up and running and then figure out how your distribution handles
these files. For example, Debian has several files in the /etc/modutils
directory and from these builds the modules.conf file.
Kernel modules aliases are utilized to associate a particular name with a
kernel module.
For token ring, this is used to assign drivers for each of the token ring
interfaces so that the system scripts know which driver to insert when you
bring an interface up.
The format of the alias lines are:
+---------------------------------------------------------------------------+
| alias module_name interface |
| |
+---------------------------------------------------------------------------+
Usually, the only line you'll need for the token ring networking would be
something like:
+---------------------------------------------------------------------------+
|alias olympic tr0 |
+---------------------------------------------------------------------------+
This binds the olympic driver to the tr0 interface so when you type
+---------------------------------------------------------------------------+
|ifconfig tr0 up |
+---------------------------------------------------------------------------+
if the tr0 interface is not already loaded, the system will insert the
olympic driver, which in turn will find the network card and create the tr0
network device.
Kernel modules parameters are specified in the following format:
+---------------------------------------------------------------------------+
| options module_name parameter_1=XXX [parameter2=YYY ...] |
| |
+---------------------------------------------------------------------------+
Where the modules_name is the name of the driver, i.e. olympic, ibmtr, 3c359
and the ` parameters are those available for each driver. See either the
following sections for driver specifics or check out the drivers source code.
For example, if you wanted to set the Olympic driver to 16 mbps operation and
with a default buffer size of 8192 bytes, you would use the following line:
+---------------------------------------------------------------------------+
| options olympic ringspeed=16 pkt_buf_sz=8192 |
| |
+---------------------------------------------------------------------------+
-----------------------------------------------------------------------------
3.1.2. IBMTR Driver
IBM Tropic Chipset Based Token Ring Adapters
This is the original token ring driver in the kernel and supports almost all
adapters that use the IBM Tropic chipset, including the IBM ISA, ISA/Pnp, and
a multitude of adapters from other manufacturers.
The IBM Turbo 16/4 ISA/PnP adapter will, in fact, work fine with the ibmtr
driver. In older drivers you had to run the card in Auto 16/4 compatability
mode. The simplest way to set this is to use the LANAID disks sent with the
card and run the command:
+---------------------------------------------------------------------------+
|LANAIDC /FAST=AUTO16 |
+---------------------------------------------------------------------------+
You should then use LANAIDC or LANAID to configure the card according to
documentation. The latest drivers for the Turbo Adapters will recognize these
adapters and configure them straight out of the box. You may have to either
turn off isapnp support in the kernel or modify your isapnp.conf file to
enable the adapter.
Options:
Perusal of the ibmtr source code may leave you to believe that the adapter
can take three parameters, however, in reality the driver doesn't take any.
These parameters are a hang over from the early stages of the driver and are
only intended to be used to force the driver to only test restricted
<EFBFBD>ddresses when looking for adapters. The information on these options are
included here for completeness only.
<EFBFBD><EFBFBD>*<2A>io: Specify the I/O ports that the driver will check for the presence of
any cards. All Tropic based ISA adapters, or adapters emulating the ISA
cards will be found on either port 0xA20 or 0xA24. If you know that your
adapter is configured for 0xA24 and/or that probing on port 0xA20 will
cause problems with your machine, use io to force the driver to check a
specific port only.
The Turbo adapters (including the confusingly named latest Auto 16/4
cards) can have their io regions located anywhere permitted by the PnP
specification. This location is found using the new turbo detection code
and no parameters are required.
<EFBFBD><EFBFBD>*<2A>irq & mem: The two options were used to tell the driver exactly which irq
to use and where the shared ram for the adapter could be found. These two
options are now totally redundant in the driver as the interrupt line and
the location of the shared ram is obtained directly by interrogating the
adapter.
-----------------------------------------------------------------------------
3.1.3. Olympic Driver
IBM PCI Pit/Pit-Phy/Olympic chipset based token ring cards
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, i.e if you
have two olympic adapters in your machine and want to assign a ring speed of
16mbps to the first adapter, but a ring speed of 4mbps to the second adapter,
your options line would read:
+---------------------------------------------------------------------------+
| options olympic ringspeed=16,4 |
| |
+---------------------------------------------------------------------------+
However, it should be noted that the driver assigns value to each adapter in
the order they are discovered<65> which is usually the order there are present
on the pci bus. A little trial and error may be required to be certain which
adapter is receiving which configuration option.
<EFBFBD><EFBFBD>*<2A>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. The driver does
support 100 mbps full duplex operation. This is automatically detected by
the adapter when connected to an appropriate switch.
<EFBFBD><EFBFBD>*<2A>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.
<EFBFBD><EFBFBD>*<2A>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.
<EFBFBD><EFBFBD>*<2A>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. I have had multiple cards in the
same system, all sharing the same interrupt and working perfectly fine
together. This is also true for the Cardbus Olympic adapters, I have quite
happily had a Cardbus adapter and regular 16 bit PCMCIA token ring adapter
working together in the same laptop.
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.
-----------------------------------------------------------------------------
3.1.4. Lanstreamer Driver
IBM PCI/MCA Lanstreamer chipset based token ring cards
Options:
The driver accepts three options: ringspeed, pkt_buf_sz, message_level and
network_monitor.
These options can be specified differently for each card found, i.e if you
have two olympic adapters in your machine and want to assign a ring speed of
16mbps to the first adapter, but a ring speed of 4mbps to the second adapter,
your options line would read:
+---------------------------------------------------------------------------+
| options lanstreamer ringspeed=16,4 |
| |
+---------------------------------------------------------------------------+
However, it should be noted that the driver assigns value to each adapter in
the order they are discovered<65> which is usually the order there are present
on the pci/mca bus. A little trial and error may be required to be certain
which adapter is receiving which configuration option.
<EFBFBD><EFBFBD>*<2A>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. switch.
<EFBFBD><EFBFBD>*<2A>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.
<EFBFBD><EFBFBD>*<2A>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. The Lanstreamer driver does support a network monitor mode
similar to the olympic driver, however it is a compile time option and not a
module parameter. To enable the network monitor mode, edit lanstreamer.c and
change the line:
+---------------------------------------------------------------------------+
|#define STREAMER_NETWORK_MONITOR 0 |
+---------------------------------------------------------------------------+
to read:
+---------------------------------------------------------------------------+
|#define STREAMER_NETWORK_MONITOR 1 |
+---------------------------------------------------------------------------+
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 streamer_tr. 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.
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.
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.
-----------------------------------------------------------------------------
3.1.5. 3Com 3C359 Driver
3COM PCI TOKEN LINK VELOCITY XL TOKEN RING CARDS
Currently the 3c359 driver in not included in the standard kernel source. To
utlize the driver, you must download the driver from the [http://
www.linuxtr.net] Linux Token Ring Project web site and patch your kernel.
Once you've downloaded the file, you can patch your kernel with the following
commands:
+---------------------------------------------------------------------------+
| cd /usr/src/linux |
| patch -p1 < 3c359-2.4.16.patch |
| |
+---------------------------------------------------------------------------+
or, if the patch file is gzipped:
+---------------------------------------------------------------------------+
| zcat 3c359-2.4.16.patch | patch -p1 |
| |
+---------------------------------------------------------------------------+
Then just run make config|menuconfig|xconfig and select the 3c359 driver from
the token ring drivers section of the kernel configuration and then compile
and install the kernel and/or modules as usual.
Options:
The driver accepts three options: ringspeed, pkt_buf_sz, message_level.
These options can be specified differently for each card found, i.e if you
have two olympic adapters in your machine and want to assign a ring speed of
16mbps to the first adapter, but a ring speed of 4mbps to the second adapter,
your options line would read:
+---------------------------------------------------------------------------+
| options 3c359 ringspeed=16,4 |
| |
+---------------------------------------------------------------------------+
However, it should be noted that the driver assigns value to each adapter in
the order they are discovered<EFBFBD> which is usually the order there are present
on the pci bus. A little trial and error may be required to be certain which
adapter is receiving which configuration option.
<EFBFBD><EFBFBD>*<EFBFBD>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 harardous if this
speed does not match the speed you want the ring to operate at.
<EFBFBD><EFBFBD>*<EFBFBD>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.
<EFBFBD><EFBFBD>*<EFBFBD>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.
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. I have had multiple cards in the
same system, all sharing the same interrupt and working perfectly fine
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.
-----------------------------------------------------------------------------
3.1.6. SysKonnect adapters
Information for the SysKonnect Token Ring ISA/PCI Adapter is courtesy 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
Important information to be noted:
<EFBFBD><EFBFBD>*<2A>1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be
patient.
<EFBFBD><EFBFBD>*<2A>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 staticly 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
Below is 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 |
| ============================================================== |
| |
| +------------------------------------------------------------------+ |
| |+------+ +-----+ +---+ | |
| ||------| W1 +-----+ +----+ | | | |
| ||------| | | | | +---+ |
| ||------| +-----------+ +----+ | | | || |
| ||------| | | +---+ +---+ +---+ |
| ||------| | TMS380C26 | | | | |
| ||------| | | +---+ |-+ |
| |+------+ | | | | |
| | +-----------+ | | |
| | | | |
| | |-+ |
| | | |
| | | |
| | | |
| | | |
| +------------+----------------+--+-----------------------+---------+ |
| +----------------+ +-----------------------+ |
| |
+---------------------------------------------------------------------------------------+
+-------------------------------------------------------------------------------+
| |
| ============================================================== |
| 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 |
| ============================================================== |
| |
| +---+---+---+---+---+---+---+---+ ON |
| | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | |
| +---+---+---+---+---+---+---+---+ 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 |
| |
| |
+-------------------------------------------------------------------------------+
-----------------------------------------------------------------------------
3.1.7. PCMCIA
3.1.7.1. Introduction
PCMCIA Token Ring adapters will work on all versions of the Linux kernel.
Unfortunately, the road to hell is often paved with melting snowballs ;-) and
there are a myriad of different combinations that can be used to get the
adapters to work, all with different options, different requirements and
different issues. Hopefully with this document you will be able to figure out
which combinations of ingredients are required and how to get them up and
running on your machine.
-----------------------------------------------------------------------------
3.1.7.2. History
In the 2.0.x and 2.2.x kernels days, pcmcia was only available as an external
package, created and maintained by David Hinds. When the only stable kernel
available was 2.0.36, life was pretty easy and with a few simple
configuration options the adapters would work.
With the advent of 2.2.x, ibmtr.c was completely updated, which broke the
pcmcia driver (ibmtr_cs.c). The pcmcia driver was updated to work with the
new ibmtr driver and the 2.2.x kernels. This is where the first level of
complication starts. As the pcmcia_cs package is stand alone, it has to
support the various different kernels, so instead of being able to have
different versions of drivers in different versions of the kernel source, the
pcmcia_cs drivers must work with all kernel versions. This not only creates
some ugliness in the driver itself but also causes confusion as to which
version of pcmcia_cs works for the latest kernel.
At this point, everything was working fine, and then come along the 2.3.x
develpment series of kernels. The 2.3.x kernels provided their own support
for pcmcia and the ibmtr_cs driver was included in the kernel proper. So now
there were two ways of getting pcmcia token ring support, either using the
kernel drivers themselves or using the pcmcia_cs package, not too much of a
problem because only developers were using the 2.3.x kernels. Of course this
all changed when the 2.4 kernel was released and a lot more users started
using the kernel.
During late 2000, early 2001, significant development work was done on both
the standard ibmtr driver and the pcmcia driver. Original pcmcia updates
including using high memory and hot-eject support. These initial updates were
only for the 2.2.x kernels, and hence only included in the pcmcia_cs package.
Later development saw great improvements in ibmtr and ibmtr_cs for the 2.4.x
kernels. So as of writing, 1/23/02 , there are many different combinations of
kernel version and driver floating around especially considering that
different distributions have released different versions of the 2.4 kernels.
-----------------------------------------------------------------------------
3.1.7.3. 2.0.x kernels
If you are using one of the 2.0.x kernels, then I salute your perserverance
and really you should have got the pcmcia drivers configured and working by
now ;-)
You will have to use the pcmcia_cs package and play with the /etc/pcmcia/
config.opts, see the section below about config.opts fun. Just about any
version of pcmcia_cs that's been released in the last 2/3 years will work
fine.
-----------------------------------------------------------------------------
3.1.7.4. 2.2.0 - 2.2.6 kernels
These were the series of kernels where the pcmcia driver didn't work at all.
It's probably just easiest to upgrade the kernel to a later version.
If you really do need to get this up and running, then a recent pcmcia_cs is
required and you should be able to grab the ibmtr.c and ibmtr.h from a 2.2.7
- 2.2.16 kernel and use them (note no greater than 2.2.16 !!)
You have to do the config.opts mangling, see the section on setting all this
up.
-----------------------------------------------------------------------------
3.1.7.5. 2.2.7 - 2.2.16 kernels
These kernels are well supported, simply use the pcmcia_cs package and play
with the config.opts file.
-----------------------------------------------------------------------------
3.1.7.6. 2.2.17 - 2.2.19 kernels
The pcmcia driver was updated for these kernel to eliminate the need for the
config.opts mangling. You'll need pcmcia_cs at least 3.1.24, although it is
probably better just to grab the latest version.
Simply compile up pcmcia_cs and you're done. No need to play with
config.opts, in fact if you've been running a previous version that did have
the ibmtr_cs line in config.opts it would be a very good idea to remove or
comment out the line. The new driver allocates the entire 64k for shared ram
and it needs to be aligned on a 64k boundary, if you've got a previous
srambase value not on a 64k boundary, the driver will barf and the kernel
will panic.
-----------------------------------------------------------------------------
3.1.7.7. 2.4.0 - 2.4.4 (non Redhat) kernels
Use the built-in kernel pcmcia driver and play with config.opts.
If you want to use the latest and greatest version of the driver with the
high memory and hot-swap support you can download the patch and patch up your
kernel. Then the line in config.opts can be removed and everything will work
fine.
-----------------------------------------------------------------------------
3.1.7.8. 2.4.4-ac11 > kernels
These kernels include the new drivers so simply compile up the drivers,
ensure that there is no configuration line in config.opts and away you go.
-----------------------------------------------------------------------------
3.1.7.9. 2.4.2 mangled, i.e. Redhat 7.1
When RedHat released 7.1 with the 2.4.2 kernel they modified the kernel (as
they always do) and included the updated ibmtr/ibmtr_cs driver from the
[http://www.linuxtr.net] web site. If you're lucky this may work straight out
of the box (again no need for the ibmtr_cs line in config.opts), if not then
it is probably easiest to upgrade to the latest 2.4.x kernels and use the
drivers there. (The reason being that while I will work out how to get around
a distribution caused problem, I will not provide support for them, I'll
answer questions and give help because I'm a nice guy, but I am not going to
provide driver updates against distributions. Official support is for the
drivers in the kernels available from the official kernel mirrors.
-----------------------------------------------------------------------------
3.1.7.10. 2.4.x kernels and pcmcia_cs
There is no need to use pcmcia_cs with the 2.4 kernels to get the token ring
adapters up and running, but I appreciate that some of you may need to use
pcmcia_cs to get other adapters working that are not supported properly in
the kernel.
The pcmcia_cs package will not work with the latest drivers, it may work with
the 2.4.0-2.4.4 drivers. I am currently in two minds about providing support
with pcmcia_cs for the 2.4 kernels, you can ask me directly or check the
[http://www.linuxtr.net] web site every now and then so see if anything has
changed.
-----------------------------------------------------------------------------
3.1.7.11. Config.opts mangling (or how to send yourself insane)
This is the hardest part to getting the pcmcia adapters working with the
drivers that need the ibmtr_cs line in /etc/pcmcia/config.opts. No set of
values is guaranteed to work the same on a different machine. It really is a
case of trial and error but forewarned and forearmed with a little bit of
knowledge can make the process a whole lot easier.
"Hey, I don't care, just give me something that works"
OK, try this, it works in most situations, if it doesn't you have to read the
rest of the section anyway. Just insert the following line in /etc/pcmcia/
config.opts
+---------------------------------------------------------------------------+
|modules "ibmtr_cs" opts "mmiobase=0xd2000 srambase=0xd4000" |
+---------------------------------------------------------------------------+
restart pcmcia and insert the adapter.
"OK, that didn't work, bring on the pain"
The pcmcia driver need to allocate two areas of memory to operate properly.
All areas of memory allocated must be aligned on the same boundary as the
size of the area being aligned, i.e. a block 8K in size must be on an 8K
boundary (0xc8000, 0xca000, 0xcc000, 0xce000, 0xd0000, 0xd2000) and for a 16K
block must be on a 16K boundary (0xc8000, 0xcc000, 0xd0000, 0xd4000). All
memory areas must be allocated within the ISA address space,
0xC0000-0xDFFFF). Theoretically you should be able to use anywhere within
this area, although experience has shown that most machines hide stuff in the
0xc0000-0xc9fff area. Some machines have even been known to use the
0xd0000-0xd1fff area without telling anybody (some thinkpads !!). So you
really want to stick with memory allocations in the 0xcc000 - 0xdffff range.
Of course, the two memory areas cannot overlap either ;)
The first area of memory is an 8K area for the memory mapped input/output
(MMIO) and must be placed on an 8K boundary. This area of memory is not
usually the cause of any problems and can be placed pretty much anywhere,
recommended values are: 0xcc000, 0xd0000,0xd2000,0xd4000.
The second area of memory can be sized to fit your desires, this is the area
of memory where the incoming and outgoing packets are stored and received.
The driver defaults to a 16K memory size and must be placed on a 16K
boundary. Good areas are: 0xd0000,0xd4000,0xd8000.
Once you've decided which areas of memory you are goin to try, you need to
add the correct line to the /etc/pcmcia/config.opts file. Configuration lines
in this file take the format of:
+-----------------------------------------------------------------------------------------------+
| module "module_name" opts "option1=opt1_value option2=opt2_value ...." |
| |
+-----------------------------------------------------------------------------------------------+
In our case module_name is ibmtr_cs. There are three options that be set with
the ibmtr_cs driver, mmiobase, srambase and sramsize.
If they are not set they will revert to the defaults in the driver, which in
9 cases out of 10 won't work for you. sramsize rarely has to be set unless
you are looking for that last little bit of performance from your adapter.
So, having decided upon your values, let's say 0xd2000 for the MMIO and
0xd4000 for the shared memory you would build a config.opts line like this:
+------------------------------------------------------------------------------------+
| module "ibmtr_cs" opts "mmiobase=0xd2000 srambase=0xd4000" |
| |
+------------------------------------------------------------------------------------+
The pcmcia_cs package must be restarted for these new options to take effect,
usually with:
+---------------------------------------------------------------------------+
|/etc/init.d/pcmcia restart or /etc/rc.d/init.d/pcmcia/restart |
+---------------------------------------------------------------------------+
depending upon which run level organization your distribution adheres to.
Then just plug it in and see if it works. If not you'll just have to go back
and change the values for mmiobase and srambase until you find a combination
that works. Or, you can upgrade to a kernel/pcmcia_cs version that support
high memory allocation, where all this config.opts nonsense is not required
and you can just happily plug your adapter in and watch it run.
-----------------------------------------------------------------------------
3.1.8. Madge Supplied Drivers
Madge released 2.31 of their driver in 1999 and 2.41 in late 2001. Both
drivers can be downloaded from the [http://www.madge.com] Madge web site and
the 2.41 driver is also available from the [http:/www.linuxtr.net] Linux
Token Ring Project web site.
Once the drivers have been downloaded, see the README file that comes with
the drivers for instruction on how to built and install the drivers. The only
other issue some people find with the drivers is a failure to build the tool
chain due to an incorrect version of the newt libraries. If you get a
compiler error relating to newt.h change the madge-source/include/mtok/
config.h file so that the #define NEWNEWT line reads:
+---------------------------------------------------------------------------+
| #define NEWNEWT 1 |
| |
+---------------------------------------------------------------------------+
This will ensure the tools use the correct newt libraries during the build
process.
A patch is available from the Linux Token Ring Project web site for the 2.31
drivers to enable them to work with the 2.4.x kernels.
-----------------------------------------------------------------------------
3.1.9. Olicom Drivers
Back when Olicom were still in business they did produce a Linux driver that
does actually work. Trying to find the driver these days is a bit tough. If
the ftp.olicom.com site is still up and running, the driver can be found
there.
The driver is a combination of GPL source code and proprietary binary low
level code. The driver only works with the 2.0.36 and 2.2.x kernels. It
should be possible to port this driver to the 2.4.x kernels...
-----------------------------------------------------------------------------
4. Known problems
See www.linuxtr.net for the latest greatest set of bugs. Generally speaking
the biggest problem that I've seen (with ibmtr) is that if you pull your
connection from the wall the 2.0.x series of kernels would generally not
recover.
This has been fixed in the latest version of ibmtr and the driver should now
recognize when the link cable has been detached.
There are some laptops that don't want to work with the Olympic Cardbus
adapter, for some reason the driver never sees the open interrupt from the
card. I don't think this is a problem with the driver, but with the Cardbus
subsystem, for some people this problem has simply gone away with a newer
kernel and I personally have never seen it on the laptops I've used in the
development of the driver (Sony Vaio Z505 and Dell Latitude CPx500).
-----------------------------------------------------------------------------
5. VMWare and Token Ring
Thanks to Scott Russell scottrus@raleigh.ibm.com for this little "trick"
One of the bummers about VMWare is if you are on a Token-Ring adapter, your
VMWare system can't have a real TCP/IP address. Turns out this isn't the
case. Here's how to do it.
<EFBFBD><EFBFBD>*<2A>In the info below we'll call your linux box 'linux.mycompany.biz.com'
<EFBFBD><EFBFBD>*<2A>Register another ip address, I'll call it 'vmware.mycompany.biz.com'
<EFBFBD><EFBFBD>*<2A>Make sure FORWARD_IPV4=true in your /etc/sysconfig/network file. If you
have to change it you can dynamically turn on the feature as root
+---------------------------------------------------------------+
| cat 1 > /proc/sys/net/ipv4/ip_forward |
+---------------------------------------------------------------+
<EFBFBD><EFBFBD>*<2A>Alias the second ip to the TR adapter. You end up with something like
this from /sbin/ifconfig:
+---------------------------------------------------------------+
| tr0 linux.mycompany.biz.com |
| tr0:0 vmware.mycompany.biz.com |
| vmnet1 192.168.0.1 |
| |
+---------------------------------------------------------------+
<EFBFBD><EFBFBD>*<2A>Make sure you can ping both ip addresses from another box. If you cannot
then this next step will not work.
<EFBFBD><EFBFBD>*<2A>Use ipchains/iptables to redirect incoming traffic for the tr0:0
interface to your vmnet1 interface. (When I did this I only redirected
specific ports from tr0:0 to vmnet1.)
Now any outside system your 'NT' box appears to be on the TR. In bound
traffic can find it as well as out.
-----------------------------------------------------------------------------
6. Commonly asked Questions
Here are a collection of commonly asked questions that arise from time to
time on the linux-tr mailing list. If your question isn't answered here or
elsewhere in this document, feel free to ask away on the mailing list.
Q: DHCP doesn't work with my Token Ring adapter.
Q: I can't set the LAA on my adapter with ifconfig tr0 hw tr 4000DEADBEEF.
Q: My Linux machine is on a bridged network and I'm having connectivity
issues with machine beyond the bridge.
Q: Can I use a Linux machine to bridge between token ring and ethernet ?
Q: OK, if I can't bridge, how do I connect my Token Ring and ethernet
networks ?
Q: DHCP doesn't work with my Token Ring adapter.
A: Certain dhcp servers and clients do not work properly with token ring
drivers. This is especially true with the 2.4 kernels. During the development
of the 2.3.x series of kernels the internal type for token ring was changed
to accomodate multicast support over token ring. The solution is to upgrade
your dhcp client/server to a version that supports token ring and/or the
latest kernel versions.
Q: I can't set the LAA on my adapter with ifconfig tr0 hw tr 4000DEADBEEF.
A: Firstly, double check that your adapter/driver support setting the LAA,
and that you've supplied a valid LAA. Also, most drivers will only allow this
to be set before the adapter is opened onto the ring. Again, this is related
to the change in the internal type for token ring in the 2.4 kernels. A patch
is available from the [http:/www.linuxtr.net] web site for nettools that
fixes this and allows the LAA to be set.
Q: My Linux machine is on a bridged network and I'm having connectivity
issues with machine beyond the bridge.
A: The token ring source routing code in the kernel uses the spanning tree
algorithm. Contact your network administrator to enable this protocol on the
bridges.
Q: Can I use a Linux machine to bridge between token ring and ethernet ?
A: The simply answer in no. Bridging network topologies in software is
incredibly complicated and while it is possibly, nobody has written the code
to do it. If you must bridge there are several manufacturers that produce
hardware bridges (most notably Cisco).
Q: OK, if I can't bridge, how do I connect my Token Ring and ethernet
networks ?
A: A cheap linux box with a token ring and ethernet adapter makes an
excellent router. There is no difference between setting up a token ring/
ethernet router and an ethernet/ethernet router. You can do masquerading
(NAT) and filtering on the router as per usual. For more details see the
Netfilter howto.
Q: What options do I need to include in the kernel for Token Ring driver
support?
A:
Kernel Compile Options:
Network device support --->
[*] Network device support
....
[*] Token Ring driver support
< > IBM Tropic chipset based adaptor support
Q: Where can I find more information?
If you have any problems with the drivers that are not talked about in this
howto, feel free to email me at <mikep@linuxtrnet>.
You may also wish to join the Linux on Token Ring Listserv by mailing <
majordomo@linuxtr.net> with the body containing:
+---------------------------------------------------------------------------+
|subscribe linux-tr |
+---------------------------------------------------------------------------+
The latest and greatest information, drivers, patches, bug fixes, etc, etc
can always be found at the [http://www.linuxtr.net] Linux Token Project site.
View Git Blame Copy Permalink