mirror of https://github.com/tLDP/LDP
3313 lines
133 KiB
XML
3313 lines
133 KiB
XML
<sect1 id="Protocols-and-Standards">
|
||
|
||
<title>Protocols-and-Standards</title>
|
||
|
||
<para>
|
||
IEEE (Institute of Electrical and Electronics Engineers) 802 Standards
|
||
|
||
802.1 Internetworking
|
||
802.2 Logical Link Control (LLC)
|
||
802.3 CSMA/CD (Ethernet) media access method
|
||
802.4 Token bus media access method
|
||
802.5 Token Ring Media access method
|
||
802.6 Metropolitan Area Netwoks (MANs)
|
||
802.7 Broadband technologies
|
||
802.8 Fiber optic technologies
|
||
802.9 Hybrid (voice and data) networking
|
||
802.10 Network security
|
||
802.11 Wireless Networking
|
||
802.12 High-speed LANs
|
||
</para>
|
||
|
||
>Start 353 Notes
|
||
Protocols
|
||
So it is clear that data units can be transmitted from a sender Data-link Layer to a (peer) receiver Data-Link ayer. The data unit (DU) is encapsulated in a frame. Each frame contains additional information. The meaning of this additional information and the rules that the sender and receiver must follow when processing this information consitutue the protocol. Hence, the frame constitutes a Protocol Data Unit (PDU). To distinguish between PDU's of different layers the PDU may be referred to as a DPDU (D for Data-link).
|
||
|
||
Piggy-backing
|
||
Each PDU may or may not contain data. In the later case, the PDU is being used expressly for the purpose of the protocol, eg. for the receiver to signal that a frame was corrupted.
|
||
|
||
Sometimes a PDU used for the purpose of protocol alone is called a control message. Sending an entire PDU without any data can lead to a waste of resources. It is possible to control information in a PDU which contains data. Thisis called piggy-backing and is a commonly used technique to save resources. The drawback is that sometimes there is no data available or ready to be sent, in which case the control message may be delayed until data becomes available.
|
||
|
||
Utopia protocol
|
||
The Utopia protocol assumes that the logical-link and receiver are ideal, e. the logical-link is error free, provides unlimited capacity and the receiver can receive PDU's at any rate. With these assumptions, each DU is transmitted as soon as it is given, without any other mechanisms or support. Similarly the receiver delivers each DU as sson as it arrives without checking for errors, duplicates or out of order delivery.
|
||
|
||
Out of order delivery is possible, even if the sender sent the frames in order! One possiblity is that an entire frame is lost (never to be received) due to noise. Utopia assumes that this cannot happen.
|
||
|
||
Stop-and-Wait Protocol
|
||
Consider sending frames from a fast machine to a slow machine. What happens if the slow machine is reading the data at half the rate that the fast machine is sending it? Eventually the sent data will be lost, never to be received.
|
||
|
||
For this reason it is important to provide some kind of flow control.
|
||
|
||
The Stop-and-Wait protocol requires the receiver to send an acknowledgement PDU in return for every frame received. Such a PDU is often called an ACK. The sender will wait for the ACK before sending the next frame.
|
||
|
||
Kinds of errors
|
||
Three kinds of errors can occur:
|
||
- the bits in the frame can be inverted, anywhere within the frame including the data bits or the frame's control bits.
|
||
- additional bits can be inserted into the frame, before the frame or after the frame and
|
||
- bits can be deleted from the frame
|
||
Such errors could cause the entire frame to be deleted. Errors don't necessarily happen because of noise. Sometimes an intermediate device devides to "drop" a frame, because eg. it's buffer may be full. These kinds of errors may lead to frames being mistaken as other frames, to ACK's being lost.... even to ACK's magically appearing!
|
||
|
||
Echo checking
|
||
Clearly, error control is required. Error control can be implemented at all layers with the choice of whn, where and how being made by those who develop the layers.
|
||
|
||
At the highest layer, the use must implement menual error control, eg. by inspecting the result of a file transfer to ensure that the contents are as expected, or by seeing that the keys typed on the terminal are echoed properly onto the display. In fact, error checking is a simple form of error control. In this case, the receiver sends back (echoes) a copy of the receive data unit, for the sender to check.
|
||
|
||
Automatic Repeat Request
|
||
Echo checking is not feasible when the computer is transmitting long data unit sequences. Typically the error control involves the receiver checking the frame for possible errors (perhaps implementing some amount of error correcting) and then either:
|
||
|
||
1. sending a positive acknowledgement as a form of receipt or
|
||
2. sending a negative acknowledgement (NACK) to request another copy of the frame be sent.
|
||
|
||
This type of error control is known as automatic repeat request (ARQ). ARQ is used in two ways:
|
||
- idle RQ and
|
||
- continuous RQ.
|
||
In either case, the use of ACK's, NACK's or both is implementation dependent and this can lead to a variety of protocols which differ slightly in their specification/operation. The continuous RQ typically uses one of the following transmission strategies:
|
||
- selective repeat or
|
||
- go-back-N
|
||
|
||
Sequence numbers
|
||
For all the ARQ error control methods, it is necessary to distinguish between different frames. The principle reason is so that duplicate frames can be avoided and to ensure that all frames are eventually received.
|
||
|
||
Furthermore, because the sequence number must be recorded as part of the frame it will occupy some number of bytes. For frames with fixed formats, the maximum size of the sequence number is also fiexed. So eg. the sequence number may be designated as 1 bit, 2 bits, 8 bits, etc....
|
||
|
||
Although a fixed suze sequence number may suggest that only a fixed number of frames can be transmitted, as will be found when examining the protocols, distinguishing each frame from every frame is not necessary and in some caes it is quite possible to have a 1-bit sequence number.
|
||
|
||
Timers
|
||
A timer provides an event after a given time interval. Timers are used to trigger protocol state transitions. Eg. recall the stop-and-wait protocol as previously described. If the ACK is lost then the sender will wait indefinitely. In this case, a timer may be used to trigger the protocol in the extendede absence of an ACK.
|
||
|
||
Idle RQ
|
||
The stop-and-wait protocol given earlier is an incomplete form of idle RQ. The basic RQ uses a timer at the sender and either ACK's only (implicit retransmission) or a combination of ACK's and NACK's (explicit retransmission).
|
||
|
||
When sending a frame, F(n), the sender starts a timer. The sender waits to receive either an ACK(n) or a NACK(n). If nothing is recieved before the timer expires then the timer is reset and F(n) is retransmitted (implicit). If ACK(n) is received then the sender repeats the process F(n+1). If NACK(n) is received before the timer expires then the sender resets the timer and retransmits F(n) (explicit).
|
||
|
||
Using a NACK
|
||
See that the NACK is used when receiving a corrupted frame and signals the sender to stop the timer and send F(n) immediately. Intuitively this decreases the amount of time wasted, and so increases the link utlization.
|
||
|
||
Link utilization
|
||
Clearly, the use of a NACK increases the use of the link. To quantify this requires first examining the basic link utilization of idle RQ.
|
||
|
||
See Page 48.
|
||
|
||
Idle RQ and sequence numbers
|
||
Clearly, the sequence numbers for idle RQ may be 1 bit. For example, the sender transmits frame F(0) and does not transmit frame F(1) until F(0) has been acknowledged. At any one time, there is only a single frame in question. The two sequence numbers are required in case that the ACK(0) is lost - the sender times out and resends F(0), however the receiver is now waiting for F(1) and can reject F(0).
|
||
|
||
In this way, the sender has to buffer only one frame, and the receiver has to record only the sequence number of the frame that was previously received.
|
||
|
||
Because of this, idle RQ does not require much buffer space and is therefore used when simple devices are communicating, such as between a terminal and a display.
|
||
|
||
Continuous RQ
|
||
In previous slide the idle RQ protocol was shown to provide poor link utilization when the time to transmit a frame was significantly less than the propogatio delay.
|
||
|
||
A number of physical layer services provide links with significantly long propogation delays, such as satellite communication and high bandwidth Ethernet.
|
||
|
||
Continuous RQ allows the sender to continue to transmit frames, even though no ACK's may have been received for previously transmitted frames.
|
||
|
||
Sliding windows
|
||
Continuous RQ may require buffering at both the sender and the receiver (as well as seen) and, with finite buffers, it is necessary to ensure that neither the sender's not the receiver's buffer becomes over loaded. A sliding window is a flow control which is used to maintain finite buffers at the sender and receiver.
|
||
|
||
There are numerous methods of implementing a sliding window. However this subject will introduce and use only one method.
|
||
|
||
Parameters for a sliding window
|
||
Each sliding window uses three parameters:
|
||
1. the size of the window K,
|
||
2. the lower window edge LWE and
|
||
3. the upper window edge UWE.
|
||
Normally, K remains as a constant while LWE and UWE vary as frames are transmitted and acknowledged. Both the sender and receiver have their own set of parameters and their own interpretations.
|
||
|
||
Sequence numbers and window size
|
||
The size of the sequence number and the window size are related and the relationship depends on the protocol.
|
||
|
||
Consider the idle RQ from previous slides. Idle RQ uses 1-bit sequence number which gives two different frame identifiers {0,1}. However the window size is K=1 at both the sender and receiver. The reason for this will be explained during go-back-N protocol (idle RQ is a simplified go-back-N). For now, examine the next slide to see how sequence numbers and sliding windows relate.
|
||
|
||
Go-back-N protocol
|
||
With an understanding of sequence numbers and sliding window it is possible to quickly understand the Go-back-N protocol.
|
||
|
||
The sender uses a window size of K. The receiver uses a window size of 1.
|
||
|
||
The receiver sends an ACK for each frame as it is received. If a corrupted frame as it is received. If a corrupted frame, F(n), is received or F(n) is missing (didn't arrive) then the receiver sends a special NACK(n) to request that the sender start restransmitting from frame F(n).
|
||
|
||
Selective repeat protocol
|
||
Selective repeat uses a window size of K at both the sender and receiver.
|
||
|
||
The protocol can be implemented in one of two ways: either the receiver sends only ACK's and the sender implicitly retransmits NACK's to explicity request a frame retransmission.
|
||
|
||
The seder buffers out-of-order frames until the missing frames are retransmitted.
|
||
|
||
As the name suggests, the receiver can "selectively" request retransmission of a frame.
|
||
|
||
When using ACK's only, the absence of an ACK triggers a retransmission.
|
||
|
||
When using ACK's only, if an ACK is lost, then a retransmission is triggered, but the retransmission frame is discarded. If NACK's are used, then the NACK explicity triggers a retransmission.
|
||
|
||
Explicit and implicit strategies
|
||
Explicit retransmission strategy uses NACK's. Implicit retransmission strategy does not use NACK's.
|
||
|
||
For explicit retransmission strategy an ACK(n) is sufficient to acknowledge all frames prior to and including F(n).
|
||
|
||
For implicit retransmission strategy an ACK(n) does not acknowledge all frames prior to F(n). The reason for this is that the strategy relies on the receiver detecting a missing ACK as the trigger for a retransmission.
|
||
|
||
Sequence numbers and K for selective repeat
|
||
|
||
Duplex protocols and lnks
|
||
So far we have discussed the operation of protocols that have data being transmitted from a sender to a receiver, called simplex protocols. In most cases these protocols required that some PDU's be sent back to the receiver.
|
||
|
||
Many links allow for data to be sent in both directions simultaneously. Indeed, a single medium may be divided logically into a send and receive channel using FSM. Such links are called duplex links and the protocols that allow data to flow in both directions simultaneously are duplex protocols.
|
||
|
||
In contrast, recall the primitive stop-and-wait protocol. At any other time, the link was being used to either send a frame or to receive ackowledgement. In this case it is sufficient for the link to be half-duplex. Duplex protocols can operate over a half-duplex link but with less efficiency.
|
||
|
||
The concepts are studied further when considering the medium access control sub-layer.
|
||
|
||
Protocol efficiency
|
||
The concept of link utilization does not consider the amount of data actually sent is less than the length of the frame. The protocol efficiency refers to the fraction of total data transmitted that represents the DU's themselves. This value is always less than 1 because each frame contains additional protocol information such as CRC and sequence number.
|
||
|
||
The link efficiency is further reduced to obtain the protocol efficiency. If the length of the DU is D and the length of the frame is L, then only D/L of the utilized link is actually used to transmit DU's.
|
||
|
||
Medium Access Control
|
||
|
||
The protocols given in the previous lectures assumed that the sender had a direct link to the receiver , and also that the link provided duplex communication, ie. so that frames could be sent at the same time that ACK's were being received. Recall that the repeater is a simple Layer 1 device that, any number of repeaters may exist between two data-link layer peers, transparently to the communication.
|
||
|
||
Also recall that the hub is a general repeater.
|
||
|
||
Frames from any of the data-link layers will be transmitted to every other data-link layer.
|
||
|
||
The use of a hub introduces new problems for the protocols because a transmitted frame will potentialy be received by a number of different data-link layers.
|
||
|
||
So each device needs an address. The address is called the medium access control (MAC) address - it is a unique identifier for every device connected to the shared medium.
|
||
|
||
|
||
The MAC sub-layer
|
||
|
||
To handle issues of MAC addressing, and other issues to do with avoiding collision of frames transmitted by two or more Layer 2 devices, the Layer 2 is broken into a MAC sub-layer and a Logical Link Contrl (LLC) sub-layer.
|
||
|
||
The protocols discussed so far are those implmented by the LLC sub-layer. The MAC sub-layer abstracts the complexity of medium access from the LLC sub-layer.
|
||
|
||
Channels
|
||
Recall that the Physical Layer is responsible for transmitting a bit stream on the transmission medium. The Physical Layer may share several bit streams over the one transmission medium using either TDM or FDM. In this way the transmission medium has been divided into a number of channels. For a prticular (shared) tranmission medium, each MAC sub-layer has access to the same set of channels. The problem for the MAC sub-layer is to decide how a particular channel will be shared.
|
||
|
||
MAC sub-layer protocols
|
||
|
||
What protocol can the MAC sub-layers implement to ensure that channels are used efficiently? (read Section 4.1 and 4.2 of your textbook)
|
||
|
||
You will see that the protocol of choice is one which takes into consideration the types of channels and also factors such as the propogation delay, frame length, error rate and the frame rate or load.
|
||
|
||
Classifying MAC protocols
|
||
|
||
There are two kinds of MAC protocols:
|
||
|
||
contention protocols: these protocols allow the possiblity of frames colliding.
|
||
|
||
contention-less protocols: these protocols don't allow the possibliity of frames colliding.
|
||
|
||
The choice of a contention or contention-less protocol is mainly made on the basis of the transmission medium. In other words different MAC sub-layer protocols have been developed according to the type of Physical Layer.
|
||
|
||
Logical Token Bus
|
||
|
||
Logical Token Bus is a contention-less protocol. With this protocol the MAC sub-layers pass around a token and only the MAC sub-layer with the token can use the channel. When a particular MAC sub-layer has finished sending a frame, it sends the token to the next MAC sub-layer, and so on. If a MAC sub-layer has no frame to transmit then it simply passes the token to the next MAC sub-layer. Clearly the protocol can be applied for both half duplex and full duplex channels.
|
||
|
||
CSMA
|
||
|
||
To overcome the low efficiency of the Logical Token Bus protocol the Carrier Sense Multiple Access (CSMA) protocol can be used. In this case devices are allowed to transmit a frame at any time (multiple access). However, each device will not transmit a frame if they are receiving a frame (carrier sense).
|
||
|
||
For the case of persistent CSMA, if a device detects that a frame is being recieved it will send its own frame immediately after the frame has been received. The the case of non-persistent CSMA the device will wait for some random period before transmitting .
|
||
|
||
Collisions can occur so this protocol is a contention protocol. If collision detection (CD) is used then colliding frames can be aborted.
|
||
|
||
ALOHA
|
||
|
||
ALOHA is a contention protocol and is used when carrier sense is not available. Mainly this i for satellite communication. The protocol allows devices to transmit at any time. Read your textbook to see the analysis of ALOHA for the case when slotted and unslotted ALOHA is used.
|
||
|
||
>End 353 Notes
|
||
|
||
3.8. Amateur Radio
|
||
|
||
The Linux kernel has built-in support for amateur radio protocols.
|
||
|
||
Especially interesting is the AX.25 support. The AX.25 protocol offers
|
||
both connected and connectionless modes of operation, and is used
|
||
either by itself for point-point links, or to carry other protocols
|
||
such as TCP/IP and NetRom.
|
||
|
||
It is similar to X.25 level 2 in structure, with some extensions to
|
||
make it more useful in the amateur radio environment.
|
||
|
||
<20> Amateur radio on Linux web site <http://radio.linux.org.au/>
|
||
|
||
NDIS and ODI
|
||
|
||
The Network Device Interface Specification (NDIS) is a standard developed
|
||
by Microsoft and IBM to enable communication between protocols and network
|
||
card drivers. The purpose of NDIS is to abstract the functions of the
|
||
network driver so that protocols can work with any driver. NDIS works
|
||
within the data link layer of the OSI model.
|
||
|
||
NDIS allows software components to be written in a modular fashion, and
|
||
components that conform to a version of the NDIS specification are
|
||
guaranteed to communicate with eachother. The current version of NDIS
|
||
is 4.0.
|
||
|
||
The process of assigning a protocol to a network card is called binding.
|
||
NDIS allows multiple protocols to be bound to a single network card,
|
||
and multiple network cards to be bound to a single protocol (or multiple
|
||
protocols).
|
||
|
||
ODI (Open Datalink Interface), devloped by Novell and Apple, is an
|
||
implementation of the same functionality. While designed primarily for
|
||
the IPX protocol, ODI can be used with any protocol. Netware clients and
|
||
servers can have network cards bound to multiple protocols. Microsoft's
|
||
implementation of the IPX protocol, NWLink, also supports the ODI standard.
|
||
|
||
</sect1>
|
||
|
||
<sect1 id="Appletalk">
|
||
|
||
<title>Appletalk</title>
|
||
|
||
<para>
|
||
Appletalk is the network architecture/internetworking stack developed
|
||
by Apple to work with Macintosh computers. It allows a peer-to-peer
|
||
network model which provides basic functionality such as file and printer
|
||
sharing. Each machine can simultaneously act as a client and a server,
|
||
and the software and hardware necessary are included with every Apple
|
||
computer. Appletalk actually supports three network transports:
|
||
Ethernet, Token Ring, and a dedicated system called Localtalk.
|
||
</para>
|
||
|
||
<para>
|
||
LocalTalk is traditionally wired in a star or hybrid topology using custom
|
||
connectors and STP cable. A popular third-party system allows ordinary phone
|
||
cable to be used instead of STP. LocalTalk supports up to 32 node per network.
|
||
The implementations of Ethernet and Token Ring (EtherTalk and TokenTalk)
|
||
support for more sophisticated networks. Localtalk uses CSMA/CA access method.
|
||
Rather than detect collisions as with Ethernet, this method requires nodes to
|
||
wait a certain amount of time after detecting an existing signal on the network
|
||
before attempting to transmit, avoiding most collisions.
|
||
</para>
|
||
|
||
<para>
|
||
Linux provides full Appletalk networking. Netatalk is a kernel-level
|
||
implementation of the AppleTalk Protocol Suite, originally for BSD-
|
||
derived systems. It includes support for routing AppleTalk, serving
|
||
Unix and AFS filesystems over AFP (AppleShare), serving Unix printers
|
||
and accessing AppleTalk printers over PAP. Linux systems just show up
|
||
as another Macintosh on the network.
|
||
</para>
|
||
|
||
<para>
|
||
To enable the Appletalk ( AF_APPLETALK ) protocol in the kernel
|
||
please add the following options to your kernel configuration.
|
||
The Appletalk support has no special device names as it uses
|
||
existing network devices.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
Networking options --->
|
||
<*> Appletalk DDP
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Appletalk support allows your Linux machine to interwork with Apple
|
||
networks. An important use for this is to share resources such as
|
||
printers and disks between both your Linux and Apple computers.
|
||
Additional software is required, this is called netatalk. Wesley Craig
|
||
netatalk@umich.edu represents a team called the `Research Systems Unix
|
||
Group' at the University of Michigan and they have produced the
|
||
netatalk package which provides software that implements the Appletalk
|
||
protocol stack and some useful utilities. The netatalk package will
|
||
either have been supplied with your Linux distribution, or you will
|
||
have to ftp it from its home site at the University of Michigan
|
||
</para>
|
||
|
||
<para>
|
||
To build and install the package do something like:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
user% tar xvfz .../netatalk-1.4b2.tar.Z
|
||
user% make
|
||
root# make install
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
You may want to edit the `Makefile' before calling make to actually
|
||
compile the software. Specifically, you might want to change the
|
||
DESTDIR variable which defines where the files will be installed
|
||
later. The default of /usr/local/atalk is fairly safe.
|
||
</para>
|
||
|
||
8.2.1. Configuring the Appletalk software.
|
||
|
||
<para>
|
||
The first thing you need to do to make it all work is to ensure that
|
||
the appropriate entries in the /etc/services file are present. The
|
||
entries you need are:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
rtmp 1/ddp # Routing Table Maintenance Protocol
|
||
nbp 2/ddp # Name Binding Protocol
|
||
echo 4/ddp # AppleTalk Echo Protocol
|
||
zip 6/ddp # Zone Information Protocol
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The next step is to create the Appletalk configuration files in the
|
||
/usr/local/atalk/etc directory (or wherever you installed the
|
||
package).
|
||
</para>
|
||
|
||
<para>
|
||
The first file to create is the /usr/local/atalk/etc/atalkd.conf file.
|
||
Initially this file needs only one line that gives the name of the
|
||
network device that supports the network that your Apple machines are
|
||
on:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
eth0
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The Appletalk daemon program will add extra details after it is run.
|
||
</para>
|
||
|
||
8.2.2. Exporting a Linux filesystems via Appletalk.
|
||
|
||
<para>
|
||
You can export filesystems from your linux machine to the network so
|
||
that Apple machine on the network can share them.
|
||
</para>
|
||
|
||
<para>
|
||
To do this you must configure the
|
||
/usr/local/atalk/etc/AppleVolumes.system file. There is another
|
||
configuration file called /usr/local/atalk/etc/AppleVolumes.default
|
||
which has exactly the same format and describes which filesystems
|
||
users connecting with guest privileges will receive.
|
||
</para>
|
||
|
||
<para>
|
||
Full details on how to configure these files and what the various
|
||
options are can be found in the afpd man page.
|
||
</para>
|
||
|
||
<para>
|
||
A simple example might look like:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
/tmp Scratch
|
||
/home/ftp/pub "Public Area"
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Which would export your /tmp filesystem as AppleShare Volume `Scratch'
|
||
and your ftp public directory as AppleShare Volume `Public Area'. The
|
||
volume names are not mandatory, the daemon will choose some for you,
|
||
but it won't hurt to specify them anyway.
|
||
</para>
|
||
|
||
8.2.3. Sharing your Linux printer across Appletalk.
|
||
|
||
<para>
|
||
You can share your linux printer with your Apple machines quite
|
||
simply. You need to run the papd program which is the Appletalk
|
||
Printer Access Protocol Daemon. When you run this program it will
|
||
accept requests from your Apple machines and spool the print job to
|
||
your local line printer daemon for printing.
|
||
</para>
|
||
|
||
<para>
|
||
You need to edit the /usr/local/atalk/etc/papd.conf file to configure
|
||
the daemon. The syntax of this file is the same as that of your usual
|
||
/etc/printcap file. The name you give to the definition is registered
|
||
with the Appletalk naming protocol, NBP.
|
||
</para>
|
||
|
||
<para>
|
||
A sample configuration might look like:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
TricWriter:\
|
||
:pr=lp:op=cg:
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Which would make a printer named `TricWriter' available to your
|
||
Appletalk network and all accepted jobs would be printed to the linux
|
||
printer `lp' (as defined in the /etc/printcap file) using lpd. The
|
||
entry `op=cg' says that the linux user `cg' is the operator of the
|
||
printer.
|
||
</para>
|
||
|
||
8.2.4. Starting the appletalk software.
|
||
|
||
<para>
|
||
Ok, you should now be ready to test this basic configuration. There is
|
||
an rc.atalk file supplied with the netatalk package that should work
|
||
ok for you, so all you should have to do is:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# /usr/local/atalk/etc/rc.atalk
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
and all should startup and run ok. You should see no error messages
|
||
and the software will send messages to the console indicating each
|
||
stage as it starts.
|
||
</para>
|
||
|
||
8.2.5. Testing the appletalk software.
|
||
|
||
<para>
|
||
To test that the software is functioning properly, go to one of your
|
||
Apple machines, pull down the Apple menu, select the Chooser, click on
|
||
AppleShare, and your Linux box should appear.
|
||
</para>
|
||
|
||
8.2.6. Caveats of the appletalk software.
|
||
|
||
<EFBFBD> You may need to start the Appletalk support before you configure
|
||
your IP network. If you have problems starting the Appletalk
|
||
programs, or if after you start them you have trouble with your IP
|
||
network, then try starting the Appletalk software before you run
|
||
your /etc/rc.d/rc.inet1 file.
|
||
|
||
<EFBFBD> The afpd (Apple Filing Protocol Daemon) severely messes up your
|
||
hard disk. Below the mount points it creates a couple of
|
||
directories called ``.AppleDesktop'' and Network Trash Folder.
|
||
Then, for each directory you access it will create a .AppleDouble
|
||
below it so it can store resource forks, etc. So think twice before
|
||
exporting /, you will have a great time cleaning up afterwards.
|
||
|
||
<EFBFBD> The afpd program expects clear text passwords from the Macs.
|
||
Security could be a problem, so be very careful when you run this
|
||
daemon on a machine connected to the Internet, you have yourself to
|
||
blame if somebody nasty does something bad.
|
||
|
||
<EFBFBD> The existing diagnostic tools such as netstat and ifconfig don't
|
||
support Appletalk. The raw information is available in the
|
||
/proc/net/ directory if you need it.
|
||
|
||
8.2.7. More information
|
||
|
||
<para>
|
||
For a much more detailed description of how to configure Appletalk for
|
||
Linux refer to Anders Brownworth Linux Netatalk-HOWTO page at
|
||
thehamptons.com.
|
||
</para>
|
||
|
||
<para>
|
||
Netatalk faq and HOWTO:
|
||
</para>
|
||
|
||
<para>
|
||
<EFBFBD> http://thehamptons.com/anders/netatalk/
|
||
<EFBFBD> http://www.umich.edu/~rsug/netatalk/
|
||
<EFBFBD> http://www.umich.edu/~rsug/netatalk/faq.html
|
||
</para>
|
||
|
||
</sect1 id="Appletalk">
|
||
|
||
<sect1 id="ARCnet">
|
||
|
||
<title>ARCnet</title>
|
||
|
||
<para>
|
||
ARCnet, developed in 1977, by Datapoint Corporation, is an older standard
|
||
that has largely been replaced by Ethernet in current networks. ARCnet,
|
||
uses RG-62 coaxial cable in a star, bus, or hybrid physical topology. This
|
||
networking scheme supports active and passive hubs, which must be connected
|
||
to an active hub. ARCnet requries 93-ohm terminators at the end of bus
|
||
cables, and on unused ports of passive hubs. It supports UTP, coaxial, or
|
||
fiber-optic cable. The distance between nodes is 400 feet with UTP cable,
|
||
and higher for coaxial or fiber-optic cable.
|
||
</para>
|
||
|
||
<para>
|
||
ARCnet uses a token-passing scheme similar to that of token ring. ARCnet
|
||
networks support a bandwidth of 2.5 Mbps. Newer standards (ARCnet Plus and
|
||
TCNS) support speeds of 20 Mbps and 100 Mbps, but have not really caught on.
|
||
</para>
|
||
|
||
<para>
|
||
ARCNet device names are `arc0e', `arc1e', `arc2e' etc. or `arc0s',
|
||
`arc1s', `arc2s' etc. The first card detected by the kernel is
|
||
assigned `arc0e' or `arc0s' and the rest are assigned sequentially in
|
||
the order they are detected. The letter at the end signifies whether
|
||
you've selected ethernet encapsulation packet format or RFC1051 packet
|
||
format.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
|
||
Network device support --->
|
||
[*] Network device support
|
||
<*> ARCnet support
|
||
[ ] Enable arc0e (ARCnet "Ether-Encap" packet format)
|
||
[ ] Enable arc0s (ARCnet RFC1051 packet format)
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Once you have your kernel properly built to support your ethernet card
|
||
then configuration of the card is easy.
|
||
</para>
|
||
|
||
<para>
|
||
Typically you would use something like:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# ifconfig arc0e 192.168.0.1 netmask 255.255.255.0 up
|
||
root# route add -net 192.168.0.0 netmask 255.255.255.0 arc0e
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Please refer to the /usr/src/linux/Documentation/networking/arcnet.txt
|
||
and /usr/src/linux/Documentation/networking/arcnet-hardware.txt files
|
||
for further information.
|
||
</para>
|
||
|
||
<para>
|
||
ARCNet support on Linux was developed by Avery Pennarun, apenwarr@foxnet.net.
|
||
</para>
|
||
|
||
</sect1 id="ARCnet">
|
||
|
||
<sect1 id="ATM">
|
||
|
||
<title>ATM</title>
|
||
|
||
<para>
|
||
ATM (Asynchronous Transfer Mode), is a high speed packet switching format
|
||
that supports up to 622 Mbps. ATM can be used with T1 and T3 lines, FDDI,
|
||
and SONET OC1 and OC3 lines. ATM uses a technology called cell switching.
|
||
Data is sent in 53-byte packets called cells. Because packets are small and
|
||
uniform in size, they can be quickly routed by hardware switches. ATM uses
|
||
a virtual circuit between connection points for high reliability over
|
||
high-speed links.
|
||
</para>
|
||
|
||
<para>
|
||
ATM support for Linux is currently in pre-alpha stage. There is an
|
||
experimental release, which supports raw ATM connections (PVCs and
|
||
SVCs), IP over ATM, LAN emulation....
|
||
</para>
|
||
|
||
<para>
|
||
The Linux ATM-Linux home page is at, <http://lrcwww.epfl.ch/linux-atm/>
|
||
</para>
|
||
|
||
<para>
|
||
Werner Almesberger <werner.almesberger@lrc.di.epfl.ch> is managing a
|
||
project to provide Asynchronous Transfer Mode support for Linux.
|
||
Current information on the status of the project may be obtained from,
|
||
http://lrcwww.epfl.ch
|
||
</para>
|
||
|
||
</sect1 id="ATM">
|
||
|
||
<sect1 id="DDS-Switched56">
|
||
|
||
<title>DDS-Switched56</title>
|
||
|
||
<para>
|
||
DDS (Digital Data Service) and Switched 56 are types types of dedicated
|
||
digital line provided by phone carriers. DDS lines are more
|
||
expensive than dedicated analog lines, but support a more consistent quality.
|
||
DDS lines support a speed of 56 Kbps. A device called a CSU/DSU (Channel
|
||
Service Unit/Digital Service Unit) is used to connect the network to the
|
||
dedicated line.
|
||
</para>
|
||
|
||
<para>
|
||
Switched 56 is an alternative to DDS that provides the same type of
|
||
connection, but in a circuit-switched format. The line is available
|
||
on demand rather than continuously, and you are billed for the hours that
|
||
you use it. ISDN has largely replaced Switched 56 for this purpose.
|
||
</para>
|
||
|
||
</sect1 id="DDS-Switched56">
|
||
|
||
<sect1 id="DECnet">
|
||
|
||
<title>DECnet</title>
|
||
|
||
<para>
|
||
Support for DECnet is currently being worked on. You should expect it
|
||
to appear in a late 2.1.* kernel.
|
||
</para>
|
||
|
||
</sect1 id="DECnet">
|
||
|
||
<sect1 id="DLC">
|
||
|
||
<title>DLC</title>
|
||
|
||
<para>
|
||
DLC (Data Link Control) is a transport protocol developed by IBM for SNA
|
||
(System Network Architecture), a protocol suite for network communication
|
||
with mainframe computers. Particular versions of DLC are called SDLC
|
||
(Synchronous Data Link Control) and HDLC (High-level Data Link Control).
|
||
Along with its main uses in mainframe communication, DLC is the protocol
|
||
used by many network-aware printers such Hewlett-Packard's JetDirect
|
||
interface.
|
||
</para>
|
||
|
||
</sect1="DLC">
|
||
|
||
<sect1 id="EQL">
|
||
|
||
<title>EQL</title>
|
||
|
||
<para>
|
||
EQL provides a means of utilizing multiple point to point lines such
|
||
as PPP, SLIP or PLIP as a single logical link to carry TCP/IP. Often,
|
||
it is cheaper to use multiple lower speed lines than to have one high
|
||
speed line installed. In short, EQL is multiple line traffic equaliser.
|
||
</para>
|
||
|
||
<para>
|
||
EQL is integrated into the Linux kernel. The EQL device name is `eql'.
|
||
With the standard kernel source you may have only one EQL device per
|
||
machine.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
|
||
Network device support --->
|
||
[*] Network device support
|
||
<*> EQL (serial line load balancing) support
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
To support this mechanism the machine at the other end of the lines
|
||
must also support EQL. Linux, Livingstone Portmasters and newer dial-
|
||
in servers support compatible facilities.
|
||
</para>
|
||
|
||
<para>
|
||
To configure EQL you will need the EQL tools which are available from:
|
||
metalab.unc.edu.
|
||
</para>
|
||
|
||
<para>
|
||
Configuration is fairly straightforward. You start by configuring the
|
||
eql interface. The eql interface is just like any other network
|
||
device. You configure the IP address and mtu using the ifconfig
|
||
utility, so something like:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# ifconfig eql 192.168.10.1 mtu 1006
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Next you need to manually initiate each of the lines you will use.
|
||
These may be any combination of point to point network devices. How
|
||
you initiate the connections will depend on what sort of link they
|
||
are, refer to the appropriate sections for further information.
|
||
</para>
|
||
|
||
<para>
|
||
Lastly you need to associate the serial link with the EQL device, this
|
||
is called `enslaving' and is done with the eql_enslave command as
|
||
shown:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# eql_enslave eql sl0 28800
|
||
root# eql_enslave eql ppp0 14400
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The `estimated speed' parameter you supply eql_enslave doesn't do
|
||
anything directly. It is used by the EQL driver to determine what
|
||
share of the datagrams that device should receive, so you can fine
|
||
tune the balancing of the lines by playing with this value.
|
||
</para>
|
||
|
||
<para>
|
||
To disassociate a line from an EQL device you use the eql_emancipate
|
||
command as shown:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# eql_emancipate eql sl0
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
You add routing as you would for any other point to point link, except
|
||
your routes should refer to the eql device rather than the actual
|
||
serial devices themselves, typically you would use:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# route add default eql
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The EQL driver was developed by Simon Janes, simon@ncm.com.
|
||
</para>
|
||
|
||
</sect1 id="EQL">
|
||
|
||
<sect1 id="Ethernet">
|
||
|
||
<title>Ethernet</title>
|
||
|
||
Ethernet
|
||
|
||
Ethernet is the most common network architecture worldwide. It was developed by Xerox,
|
||
Intel and DEC in the late 1960s and revised as Ethernet 2.0 in 1982. Ethernet networks
|
||
the CSMA/CD (carrier sense multiple access with collision detection) media access method,
|
||
defined in IEEE 802.3.
|
||
|
||
There are three Ethernet standards for different media:
|
||
|
||
See P41 of Oreilly "MSCE Networking"
|
||
|
||
10BaseT
|
||
10Base2
|
||
10Base5
|
||
|
||
Fast Ethernet
|
||
|
||
Fast Ethernet, also known as 100BaseT, is a new standard for 100 Mbps Ethernet. Fast Ethernet
|
||
can use two-pair Category 5 cable of four-pair Category 3-5 cable.
|
||
|
||
100BaseT uses a physical star topology identical to that used by 10BaseT, but requires that
|
||
all equipment (hubs, NICs, and repeaters) support 100 Mbps speeds. Some NICs and hubs can support
|
||
both standards, but all devices on the network need to be configured to use the same standard.
|
||
|
||
Several manufacturers devleloped 100 Mbps Ethernet devices before 100BaseT became a standard. The
|
||
most popular of these, 100VG-AnyLan, is still widely used. This standard uses a demand priority
|
||
access method rather than CSMA/CD, and also supports networks that combine Ethernet and Token
|
||
Ring packets.
|
||
|
||
|
||
> Start Binh
|
||
GigE
|
||
|
||
GigE Ethernet, also known as 1000BaseT or Gigabit Ethernet. GigE can only use Cat 5 cable.
|
||
|
||
GigE uses the same topology as that of Fast Ethernet (ie. physical star topology). Like Fast Ethernet
|
||
though it requires that hubs/switches on the LAN to be GigE capable. If not it will revert back to
|
||
100BaseT, and if this is not available to 10BaseT Ethernet.
|
||
> End Binh
|
||
|
||
* Ethernet-Howto
|
||
|
||
</sect1 id="Ethernet">
|
||
|
||
<sect1 id="FDDI">
|
||
|
||
<title>FDDI</title>
|
||
|
||
<para>
|
||
FDDI (Fiber Distributed Data Interface) is a high-speed, reliable, long-distance
|
||
networking scheme often used for network backbones and networks that require
|
||
high bandwidth. FDDI uses fiber optic cable wired in a true ring. It supports
|
||
speeds up to 100 Mbps and a maximum distance bewteen nodes of 100 kilometers
|
||
(62 miles).
|
||
</para>
|
||
|
||
<para>
|
||
FDDI uses token-passing scheme wired into two rings, primary and secondary. The
|
||
primary ring is used for normal networking. When a failure is detected, the
|
||
secondary ring is used in the opposite direction to compensate for the failure
|
||
in the primary ring.
|
||
</para>
|
||
|
||
<para>
|
||
The advantages of FDDI are their high speed, long distance, and reliablity.
|
||
The token-passing scheme used by FDDI is also more sophisticated than that
|
||
of Token Ring: it allows multiple packets to be on the ring at once, and
|
||
allows certain nodes to be given higher priority than the rest. The
|
||
disadvantage of FDDI is its high cost and the difficult in installing and
|
||
maintaing fiber optic cable.
|
||
</para>
|
||
|
||
<para>
|
||
FDDI device names are `fddi0', `fddi1', `fddi2' etc. The first card
|
||
detected by the kernel is assigned `fddi0' and the rest are assigned
|
||
sequentially in the order they are detected.
|
||
</para>
|
||
|
||
<para>
|
||
Larry Stefani, lstefani@ultranet.com, has developed a driver for the
|
||
Digital Equipment Corporation FDDI EISA and PCI cards.
|
||
</para>
|
||
|
||
<para>
|
||
When you have your kernel built to support the FDDI driver and
|
||
installed (the compilation options are given below), configuration
|
||
of the FDDI interface is virtually identical to that of an ethernet
|
||
interface. You just specify the need to replace the Ethernet interface
|
||
names with appropriate FDDI interface names in the ifconfig and route commands.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
|
||
Network device support --->
|
||
[*] FDDI driver support
|
||
[*] Digital DEFEA and DEFPA adapter support
|
||
</screen>
|
||
</para>
|
||
|
||
</sect1 id="FDDI">
|
||
|
||
<sect1 id="Frame-Relay">
|
||
|
||
<title>Frame-Relay</title>
|
||
|
||
<para>
|
||
Frame relay is a protocol used with leased lines to support speeds up to
|
||
1.544 Mbps. Frame realy uses packet switching over a phone company's
|
||
network. Frame realy connections use a virtual circuit, called
|
||
a PVC (private virtual circuit), to establish connections. Once established,
|
||
connections use a low overhead and do not provide error correction.
|
||
</para>
|
||
|
||
<para>
|
||
A frame realy compatible router is used to attach the LAN to the frame
|
||
relay line. Frame relay lines are available in speeds ranging from 56 Kbps
|
||
to 1.544 Mbps, and varying proportionally in cost. One advantage of frame
|
||
relay is that bandwidth is available on demand: you can install a line
|
||
at 56 Kbps and later upgrade it to a higher speed by ordering the service
|
||
from the carrier, usually without replacing any equipment.
|
||
</para>
|
||
|
||
<para>
|
||
It was specifically designed and is well suited to data communications traffic
|
||
that is of a `bursty' or intermittent nature. You connect to a Frame Relay
|
||
network using a Frame Relay Access Device (FRAD). The Linux Frame Relay
|
||
supports IP over Frame Relay as described in RFC-1490.
|
||
</para>
|
||
|
||
<para>
|
||
The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI
|
||
encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s).
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
|
||
|
||
Network device support --->
|
||
<*> Frame relay DLCI support (EXPERIMENTAL)
|
||
(24) Max open DLCI
|
||
(8) Max DLCI per device
|
||
<*> SDLA (Sangoma S502/S508) support
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay
|
||
support and configuration tools.
|
||
</para>
|
||
|
||
<para>
|
||
Currently the only FRAD supported are the Sangoma Technologies S502A,
|
||
S502E and S508.
|
||
</para>
|
||
|
||
<para>
|
||
To configure the FRAD and DLCI devices after you have rebuilt your
|
||
kernel you will need the Frame Relay configuration tools. These are
|
||
available from ftp.invlogic.com. Compiling and installing the tools
|
||
is straightforward, but the lack of a top level Makefile makes it a
|
||
fairly manual process:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
user% tar xvfz .../frad-0.15.tgz
|
||
user% cd frad-0.15
|
||
user% for i in common dlci frad; make -C $i clean; make -C $i; done
|
||
root# mkdir /etc/frad
|
||
root# install -m 644 -o root -g root bin/*.sfm /etc/frad
|
||
root# install -m 700 -o root -g root frad/fradcfg /sbin
|
||
root# install -m 700 -o root -g root dlci/dlcicfg /sbin
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Note that the previous commands use sh syntax, if you use a csh
|
||
flavour instead (like tcsh), the for loop will look different.
|
||
</para>
|
||
|
||
<para>
|
||
After installing the tools you need to create an /etc/frad/router.conf
|
||
file. You can use this template, which is a modified version of one of
|
||
the example files:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
# /etc/frad/router.conf
|
||
# This is a template configuration for frame relay.
|
||
# All tags are included. The default values are based on the code
|
||
# supplied with the DOS drivers for the Sangoma S502A card.
|
||
#
|
||
# A '#' anywhere in a line constitutes a comment
|
||
# Blanks are ignored (you can indent with tabs too)
|
||
# Unknown [] entries and unknown keys are ignored
|
||
#
|
||
|
||
[Devices]
|
||
Count=1 # number of devices to configure
|
||
Dev_1=sdla0 # the name of a device
|
||
#Dev_2=sdla1 # the name of a device
|
||
|
||
# Specified here, these are applied to all devices and can be overridden for
|
||
# each individual board.
|
||
#
|
||
Access=CPE
|
||
Clock=Internal
|
||
KBaud=64
|
||
Flags=TX
|
||
#
|
||
# MTU=1500 # Maximum transmit IFrame length, default is 4096
|
||
# T391=10 # T391 value 5 - 30, default is 10
|
||
# T392=15 # T392 value 5 - 30, default is 15
|
||
# N391=6 # N391 value 1 - 255, default is 6
|
||
# N392=3 # N392 value 1 - 10, default is 3
|
||
# N393=4 # N393 value 1 - 10, default is 4
|
||
|
||
# Specified here, these set the defaults for all boards
|
||
# CIRfwd=16 # CIR forward 1 - 64
|
||
# Bc_fwd=16 # Bc forward 1 - 512
|
||
# Be_fwd=0 # Be forward 0 - 511
|
||
# CIRbak=16 # CIR backward 1 - 64
|
||
# Bc_bak=16 # Bc backward 1 - 512
|
||
# Be_bak=0 # Be backward 0 - 511
|
||
|
||
|
||
#
|
||
#
|
||
# Device specific configuration
|
||
#
|
||
#
|
||
|
||
#
|
||
# The first device is a Sangoma S502E
|
||
#
|
||
[sdla0]
|
||
Type=Sangoma # Type of the device to configure, currently only
|
||
# SANGOMA is recognized
|
||
#
|
||
# These keys are specific to the 'Sangoma' type
|
||
#
|
||
# The type of Sangoma board - S502A, S502E, S508
|
||
Board=S502E
|
||
#
|
||
# The name of the test firmware for the Sangoma board
|
||
# Testware=/usr/src/frad-0.10/bin/sdla_tst.502
|
||
#
|
||
# The name of the FR firmware
|
||
# Firmware=/usr/src/frad-0.10/bin/frm_rel.502
|
||
#
|
||
Port=360 # Port for this particular card
|
||
Mem=C8 # Address of memory window, A0-EE, depending on card
|
||
IRQ=5 # IRQ number, do not supply for S502A
|
||
DLCIs=1 # Number of DLCI's attached to this device
|
||
DLCI_1=16 # DLCI #1's number, 16 - 991
|
||
# DLCI_2=17
|
||
# DLCI_3=18
|
||
# DLCI_4=19
|
||
# DLCI_5=20
|
||
#
|
||
# Specified here, these apply to this device only,
|
||
# and override defaults from above
|
||
#
|
||
# Access=CPE # CPE or NODE, default is CPE
|
||
# Flags=TXIgnore,RXIgnore,BufferFrames,DropAborted,Stats,MCI,AutoDLCI
|
||
# Clock=Internal # External or Internal, default is Internal
|
||
# Baud=128 # Specified baud rate of attached CSU/DSU
|
||
# MTU=2048 # Maximum transmit IFrame length, default is 4096
|
||
# T391=10 # T391 value 5 - 30, default is 10
|
||
# T392=15 # T392 value 5 - 30, default is 15
|
||
# N391=6 # N391 value 1 - 255, default is 6
|
||
# N392=3 # N392 value 1 - 10, default is 3
|
||
# N393=4 # N393 value 1 - 10, default is 4
|
||
|
||
#
|
||
# The second device is some other card
|
||
#
|
||
# [sdla1]
|
||
# Type=FancyCard # Type of the device to configure.
|
||
# Board= # Type of Sangoma board
|
||
# Key=Value # values specific to this type of device
|
||
|
||
|
||
#
|
||
# DLCI Default configuration parameters
|
||
# These may be overridden in the DLCI specific configurations
|
||
#
|
||
CIRfwd=64 # CIR forward 1 - 64
|
||
# Bc_fwd=16 # Bc forward 1 - 512
|
||
# Be_fwd=0 # Be forward 0 - 511
|
||
# CIRbak=16 # CIR backward 1 - 64
|
||
# Bc_bak=16 # Bc backward 1 - 512
|
||
# Be_bak=0 # Be backward 0 - 511
|
||
|
||
#
|
||
# DLCI Configuration
|
||
# These are all optional. The naming convention is
|
||
# [DLCI_D<devicenum>_<DLCI_Num>]
|
||
#
|
||
|
||
[DLCI_D1_16]
|
||
# IP=
|
||
# Net=
|
||
# Mask=
|
||
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
|
||
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
|
||
# CIRfwd=64
|
||
# Bc_fwd=512
|
||
# Be_fwd=0
|
||
# CIRbak=64
|
||
# Bc_bak=512
|
||
# Be_bak=0
|
||
|
||
[DLCI_D2_16]
|
||
# IP=
|
||
# Net=
|
||
# Mask=
|
||
# Flags defined by Sangoma: TXIgnore,RXIgnore,BufferFrames
|
||
# DLCIFlags=TXIgnore,RXIgnore,BufferFrames
|
||
# CIRfwd=16
|
||
# Bc_fwd=16
|
||
# Be_fwd=0
|
||
# CIRbak=16
|
||
# Bc_bak=16
|
||
# Be_bak=0
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
When you've built your /etc/frad/router.conf file the only step
|
||
remaining is to configure the actual devices themselves. This is only
|
||
a little trickier than a normal network device configuration, you need
|
||
to remember to bring up the FRAD device before the DLCI encapsulation
|
||
devices. These commands are best hosted in a shell script, due to
|
||
their number:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
#!/bin/sh
|
||
# Configure the frad hardware and the DLCI parameters
|
||
/sbin/fradcfg /etc/frad/router.conf || exit 1
|
||
/sbin/dlcicfg file /etc/frad/router.conf
|
||
#
|
||
# Bring up the FRAD device
|
||
ifconfig sdla0 up
|
||
#
|
||
# Configure the DLCI encapsulation interfaces and routing
|
||
ifconfig dlci00 192.168.10.1 pointopoint 192.168.10.2 up
|
||
route add -net 192.168.10.0 netmask 255.255.255.0 dlci00
|
||
#
|
||
ifconfig dlci01 192.168.11.1 pointopoint 192.168.11.2 up
|
||
route add -net 192.168.11.0 netmask 255.255.255.0 dlci00
|
||
#
|
||
route add default dev dlci00
|
||
#
|
||
</screen>
|
||
</para>
|
||
|
||
</sect1 id="Frame-Relay">
|
||
|
||
<sect1 id="NetBEUI">
|
||
|
||
<title>NetBEUI</title>
|
||
|
||
<para>
|
||
NetBEUI (NetBIOS Extended User Interface) is a transport-layer protocol
|
||
developed by Microsoft and IBM. NetBEUI was mainly intended as a basic
|
||
protocol to support NetBIOS (Network Basic Input/Output System), the
|
||
Windows standard for workstation naming, communications, and file sharing.
|
||
</para>
|
||
|
||
<para>
|
||
NetBEUI is a fast protocol with a low overhead, which makes it a good
|
||
choice for small networks. However, it is a non-routable protocol.
|
||
Networks that use NetBEUI can be use bridges for traffic management,
|
||
but cannot use routers. Another disadvantage is its proprietary nature.
|
||
NetBEUI is supported by few systems other than Windows.
|
||
</para>
|
||
|
||
<para>
|
||
Although NetBEUI was developed by Microsoft and was the default protocol
|
||
for some operating systems (such as Windows for Workgroups and Windows 95),
|
||
Microsoft recommends TCP/IP over NetBEUI for most Windows NT networks.
|
||
</para>
|
||
|
||
</sect1 id="NetBEUI">
|
||
|
||
<sect1 id="IPX">
|
||
|
||
<title>IPX</title>
|
||
|
||
<para>
|
||
IPX and SPX are proprietary protocols that were developed during the
|
||
early 1980s by Novell for use in NetWare networks.
|
||
|
||
NetWare became the de facto standard network operating system (NOS) of
|
||
first generation LANs. Novell complemented its NOS with a
|
||
business-oriented application suite and client-side connection utilities.
|
||
|
||
They were based on protocols used in Xerox's XNS (Xerox Network Systems)
|
||
network architecture.
|
||
|
||
IPX (Internetwork Packet Exchange) is a connectionless protocol that works
|
||
at the network layer of the OSI model, and SPX (Sequenced Packet Exchange)
|
||
is a connection-orientated protocol that works at the transport layer.
|
||
</para>
|
||
|
||
<para>
|
||
These protocols are often easier to configure than TCP/IP and are routable,
|
||
so they make a good alternative for some networks, particularly small
|
||
peer-to-peer networks. However, TCP/IP is more suitable for larger
|
||
LANs and WANs.
|
||
</para>
|
||
|
||
<para>
|
||
Frame types are one aspect of IPX networks that sometimes does require
|
||
configuration. The frame type determines the order and type of data included
|
||
in the packet. Typical frame types used in NetWare networks
|
||
802.2 and 802.3.
|
||
</para>
|
||
|
||
<para>
|
||
Linux has a very clean IPX/SPX implementation, allowing it to be
|
||
configured as an:
|
||
|
||
<20> IPX router
|
||
<20> IPX bridge
|
||
<20> NCP client and/or NCP Server (for sharing files)
|
||
<20> Novell Print Client, Novell Print Server
|
||
|
||
And to:
|
||
|
||
<20> Enable PPP/IPX, allowing a Linux box to act as a PPP server/client
|
||
<20> Perform IPX tunnelling through IP, allowing the connection of two
|
||
IPX networks through an IP only link
|
||
</para>
|
||
|
||
How do I configure the kernel for IPX networking support?
|
||
<para>
|
||
<screen>
|
||
IPX ( AF_IPX )
|
||
Kernel Compile Options:
|
||
|
||
Networking options --->
|
||
[*] The IPX protocol
|
||
[ ] Full internal IPX network
|
||
</screen>
|
||
</para>
|
||
|
||
* IPX-SPX HOWTO
|
||
|
||
</sect1 id="IPX">
|
||
|
||
<sect1 id="Leased-Line">
|
||
|
||
<title>Leased-Line</title>
|
||
|
||
_______________________________________________________________________________
|
||
<sect>
|
||
<para>
|
||
Configuring your modem and pppd to use a 2 wire twisted pair leased
|
||
line.
|
||
</para>
|
||
|
||
1.2. What is a leased line
|
||
|
||
<para>
|
||
Any fixed, that is permanent, point to point data communications link,
|
||
which is leased from a telco or similar organisation. The leased line
|
||
involves cables, such as twisted pair, coax or fiber optic, and may
|
||
involve all sorts of other hardware such as (pupin) coils,
|
||
transformers, amplifiers and regenerators.
|
||
</para>
|
||
|
||
<para>
|
||
This document deals with:
|
||
Configuring your modem and pppd to use a 2 wire twisted pair
|
||
leased line.
|
||
</para>
|
||
|
||
<para>
|
||
This document does NOT deal with:
|
||
SLIP, getting or installing pppd, synchronous data
|
||
communication, baseband modems, xDSL.
|
||
</para>
|
||
|
||
1.3. Assumptions
|
||
|
||
<para>
|
||
You should already have a working pppd on your system. You also need
|
||
Minicom or a similar program to configure your modems.
|
||
</para>
|
||
|
||
2. Modem
|
||
|
||
<para>
|
||
A leased line is not connected to a telephone exchange and does not
|
||
provide DC power, dial tone, busy tone or ring signal. This means that
|
||
your modems are on their own and have to be able to deal with this
|
||
situation.
|
||
</para>
|
||
|
||
<para>
|
||
You should have 2 identical (including firmware version) external
|
||
modems supporting both leased line and dumb mode. Make sure your
|
||
modems can actually do this! Also make sure your modem is properly
|
||
documented. You also need:
|
||
</para>
|
||
|
||
<EFBFBD> 2 fully wired shielded RS232 cables. The shield should be connected
|
||
to the connector shell (not pin 1) at both ends (not at one end).
|
||
<EFBFBD> A RS232 test plug may be handy for test purposes.
|
||
<EFBFBD> 2 RJ11 cords, one for each end of the leased line.
|
||
<EFBFBD> A basic understanding of `AT' commands.
|
||
|
||
2.1. Modem Configuration
|
||
|
||
<para>
|
||
A note on modem configuration and init strings in general: Configure
|
||
your modem software such as minicom or (m)getty to use the highest
|
||
possible speed; 57600 bps for 14k4 and 115200 bps for 28k8 or faster
|
||
modems. Lots of people use very long and complicated init strings,
|
||
often starting with AT&F and containing lots of modem brand and -type
|
||
specific commands. This however is needlessly complicated. Most
|
||
programs feel happy with the same modem settings, so why not write
|
||
these settings in the non volatile memory of all your modems, and only
|
||
use `ATZ' as an init string in all your programs. This way you can
|
||
swap or upgrade your modems without ever having to reconfigure any of
|
||
your software.
|
||
</para>
|
||
|
||
<para>
|
||
Most programs require you to use the following settings;
|
||
</para>
|
||
|
||
<EFBFBD> Fixed baud rate (no auto baud)
|
||
<EFBFBD> Hardware bidirectional RTS-CTS flow control (no x-on/x-off)
|
||
<EFBFBD> 8 Bits, no parity, 1 stopbit
|
||
<EFBFBD> The modem should produce the TRUE DCD status (&C1)
|
||
<EFBFBD> The modem should NOT ignore the DTR status (&D2 or &D3)
|
||
|
||
<para>
|
||
Check this with AT&V or AT&Ix (consult your modem documentation)
|
||
</para>
|
||
|
||
<para>
|
||
These settings are not necessarily the same as the default factory
|
||
profile (&F), so starting an init string with AT&F is probably not a
|
||
good idea in the first place. The smart thing to do is probably to use
|
||
AT&F only when you have reason to believe that the modem setup stored
|
||
in the non volatile memory is really screwed up. If you think you
|
||
have found the right setup for your modems, write it to non volatile
|
||
memory with AT&W and test it thoroughly with Z-modem file transfers of
|
||
both ASCII text and binary files. Only if all of this works perfectly
|
||
should you configure your modems for leased line.
|
||
</para>
|
||
|
||
<para>
|
||
Find out how to put your modem into dumb mode and, more importantly,
|
||
how to get it out of dumb mode; The modem can only be reconfigured
|
||
when it is not in dumb mode. Make sure you actually configure your
|
||
modems at the highest possible speed. Once in dumb mode it will
|
||
ignore all `AT' commands and consequently will not adjust its speed to
|
||
that of the COM port, but will use the speed at which it was
|
||
configured instead (this speed is stored in a S-register by the AT&W
|
||
command).
|
||
</para>
|
||
|
||
<para>
|
||
Now configure your modem as follows;
|
||
</para>
|
||
|
||
<EFBFBD> Reset on DTR toggle (&D3, this is sometimes a S register). This
|
||
setting is required by some ISP's!
|
||
<EFBFBD> Leased line mode (&L1 or &L2, consult your modem documentation)
|
||
<EFBFBD> The remote modem auto answer (S0=1), the local originate (S0=0)
|
||
<EFBFBD> Disable result codes (Q1, sometimes the dumb mode does this for
|
||
you)
|
||
<EFBFBD> Dumb mode (\D1 or %D1, this is sometimes a jumper) In dumb mode the
|
||
modem will ignore all AT commands (sometimes you need to disable
|
||
the ESC char as well).
|
||
|
||
<para>
|
||
Write the configuration to non-volatile memory (&W).
|
||
</para>
|
||
|
||
2.2. Test
|
||
|
||
<para>
|
||
Now connect the modems to 2 computers using the RS232 cables and
|
||
connect the modems to each other using a RJ11 lead. Use a modem
|
||
program such as Minicom (Linux), procom or telix (DOS) on both
|
||
computers to test the modems. You should be able to type text from
|
||
one computer to the other and vice versa. If the screen produces
|
||
garbage check your COM port speed and other settings. Now disconnect
|
||
and reconnect the RJ11 cord. Wait for the connection to reestablish
|
||
itself. Disconnect and reconnect the RS232 cables, switch the modems
|
||
on and off, stop and restart Minicom. The modems should always
|
||
reconnect at the highest possible speed (some modems have speed
|
||
indicator leds). Check whether the modems actually ignores the ESC
|
||
(+++) character. If necessary disable the ESC character.
|
||
</para>
|
||
|
||
<para>
|
||
If all of this works you may want to reconfigure your modems; Switch
|
||
off the sound at the remote modem (M0) and put the local modem at low
|
||
volume (L1).
|
||
</para>
|
||
|
||
2.3. Examples
|
||
|
||
2.3.1. Hi-Tech
|
||
|
||
<para>
|
||
This is a rather vague `no name clone modem'. Its config string is
|
||
however typical and should work on most modems.
|
||
</para>
|
||
|
||
<para>
|
||
Originate (local):
|
||
ATL1&C1&D3&L2%D1&W&W1
|
||
</para>
|
||
|
||
<para>
|
||
Answer (remote):
|
||
ATM0L1&C1&D3&L2%D1S0=1&W&W1
|
||
</para>
|
||
|
||
2.3.2. Tornado FM 228 E
|
||
|
||
<para>
|
||
This is what should work;
|
||
</para>
|
||
|
||
<para>
|
||
Originate (local):
|
||
ATB15L1Q1&C1&D3&L2&W&W1
|
||
</para>
|
||
|
||
<para>
|
||
Answer (remote):
|
||
ATM0B15M0Q1&C1&D3&L2S0=1&W&W1
|
||
</para>
|
||
|
||
<para>
|
||
Move the dumb jumper from position 2-3 to 1-2.
|
||
</para>
|
||
|
||
<para>
|
||
Due to a firmware bug, the modems will only connect after being hard
|
||
reset (power off and on) while DTR is high. I designed a circuit which
|
||
hard resets the modem on the low to high transition of DTR. The
|
||
FreeBSD pppd however, isn't very happy about this. By combining the
|
||
setting &D0 with a circuit which resets on the high to low transition
|
||
instead, this problem can be avoided.
|
||
</para>
|
||
|
||
2.3.3. Tron DF
|
||
|
||
<para>
|
||
The ESC char should be disabled by setting S2 > 127;
|
||
</para>
|
||
|
||
<para>
|
||
Originate:
|
||
ATL1&L1Q1&C1&D3S2=171\D1&W
|
||
</para>
|
||
|
||
<para>
|
||
Answer:
|
||
ATM0&L2Q1&C1&D3S0=1S2=171\D1&W
|
||
</para>
|
||
|
||
2.3.4. US Robotics Courier V-Everything
|
||
|
||
<para>
|
||
The USR Sportster and USR Courier-I do not support leased line. You
|
||
need the Courier V-everything version for this job. There is a
|
||
webpage on the USR site `explaining' how to set-up your Courier for
|
||
leased line. However, if you follow these instructions you will end up
|
||
with a completely brain dead modem, which can not be controlled or
|
||
monitored by your pppd.
|
||
</para>
|
||
|
||
<para>
|
||
The USR Courier can be configured with dip switches, however you need
|
||
to feed it the config string first. First make sure it uses the right
|
||
factory profile. Unlike most other modems it has three; &F0, &F1 and
|
||
&F2. The default, which is also the one you should use, is &F1. If you
|
||
send it an AT&F, however it will load the factory profile &F0! For
|
||
the reset on DTR toggle you set bit 0 of S register 13. This means you
|
||
have to set S13 to 1. Furthermore you need set it to leased line mode
|
||
with &L1; ATS13=1&L1&W The dip switches are all default except for the
|
||
following:
|
||
<para>
|
||
|
||
<para>
|
||
3 OFF Disable result codes
|
||
4 ON Disable offline commands
|
||
5 ON For originate, OFF For answer
|
||
8 OFF Dumb mode
|
||
</para>
|
||
|
||
3. PPPD
|
||
|
||
<para>
|
||
You need a pppd (Point to Point Protocol Daemon) and a reasonable
|
||
knowledge of how it works. Consult the relevant RFC's or the Linux PPP
|
||
HOWTO if necessary. Since you are not going to use a login procedure,
|
||
you don't use (m)getty and you do not need a (fake) user associated
|
||
with the pppd controlling your link. You are not going to dial so you
|
||
don't need any chat scripts either. In fact, the modem circuit and
|
||
configuration you have just build, are rather like a fully wired null
|
||
modem cable. This means you have to configure your pppd the same way
|
||
as you would with a null modem cable.
|
||
</para>
|
||
|
||
<para>
|
||
For a reliable link, your setup should meet the following criteria;
|
||
</para>
|
||
|
||
<EFBFBD> Shortly after booting your system, pppd should raise the DTR signal
|
||
in your RS232 port, wait for DCD to go up, and negotiate the link.
|
||
<EFBFBD> If the remote system is down, pppd should wait until it is up
|
||
again.
|
||
<EFBFBD> If the link is up and then goes down, pppd should reset the modem
|
||
(it does this by dropping and then raising DTR), and then try to
|
||
reconnect.
|
||
<EFBFBD> If the quality of the link deteriorates too much, pppd should reset
|
||
the modem and then reestablish the link.
|
||
<EFBFBD> If the process controlling the link, that is the pppd, dies, a
|
||
watchdog should restart the pppd.
|
||
|
||
3.1. Configuration
|
||
|
||
<para>
|
||
Suppose the modem is connected to COM2, the local IP address is
|
||
`Loc_Ip' and the remote IP address is `Rem_Ip'. We want to use 576 as
|
||
our MTU. The /etc/ppp/options.ttyS1 would now be:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
crtscts
|
||
mru 576
|
||
mtu 576
|
||
passive
|
||
Loc_Ip:Rem_Ip
|
||
-chap
|
||
modem
|
||
#noauth
|
||
-pap
|
||
persist
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Stuff like `asyncmap 0', `lock', `modem' and `-detach' are probably
|
||
already in /etc/ppp/options. If not, add them to your
|
||
/etc/ppp/options.ttyS1. So, if the local system is 192.168.1.1 and
|
||
the remote system is 10.1.1.1, then /etc/ppp/options.ttyS1 on the
|
||
local system would be:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
crtscts
|
||
mru 576
|
||
mtu 576
|
||
passive
|
||
192.168.1.1:10.1.1.1
|
||
-chap
|
||
modem
|
||
#noauth
|
||
-pap
|
||
persist
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The options.ttyS1 on the remote system would be:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
crtscts
|
||
mru 576
|
||
mtu 576
|
||
passive
|
||
10.1.1.1:192.168.1.1
|
||
-chap
|
||
modem
|
||
#noauth
|
||
-pap
|
||
persist
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The passive option limits the number of (re)connection attempts. The
|
||
persist option will keep pppd alive in case of a disconnect or when it
|
||
can't connect in the first place. If you telnet a lot while doing
|
||
filetransfers (FTP or webbrowsing) at the same time, you might want to
|
||
use a smaller MTU and MRU such as 296. This will make the remote sys<79>
|
||
tem more responsive. If you don't care much about telnetting during
|
||
FTP, you could set the MTU and MRU to 1500. Keep in mind though, that
|
||
UDP cannot be fragmented. Speakfreely for instance uses 512 byte UDP
|
||
packets. So the minimum MTU for speakfreely is 552 bytes. The noauth
|
||
option may be necessary with some newer distributions.
|
||
</para>
|
||
|
||
3.2. Scripts
|
||
|
||
3.2.1. Starting the pppd and keeping it alive
|
||
|
||
<para>
|
||
You could start the pppd form a boot (rc) script. However, if you do
|
||
this, and the pppd dies, you are without a link. A more stable
|
||
solution, is to start the pppd from /etc/inittab;
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
This way, the pppd will be restarted if it dies. Make sure you have a
|
||
`-detach' option (nodetach on newer systems) though, otherwise inittab
|
||
will start numerous instances of pppd, will complaining about
|
||
`respawning too fast'.
|
||
</para>
|
||
|
||
<para>
|
||
Note: Some older systems will not accept the speed `115200'. In this
|
||
case you will have to set the speed to 38400 en set the `spd_vhi' flag
|
||
with setserial. Some systems expect you to use a `cua' instead of
|
||
`ttyS' device.
|
||
</para>
|
||
|
||
3.2.2. Setting the routes
|
||
|
||
<para>
|
||
The default route can be set with the defaultroute option or with the
|
||
/etc/ppp/ip-up script;
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
#!/bin/bash
|
||
case $2 in
|
||
/dev/ttyS1)
|
||
/sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0
|
||
;;
|
||
esac
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Ip-up can also be used to sync your clock using netdate.
|
||
</para>
|
||
|
||
<para>
|
||
Of course the route set in ip-up is not necessarily the default route.
|
||
Your ip-up sets the route to the remote network while the ip-up script
|
||
on the remote system sets the route to your network. If your network
|
||
is 192.168.1.0 and your ppp interface 192.168.1.1, the ip-up script on
|
||
the remote machine looks like this;
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
#!/bin/bash
|
||
case $2 in
|
||
/dev/ttyS1)
|
||
/sbin/route add -net 192.168.1.0 gw 192.168.1.1 netmask 255.255.255.0
|
||
;;
|
||
esac
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The `case $2' and `/dev/ttyS1)' bits are there in case you use more
|
||
than one ppp link. Ip-up will run each time a link comes up, but only
|
||
the part between `/dev/ttySx)' and `;;' will be executed, setting the
|
||
right route for the right ttyS. You can find more about routing in
|
||
the Linux Networking HOWTO section on routing.
|
||
</para>
|
||
|
||
3.3. Test
|
||
|
||
<para>
|
||
Test the whole thing just like the modem test. If it works, get on
|
||
your bike and bring the remote modem to the remote side of your link.
|
||
If it doesn't work, one of the things you should check is the COM port
|
||
speed; Apparently, a common mistake is to configure the modems with
|
||
Minicom using one speed and then configure the pppd to use an other.
|
||
This will NOT work! You have to use the same speed all of the time!
|
||
</para>
|
||
</sect>
|
||
|
||
<sect>
|
||
|
||
T1-T4
|
||
<para>
|
||
A T1 line is a high-speed, dedicated, point-to-point leased line that
|
||
includes 24 seperate 64 Kbps channles for voice and data. Other lines
|
||
of this type, called T-carrier lines, support larger numbers of channels.
|
||
T1 and T3 lines are the most commonly used.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Carrier Channels Total Bandwidth
|
||
T1 24 1.544 Mbps
|
||
T2 96 6.312 Mbps
|
||
T3 672 44.736 Mbps
|
||
T4 4032 274.176 Mbps
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
While the specification for T-carrier lines does not mandate a particular
|
||
media type, T1 and T2 are typically carried on copper, and T3 and T4
|
||
typically use fiber optic media. DS1, DS2, DS3, and DS4 are an alternate
|
||
type of line equivalent to T1-T4, and typically use fiber optic media.
|
||
</para>
|
||
|
||
SONET (Synchronous Optical Network)
|
||
<para>
|
||
A leased-line system using fiber optic media to support data speeds up to
|
||
2.4 Gbps. SONET services are sold based on optical carier (OC) levels. OC
|
||
levels are calculated as multiples of the OC-1 speed, 51.840 Mbps. For
|
||
example, OC-3 level would correspond with a data speed of 155 Mbps and
|
||
OC-12 level would equate to a data transfer rate of 622 Mbps. OC-1 and
|
||
OC-3 are the most commonly used SONET lines.
|
||
</para>
|
||
|
||
</sect id="Leased-Line">
|
||
|
||
<sect1 id="PLIP">
|
||
|
||
<title>PLIP</title>
|
||
|
||
<para>
|
||
PLIP (Parallel Line IP), is like SLIP, in that it is used for
|
||
providing a point to point network connection between two machines,
|
||
except that it is designed to use the parallel printer ports on your
|
||
machine instead of the serial ports (a cabling diagram in included in
|
||
the cabling diagram section later in this document). Because it is
|
||
possible to transfer more than one bit at a time with a parallel port,
|
||
it is possible to attain higher speeds with the plip interface than
|
||
with a standard serial device. In addition, even the simplest of
|
||
parallel ports, printer ports, can be used in lieu of you having to
|
||
purchase comparatively expensive 16550AFN UART's for your serial
|
||
ports. PLIP uses a lot of CPU compared to a serial link and is most
|
||
certainly not a good option if you can obtain some cheap ethernet
|
||
cards, but it will work when nothing else is available and will work
|
||
quite well. You should expect a data transfer rate of about 20
|
||
kilobytes per second when a link is running well.
|
||
</para>
|
||
|
||
7.2. PLIP for Linux-2.0
|
||
|
||
<para>
|
||
PLIP device names are `plip0', `plip1 and plip2.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
|
||
Network device support --->
|
||
<*> PLIP (parallel port) support
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The PLIP device drivers competes with the parallel device driver for
|
||
the parallel port hardware. If you wish to use both drivers then you
|
||
should compile them both as modules to ensure that you are able to
|
||
select which port you want to use for PLIP and which ports you want
|
||
for the printer driver. Refer to the ``Modules mini-HOWTO'' for more
|
||
information on kernel module configuration.
|
||
</para>
|
||
|
||
<para>
|
||
Please note that some laptops use chipsets that will not work with
|
||
PLIP because they do not allow some combinations of signals that PLIP
|
||
relies on, that printers don't use.
|
||
</para>
|
||
|
||
<para>
|
||
The Linux plip interface is compatible with the Crynwyr Packet Driver
|
||
PLIP and this will mean that you can connect your Linux machine to a
|
||
DOS machine running any other sort of tcp/ip software via plip.
|
||
</para>
|
||
|
||
<para>
|
||
In the 2.0.* series kernel the plip devices are mapped to i/o port and
|
||
IRQ as follows:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
device i/o IRQ
|
||
------ ----- ---
|
||
plip0 0x3bc 5
|
||
plip1 0x378 7
|
||
plip2 0x278 2
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
If your parallel ports don't match any of the above combinations then
|
||
you can change the IRQ of a port using the ifconfig command using the
|
||
`irq' parameter (be sure to enable IRQ's on your printer ports in your
|
||
ROM BIOS if it supports this option). As an alternative, you can
|
||
specify ``io='' annd ``irq='' options on the insmod command line, if
|
||
you use modules. For example:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# insmod plip.o io=0x288 irq=5
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
PLIP operation is controlled by two timeouts, whose default values are
|
||
probably ok in most cases. You will probably need to increase them if
|
||
you have an especially slow computer, in which case the timers to
|
||
increase are actually on the other computer. A program called
|
||
plipconfig exists that allows you to change these timer settings
|
||
without recompiling your kernel. It is supplied with many Linux
|
||
distributions.
|
||
</para>
|
||
|
||
<para>
|
||
To configure a plip interface, you will need to invoke the following
|
||
commands (or add them to your initialization scripts):
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
root# /sbin/ifconfig plip1 localplip pointopoint remoteplip
|
||
root# /sbin/route add remoteplip plip1
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
Here, the port being used is the one at I/O address 0x378; localplip
|
||
amd remoteplip are the names or IP addresses used over the PLIP cable.
|
||
I personally keep them in my /etc/hosts database:
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
# plip entries
|
||
192.168.3.1 localplip
|
||
192.168.3.2 remoteplip
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The pointopoint parameter has the same meaning as for SLIP, in that it
|
||
specifies the address of the machine at the other end of the link.
|
||
</para>
|
||
|
||
<para>
|
||
In almost all respects you can treat a plip interface as though it
|
||
were a SLIP interface, except that neither dip nor slattach need be,
|
||
nor can be, used.
|
||
</para>
|
||
|
||
<para>
|
||
Further information on PLIP may be obtained from the ``PLIP mini-
|
||
HOWTO''.
|
||
</para>
|
||
|
||
7.3. PLIP for Linux-2.2
|
||
|
||
<para>
|
||
During development of the 2.1 kernel versions, support for the
|
||
parallel port was changed to a better setup.
|
||
</para>
|
||
|
||
<para>
|
||
<screen>
|
||
Kernel Compile Options:
|
||
|
||
General setup --->
|
||
[*] Parallel port support
|
||
Network device support --->
|
||
<*> PLIP (parallel port) support
|
||
</screen>
|
||
</para>
|
||
|
||
<para>
|
||
The new code for PLIP behaves like the old one (use the same ifconfig
|
||
and route commands as in the previous section, but initialization of
|
||
the device is different due to the advanced parallel port support.
|
||
</para>
|
||
|
||
<para>
|
||
The ``first'' PLIP device is always called ``plip0'', where first is
|
||
the first device detected by the system, similarly to what happens for
|
||
Ethernet devices. The actual parallel port being used is one of the
|
||
available ports, as shown in /proc/parport. For example, if you have
|
||
only one parallel port, you'll only have a directory called
|
||
/proc/parport/0.
|
||
</para>
|
||
|
||
<para>
|
||
If your kernel didn't detect the IRQ number used by your port,
|
||
``insmod plip'' will fail; in this case just write the right number to
|
||
/proc/parport/0/irq and reinvoke insmod.
|
||
</para>
|
||
|
||
<para>
|
||
Complete information about parallel port management is available in
|
||
the file Documentation/parport.txt, part of your kernel sources.
|
||
</para>
|
||
|
||
<EFBFBD> PLIP information can be found in The Network Administrator Guide
|
||
<http://metalab.unc.edu/mdw/LDP/nag/nag.html>
|
||
|
||
PLIP allows the cheap connection of two machines.
|
||
It uses a parallel port and a special cable, achieving speeds of
|
||
10kBps to 20kBps.
|
||
|
||
</sect1 id="PLIP">
|
||
|
||
<sect1 id="PPP-and-SLIP">
|
||
|
||
<title>PPP and SLIP</title>
|
||
|
||
<para>
|
||
The Linux kernel has built-in support for PPP (Point-to-Point-
|
||
Protocol) and SLIP (Serial Line IP). PPP is the most popular
|
||
way individual users access their ISPs (Internet Service
|
||
Providers).
|
||
|
||
<EFBFBD> Linux PPP HOWTO <http://metalab.unc.edu/mdw/HOWTO/PPP-HOWTO.html>
|
||
|
||
<EFBFBD> PPP/SLIP emulator <http://metalab.unc.edu/mdw/HOWTO/mini/SLIP-PPP-
|
||
Emulator.html>
|
||
|
||
</sect1 id="PPP-and-SLIP">
|
||
|
||
<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.
|
||
|
||
</sect1 id="Token-Ring">
|
||
|
||
<sect1 id="X25">
|
||
|
||
<title>X25</title>
|
||
|
||
<para>
|
||
X.25 is a circuit based protocol developed in the 1970s for packet switching
|
||
by the C.C.I.T.T. (a standards body recognized by Telecommunications
|
||
companies in most parts of the world), allowing customers to share access to
|
||
a PDN (Public Data Network). These networks, such as Sprintnet and Tymnet,
|
||
were the most practical way to connect large companies at the time,
|
||
and are still used by some companies. PDNs are networks that have local
|
||
dial-up access points in cities throughout the country and use dedicated lines
|
||
to network between these cities. Companies would dial up in two locations to
|
||
connect their computers.
|
||
</para>
|
||
|
||
<para>
|
||
Computers, routers, or other devices that access a PDN using the X.25
|
||
protocols are called data terminal equipment, or DTEs. DTEs without built-in
|
||
support for X.25 is a protocol with a relatively high overhead, since it
|
||
provides error control and accounting for users of the network.
|
||
</para>
|
||
|
||
<para>
|
||
The X.25 protocol supports speeds up to 64 Kbps. This makes it impractical for
|
||
many networks, but it is an inexpensive alternative for low-bandwidth
|
||
applications. X,25 is a protocol with a relatively high overhead, since it
|
||
provides error control and accouting for users of the network.
|
||
</para>
|
||
|
||
<para>
|
||
An implementation of X.25 and LAPB are being worked on and recent
|
||
2.1.* kernels include the work in progress. Jonathon Naylor
|
||
jsn@cs.nott.ac.uk is leading the development and a
|
||
mailing list has been established to discuss Linux X.25 related
|
||
matters. To subscribe send a message to: majordomo@vger.rutgers.edu
|
||
with the text "subscribe linux-x25" in the body of the message.
|
||
Early versions of the configuration tools may be obtained from
|
||
Jonathon's ftp site at ftp.cs.nott.ac.uk.
|
||
</para>
|
||
|
||
</sect1 id="X25">
|
||
|
||
<sect1 id="IPv6">
|
||
|
||
<title>IPv6</title>
|
||
|
||
|
||
<para>
|
||
2.1. What is IPv6?
|
||
|
||
IPv6, sometimes also referred to as IPng (IP Next Generation)
|
||
is a new layer 3 protocol (see [http://www.linuxports.com/howto/
|
||
intro_to_networking/c4412.htm#PAGE103HTML] linuxports/howto/
|
||
intro_to_networking/ISO - OSI Model) which will supersede IPv4 (also known as
|
||
IP).
|
||
|
||
It was designed to address many issues including, the shortage of
|
||
available IP addresses, lack of mechanisms to handle time-sensitive
|
||
traffic, lack of network layer security, etc.
|
||
|
||
IPv4 was designed long time ago ([http://www.faqs.org/rfcs/rfc760.html]
|
||
RFC 760 / Internet Protocol from January 1980) and since its inception, there
|
||
have been many requests for more addresses and enhanced capabilities. Latest
|
||
RFC is [http://www.faqs.org/rfcs/rfc2460.html] RFC 2460 / Internet Protocol
|
||
Version 6 Specification. Major changes in IPv6 are the redesign of the
|
||
header, including the increase of address size from 32 bits to 128 bits.
|
||
Because layer 3 is responsible for end-to-end packet transport using packet
|
||
routing based on addresses, it must include the new IPv6 addresses (source
|
||
and destination), like IPv4. It is anticpated that the larger name space
|
||
and accompanying improved addressing scheme, which will prove to provide
|
||
a major improvement on routing performance.
|
||
|
||
For more information about the IPv6 history take a look at older IPv6 related
|
||
RFCs listed e.g. at [http://www.switch.ch/lan/ipv6/references.html] SWITCH
|
||
IPv6 Pilot / References.
|
||
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.2. History of IPv6 in Linux
|
||
|
||
The years 1992, 1993 and 1994 of the IPv6 History (in general) are covered by
|
||
following document: [http://www.laynetworks.com/users/webs/IPv6.htm#CH3] IPv6
|
||
or IPng (IP next generation).
|
||
|
||
To-do: better time-line, more content...
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.2.1. Beginning
|
||
|
||
The first IPv6 related network code was added to the Linux kernel 2.1.8 in
|
||
November 1996 by Pedro Roque. It was based on the BSD API:
|
||
diff -u --recursive --new-file v2.1.7/linux/include/linux/in6.h
|
||
<EFBFBD> linux/include/linux/in6.h
|
||
--- v2.1.7/linux/include/linux/in6.h Thu Jan 1 02:00:00 1970
|
||
+++ linux/include/linux/in6.h Sun Nov 3 11:04:42 1996
|
||
@@ -0,0 +1,99 @@
|
||
+/*
|
||
+ * Types and definitions for AF_INET6
|
||
+ * Linux INET6 implementation
|
||
+ * + * Authors:
|
||
+ * Pedro Roque <******>
|
||
+ *
|
||
+ * Source:
|
||
+ * IPv6 Program Interfaces for BSD Systems
|
||
+ * <draft-ietf-ipngwg-bsd-api-05.txt>
|
||
|
||
|
||
The shown lines were copied from patch-2.1.8 (e-mail address was blanked on
|
||
copy&paste).
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.2.2. In between
|
||
|
||
Because of lack of manpower, the IPv6 implementation in the kernel was unable
|
||
to follow the discussed drafts or newly released RFCs. In October 2000, a
|
||
project was started in Japan, called [http://www.linux-ipv6.org/] USAGI,
|
||
whose aim was to implement all missing, or outdated IPv6 support in Linux. It
|
||
tracks the current IPv6 implementation in FreeBSD made by the [http://
|
||
www.kame.net/] KAME project. From time to time they create snapshots against
|
||
current vanilla Linux kernel sources.
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.2.3. Current
|
||
|
||
Unfortunately, the [http://www.linux-ipv6.org/] USAGI patch is so big, that
|
||
current Linux networking maintainers are unable to include it in the
|
||
production source of the Linux kernel 2.4.x series. Therefore the 2.4.x
|
||
series is missing some (many) extensions and also does not confirm to all
|
||
current drafts and RFCs (see [http://www.ietf.org/html.charters/
|
||
ipv6-charter.html] IP Version 6 Working Group (ipv6) Charter). This can cause
|
||
some interoperability problems with other operating systems.
|
||
-----------------------------------------------------------------------------
|
||
|
||
2.2.4. Future
|
||
|
||
[http://www.linux-ipv6.org/] USAGI is now making use of the new Linux kernel
|
||
development series 2.5.x to insert all of their current extensions into this
|
||
development release. Hopefully the 2.6.x kernel series will contain a true
|
||
and up-to-date IPv6 implementation.
|
||
-----------------------------------------------------------------------------
|
||
|
||
</sect1 id="IPv6">
|