From 28e0702f8ca171e65f652db91c9dce399388a298 Mon Sep 17 00:00:00 2001 From: binh <> Date: Wed, 9 Feb 2005 13:29:44 +0000 Subject: [PATCH] Consolidated several sections together, hence the removal of several files. Creation of a seperate chapter on Layering Binh. --- .../Linux-Networking/DDS-Switched56.xml | 21 - LDP/guide/docbook/Linux-Networking/DECnet.xml | 10 - LDP/guide/docbook/Linux-Networking/DLC.xml | 15 - LDP/guide/docbook/Linux-Networking/Diald.xml | 1110 ------- LDP/guide/docbook/Linux-Networking/EQL.xml | 106 - .../docbook/Linux-Networking/Ethernet.xml | 48 - LDP/guide/docbook/Linux-Networking/FDDI.xml | 58 - .../docbook/Linux-Networking/Frame-Relay.xml | 262 -- LDP/guide/docbook/Linux-Networking/IPX.xml | 65 - LDP/guide/docbook/Linux-Networking/IPv6.xml | 100 - .../docbook/Linux-Networking/Layering.xml | 141 + .../docbook/Linux-Networking/Leased-Line.xml | 487 --- .../docbook/Linux-Networking/NetBEUI.xml | 26 - LDP/guide/docbook/Linux-Networking/PLIP.xml | 192 -- .../docbook/Linux-Networking/PPP-and-SLIP.xml | 16 - .../Protocols-and-Standards.xml | 2683 +++++++++++++++++ .../docbook/Linux-Networking/Token-Ring.xml | 1219 -------- LDP/guide/docbook/Linux-Networking/X25.xml | 42 - 18 files changed, 2824 insertions(+), 3777 deletions(-) delete mode 100644 LDP/guide/docbook/Linux-Networking/DDS-Switched56.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/DECnet.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/DLC.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/Diald.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/EQL.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/Ethernet.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/FDDI.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/Frame-Relay.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/IPX.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/IPv6.xml create mode 100644 LDP/guide/docbook/Linux-Networking/Layering.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/Leased-Line.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/NetBEUI.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/PLIP.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/PPP-and-SLIP.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/Token-Ring.xml delete mode 100644 LDP/guide/docbook/Linux-Networking/X25.xml diff --git a/LDP/guide/docbook/Linux-Networking/DDS-Switched56.xml b/LDP/guide/docbook/Linux-Networking/DDS-Switched56.xml deleted file mode 100644 index 752d0cb7..00000000 --- a/LDP/guide/docbook/Linux-Networking/DDS-Switched56.xml +++ /dev/null @@ -1,21 +0,0 @@ - - -DDS-Switched56 - - -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. - - - -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. - - - diff --git a/LDP/guide/docbook/Linux-Networking/DECnet.xml b/LDP/guide/docbook/Linux-Networking/DECnet.xml deleted file mode 100644 index bf429596..00000000 --- a/LDP/guide/docbook/Linux-Networking/DECnet.xml +++ /dev/null @@ -1,10 +0,0 @@ - - -DECnet - - -Support for DECnet is currently being worked on. You should expect it -to appear in a late 2.1.* kernel. - - - diff --git a/LDP/guide/docbook/Linux-Networking/DLC.xml b/LDP/guide/docbook/Linux-Networking/DLC.xml deleted file mode 100644 index bcf1ef96..00000000 --- a/LDP/guide/docbook/Linux-Networking/DLC.xml +++ /dev/null @@ -1,15 +0,0 @@ - - -DLC - - -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. - - - diff --git a/LDP/guide/docbook/Linux-Networking/Diald.xml b/LDP/guide/docbook/Linux-Networking/Diald.xml deleted file mode 100644 index f5b1b2ec..00000000 --- a/LDP/guide/docbook/Linux-Networking/Diald.xml +++ /dev/null @@ -1,1110 +0,0 @@ - - -Diald - - -The purpose of dial on demand is to make it transparently appear that -the users have a permanent connection to a remote site. Usually, -there is a daemon who monitors the traffic of packets and where an -interesting packet (interesting is defined usually by a set of -rules/priorities/permissions) arrives it establishes a connection with -the remote end. When the channel is idle for a certain period of time, -it drops the connection. - - - -This section shows some typical scenarios for easy start using Diald. -These scenarios include a connection from a standalone computer to an -ISP using PPP over a modem without using pon/poff or ppp-on/ppp-off to -a proxy/firewall server with different Internet connections through -various ISPs. - - - -Presently, the following scenarios will be treated: -· Connecting a standalone computer to an ISP using a modem and PPP -· Conecting a computer to a group of different ISPs with a modem and - PPP -· Connecting a proxy/firewall to an ISP using a modem and PPP - - - -However, in following versions of this document, other scenarios will be added, -as multiple instances of Diald, ISDN lines and lines used to call and -receive calls. - - - -Before this document, a Diald-mini-Howto exist, wrote by Harish Pillay -h.pillay@ieee.org, that presented and example of connection to an ISP -using a chat based authentication scheme (login and password previous -to the pppd start, with no use of PAP or CHAP). - - - -Example configuration files will be included in this document to serve -as starting point to get Diald up. To obtain maximum performance and -all programs attributes, it is necesary you read all documentation -from the programs and reconfigure the example configuration files -included here. - - - -Finally, configuration files can be in different directories depending -on what GNU/Linux distribution you are using. If you find a file -commented here in other directory, please, write me. - - - -3. Quick Diald operation description - -In a few words, Diald creates a new network interface and sets it as -the default gateway. This interface is not real (in the original -documentation it is called proxy interface). Diald monitors this -interface, and, when packets arrive, makes a ppp connection, waits for -it to be stablished and changes the default gateway to this new ppp -interface (usually ppp0). - - - -Diald monitors the interface to determine which packets have been -received the interface and their types to decide if they are going to -be considered to set the ppp connection up, maintain the link, drop it -or do nothing, and how long the link should be help up after the -packet is transmitted. - - - -Finally, if there is no more traffic and the last packet up time is -over, Diald will close the link. - - - -You can control days and hours when the link can go up and when it -cannot, so you can use the low cost hours/days or low trafic times. - - - -This previous description is valid for Diald versions from 0.16.5 to -latest (0.99.3 when this document was finished), but latest versions -also include aditional attributes such as user enabled list, advanced -accounting, better support for ISDN lines, better performance using an -ethertap device as proxy (this is like a network interface that -read/writes over a socket instead of a real network adapter) in place -of slip, backup connections and other functions. - - - -4. Note about authentication - -When you connect to an Internet Services Provider, it is usually -necesary that you send an username and a password. This can be -accomplished using several methods; the exact method that you use is -determined by your provider. - - - -Added to the three shown options, you can use a link without -authentication, (generally when the remote end is also yours). - - - -4.1. Username and password - Login and password prompts. - -Actually, this is not an usual authentication method to access the -Internet through an ISP. - - - -Identification is made before pppd is started, and it is the dialer, -usually chat, who sends the login name and the password. This data is -sent in plaintext, so this method should not be considered secure. - - - -An example script for chat where you can see how to specify username -and password to be sent before running pppd would look something like -this: - - - - - ABORT BUSY - ABORT "NO CARRIER" - ABORT VOICE - ABORT "NO DIALTONE" - ABORT "NO ANSWER" - "" ATZ - OK ATDT_TelephoneNumber_ - CONNECT \d\c - ogin _Username_ - assword _Password_ - - - - -The last 2 lines define username and password, and when to send it -(after receiving «ogin» and «assword» respectively. The chat script -only needs to see parts of the words «login» and «password» and so we -don't check the first letter of each. This is so that we don't need -to worry about uppercase/lowercase characters. - - - -Suppose that this script is called provider, and it is saved into the -/etc/chatscripts directory. Then, you can run it with: - - - - - /usr/sbin/chat -v -f /etc/chatscripts/provider - - - - -4.2. PAP - Password Authentication Protocol - -If the provider you are using requires PAP as the authentication -protocol, during the LCP negotiation in PPP this protocol will be -asked to use this protocol. When the phone call is connected after -using chat, pppd is started. In this scenario, pppd will send the -username and the password, which it will look for in the /etc/ppp/pap- -secrets file. This file must have read and write permissions only for -root only, so that nobody else can read the passwords inside it. - - - -PAP is not very secure, as the password is sent in plaintext, so can -be read by somebody that monitors your transmission line. - - - -Simple example of /etc/ppp/pap-secrets: - - - - - _Username_ * _Password_ - - - - -4.3. CHAP - Challenge Authentication Protocol - -If the provider you are using requires CHAP as the authentication -protocol, during the LCP negotiation in PPP this protocol will be -asked to use this protocol. When the phone call is connected after -using chat, pppd is started. In this scenario, pppd will send the -username and the password, which it will look for in the -/etc/ppp/chap-secrets file. This file must have read and write -permissions only for root only, so that nobody else can read the -passwords inside it. - - - -CHAP is more secure than PAP, as the password is never sent through -the transmission line in plaintext. The authentication server sends a -random identifier (the challenge), that the client must encrypt with -its password, and then send back to the server. - - - -Simple example of /etc/ppp/chap-secrets: - - - - - _Username_ * _Password_ - - - - -Sometimes an ISP uses PAP and other times CHAP, so it is common to -define your username and password in both files. - - - -5. Notes about DNS name resolution - -Everytime you connect to an ISP, it is necesary to have configured DNS -name resolution, so your computer can find IP addresses associated to -a computer name. - - - -IP addresses of your DNS servers are placed into the /etc/resolv.conf -file. - - - -In a standalone computer connecting to Internet, this file usually -contains the IP addresses of your ISP's DNS servers: - - - - - #/etc/resolv.conf file for ISPname - nameserver 111.222.333.444 - nameserver 222.333.444.555 - - - - -In a proxy/firewall computer, this file usually contains its own IP -address (or the loopback address, 127.0.0.1), and this computer -includes a DNS server that translates DNS names to IP addresses by -querying external DNS servers. - - - - - #/etc/resolv.conf file for local DNS resolution - nameserver 127.0.0.1 - - - - -Installation of a local DNS server is out of the scope of this -document. There is a lot of documentation about this, but a good and -quick approach can be found in the DNS-Howto -(http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html). - - - - 6. Connecting a standalone computer to an ISP using a modem and PPP - - When configuring Diald to connect your computer to an ISP, the next - steps will be necesary: - - · Getting the Diald package installed. The quickest way is to install - the package that comes with your GNU/Linux distribution. - · Configure DNS resolver (/etc/resolv.conf file). - · Check that you can call an ISP. If your GNU/Linux distribution - includes an utility to configure a connection, the quickest way - will be to use it (pppconfig in Debian, kppp if you use KDE, etc). - If you are having problems connecting to an ISP, the PPP-Howto - (http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html), Modem-Howto - (http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html) and Serial-Howto - (http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html) documents can - help you. - · Configure username and password in the /etc/ppp/pap-secrets and - /etc/ppp/chap-secrets files, as mentioned in previous sections. - - - - And finally, going into Diald: - - · Prepare the Diald configuration file (/etc/diald/diald.options for - version 0.16.5 and /etc/diald/diald.conf for later versions). - · Prepare filters file /etc/diald/standard.filter, or better, leave - that file as is, and modify a copy of it that you can call - /etc/diald/personal.filter. - · Prepare the script to make the call (/etc/diald/diald.connect with - execute permissions for root) and instruction file for chat - (/etc/chatscripts/provider), that will be used by the previous - script. - · Prepare scripts to be run when the link goes up and down - (/etc/diald/ip-up and /etc/diald/ip-down) if you want to use it - (both must have execute permissions for root). - · Prepare script to set and delete routes (/etc/diald/addroute and - /etc/diald/delroute) if you want (both must have execute - permissions for root). This step is not necesary if you only use a - single Diald instance. - · Finally, start the diald daemon («/etc/init.d/diald start» in - Debian, «/etc/rc.d/init.d/diald start» in RedHat). Normally, Diald - package installation process prepares the scripts to run Diald when - the computer boot up in the /etc/rcX.d directories. - - - -If you make any change in the Diald config file when it is running, it -is necesary to restart it («/etc/init.d/diald restart» in Debian, -«/etc/rc.d/init.d/diald restart» in RedHat). - - - - 6.1. /etc/diald/diald.options or diald.conf file - - In this example file you must check for: - · Comm port where your modem is connected. Option device. - · Comm port speed to talk with modem. Option speed. - · User name to be used in ppp. Option pppd-options. - · Retry counters and timers. - · Enabled connection hours. Options restrict. - · Decide if you want to use the ip-up and ip-down scripts. Options - ip-up and ip-down. - · Decide if you want to use the addroute and delroute scripts. - Options addroute and delroute. Generally it is not needed to modify - this scripts, but if you use more than one instance of Diald or - have a complex configuration, you need it. - · Decide if you use the standar or personal filter file. Options - include. - - - - - ########################## - # /etc/diald/diald.options - - # Device where your modem is connected - device /dev/ttyS0 - - # Log file - accounting-log /var/log/diald.log - - # Monitoring queue - #fifo /var/run/diald/diald.fifo - - # Debug activation - # Activating debug reduces performance - #debug 31 - - # We use PPP as encapsulator - mode ppp - - # Local IP (when you connect this address is automatically modified - # with the ip assigned by your ISP if you use the dinamic option). - local 127.0.0.5 - - # Remote IP (when you connect this address is automatically modified - # with the ip of the remote server that receives our call). - remote 127.0.0.4 - - # Subnet mask for the wan link - netmask 255.255.255.0 - - # The IP addresses will be asigned when connection starts. - dynamic - - # If link goes down by remote end, start it again only if there is - # outgoing packets. - two-way - - # When link is up, route directly to the real ppp interface, not the proxy - # interface. Not to do this is a performance lost of about 20 per cent. - # There are old kernels that do not support reroute. See diald manual for - # more information - reroute - - # Diald will set up the default route the the SLIP interface used as proxy - defaultroute - - # Script to set up personalized routes - #addroute "/etc/diald/addroute" - #delroute "/etc/diald/delroute" - - # Scripts to execute when the link is up and ready or down and closed. - # In Diald versions 0.9x there is another option called ip-goingdown that - # can be used to run commands when the link is going to be down but is - # still up. - ip-up /etc/diald/ip-up - #ip-down /etc/diald/ip-down - - # Scripts used to connect or disconnect the interface - connect "/etc/diald/diald.connect" - #disconnect "/etc/diald/diald.disconnect" - - # Use UUCP lock to signal the device is being used - #lock - - # We connect over a modem. WARNING: Do not especify this options in the - # ppp options file, because they will conflict with the diald options. To - # see what ppp options that you can not use in the pppd-options option, - # see the diald man page and search for pppd-options - modem - crtscts - speed 115200 - - # Some timers and retry options - # See Diald man page for more information - connect-timeout 120 - redial-timeout 60 - start-pppd-timeout 120 - died-retry-count 0 - redial-backoff-start 4 - redial-backoff-limit 300 - dial-fail-limit 10 - - # Options to be passed to pppd - # This options can be included in the /etc/ppp/options file, that are the - # default options for pppd, but if you need to use different - # configurations of diald for more than one instance, you must put it here - # noauth - do not ask remote for authenticaion. - # "Infovía Plus" (Spain) do not identify to our machine - # user - our username and isp. Ask your isp for the sintaxis. Some isps, - # do not need the @isp - pppd-options noauth user usuario@isp - - # Hour restriccions. - # This section must be before filters. - # The restrict command is experimental, and can change in other versions - # of diald. Check the man page. (this example has been checked for 0.16, - # but i think it runs in later versions). - # Example: only use in the night from monday to friday, and all day in - # saturday and sunday. - restrict 8:00:00 18:00:00 1-5 * * - down - restrict * * * * * - - # No special tarificaion considerations - # (first seconds included in the setup cost, tarify unit in seconds, - # time in seconds to check if it is good to go down) - #impulse 0,0,0 - # Bononet Noche (Spain-Telefónica) is billed in seconds after the 160 - # first seconds - impulse 160,0,0 - # if it would be billed in minuttes and the first 10 will be billed - # always: - #impulse 600,60,10 - - # Standar filters - #include /etc/diald/standard.filter - # or personal filters - include /etc/diald/personal.filter - - - - -6.2. Personal filters file - -Manipulation of this file must be done very carefully. This file is -used to decide when and why to start up the line, maintain it, bring -down the line or ignore a packet, depending on the traffic type. - - - -Generally, the Diald standar filter file is sufficient for most cases, -but perhaps, it may be too restrictive or not restrictive enough in -some situations. The personal.filter file that is shown has some -corrections over the original from the 0.16 version. - - - -In next versions of this document, other commented more restrictive -examples will be included. - - - - - # /etc/diald/personal.filter - # Filter rules shown are the same as in the standard.filter with the - # following changes: - # - # Change 10 to 4 minuttes in "any other tcp conection". - # Added "ignore tcp tcp.fin" to ignore the FIN ACK packets. - # Ignore icmp packets (ping and traceroute don't fire up the interface). - # - - # This is a pretty complicated set of filter rules. - # (These are the rules I use myself.) - # - # I've divided the rules up into four sections. - # TCP packets, UDP packets, ICMP packets and a general catch all rule - # at the end. - - ignore icmp any - - #------------------------------------------------------------------------------ - # Rules for TCP packets. - #------------------------------------------------------------------------------ - # General comments on the rule set: - # - # In general we would like to treat only data on a TCP link as significant - # for timeouts. Therefore, we try to ignore packets with no data. - # Since the shortest possible set of headers in a TCP/IP packet is 40 bytes, - # any packet with length 40 must have no data riding in it. - # We may miss some empty packets this way (optional routing information - # and other extras may be present in the IP header), but we should get - # most of them. Note that we don't want to filter out packets with - # tcp.live clear, since we use them later to speedup disconnects - # on some TCP links. - # - # We also want to make sure WWW packets live even if the TCP socket - # is shut down. We do this because WWW doesn't keep connections open - # once the data has been transfered, and it would be annoying to have the link - # keep bouncing up and down every time you get a document. - # - # Outside of WWW the most common use of TCP is for long lived connections, - # that once they are gone mean we no longer need the network connection. - # We don't neccessarily want to wait 10 minutes for the connection - # to go down when we don't have any telnet's or rlogin's running, - # so we want to speed up the timeout on TCP connections that have - # shutdown. We do this by catching packets that do not have the live flag set. - - # --- start of rule set proper --- - - # When initiating a connection we only give the link 15 seconds initially. - # The idea here is to deal with possibility that the network on the opposite - # end of the connection is unreachable. In this case you don't really - # want to give the link 10 minutes up time. With the rule below - # we only give the link 15 seconds initially. If the network is reachable - # then we will normally get a response that actually contains some - # data within 15 seconds. If this causes problems because you have a slow - # response time at some site you want to regularly access, you can either - # increase the timeout or remove this rule. - accept tcp 15 tcp.syn - - # Keep named xfers from holding the link up - ignore tcp tcp.dest=tcp.domain - ignore tcp tcp.source=tcp.domain - - # (Ack! SCO telnet starts by sending empty SYNs and only opens the - # connection if it gets a response. Sheesh..) - accept tcp 5 ip.tot_len=40,tcp.syn - - # keep empty packets from holding the link up (other than empty SYN packets) - ignore tcp ip.tot_len=40,tcp.live - - # Modification by Andres Seco to ignore the FIN ACK packets. - ignore tcp tcp.fin - - # make sure http transfers hold the link for 2 minutes, even after they end. - # NOTE: Your /etc/services may not define the tcp service www, in which - # case you should comment out the following two lines or get a more - # up to date /etc/services file. See the FAQ for information on obtaining - # a new /etc/services file. - accept tcp 120 tcp.dest=tcp.www - accept tcp 120 tcp.source=tcp.www - # Same for https - accept tcp 120 tcp.dest=tcp.443 - accept tcp 120 tcp.source=tcp.443 - - # Once the link is no longer live, we try to shut down the connection - # quickly. Note that if the link is already down, a state change - # will not bring it back up. - keepup tcp 5 !tcp.live - ignore tcp !tcp.live - - # an ftp-data or ftp connection can be expected to show reasonably frequent - # traffic. - accept tcp 120 tcp.dest=tcp.ftp - accept tcp 120 tcp.source=tcp.ftp - - #NOTE: ftp-data is not defined in the /etc/services file provided with - # the latest versions of NETKIT, so I've got this commented out here. - # If you want to define it add the following line to your /etc/services: - # ftp-data 20/tcp - # and uncomment the following two rules. - #accept tcp 120 tcp.dest=tcp.ftp-data - #accept tcp 120 tcp.source=tcp.ftp-data - - # If we don't catch it above, give the link 10 minutes up time. - #accept tcp 600 any - # Modificacion de Andres Seco. Solo dejar 4 minutos mas. - accept tcp 240 any - - # Rules for UDP packets - # - # We time out domain requests right away, we just want them to bring - # the link up, not keep it around for very long. - # This is because the network will usually come up on a call - # from the resolver library (unless you have all your commonly - # used addresses in /etc/hosts, in which case you will discover - # other problems.) - # Note that you should not make the timeout shorter than the time you - # might expect your DNS server to take to respond. Otherwise - # when the initial link gets established there might be a delay - # greater than this between the initial series of packets before - # any packets that keep the link up longer pass over the link. - - # Don't bring the link up for rwho. - ignore udp udp.dest=udp.who - ignore udp udp.source=udp.who - # Don't bring the link up for RIP. - ignore udp udp.dest=udp.route - ignore udp udp.source=udp.route - # Don't bring the link up for NTP or timed. - ignore udp udp.dest=udp.ntp - ignore udp udp.source=udp.ntp - ignore udp udp.dest=udp.timed - ignore udp udp.source=udp.timed - # Don't bring up on domain name requests between two running nameds. - ignore udp udp.dest=udp.domain,udp.source=udp.domain - # Bring up the network whenever we make a domain request from someplace - # other than named. - accept udp 30 udp.dest=udp.domain - accept udp 30 udp.source=udp.domain - # Do the same for netbios-ns broadcasts - # NOTE: your /etc/services file may not define the netbios-ns service - # in which case you should comment out the next three lines. - ignore udp udp.source=udp.netbios-ns,udp.dest=udp.netbios-ns - accept udp 30 udp.dest=udp.netbios-ns - accept udp 30 udp.source=udp.netbios-ns - # keep routed and gated transfers from holding the link up - ignore udp tcp.dest=udp.route - ignore udp tcp.source=udp.route - # Anything else gest 2 minutes. - accept udp 120 any - - # Catch any packets that we didn't catch above and give the connection - # 30 seconds of live time. - accept any 30 any - - - - - 6.3. Making the call - - /etc/diald/diald.connect file (it must have execute permission): - - - - - /usr/sbin/chat -f /etc/chatscripts/provider - - - - -/etc/chatscripts/provider file. In this example file you must check -the destination phone number: - - - - - ABORT BUSY - ABORT "NO CARRIER" - ABORT VOICE - ABORT "NO DIALTONE" - ABORT "NO ANSWER" - "" ATZ - OK ATDT123456789 - CONNECT \d\c - - - - -6.4. Connection start script - -It must have execute permission. - - - -This script can be used to many tasks (synchronize time, send the -queued mail, get incoming mail, etc.). - - - -In the example, a message is sent to root with data passed to the -script (interface, subnet mask, local ip address, remote ip address -and cost for routing): - - - - - #!/bin/sh - - iface=$1 - netmask=$2 - localip=$3 - remoteip=$4 - metric=$5 - - # Set the time and date - # netdate ntp.server.somecountry - - # Run the mail queue - # runq - - echo `date` $1 $2 $3 $4 $5 | mail -s "diald - conecting" root@localhost - - - - -7. Conecting a computer to a group of different ISPs with a modem and -PPP - -Many times, one standalone computer does not only connect to just one -network. It is common to connect to different networks or to the -Internet using some different service providers. In this case, -changing configuration files each time you want to connect to a -different site can be annoying. - - - -The solution i propose here consist in using different sets of -configuration files for each different connection. You can find here -some scripts to automate changing from one to another. - - - -7.1. Note about sending mail using a relay host - -If your email client program uses a local Message Transfer Agent with -a smtp relay host to send all messages, or if you use a email client -program that sends the messages directly to your provider's smtp -server, changing where you are connecting means you need to -reconfigure this option for the smtp relay server. This is because the -providers usually check if the receipt mailbox is local or to any -domain directly maintained by this provider or if the origin ip -address is from the range of ip addresses that this provider assigns, -to avoid having an open relay server that can be used to send spam, -anonymous message and so on. - - - -In the following examples, you will find how to change this parameter -in the Smail configuration files in a simple configuration where all -external messages are sent to a smtp relay server. If you use another -Message Transfer Agent (MTA) in your system, you can send me what you -must change in your MTA to include it here. If you use an email client -program that directly sends to the external smtp server (Kmail, -Netscape, etc.) send me your changes too. - - - -7.2. Scripts to automate multiple connections and changing from one -to another - - - -7.2.1. Starting up - -First of all, create a subdirectory of /etc/diald called providers -where you store your scripts to automatically change from one to -another provider and the subdirectories with the set of files to -configure each of the providers connections. - - - -With the next script this directory is created and filled with the -current configuration files from Diald, chat, pppd and Smail, that -will be treated as a template for the next configurations. - - - - - #!/bin/sh - #File /etc/diald/providers/setupdialdmultiprovider - mkdir /etc/diald/providers - mkdir /etc/diald/providers/setup - cp /etc/ppp/pap-secrets /etc/diald/providers/setup - cp /etc/ppp/chap-secrets /etc/diald/providers/setup - cp /etc/resolv.conf /etc/diald/providers/setup - cp /etc/diald/diald.options /etc/diald/providers/setup - cp /etc/diald/standard.filter /etc/diald/providers/setup - cp /etc/diald/personal.filter /etc/diald/providers/setup - cp /etc/diald/diald.connect /etc/diald/providers/setup - cp /etc/chatscripts/provider /etc/diald/providers/setup - cp /etc/diald/ip-up /etc/diald/providers/setup - cp /etc/diald/ip-down /etc/diald/providers/setup - cp /etc/smail/routers /etc/diald/providers/setup - - - - - 7.2.2. New provider - - With the next script the template configuration will be copied to a - new directory to prepare it for a new provider connection or a new net - connection. This script (/etc/diald/providers/newdialdprovider) will - need a parameter with the provider or net name. - - - - - #!/bin/sh - #File /etc/diald/providers/newdialdprovider - mkdir /etc/diald/providers/$1 - cp /etc/diald/providers/setup/* /etc/diald/providers/$1 - - - - -Now, you will modify as you need the new files in -/etc/diald/providers/provdidername, being providername the parameter -passed to newdialdprovider. - - - -7.2.3. Changing from one to another - -At the end, with this script you will change all your configuration -files related to Diald to connect to another provider or net. I use -symbolic links to avoid using duplicate files. Using symbolic links, -if you change any config file in its original location like -/etc/resolv.conf, the change is really made in the -/etc/diald/providers/providername/resolv.conf file. - - - - - #!/bin/sh - #File /etc/diald/providers/setdialdprovider - /etc/init.d/diald stop - #wait for Diald to stop. - sleep 4 - ln -sf /etc/diald/providers/$1/pap-secrets /etc/ppp - ln -sf /etc/diald/providers/$1/chap-secrets /etc/ppp - ln -sf /etc/diald/providers/$1/resolv.conf /etc - ln -sf /etc/diald/providers/$1/diald.options /etc/diald - ln -sf /etc/diald/providers/$1/standard.filter /etc/diald - ln -sf /etc/diald/providers/$1/personal.filter /etc/diald - ln -sf /etc/diald/providers/$1/diald.connect /etc/diald - ln -sf /etc/diald/providers/$1/provider /etc/chatscripts - ln -sf /etc/diald/providers/$1/ip-up /etc/diald - ln -sf /etc/diald/providers/$1/ip-down /etc/diald - ln -sf /etc/diald/providers/$1/routers /etc/smail - /etc/init.d/diald start - - - - -8. Connecting a proxy/firewall to an ISP using a modem and PPP - -Connecting a private net to the Internet with dedicated server which -handles packet routing from the local network to the Internet along -with proxy/caching services and security firewalling is a complex -theme that is beyond the scope of this document. There are other -«Howto» documents that handle these topics much more comprehensively. -At the end of this document you can find a list of links and -references to such documents. - - - -Here, we are only configuring Diald supposing that the computer -already uses IP-Masquerading, has a web proxy like Squid or similar -working, an ISP connection correctly configured and that access -security to TCP/UDP ports have been revised (/etc/inetd.conf file and -others like securetty, host.allow, etc). - - - -Basically, the only need is to reconfigure the rules for -masquerading/filtering/accessing each time the set of interfaces -change, that is, when the interface ppp0 is stablished and when it is -deleted. A good location to do that are the ip-up and ip-down scripts -from pppd. - - - -8.1. Example for Debian 2.1 - -With Debian, it is sufficient to install the ipmasq package answering -that you want to change rules sinchronously with pppd when seting it -up. Two scripts will be created inside /etc/ppp/ip-up.d and -/etc/ppp/ip-down.d directories to call /sbin/ipmasq, a script that -analizes existing interfaces and makes a simple configuration that is -valid in many cases, but you can personalize it using rule files in -/etc/ipmasq/rules. - - - -The only correction after installing this package is to change when -the startup script for ipmasq is run, deleting the symbolic link from -/etc/rcS.d and creating a new one in /etc/rc2.d to run it after -S20diald. Now, when ipmasq is executed to analyze interfaces sl0 -already exist. S90ipmasq is a good name for this symbolic link to -/etc/init.d/ipmasq. - - - -Using Debian there is no need to worry about the kernel version, as -the /sbin/ipmasq script uses ipfwadm or ipchains as needed. -8.2. Example for Suse 6.1 - - - -This example is from Mr Cornish Rex, troll@tnet.com.au. - - - -The following ip-masp and routing control commands are for use with -version 2.2 kernels, using ipchains, but they are not valid for -version 2.0 kernels. - - - -We are going to supose that the ethernet interface has the 192.168.1.1 -ip address with 16 bit netmask, that is, 255.255.0.0. - - - -This is the /etc/ppp/ip-up file: - - - - - #!/bin/sh - # $1 = Interface - # $2 = Tty device - # $3 = speed - # $4 = local ip - # $5 = remote ip - # $6 = ipparam - /sbin/ipchains -F input - /sbin/ipchains -P input DENY - /sbin/ipchains -A input -j ACCEPT -i eth0 -s 192.168.0.0/16 -d 0.0.0.0/0 - /sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 0:52 -l - /sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 54:1023 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 0:112 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 114:1023 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 6000:6010 -l - /sbin/ipchains -A input -j DENY -p icmp --icmp-type echo-request \ - -i $1 -s 0.0.0.0/0 -l - /sbin/ipchains -A input -j DENY -p icmp -f -i $1 -s 0.0.0.0/0 -l - /sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 5555 -l - /sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 8000 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 8000 -l - /sbin/ipchains -A input -j DENY -p udp -i $1 -s 0.0.0.0/0 -d $4/32 6667 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 6667 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 4557 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 4559 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 4001 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 2005 -l - /sbin/ipchains -A input -j DENY -p tcp -i $1 -s 0.0.0.0/0 -d $4/32 6711 -l - /sbin/ipchains -A input -j DENY -i $1 -s 192.168.0.0/16 -d 0.0.0.0/0 -l - /sbin/ipchains -A input -j ACCEPT -i $1 -s 0.0.0.0/0 -d $4/32 - /sbin/ipchains -A input -j ACCEPT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 - /sbin/ipchains -A input -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 -l - - /sbin/ipchains -F output - /sbin/ipchains -P output DENY - /sbin/ipchains -A output -j ACCEPT -i eth0 -s 0.0.0.0/0 -d 192.168.0.0/16 - /sbin/ipchains -A output -j DENY -i $1 -s 192.168.0.0/16 -d 0.0.0.0/0 -l - /sbin/ipchains -A output -j ACCEPT -i $1 -s $4/32 -d 0.0.0.0/0 - /sbin/ipchains -A output -j ACCEPT -i lo -s 0.0.0.0/0 -d 0.0.0.0/0 - /sbin/ipchains -A output -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 - - /sbin/ipchains -F forward - /sbin/ipchains -P forward DENY - /sbin/ipchains -M -S 120 120 120 - /sbin/ipchains -A forward -j MASQ -s 192.168.1.0/24 - /sbin/ipchains -A forward -j DENY -s 0.0.0.0/0 -d 0.0.0.0/0 - - exit 0 - - - - -This is the /etc/ppp/ip-down file: - - - - - #!/bin/sh - # $1 = Interface - # $2 = Tty device - # $3 = Speed - # $4 = Local ip - # $5 = Remote ip - /sbin/ipchains -F input - /sbin/ipchains -F output - /sbin/ipchains -F forward - /sbin/ipchains-restore < /etc/ppp/orig.chains - - - - -Last file in last script, orig.chains, is the following file (original -status of ipchains): - - - - - # orig.chains - # created with: ipchains-save > orig.chains - :input ACCEPT - :forward ACCEPT - :output ACCEPT - -A input -s 0.0.0.0/0.0.0.0 -d 192.168.1.1/255.255.255.255 - -A output -s 192.168.1.1/255.255.255.255 -d 0.0.0.0/0.0.0.0 - - - - -8.3. Example for Slackware 3.6 - -This example is from Hoo Kok Mun, hkmun@pacific.net.sg. - - - -This is the most simple example i have seen, but fully functional. -From the beginning, this example configures masquerading, before the -sl0 interface exists, and it does not change when the ppp0 interface -appears. If you need advanced security considerations, it may be a -little limited. - - - - - #/etc/rc.d/rc.local - /sbin/ipfwadm -F -p deny - /sbin/ipfwadm -F -a m -S 192.168.0.0/24 -D 0.0.0.0/0 - - - - -As you can see, it is for version 2.0 kernels. - - - -9. Programs and versions used -To write this document i have used the following diald versions: -· Diald 0.16.5 - Last version maintained by the original diald autor. -· Diald 0.99.3 - Last version until the first edition of this -document. - - - -And the following pppd versions: -· pppd 2.3.5 - - - -Diald 0.16.5 version is perhaps the most extended, and the one that -many Linux distributions include. It is suficient for many sites, and -it is very reliable, but, of course, later versions have many -interesting capabilites. - - - -10. More information -Original information from where this document has been obtained can be -found in the man pages about diald, diald-examples, diald-control, -diald-monitor, dctrl, pppd, chat, as well as from information in the -/usr/doc directories and in web pages of this packages: - - · New Diald Official Home Page: http://diald.sourceforge.net/ - · Download of new versions: ftp://diald.sourceforge.net/pub/diald/ - · Previous Diald home page: http://diald.unix.ch - · Old Diald home page until 0.16.5 version: - http://www.loonie.net/~erics/diald.html - · pppd FTP site: ftp://cs.anu.edu.au/pub/software/ppp/ - · Other site: http://www.p2sel.com/diald - · One more: http://rufus.w3.org/linux/RPM/ - - - -There is a mailing list for discussion about diald on David S. -Miller's mailing list server at vger.rutgers.edu. To subscribe, send a -message to Majordomo@vger.rutgers.edu with the text «subscribe linux- -diald» IN THE MESSAGE BODY. - - - -An archive of the list can be found in http://www.geocrawler.com. - - - -There are also multiple RFC documents (Request For Comments) that -define how the PPP encapsulated lines and its associated protocols -(LCP, IPCP, PAP, CHAP, ...) must work. You can find these documents in -the /usr/doc/doc-rfc directory and some World Wide Web sites, like -http://metalab.unc.edu and http://nic.mil/RFC. You can ask for -information about RFCs in RFC-INFO@ISI.EDU. - - - -The following «Howtos» can help you: -· DNS-HOWTO - http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html -· Firewall-HOWTO - http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html -· IP-Masquerade-HOWTO - http://www.linuxdoc.org/HOWTO/IP-Masquerade- -HOWTO.html -· IPCHAINS-HOWTO - http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.html -· Modem-HOWTO - http://www.linuxdoc.org/HOWTO/Modem-HOWTO.html -· NET3-4-HOWTO - http://www.linuxdoc.org/HOWTO/NET3-4-HOWTO.html -· PPP-HOWTO - http://www.linuxdoc.org/HOWTO/PPP-HOWTO.html -· Serial-HOWTO - http://www.linuxdoc.org/HOWTO/Serial-HOWTO.html - - - diff --git a/LDP/guide/docbook/Linux-Networking/EQL.xml b/LDP/guide/docbook/Linux-Networking/EQL.xml deleted file mode 100644 index 39cf772d..00000000 --- a/LDP/guide/docbook/Linux-Networking/EQL.xml +++ /dev/null @@ -1,106 +0,0 @@ - - -EQL - - -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. - - - -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. - - - - - Kernel Compile Options: - - Network device support ---> - [*] Network device support - <*> EQL (serial line load balancing) support - - - - -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. - - - -To configure EQL you will need the EQL tools which are available from: -metalab.unc.edu. - - - -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: - - - - - root# ifconfig eql 192.168.10.1 mtu 1006 - - - - -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. - - - -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: - - - - - root# eql_enslave eql sl0 28800 - root# eql_enslave eql ppp0 14400 - - - - -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. - - - -To disassociate a line from an EQL device you use the eql_emancipate -command as shown: - - - - - root# eql_emancipate eql sl0 - - - - -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: - - - - - root# route add default eql - - - - -The EQL driver was developed by Simon Janes, simon@ncm.com. - - - diff --git a/LDP/guide/docbook/Linux-Networking/Ethernet.xml b/LDP/guide/docbook/Linux-Networking/Ethernet.xml deleted file mode 100644 index 84b6f161..00000000 --- a/LDP/guide/docbook/Linux-Networking/Ethernet.xml +++ /dev/null @@ -1,48 +0,0 @@ - - -Ethernet - -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 - - - diff --git a/LDP/guide/docbook/Linux-Networking/FDDI.xml b/LDP/guide/docbook/Linux-Networking/FDDI.xml deleted file mode 100644 index 4faf4cb5..00000000 --- a/LDP/guide/docbook/Linux-Networking/FDDI.xml +++ /dev/null @@ -1,58 +0,0 @@ - - -FDDI - - -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). - - - -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. - - - -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. - - - -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. - - - -Larry Stefani, lstefani@ultranet.com, has developed a driver for the -Digital Equipment Corporation FDDI EISA and PCI cards. - - - -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. - - - - - Kernel Compile Options: - - Network device support ---> - [*] FDDI driver support - [*] Digital DEFEA and DEFPA adapter support - - - - diff --git a/LDP/guide/docbook/Linux-Networking/Frame-Relay.xml b/LDP/guide/docbook/Linux-Networking/Frame-Relay.xml deleted file mode 100644 index 2d730885..00000000 --- a/LDP/guide/docbook/Linux-Networking/Frame-Relay.xml +++ /dev/null @@ -1,262 +0,0 @@ - - -Frame-Relay - - -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. - - - -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. - - - -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. - - - -The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI -encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s). - - - - - 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 - - - - -Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay -support and configuration tools. - - - -Currently the only FRAD supported are the Sangoma Technologies S502A, -S502E and S508. - - - -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: - - - - - 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 - - - - -Note that the previous commands use sh syntax, if you use a csh -flavour instead (like tcsh), the for loop will look different. - - - -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: - - - - - # /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_] - # - - [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 - - - - -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: - - - - - #!/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 - # - - - - diff --git a/LDP/guide/docbook/Linux-Networking/IPX.xml b/LDP/guide/docbook/Linux-Networking/IPX.xml deleted file mode 100644 index a3b5a283..00000000 --- a/LDP/guide/docbook/Linux-Networking/IPX.xml +++ /dev/null @@ -1,65 +0,0 @@ - - -IPX - - -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. - - - -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. - - - -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. - - - - 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 - - - How do I configure the kernel for IPX networking support? - - - IPX ( AF_IPX ) - Kernel Compile Options: - - Networking options ---> - [*] The IPX protocol - [ ] Full internal IPX network - - - -* IPX-SPX HOWTO - - diff --git a/LDP/guide/docbook/Linux-Networking/IPv6.xml b/LDP/guide/docbook/Linux-Networking/IPv6.xml deleted file mode 100644 index 5805a8f9..00000000 --- a/LDP/guide/docbook/Linux-Networking/IPv6.xml +++ /dev/null @@ -1,100 +0,0 @@ - - -IPv6 - - - -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 -+ * - - -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. ------------------------------------------------------------------------------ - - diff --git a/LDP/guide/docbook/Linux-Networking/Layering.xml b/LDP/guide/docbook/Linux-Networking/Layering.xml new file mode 100644 index 00000000..0fb95e83 --- /dev/null +++ b/LDP/guide/docbook/Linux-Networking/Layering.xml @@ -0,0 +1,141 @@ + + +Foreward + + +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. + + diff --git a/LDP/guide/docbook/Linux-Networking/Leased-Line.xml b/LDP/guide/docbook/Linux-Networking/Leased-Line.xml deleted file mode 100644 index 10eae53f..00000000 --- a/LDP/guide/docbook/Linux-Networking/Leased-Line.xml +++ /dev/null @@ -1,487 +0,0 @@ - - -Leased-Line - -_______________________________________________________________________________ - - -Configuring your modem and pppd to use a 2 wire twisted pair leased -line. - - -1.2. What is a leased line - - -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. - - - - This document deals with: - Configuring your modem and pppd to use a 2 wire twisted pair - leased line. - - - - This document does NOT deal with: - SLIP, getting or installing pppd, synchronous data - communication, baseband modems, xDSL. - - -1.3. Assumptions - - -You should already have a working pppd on your system. You also need -Minicom or a similar program to configure your modems. - - -2. Modem - - -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. - - - -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: - - -· 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 - - -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. - - - -Most programs require you to use the following settings; - - -· 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) - - -Check this with AT&V or AT&Ix (consult your modem documentation) - - - -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. - - - -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). - - - -Now configure your modem as follows; - - -· 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). - - -Write the configuration to non-volatile memory (&W). - - -2.2. Test - - -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. - - - -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). - - -2.3. Examples - -2.3.1. Hi-Tech - - -This is a rather vague `no name clone modem'. Its config string is -however typical and should work on most modems. - - - - Originate (local): - ATL1&C1&D3&L2%D1&W&W1 - - - - Answer (remote): - ATM0L1&C1&D3&L2%D1S0=1&W&W1 - - -2.3.2. Tornado FM 228 E - - -This is what should work; - - - - Originate (local): - ATB15L1Q1&C1&D3&L2&W&W1 - - - - Answer (remote): - ATM0B15M0Q1&C1&D3&L2S0=1&W&W1 - - - -Move the dumb jumper from position 2-3 to 1-2. - - - -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. - - -2.3.3. Tron DF - - -The ESC char should be disabled by setting S2 > 127; - - - - Originate: - ATL1&L1Q1&C1&D3S2=171\D1&W - - - - Answer: - ATM0&L2Q1&C1&D3S0=1S2=171\D1&W - - -2.3.4. US Robotics Courier V-Everything - - -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. - - - -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: - - - - 3 OFF Disable result codes - 4 ON Disable offline commands - 5 ON For originate, OFF For answer - 8 OFF Dumb mode - - -3. PPPD - - -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. - - - -For a reliable link, your setup should meet the following criteria; - - -· 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 - - -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: - - - - -crtscts -mru 576 -mtu 576 -passive -Loc_Ip:Rem_Ip --chap -modem -#noauth --pap -persist - - - - -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: - - - - - crtscts - mru 576 - mtu 576 - passive - 192.168.1.1:10.1.1.1 - -chap - modem - #noauth - -pap - persist - - - - -The options.ttyS1 on the remote system would be: - - - - - crtscts - mru 576 - mtu 576 - passive - 10.1.1.1:192.168.1.1 - -chap - modem - #noauth - -pap - persist - - - - -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. - - -3.2. Scripts - -3.2.1. Starting the pppd and keeping it alive - - -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; - - - - - s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200 - - - - -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'. - - - -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. - - -3.2.2. Setting the routes - - -The default route can be set with the defaultroute option or with the -/etc/ppp/ip-up script; - - - - - #!/bin/bash - case $2 in - /dev/ttyS1) - /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0 - ;; - esac - - - - -Ip-up can also be used to sync your clock using netdate. - - - -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; - - - - - #!/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 - - - - -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. - - -3.3. Test - - -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! - - - - - -T1-T4 - -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. - - - - -Carrier Channels Total Bandwidth -T1 24 1.544 Mbps -T2 96 6.312 Mbps -T3 672 44.736 Mbps -T4 4032 274.176 Mbps - - - - -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. - - -SONET (Synchronous Optical Network) - -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. - - - diff --git a/LDP/guide/docbook/Linux-Networking/NetBEUI.xml b/LDP/guide/docbook/Linux-Networking/NetBEUI.xml deleted file mode 100644 index 5b9d6ee6..00000000 --- a/LDP/guide/docbook/Linux-Networking/NetBEUI.xml +++ /dev/null @@ -1,26 +0,0 @@ - - -NetBEUI - - -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. - - - -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. - - - -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. - - - diff --git a/LDP/guide/docbook/Linux-Networking/PLIP.xml b/LDP/guide/docbook/Linux-Networking/PLIP.xml deleted file mode 100644 index d81f8e51..00000000 --- a/LDP/guide/docbook/Linux-Networking/PLIP.xml +++ /dev/null @@ -1,192 +0,0 @@ - - -PLIP - - -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. - - -7.2. PLIP for Linux-2.0 - - -PLIP device names are `plip0', `plip1 and plip2. - - - - - Kernel Compile Options: - - Network device support ---> - <*> PLIP (parallel port) support - - - - -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. - - - -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. - - - -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. - - - -In the 2.0.* series kernel the plip devices are mapped to i/o port and -IRQ as follows: - - - - - device i/o IRQ - ------ ----- --- - plip0 0x3bc 5 - plip1 0x378 7 - plip2 0x278 2 - - - - -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: - - - - - root# insmod plip.o io=0x288 irq=5 - - - - -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. - - - -To configure a plip interface, you will need to invoke the following -commands (or add them to your initialization scripts): - - - - - root# /sbin/ifconfig plip1 localplip pointopoint remoteplip - root# /sbin/route add remoteplip plip1 - - - - -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: - - - - - # plip entries - 192.168.3.1 localplip - 192.168.3.2 remoteplip - - - - -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. - - - -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. - - - -Further information on PLIP may be obtained from the ``PLIP mini- -HOWTO''. - - -7.3. PLIP for Linux-2.2 - - -During development of the 2.1 kernel versions, support for the -parallel port was changed to a better setup. - - - - - Kernel Compile Options: - - General setup ---> - [*] Parallel port support - Network device support ---> - <*> PLIP (parallel port) support - - - - -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. - - - -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. - - - -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. - - - -Complete information about parallel port management is available in -the file Documentation/parport.txt, part of your kernel sources. - - -· PLIP information can be found in The Network Administrator Guide - - -PLIP allows the cheap connection of two machines. -It uses a parallel port and a special cable, achieving speeds of -10kBps to 20kBps. - - diff --git a/LDP/guide/docbook/Linux-Networking/PPP-and-SLIP.xml b/LDP/guide/docbook/Linux-Networking/PPP-and-SLIP.xml deleted file mode 100644 index 9c99ec31..00000000 --- a/LDP/guide/docbook/Linux-Networking/PPP-and-SLIP.xml +++ /dev/null @@ -1,16 +0,0 @@ - - -PPP and SLIP - - -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 - -· PPP/SLIP emulator - - diff --git a/LDP/guide/docbook/Linux-Networking/Protocols-and-Standards.xml b/LDP/guide/docbook/Linux-Networking/Protocols-and-Standards.xml index 5e39c114..93f9baf1 100644 --- a/LDP/guide/docbook/Linux-Networking/Protocols-and-Standards.xml +++ b/LDP/guide/docbook/Linux-Networking/Protocols-and-Standards.xml @@ -627,3 +627,2686 @@ http://lrcwww.epfl.ch + + + +DDS-Switched56 + + +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. + + + +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. + + + + + + +DECnet + + +Support for DECnet is currently being worked on. You should expect it +to appear in a late 2.1.* kernel. + + + + + + +DLC + + +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. + + + + + + +EQL + + +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. + + + +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. + + + + + Kernel Compile Options: + + Network device support ---> + [*] Network device support + <*> EQL (serial line load balancing) support + + + + +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. + + + +To configure EQL you will need the EQL tools which are available from: +metalab.unc.edu. + + + +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: + + + + + root# ifconfig eql 192.168.10.1 mtu 1006 + + + + +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. + + + +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: + + + + + root# eql_enslave eql sl0 28800 + root# eql_enslave eql ppp0 14400 + + + + +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. + + + +To disassociate a line from an EQL device you use the eql_emancipate +command as shown: + + + + + root# eql_emancipate eql sl0 + + + + +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: + + + + + root# route add default eql + + + + +The EQL driver was developed by Simon Janes, simon@ncm.com. + + + + + + +Ethernet + +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 + + + + + +FDDI + + +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). + + + +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. + + + +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. + + + +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. + + + +Larry Stefani, lstefani@ultranet.com, has developed a driver for the +Digital Equipment Corporation FDDI EISA and PCI cards. + + + +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. + + + + + Kernel Compile Options: + + Network device support ---> + [*] FDDI driver support + [*] Digital DEFEA and DEFPA adapter support + + + + + + + +Frame-Relay + + +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. + + + +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. + + + +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. + + + +The Frame Relay device names are `dlci00', `dlci01' etc for the DLCI +encapsulation devices and `sdla0', `sdla1' etc for the FRAD(s). + + + + + 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 + + + + +Mike McLagan, mike.mclagan@linux.org, developed the Frame Relay +support and configuration tools. + + + +Currently the only FRAD supported are the Sangoma Technologies S502A, +S502E and S508. + + + +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: + + + + + 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 + + + + +Note that the previous commands use sh syntax, if you use a csh +flavour instead (like tcsh), the for loop will look different. + + + +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: + + + + + # /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_] + # + + [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 + + + + +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: + + + + + #!/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 + # + + + + + + + +NetBEUI + + +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. + + + +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. + + + +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. + + + + + + +IPX + + +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. + + + +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. + + + +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. + + + + 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 + + + How do I configure the kernel for IPX networking support? + + + IPX ( AF_IPX ) + Kernel Compile Options: + + Networking options ---> + [*] The IPX protocol + [ ] Full internal IPX network + + + +* IPX-SPX HOWTO + + + + + +Leased-Line + +_______________________________________________________________________________ + + +Configuring your modem and pppd to use a 2 wire twisted pair leased +line. + + +1.2. What is a leased line + + +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. + + + + This document deals with: + Configuring your modem and pppd to use a 2 wire twisted pair + leased line. + + + + This document does NOT deal with: + SLIP, getting or installing pppd, synchronous data + communication, baseband modems, xDSL. + + +1.3. Assumptions + + +You should already have a working pppd on your system. You also need +Minicom or a similar program to configure your modems. + + +2. Modem + + +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. + + + +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: + + +· 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 + + +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. + + + +Most programs require you to use the following settings; + + +· 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) + + +Check this with AT&V or AT&Ix (consult your modem documentation) + + + +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. + + + +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). + + + +Now configure your modem as follows; + + +· 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). + + +Write the configuration to non-volatile memory (&W). + + +2.2. Test + + +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. + + + +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). + + +2.3. Examples + +2.3.1. Hi-Tech + + +This is a rather vague `no name clone modem'. Its config string is +however typical and should work on most modems. + + + + Originate (local): + ATL1&C1&D3&L2%D1&W&W1 + + + + Answer (remote): + ATM0L1&C1&D3&L2%D1S0=1&W&W1 + + +2.3.2. Tornado FM 228 E + + +This is what should work; + + + + Originate (local): + ATB15L1Q1&C1&D3&L2&W&W1 + + + + Answer (remote): + ATM0B15M0Q1&C1&D3&L2S0=1&W&W1 + + + +Move the dumb jumper from position 2-3 to 1-2. + + + +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. + + +2.3.3. Tron DF + + +The ESC char should be disabled by setting S2 > 127; + + + + Originate: + ATL1&L1Q1&C1&D3S2=171\D1&W + + + + Answer: + ATM0&L2Q1&C1&D3S0=1S2=171\D1&W + + +2.3.4. US Robotics Courier V-Everything + + +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. + + + +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: + + + + 3 OFF Disable result codes + 4 ON Disable offline commands + 5 ON For originate, OFF For answer + 8 OFF Dumb mode + + +3. PPPD + + +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. + + + +For a reliable link, your setup should meet the following criteria; + + +· 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 + + +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: + + + + +crtscts +mru 576 +mtu 576 +passive +Loc_Ip:Rem_Ip +-chap +modem +#noauth +-pap +persist + + + + +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: + + + + + crtscts + mru 576 + mtu 576 + passive + 192.168.1.1:10.1.1.1 + -chap + modem + #noauth + -pap + persist + + + + +The options.ttyS1 on the remote system would be: + + + + + crtscts + mru 576 + mtu 576 + passive + 10.1.1.1:192.168.1.1 + -chap + modem + #noauth + -pap + persist + + + + +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. + + +3.2. Scripts + +3.2.1. Starting the pppd and keeping it alive + + +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; + + + + + s1:23:respawn:/usr/sbin/pppd /dev/ttyS1 115200 + + + + +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'. + + + +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. + + +3.2.2. Setting the routes + + +The default route can be set with the defaultroute option or with the +/etc/ppp/ip-up script; + + + + + #!/bin/bash + case $2 in + /dev/ttyS1) + /sbin/route add -net 0.0.0.0 gw Rem_Ip netmask 0.0.0.0 + ;; + esac + + + + +Ip-up can also be used to sync your clock using netdate. + + + +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; + + + + + #!/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 + + + + +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. + + +3.3. Test + + +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! + + + + + +T1-T4 + +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. + + + + +Carrier Channels Total Bandwidth +T1 24 1.544 Mbps +T2 96 6.312 Mbps +T3 672 44.736 Mbps +T4 4032 274.176 Mbps + + + + +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. + + +SONET (Synchronous Optical Network) + +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. + + + + + + +PLIP + + +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. + + +7.2. PLIP for Linux-2.0 + + +PLIP device names are `plip0', `plip1 and plip2. + + + + + Kernel Compile Options: + + Network device support ---> + <*> PLIP (parallel port) support + + + + +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. + + + +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. + + + +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. + + + +In the 2.0.* series kernel the plip devices are mapped to i/o port and +IRQ as follows: + + + + + device i/o IRQ + ------ ----- --- + plip0 0x3bc 5 + plip1 0x378 7 + plip2 0x278 2 + + + + +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: + + + + + root# insmod plip.o io=0x288 irq=5 + + + + +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. + + + +To configure a plip interface, you will need to invoke the following +commands (or add them to your initialization scripts): + + + + + root# /sbin/ifconfig plip1 localplip pointopoint remoteplip + root# /sbin/route add remoteplip plip1 + + + + +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: + + + + + # plip entries + 192.168.3.1 localplip + 192.168.3.2 remoteplip + + + + +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. + + + +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. + + + +Further information on PLIP may be obtained from the ``PLIP mini- +HOWTO''. + + +7.3. PLIP for Linux-2.2 + + +During development of the 2.1 kernel versions, support for the +parallel port was changed to a better setup. + + + + + Kernel Compile Options: + + General setup ---> + [*] Parallel port support + Network device support ---> + <*> PLIP (parallel port) support + + + + +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. + + + +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. + + + +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. + + + +Complete information about parallel port management is available in +the file Documentation/parport.txt, part of your kernel sources. + + +· PLIP information can be found in The Network Administrator Guide + + +PLIP allows the cheap connection of two machines. +It uses a parallel port and a special cable, achieving speeds of +10kBps to 20kBps. + + + + + +PPP and SLIP + + +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 + +· PPP/SLIP emulator + + + + + +Token-Ring + + +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. + + + +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. + + + +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. + + + +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. + + + +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. + + +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 + +  * 3C389 PCMCIA + +  * 3C619, 3C619B or 3C619C Token Link + +  * 3C319 Velocity ISA + +  * 3C359 Velocity XL - PCI + +  * 3C339 Velocity PCI + + +IBM + +  * 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. + +  * Cardbus. 16/4 Token Ring Adapter + +  * LanStreamer. PCI: Auto LanStreamer, Triple Lanstreamer; MCA: LanStreamer + MC16, Lanstreamer MC32, AutoLanstreamer MC32, Dual Lanstreamer MC32 + +  * ISA. Auto 16/4 Token Ring Adapter, 16/4 Token Ring Adapter, Turbo 16/4 + Token Ring Adapter, Auto Wake Token Ring Adapter. + +  * 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 + +  * Tropic MCA. 16/4 Token Ring Adapter/A, Auto 16/4 Token Ring Adapter + + +Olicom + +  * RapidFire 3139, 3140, 3141, and 3540 + +  * OC 3136 + +  * OC 3137 + +  * OC 3118 + +  * OC 3129 + + +Madge + +  * 51-02 Smart 16/4 PCI + +  * 20-03 16/4 Cardbus Adapter Mk2 + +  * 51-04 Smart 16/4 PCI Ringnode Mk3 + +  * 51-09 Smart 16/4 Fiber PCI Ringnode + +  * 51-07 Smart 100/16/4 PCI-HS Ringnode + +  * 51-05 Smart 100/16/4 PCI Ringnode + +  * 20-01 Smart 16/4 PCMCIA + +  * 60-07 Presto PCI 2000 + +  * 60-06 Presto PCI Plus + +  * 60-05 Presto PCI + +  * 53-05 Smart Mk4 PCI Adapter (low profile) + +  * 31-40 Rapidfire 3140V2 16/4 PCI Adapter + + +SysKonnect + +  * TR4/16(+) SK-4190 ISA + +  * TR4/16(+) SK-4590 PCI + +  * TR4/16(+) SK-4591 PCI + + +SMC + +  * Tokencard Elite (8115T) + +  * Tokencard Elite/A MCA (8115T/A) + + +Intel + +  * TokenExpress PRO + +  * 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 + +  * 3C389 PCMCIA -- ibmtr_cs + +  * 3C619, 3C619B or 3C619C Token Link -- ibmtr + +  * 3C319 Velocity ISA -- try ibmtr + +  * 3C359 Velocity XL - PCI -- driver available from [http://www.linuxtr.net] + http://www.linuxtr.net + +  * 3C339 Velocity PCI -- tms380tr + + +IBM + +  * PCI Token Ring Adaptor -- olympic + +  * PCI Wake on Lan Token Ring Adaptor -- olympic + +  * 16/4 Token Ring PCI Adaptor 2, Wake On Lan, and Wake on Lan Special -- + olympic + +  * High Speed 100/16/4 Token Ring -- olympic + +  * Turbo 16/4 ISA adapter -- ibmtr + +  * Token Ring Auto 16/4 ISA adapter -- ibmtr + +  * Token Ring Auto 16/4 adapter /A -- ibmtr + +  * Token Ring 16/4 adapter /A -- ibmtr + +  * Token Ring adapter /A -- ibmtr + +  * Token Ring adapter II (4 Megabit only) -- ibmtr + +  * 16/4 ISA Token Ring card (16bit) -- ibmtr + +  * 16/4 ISA Token Ring card (8bit) -- ibmtr + +  * All LANStreamer -- lanstreamer + +  * PCMCIA - Turbo 16/4 -- ibmtr_cs + +  * PCMCIA - 16/4 -- ibmtr_cs + +  * Cardbus - 16/4 - olympic, kernel v.2.4.3 or greater + + +Olicom + +  * RapidFire 3139, 3140, 3141, and 3540 + +  * OC 3136 + +  * OC 3137 + +  * OC 3118 + +  * 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 + +  * 51-02 Smart 16/4 PCI + +  * 20-03 16/4 Cardbus Adapter Mk2 + +  * 51-04 Smart 16/4 PCI Ringnode Mk3 + +  * 51-09 Smart 16/4 Fiber PCI Ringnode + +  * 51-07 Smart 100/16/4 PCI-HS Ringnode + +  * 51-05 Smart 100/16/4 PCI Ringnode + +  * 20-01 Smart 16/4 PCMCIA + +  * 60-07 Presto PCI 2000 + +  * 60-06 Presto PCI Plus + +  * 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: + +  * 51-05 Smart Mk4 PCI Adapter + +  * 53-05 Smart Mk4 PCI Adapter (low profile) + +  * 31-40 Rapidfire 3140V2 16/4 PCI Adapter + +  * 20-03 Smart 16/4 Cardbus Mk2 + +  * 51-04 Smart 16/4 PCI Ringnode Mk3 + +  * 60-07 Presto PCI 2000 + +  * 60-06 Presto PCI Plus + +  * 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 + +  * TR4/16(+) SK-4190 ISA + +  * TR4/16(+) SK-4590 PCI + +  * 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 + +  * Tokencard Elite (8115T) + +  * Tokencard Elite/A MCA (8115T/A) + + +Driver is included as part of the 2.3.38+ kernel. + +Intel + +  * TokenExpress PRO + +  * 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 +åddresses when looking for adapters. The information on these options are +included here for completeness only. + +  * 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. + +  * 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¸ 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. + + + +  * 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. + +  * pkt_buf_sz: This is this initial receive buffer allocation size. This + will default to 4096 if no value is entered. You may increase performance + of the driver by setting this to a value larger than the network packet + size, although the driver now re-sizes buffers based on MTU settings as + well. + +  * message_level: Controls level of messages created by the driver. Defaults + to 0 which only displays start-up and critical messages. Presently any + non-zero value will display all soft messages as well. NB This does not + turn debugging messages on, that must be done by modified the source + code. + +  * network_monitor: Any non-zero value will provide a quasi network + monitoring mode. All unexpected MAC frames (beaconing etc.) will be + received by the driver and the source and destination addresses printed. + Also an entry will be added in /proc/net called olympic_tr%d, where tr%d + is the registered device name, i.e tr0, tr1, etc. This displays low level + information about the configuration of the ring and the adapter. This + feature has been designed for network administrators to assist in the + diagnosis of network / ring problems. (This used to + OLYMPIC_NETWORK_MONITOR, but has now changed to allow each adapter to be + configured differently and to alleviate the necessity to re-compile + olympic to turn the option on). + + +Multi-card. The driver will detect multiple cards and will work with shared +interrupts, each card is assigned the next token ring device, i.e. tr0 , tr1, +tr2. The driver should also happily reside in the system with other drivers. +It has been tested with ibmtr.c running. 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¸ 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. + + + +  * 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. + +  * pkt_buf_sz: This is this initial receive buffer allocation size. This + will default to 4096 if no value is entered. You may increase performance + of the driver by setting this to a value larger than the network packet + size, although the driver now re-sizes buffers based on MTU settings as + well. + +  * message_level: Controls level of messages created by the driver. Defaults + to 0 which only displays start-up and critical messages. Presently any + non-zero value will display all soft messages as well. NB This does not + turn debugging messages on, that must be done by modified the source + code. + + +Network Monitor. 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¸ 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. + + + +  * 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. + +  * pkt_buf_sz: This is this initial receive buffer allocation size. This + will default to 4096 if no value is entered. You may increase performance + of the driver by setting this to a value larger than the network packet + size, although the driver now re-sizes buffers based on MTU settings as + well. + +  * message_level: Controls level of messages created by the driver. Defaults + to 0 which only displays start-up and critical messages. Presently any + non-zero value will display all soft messages as well. NB This does not + turn debugging messages on, that must be done by modified the source + code. + + +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 + +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: + +  * 1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be + patient. + +  * 2. This driver works very well when autoprobing for adapters. Why even + think about those nasty io/int/dma settings of modprobe when the driver + will do it all for you! + + +This driver is rather simple to use. Select Y to Token Ring adapter support +in the kernel configuration. A choice for SysKonnect Token Ring adapters will +appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this +option. I personally recommend compiling the driver as a module (M), but if +you you would like to compile it 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. + +  * In the info below we'll call your linux box 'linux.mycompany.biz.com' + +  * Register another ip address, I'll call it 'vmware.mycompany.biz.com' + +  * 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 | + +---------------------------------------------------------------+ + +  * 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 | + | | + +---------------------------------------------------------------+ + +  * Make sure you can ping both ip addresses from another box. If you cannot + then this next step will not work. + +  * 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 . + +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. + + + + + +X25 + + +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. + + + +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. + + + +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. + + + +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. + + + + + + +IPv6 + + + +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 ++ * + + +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. +----------------------------------------------------------------------------- + + diff --git a/LDP/guide/docbook/Linux-Networking/Token-Ring.xml b/LDP/guide/docbook/Linux-Networking/Token-Ring.xml deleted file mode 100644 index 1a9e9b0a..00000000 --- a/LDP/guide/docbook/Linux-Networking/Token-Ring.xml +++ /dev/null @@ -1,1219 +0,0 @@ - - -Token-Ring - - -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. - - - -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. - - - -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. - - - -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. - - - -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. - - -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 - -  * 3C389 PCMCIA - -  * 3C619, 3C619B or 3C619C Token Link - -  * 3C319 Velocity ISA - -  * 3C359 Velocity XL - PCI - -  * 3C339 Velocity PCI - - -IBM - -  * 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. - -  * Cardbus. 16/4 Token Ring Adapter - -  * LanStreamer. PCI: Auto LanStreamer, Triple Lanstreamer; MCA: LanStreamer - MC16, Lanstreamer MC32, AutoLanstreamer MC32, Dual Lanstreamer MC32 - -  * ISA. Auto 16/4 Token Ring Adapter, 16/4 Token Ring Adapter, Turbo 16/4 - Token Ring Adapter, Auto Wake Token Ring Adapter. - -  * 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 - -  * Tropic MCA. 16/4 Token Ring Adapter/A, Auto 16/4 Token Ring Adapter - - -Olicom - -  * RapidFire 3139, 3140, 3141, and 3540 - -  * OC 3136 - -  * OC 3137 - -  * OC 3118 - -  * OC 3129 - - -Madge - -  * 51-02 Smart 16/4 PCI - -  * 20-03 16/4 Cardbus Adapter Mk2 - -  * 51-04 Smart 16/4 PCI Ringnode Mk3 - -  * 51-09 Smart 16/4 Fiber PCI Ringnode - -  * 51-07 Smart 100/16/4 PCI-HS Ringnode - -  * 51-05 Smart 100/16/4 PCI Ringnode - -  * 20-01 Smart 16/4 PCMCIA - -  * 60-07 Presto PCI 2000 - -  * 60-06 Presto PCI Plus - -  * 60-05 Presto PCI - -  * 53-05 Smart Mk4 PCI Adapter (low profile) - -  * 31-40 Rapidfire 3140V2 16/4 PCI Adapter - - -SysKonnect - -  * TR4/16(+) SK-4190 ISA - -  * TR4/16(+) SK-4590 PCI - -  * TR4/16(+) SK-4591 PCI - - -SMC - -  * Tokencard Elite (8115T) - -  * Tokencard Elite/A MCA (8115T/A) - - -Intel - -  * TokenExpress PRO - -  * 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 - -  * 3C389 PCMCIA -- ibmtr_cs - -  * 3C619, 3C619B or 3C619C Token Link -- ibmtr - -  * 3C319 Velocity ISA -- try ibmtr - -  * 3C359 Velocity XL - PCI -- driver available from [http://www.linuxtr.net] - http://www.linuxtr.net - -  * 3C339 Velocity PCI -- tms380tr - - -IBM - -  * PCI Token Ring Adaptor -- olympic - -  * PCI Wake on Lan Token Ring Adaptor -- olympic - -  * 16/4 Token Ring PCI Adaptor 2, Wake On Lan, and Wake on Lan Special -- - olympic - -  * High Speed 100/16/4 Token Ring -- olympic - -  * Turbo 16/4 ISA adapter -- ibmtr - -  * Token Ring Auto 16/4 ISA adapter -- ibmtr - -  * Token Ring Auto 16/4 adapter /A -- ibmtr - -  * Token Ring 16/4 adapter /A -- ibmtr - -  * Token Ring adapter /A -- ibmtr - -  * Token Ring adapter II (4 Megabit only) -- ibmtr - -  * 16/4 ISA Token Ring card (16bit) -- ibmtr - -  * 16/4 ISA Token Ring card (8bit) -- ibmtr - -  * All LANStreamer -- lanstreamer - -  * PCMCIA - Turbo 16/4 -- ibmtr_cs - -  * PCMCIA - 16/4 -- ibmtr_cs - -  * Cardbus - 16/4 - olympic, kernel v.2.4.3 or greater - - -Olicom - -  * RapidFire 3139, 3140, 3141, and 3540 - -  * OC 3136 - -  * OC 3137 - -  * OC 3118 - -  * 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 - -  * 51-02 Smart 16/4 PCI - -  * 20-03 16/4 Cardbus Adapter Mk2 - -  * 51-04 Smart 16/4 PCI Ringnode Mk3 - -  * 51-09 Smart 16/4 Fiber PCI Ringnode - -  * 51-07 Smart 100/16/4 PCI-HS Ringnode - -  * 51-05 Smart 100/16/4 PCI Ringnode - -  * 20-01 Smart 16/4 PCMCIA - -  * 60-07 Presto PCI 2000 - -  * 60-06 Presto PCI Plus - -  * 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: - -  * 51-05 Smart Mk4 PCI Adapter - -  * 53-05 Smart Mk4 PCI Adapter (low profile) - -  * 31-40 Rapidfire 3140V2 16/4 PCI Adapter - -  * 20-03 Smart 16/4 Cardbus Mk2 - -  * 51-04 Smart 16/4 PCI Ringnode Mk3 - -  * 60-07 Presto PCI 2000 - -  * 60-06 Presto PCI Plus - -  * 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 - -  * TR4/16(+) SK-4190 ISA - -  * TR4/16(+) SK-4590 PCI - -  * 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 - -  * Tokencard Elite (8115T) - -  * Tokencard Elite/A MCA (8115T/A) - - -Driver is included as part of the 2.3.38+ kernel. - -Intel - -  * TokenExpress PRO - -  * 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 -åddresses when looking for adapters. The information on these options are -included here for completeness only. - -  * 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. - -  * 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¸ 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. - - - -  * 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. - -  * pkt_buf_sz: This is this initial receive buffer allocation size. This - will default to 4096 if no value is entered. You may increase performance - of the driver by setting this to a value larger than the network packet - size, although the driver now re-sizes buffers based on MTU settings as - well. - -  * message_level: Controls level of messages created by the driver. Defaults - to 0 which only displays start-up and critical messages. Presently any - non-zero value will display all soft messages as well. NB This does not - turn debugging messages on, that must be done by modified the source - code. - -  * network_monitor: Any non-zero value will provide a quasi network - monitoring mode. All unexpected MAC frames (beaconing etc.) will be - received by the driver and the source and destination addresses printed. - Also an entry will be added in /proc/net called olympic_tr%d, where tr%d - is the registered device name, i.e tr0, tr1, etc. This displays low level - information about the configuration of the ring and the adapter. This - feature has been designed for network administrators to assist in the - diagnosis of network / ring problems. (This used to - OLYMPIC_NETWORK_MONITOR, but has now changed to allow each adapter to be - configured differently and to alleviate the necessity to re-compile - olympic to turn the option on). - - -Multi-card. The driver will detect multiple cards and will work with shared -interrupts, each card is assigned the next token ring device, i.e. tr0 , tr1, -tr2. The driver should also happily reside in the system with other drivers. -It has been tested with ibmtr.c running. 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¸ 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. - - - -  * 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. - -  * pkt_buf_sz: This is this initial receive buffer allocation size. This - will default to 4096 if no value is entered. You may increase performance - of the driver by setting this to a value larger than the network packet - size, although the driver now re-sizes buffers based on MTU settings as - well. - -  * message_level: Controls level of messages created by the driver. Defaults - to 0 which only displays start-up and critical messages. Presently any - non-zero value will display all soft messages as well. NB This does not - turn debugging messages on, that must be done by modified the source - code. - - -Network Monitor. 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¸ 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. - - - -  * 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. - -  * pkt_buf_sz: This is this initial receive buffer allocation size. This - will default to 4096 if no value is entered. You may increase performance - of the driver by setting this to a value larger than the network packet - size, although the driver now re-sizes buffers based on MTU settings as - well. - -  * message_level: Controls level of messages created by the driver. Defaults - to 0 which only displays start-up and critical messages. Presently any - non-zero value will display all soft messages as well. NB This does not - turn debugging messages on, that must be done by modified the source - code. - - -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 - -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: - -  * 1. Adapters can be slow to open (~20 secs) and close (~5 secs), please be - patient. - -  * 2. This driver works very well when autoprobing for adapters. Why even - think about those nasty io/int/dma settings of modprobe when the driver - will do it all for you! - - -This driver is rather simple to use. Select Y to Token Ring adapter support -in the kernel configuration. A choice for SysKonnect Token Ring adapters will -appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this -option. I personally recommend compiling the driver as a module (M), but if -you you would like to compile it 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. - -  * In the info below we'll call your linux box 'linux.mycompany.biz.com' - -  * Register another ip address, I'll call it 'vmware.mycompany.biz.com' - -  * 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 | - +---------------------------------------------------------------+ - -  * 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 | - | | - +---------------------------------------------------------------+ - -  * Make sure you can ping both ip addresses from another box. If you cannot - then this next step will not work. - -  * 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 . - -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. diff --git a/LDP/guide/docbook/Linux-Networking/X25.xml b/LDP/guide/docbook/Linux-Networking/X25.xml deleted file mode 100644 index 00f9a719..00000000 --- a/LDP/guide/docbook/Linux-Networking/X25.xml +++ /dev/null @@ -1,42 +0,0 @@ - - -X25 - - -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. - - - -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. - - - -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. - - - -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. - - -