mirror of https://github.com/tLDP/LDP
Consolidated several sections together, hence the removal of several files. Creation of a seperate chapter on Layering
Binh.
This commit is contained in:
parent
e54d6e945a
commit
28e0702f8c
|
@ -1,21 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,10 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,15 +0,0 @@
|
||||||
<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>
|
|
File diff suppressed because it is too large
Load Diff
|
@ -1,106 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,48 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,58 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,262 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,65 +0,0 @@
|
||||||
<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:
|
|
||||||
|
|
||||||
· IPX router
|
|
||||||
· IPX bridge
|
|
||||||
· NCP client and/or NCP Server (for sharing files)
|
|
||||||
· Novell Print Client, Novell Print Server
|
|
||||||
|
|
||||||
And to:
|
|
||||||
|
|
||||||
· Enable PPP/IPX, allowing a Linux box to act as a PPP server/client
|
|
||||||
· 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>
|
|
|
@ -1,100 +0,0 @@
|
||||||
<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
|
|
||||||
¬ 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>
|
|
|
@ -0,0 +1,141 @@
|
||||||
|
<sect1 id="Foreward">
|
||||||
|
|
||||||
|
<title>Foreward</title>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Using a virtual machine concept, each layer is a virtual machine, with layer
|
||||||
|
one being the real machine. The top layer provides the highest level
|
||||||
|
functionality or the functions that are most abstracted from the physical
|
||||||
|
world. The top layer is directly interpreted by human beings. The bottom layer
|
||||||
|
provides the lowest level functionality, ie. it is strongly related to the
|
||||||
|
physical world and (preferably) is not interpreted by human beings.
|
||||||
|
|
||||||
|
In a layered model, entities forming the corresponding layers on different machines are
|
||||||
|
called peers and protocols forms a central part of network software. The layered approach
|
||||||
|
to networks and general software engineering principles adopted add to the structure
|
||||||
|
of network software. Each layer performs a small set of well defined functions (services)
|
||||||
|
required by the layer above it.
|
||||||
|
|
||||||
|
The layered approach offers a communication setting where layer n on one machine can have a
|
||||||
|
conversation with layer n on the other mahine. Layer n-protocol is essentially a set of rules
|
||||||
|
and conventions facilitating this conversation. This includes addressing and specification of
|
||||||
|
necessary DU's (Data Units).
|
||||||
|
|
||||||
|
You should note that this communication between layers is virtual. There is no physical or
|
||||||
|
direct communication between layers of two layer-n hosts. The actual communication takes
|
||||||
|
place at the lowest layer (usually called the physical layer). The conglomeration of layers
|
||||||
|
and corresponding layer protocols form a network architecture.
|
||||||
|
|
||||||
|
The general consensus in computing is that a typical data unit exchanged between systems
|
||||||
|
should consist of the address of the transmitting computer, the address of the receiving
|
||||||
|
computer, the actual data being transmitted, as well as a checksum.
|
||||||
|
|
||||||
|
This leads us to the problem of addressing. In order for computers to communicate properly
|
||||||
|
it was generally agreed by Ethernet card manufacturers that all NIC cards would possess a
|
||||||
|
48 bit unique address. This is called a MAC address but is often called the hardware address
|
||||||
|
of these cards. This aids portability and modularity of LAN (Local Area Network) technology and
|
||||||
|
software to a major extent. The data units here are called as frames. This is all you need
|
||||||
|
really to have a small network.
|
||||||
|
|
||||||
|
However, there exists a fundamental problem if you were to extend this idea to larger systems
|
||||||
|
(ie. greater than 100 nodes). It is extremely difficult to keep track of and maintain such a
|
||||||
|
network due to administrators having to keep track of the name of each and every system and
|
||||||
|
deciding what the name of new computers on the network will be.
|
||||||
|
|
||||||
|
For this reason, the idea of hostnames and network addresses were developed. For example,
|
||||||
|
on the LAN a computer may be called "computer" but on the internet it may be referred to
|
||||||
|
as "computer.network.com". The idea behind network addressing came to be known simply now
|
||||||
|
as IP (Internet Prococol) addressing.
|
||||||
|
|
||||||
|
You could say that the idea behind computer network addressing is roughly synonymous with that
|
||||||
|
of the rather mundane telephone network. To call a number in your region all you have to do
|
||||||
|
is dial that number. To call a number in another state you must add a number of other digits
|
||||||
|
to the start of the number. To call a number that is overseas you must add further digits
|
||||||
|
to the beginning of the now burgeoning number. The only difference between telephone and
|
||||||
|
network addressing is that you add numbers to the front rather than at the end of the address.
|
||||||
|
|
||||||
|
To this day, it has been found that by utilising so called layer architecture for networks,
|
||||||
|
suitable protocols and appropriate communication technologies the issues of network
|
||||||
|
application interfacing, network addressing and network functionality can be addressed
|
||||||
|
successfully.
|
||||||
|
|
||||||
|
There are eight main network technology issues that must be addressed at each layer in the
|
||||||
|
architecture though. These are outlined below:
|
||||||
|
|
||||||
|
1. Mechanism of identifying senders and receivers: addressing.
|
||||||
|
2. Rules for data transfer: simplex, half-duplex, or full-duplex.
|
||||||
|
3. Logical channels: sharing a link among a number of connections.
|
||||||
|
4. Error control strategies: correction and detection.
|
||||||
|
5. Sequencing protocols for the correct order of messages: put messages in the correct order.
|
||||||
|
6. Incompatible speed between fast sender and slow receiver.
|
||||||
|
7. Message fragmentation and assembly.
|
||||||
|
8. Strategies for choosing routes.
|
||||||
|
|
||||||
|
To study the above issues in detail please consult, Tannenbaum 4th edition.
|
||||||
|
|
||||||
|
These design issues become recurring themes that are usually addressed by each and every
|
||||||
|
layer in the architecture. As a stark example, although error detection and correction is
|
||||||
|
undertaken by the low level transmission protocol that sends characters from a terminal
|
||||||
|
to the display, the user will also implement error detection and correction at the highest
|
||||||
|
level by deleting an incorrect character and retyping.
|
||||||
|
|
||||||
|
A concept of an interface is central to layered network architecture. It is important
|
||||||
|
to recognise implementation and design issues and pertaining to interfaces of layers
|
||||||
|
and their respective functions and services.
|
||||||
|
|
||||||
|
- entity: in software, it is sometimes called a process; in hardware in hardware it
|
||||||
|
could mean in pratice an I/O chip
|
||||||
|
- peer enties: entities at the same layer in different machines/devices
|
||||||
|
- service provider: eg. layer n, a layer that provides a service
|
||||||
|
- service receiver: eg. layer n + 1, a layer that receives a service
|
||||||
|
- service access point (SAP): a point where service is accessed, for example a
|
||||||
|
function call in software, or the telephone for a telephone company
|
||||||
|
- protocol data unit (PDU): a data unit that is communicated between peer entities
|
||||||
|
- service data unit (SDU): the PDU from the serice receiver
|
||||||
|
- protocol control information (PCI): is appended by a service receiver to an SDU
|
||||||
|
in order to indicated the type of service required and forms the IDU
|
||||||
|
- interface data unit (IDU): the data unit that is given from a service receiver to
|
||||||
|
a service provider.
|
||||||
|
|
||||||
|
The term "service" can be deemed to mean a number of things. These are outlined
|
||||||
|
below.
|
||||||
|
|
||||||
|
Quality of Service: each service is chractereised by a quality of service. For example,
|
||||||
|
reliable service by such applications as file transfer - the data must be delivered
|
||||||
|
correctly but it may be unusually delayed. However, voice and video transmission may
|
||||||
|
allow some error in the data but does not allow delayed data.
|
||||||
|
|
||||||
|
Connection and connectionless services are the two fundamental categories. The
|
||||||
|
distinctions between them may be intuitive but there are subtle differences. For
|
||||||
|
example, a connection-orientated services allows two communicating parties to make
|
||||||
|
use of the connection in any way they like - a telephone connection can even be
|
||||||
|
used for transmitting fax and digital information as the service provider doesn't
|
||||||
|
process the communication at any point through the network.
|
||||||
|
|
||||||
|
However a connectionless services does not provide such a convenience because
|
||||||
|
for example a letter may be packaged and processed along the way, being stamped
|
||||||
|
for accounting, delivered using a car or plane, etc....
|
||||||
|
|
||||||
|
A service is formally specified by a set of primitives (operations) that define
|
||||||
|
the service interface. The primitives differ for different services. As a simple
|
||||||
|
example, a service may provide the following primitives:
|
||||||
|
|
||||||
|
1. LISTEN: listen for an incoming communication request
|
||||||
|
2. CONNECT: make a communication request
|
||||||
|
3. RECEIVE: receive data of a communication
|
||||||
|
4. SEND: send data of a communication
|
||||||
|
5. DISCONNECT: disconnect or discontinue a communication
|
||||||
|
|
||||||
|
As discussed before, each layer has specfic functions and offers certain services
|
||||||
|
to the layer above it. A service is a set of primitives (operations) that a layer
|
||||||
|
provides to the layer above it. In the definition of services, we do not specify
|
||||||
|
their implementation. The implementation is only visible to the provider of the
|
||||||
|
service.
|
||||||
|
|
||||||
|
A protocol defines the implementation of the service and is not visible to the
|
||||||
|
user of the service. A protocol is a set of rules governing the format and
|
||||||
|
meaning of the frames, packets, or messages within a layer and can be changed
|
||||||
|
at will by entities, provided that they do not change the service visible to their
|
||||||
|
users.
|
||||||
|
|
||||||
|
</sect1>
|
|
@ -1,487 +0,0 @@
|
||||||
<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>
|
|
||||||
|
|
||||||
· 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).
|
|
||||||
· A RS232 test plug may be handy for test purposes.
|
|
||||||
· 2 RJ11 cords, one for each end of the leased line.
|
|
||||||
· 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>
|
|
||||||
|
|
||||||
· Fixed baud rate (no auto baud)
|
|
||||||
· Hardware bidirectional RTS-CTS flow control (no x-on/x-off)
|
|
||||||
· 8 Bits, no parity, 1 stopbit
|
|
||||||
· The modem should produce the TRUE DCD status (&C1)
|
|
||||||
· 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>
|
|
||||||
|
|
||||||
· Reset on DTR toggle (&D3, this is sometimes a S register). This
|
|
||||||
setting is required by some ISP's!
|
|
||||||
· Leased line mode (&L1 or &L2, consult your modem documentation)
|
|
||||||
· The remote modem auto answer (S0=1), the local originate (S0=0)
|
|
||||||
· Disable result codes (Q1, sometimes the dumb mode does this for
|
|
||||||
you)
|
|
||||||
· 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>
|
|
||||||
|
|
||||||
· 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.
|
|
||||||
· If the remote system is down, pppd should wait until it is up
|
|
||||||
again.
|
|
||||||
· 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.
|
|
||||||
· If the quality of the link deteriorates too much, pppd should reset
|
|
||||||
the modem and then reestablish the link.
|
|
||||||
· 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
|
|
||||||
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>
|
|
|
@ -1,26 +0,0 @@
|
||||||
<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>
|
|
|
@ -1,192 +0,0 @@
|
||||||
<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>
|
|
||||||
|
|
||||||
· 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>
|
|
|
@ -1,16 +0,0 @@
|
||||||
<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).
|
|
||||||
|
|
||||||
· Linux PPP HOWTO <http://metalab.unc.edu/mdw/HOWTO/PPP-HOWTO.html>
|
|
||||||
|
|
||||||
· PPP/SLIP emulator <http://metalab.unc.edu/mdw/HOWTO/mini/SLIP-PPP-
|
|
||||||
Emulator.html>
|
|
||||||
|
|
||||||
</sect1>
|
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
@ -1,42 +0,0 @@
|
||||||
<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>
|
|
Loading…
Reference in New Issue