home *** CD-ROM | disk | FTP | other *** search
<!doctype linuxdoc system> <!-- This is the Linux NET-2/3-HOWTO, please forward any comments or suggestions to the author: terry@perf.no.itg.telecom.com.au --> <article> <!-- Title information --> <title>Linux NET-2/3-HOWTO <author>Terry Dawson, <tt>terry@perf.no.itg.telecom.com.au</tt> <date>v3.5, 16 January 1996 <abstract> This document aims to describe how to obtain, install and configure the Linux NET-2 and NET-3 networking software. Some answers to some of the more frequently asked questions are included in the appendix. This document is not designed to teach you about tcp/ip networking, though some information of this kind is included where possible. Pointers to other documentation which does teach tcp/ip networking principles are listed. </abstract> <!-- Table of contents --> <toc> <!-- Begin the document --> <sect><heading>Introduction. <p> This is the Linux NET-2/3-HOWTO. This document is a complete rewrite of the earlier NET-FAQ and of the subsequent NET-2-HOWTO versions 1.0+. This document is for the new NET-2/NET-3 tcp/ip networking code for Linux kernels 1.0 and above. <sect1><heading>Changes from the previous release. <p> <verb> Additions: Corrections/Updates: updated ipalias to apply to new 1.3.* kernels pointed IPX questions to IPX-HOWTO </verb> <sect1><heading>A brief development history of Linux Networking. <p> <tt>Ross Biro <biro@yggdrasil.com></tt> wrote the original kernel based networking code for Linux. He used ethernet drivers written by <tt>Donald Becker <becker@cesdis1.gsfc.nasa.gov></tt>, a <em>SLIP</em> driver written by <tt>Laurence Culhane <loz@holmes.demon.co.uk></tt> and a D-Link driver by <tt>Bj0rn Ekwall <bj0rn@blox.se></tt>. The further development of the Linux networking code was later taken up by <tt>Fred van Kempen <waltje@hacktic.nl></tt>, who took Ross's code and produced the <em>NET-2</em> release of network code. NET-2 went through a number of revisions until release NET-2d, when <tt>Alan Cox <iialan@iifeak.swan.ac.uk></tt> set about debugging Fred's code with the aim of producing a stable and working release of code for incorporation into the standard kernel releases. This code was called originally called <em>NET-2D(ebugged)</em> and was incorporated into the standard kernel releases some time before Linux version 1.0 was released. PPP support was added by <tt>Michael Callahan, <callahan@maths.ox.ac.uk></tt> and <tt>Al Longyear, <longyear@netcom.com></tt>, originally as patches to the kernel and in later releases as part of the standard kernel distribution. The latest version of the code, NET-3, appears in kernel releases 1.1.5 and later and is essentially the same code, but with many fixes, corrections and enhancements. Alan has added such features as IPX and AX.25 modules. <tt>Florian La Roche, <flla@stud.uni-sb.de></tt> has produced an updated distribution of network applications. NIIBE Yutaka has enhanced the PLIP driver. Jonathan Naylor has taken up development work on the AX.25 code and has added many features including NetRom support. Many other people have made contributions by way of bug fixes, ports of applications and by writing device drivers. <sect><heading>Disclaimer. <p> The Linux networking code is a brand new implementation of kernel based tcp/ip networking. It has been developed from scratch and is not a port of any existing kernel networking code. The Linux networking is some of the newest and most innovative kernel based networking code around. There are many developers working on pressing it into service for many new applications and tasks and because of this it is growing rapidly. It is in a constant state of flux and it may still have a number of bugs or problems with it and there may be a number of fixes and patches released. If you are worried about problems then just stick to the version of network code released with the standard kernel releases and utility sets. These standard kernel releases are denoted by an <bf>even</bf> number in the second digit, 1.2.7 for example is a production release. The kernel versions with an odd number as the second digit are <bf>alpha</bf> versions and you should expect to find problems or bugs with these version as they are <em>test</em> releases. The networking code has a small team of dedicated people working on it, with a cast of thousands testing the code, collecting and reporting bugs and problems, providing fixes for problems. Any problem you experience is likely to have already been reported and be being worked on and will possibly be corrected soon, so be patient, or if you can help, offer your assistance. We do not and cannot know everything there is to know about the Linux network software. Please accept and be warned that this document probably does contain errors. Please read any README files that are included with any of the various pieces of software described in this document for more detailed and accurate information. We will attempt to keep this document as error-free and up-to-date as possible. Versions of software are current as at time of writing. <bf>NOTE:</bf> While its name may appear similar to the <em>Berkeley Software Distribution NET-2 release</em>, the Linux network code actually has nothing at all to do with it. Please don't confuse them. <sect><heading>Questions already ? <p> <em>`The only stupid question is the unasked one.'</em> If you have general configuration questions and you have been unable to find the answers after reading the other various HOWTO and FAQ files, then you would be best served to post them to <em>comp.os.linux.networking</em>, or, if you believe your question to be specifically related to the Linux Network code, then you could post it to the NET mailing list. <bf>Please include as much relevant information as possible</bf>, there is nothing more annoying than to have a bug or problem reported without sufficient information to even begin searching for it. <bf>Version numbers and revisions of code, a detailed account of the problem, and the circumstances that caused it to occur, are essential. Trace and debug messages where available should also be considered mandatory.</bf> If you have a question relating to the configuration of, or problems experienced with, <bf>any</bf> linux distribution, regardless of who has provided it, please contact the people who created the distribution first before attempting to report the problem to the network code developers. The reason for this is that some of the distributions use non-standard directory structures and supply test/non-standard versions of code and utilities. The developers of the NET-2 code cannot be expected to offer support for the network code as distributed in any form, other than as described in this document, or as per distributed Alpha test instructions. To join the Linux <bf>linux-net</bf> channel on the mail list server, send mail to: <tscreen><verb> Majordomo@vger.rutgers.edu </verb></tscreen> with the line: <tscreen><verb> subscribe linux-net </verb></tscreen> as the message body and you will be subscribed. The subject line is ignored. Remember, keep in mind that the <tt>linux-net</tt> channel is for development discussions only. A PPP list has been established. To join it, use the same procedure as for joining the <tt>linux-net</tt> channel, except specify <tt>linux-ppp</tt> in place of <tt>linux-net</tt> in the message body. Note also that a <tt>linux-hams</tt> list has been established. This list has been established for the discussion of programs related to Amateur Radio. To join it, follow the same procedure as for joining the <tt>linux-net</tt> or <tt>linux-ppp</tt> channels, except specify <tt>linux-hams</tt> in place of <tt>linux-net</tt> in the message body. <sect><heading>Related Documentation. (Where to learn about tcp/ip) <p> If you are looking for information about tcp/ip networking that this HOWTO does not cover, then you might try the following sources, as they provide some very useful information. <tt>Olaf Kirch</tt> has written a substantial document as part of the <em>Linux Documentation Project</em> entitled the <em>Linux Network Administration Guide</em>. This is an excellent document. It covers all aspects of setting up and using the tcp/ip networking under Linux, including NFS, UUCP, mail, News, nameserver etc. Olaf's book supplements this HOWTO, taking up where this document leaves off. This document covers the installation and configuration of the NET code, i.e. `How to put your machine on the net'. If you are new to unix networking, then I strongly urge you to obtain a copy and read it first. It will answer a lot of questions for you that are not within the scope of this document. The current release version is available in: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/docs/linux-doc-project/network-guide/* </verb></tscreen> There are various versions of the document in this directory. The most common formats are supported, being plain ascii, Postscript, DVI, Latex and groff. The <em>Linux Network Administrators Guide</em> is Copyright (c) by Olaf Kirch. There are now quite a variety of companies publishing Linux documentation so if you want to avoid having to retrieve and print the document yourself you should have little trouble finding Olaf's book in a bound form over the counter at any good bookshop. You should also read the other HOWTO documents relevant to networking with Linux. They are: <p> The <url url="http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html" name="Ethernet-HOWTO">, which you should read if you intend using an ethernet card with Linux. It includes a lot of detail on how to select, install and configure an ethernet card for Linux and on how to diagnose problems related to the ethernet driver. The <url url="http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html" name="PPP-HOWTO"> if you intend using PPP. The <url url="http://sunsite.unc.edu/mdw/HOWTO/IPX-HOWTO.html" name="IPX-HOWTO"> if you would like information relating to IPX support for Linux. The <url url="http://sunsite.unc.edu/mdw/HOWTO/Serial-HOWTO.html" name="Serial-HOWTO"> if you intend using SLIP or PPP in server mode. The <url url="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html" name="NIS-HOWTO"> if you are interested in running a version of Sun's Network Information Service. The <url url="http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html" name="HAM-HOWTO"> if you are interested in configuring and running amateur radio software. The <url url="http://sunsite.unc.edu/mdw/HOWTO/Mail-HOWTO.html" name="Mail-HOWTO"> and the <url url="http://sunsite.unc.edu/mdw/HOWTO/News-HOWTO.html" name="News-HOWTO"> for some specific information on setting up Mail and News on your system. The <url url="http://sunsite.unc.edu/mdw/HOWTO/UUCP-HOWTO.html" name="UUCP-HOWTO"> if you will be connecting to the net via UUCP. The <url url="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html" name="Firewall-HOWTO"> if you want to build a Linux based Firewall gateway for your network. If you are after some basic tutorial information on tcp/ip networking generally, then I recommend you take a look at the following documents: <descrip> <tag>tcp/ip introduction </tag> <url url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc" name="text version">, <url url="ftp://athos.rutgers.edu/runet/tcp-ip-intro.ps" name="postscript version">. <tag>tcp/ip administration </tag> <url url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc" name="text version">, <url url="ftp://athos.rutgers.edu/runet/tcp-ip-admin.ps" name="postscript version">. </descrip> If you are after some more detailed information on tcp/ip networking then I highly recommend: <tscreen><verb> "Internetworking with TCP/IP" by Douglas E. Comer ISBN 0-13-474321-0 Prentice Hall publications. </verb></tscreen> If you are wanting to learn about how to write network applications in a Unix compatible environment then I also highly recommend: <tscreen><verb> "Unix Network Programming" by W. Richard Stevens ISBN 0-13-949876-1 Prentice Hall publications. </verb></tscreen> <sect1><heading>New versions of this document. <p> If your copy of this document is more than two months old then I strongly recommend you obtain a newer version. The networking support for Linux is changing very rapidly with new enhancements and features, so this document also changes fairly frequently. The latest released version of this document can always be retrieved by anonymous ftp from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/docs/HOWTO/NET-2-HOWTO </verb></tscreen> or: <tscreen><verb> /pub/Linux/docs/HOWTO/other-formats/NET-2-HOWTO{-html.tar,ps,dvi}.gz </verb></tscreen> or via the World Wide Web from the <url url="http://sunsite.unc.edu/mdw/linux.html" name="Linux Documentation Project Web Server">, at page: <url url="http://sunsite.unc.edu/mdw/HOWTO/NET-2-HOWTO.html" name="NET-2-HOWTO"> or directly from me, <tt><94004531@postoffice.csu.edu.au></tt>. It will also be posted to the newsgroups: <tt>comp.os.linux.networking</tt>, <tt>comp.os.linux.answers</tt> and <tt>news.answers</tt> from time to time. You can find <tt>news.answers</tt> FAQ postings, including this one, archived on <tt>rtfm.mit.edu:/pub/usenet</tt>. <sect1><heading>Feedback. <p> Please send any comments, updates, or suggestions to me, <tt><94004531@postoffice.csu.edu.au></tt>. The sooner I get feedback, the sooner I can update and correct this document. If you find any problems with it, please mail me directly as I now very rarely read the newsgroup. You might also catch me as <em>terryd</em> on the <tt>#linpeople</tt> IRC channel on the <tt>undernet</tt> IRC network. <sect><heading>Some of the terms used in this document. <p> You will often see the terms <tt>client</tt> and <tt>server</tt> used in this document. They are normally fairly specific terms but in this document I have generalised their definitions a little so that they mean the following: <descrip> <tag>client</tag>The machine or program that initiates an action or a connection for the purpose of gaining use of some service or data. <tag>server</tag>The machine or program that accepts incoming connections from multiple remote machines and provides a service or data to those. </descrip> These definitions are not very reliable either, but they provide a means of distinguishing the ends of peer to peer systems such as <em>SLIP</em> or <em>PPP</em> which truly do not actually have clients and servers. <p> Other terms you will see are: <descrip> <tag>IP address</tag>This is a number that uniquely identifies a TCP/IP host on the network. The address is 4 bytes long and is usually represented in what is called the "dotted decimal notation", where each byte is represented in decimal from with dots `.' between them. <tag>Hardware address</tag>This is a number that uniquely identifies a host in a physical network at the media access layer. Examples of this are <em>Ethernet Addresses</em> and <em>AX.25 Addresses</em>. <tag>datagram</tag>A datagram is a discrete package of data and headers which contain addresses, which is the basic unit of transmission across an IP network. You might also hear this called a `packet'. <tag>MTU</tag>The Maximum Transmission Unit (<em>MTU</em>) is a parameter that determines the largest datagram than can be transmitted by an IP interface without it needing to be broken down into smaller units. The MTU should be larger than the largest datagram you wish to transmit unfragmented. Note, this only prevents fragmentation locally, some other link in the path may have a smaller MTU and the datagram will be fragmented there. Typical values are 1500 bytes for an ethernet interface, or 576 bytes for a SLIP interface. <tag>MSS</tag>The Maximum Segment Size (<em>MSS</em>) is the largest quantity of data that can be transmitted at one time. If you want to prevent local fragmentation MSS would equal MTU-IP header. <tag>window</tag>The <em>window</em> is the largest amount of data that the receiving end can accept at a given point in time. <tag>route</tag>The <em>route</em> is the path that your datagrams take through the network to reach their destination. <tag>ARP</tag>This is an acronym for the <em>Address Resolution Protocol</em> and this is how a network machine associates an IP Address with a hardware address. </descrip> <sect><heading>NET-3 Supported functionality. <p> The NET code is a complete kernel based implementation of tcp/ip for Linux. <sect1><heading>General Support <p> The recent NET-3 versions of code support: <descrip> <tag>Ethernet Cards </tag>most popular ethernet cards are supported. Including some portable, pocket adaptors and PCI. <tag>SLIP (Serial Line IP) and PPP (Point to Point Protocol) </tag>for tcp/ip networking over serial lines such as the telephone via modem, or a local cable between two machines. <tag>Van Jacobsen Header Compression </tag>for compressing the tcp/ip headers to improve SLIP/PPP performance over low speed lines. <tag>PLIP (Parallel Lines IP) </tag>to allow local connections between two machines using your printer ports. <tag>EQL Load balancing </tag>allows you to use two (or more) links to connect your machine to another machine or the Internet (provided your ISP supports it) to effectively double your bandwidth. New release kernels support this. <tag>NFS (Networked File System) </tag>to allow you to remotely mount another machines filesystems across a network connection. <tag>IPX (Novell) </tag>to allow you to write custom IPX applications, or to use Linux as an IPX router. <tag>Sun's Network Information System - NIS </tag>An NIS implementation has been ported to Linux should you wish to use it. <tag>ARCNet </tag>An ARCNet driver has been written and is included in recent kernels. It might not be as fast as ethernet but the cards are much cheaper. <tag>IBM's Token Ring </tag>to allow linux to be installed on a Token Ring lan. An experimental Token Ring driver has been written is included in recent kernels. <tag>Appletalk </tag>Or is this EtherTalk ? Either way, I think this will let you shares files and printers with your Macintosh. See `Experimental and Developmental modules.' below. <tag>WaveLan Wireless Lan Card support </tag>to allow you to operate your linux machine in a mobile fashion or at some distance from your network. Support for the WaveLan Wireless lan card is now included in recent kernels. <tag>ISDN </tag>There is some experimental support for some proprietary ISDN cards available. See `Experimental and Developmental modules.' below. <tag>ATM </tag>There is a team of programmers working to provide ATM support for Linux. <tag>IP firewalling </tag>to assist in configuring your Linux machine as a secure firewall gateway. <tag>IP Accounting </tag>to allow you to keep track of who is using how much of your network. <tag>IP tunnelling </tag>to allow mobile IP experimentation </descrip> <p> The NET-3 network code does not yet currently support: <descrip> <tag>SPX/NCP (Novell Netware) support </tag>to allow Linux to serve and mount Novell network filesystems or use Novell printers. This is being worked on but due to the proprietary nature of the product it may take some time to do. <tag>FDDI </tag>There is currently no support that I know of for FDDI cards for Linux. <tag>System-V streams </tag>there is a team of people working on System-V streams for Linux, details are presented later. </descrip> <sect1><heading>Supported Ethernet cards. <p> The 1.2.0 linux kernel release supports the following types of Ethernet cards: <itemize> <item>WD80*3 and close compatibles. <item>SMC Ultra. <item>AMD LANCE and PCnet (AT1500 and NE2100) and close compatibles. <item>3Com 3c501 (obsolete and very slow). <item>3Com 3c503. <item>3Com 3c505. <item>3Com 3c507. <item>3Com 3c509/3c579. <item>Cabletron E21xx. <item>DEPCA and close compatibles. <item>EtherWorks 3. <item>ARCNet. <item>AT1700 (not clones). <item>EtherExpress. <item>NI5210 and close compatibles. <item>NI6510. <item>WaveLAN. <item>HP PCLAN+ (27247B and 27252A). <item>HP PCLAN (27245 and other 27xxx series). <item>NE2000/NE1000 and close compatibles. <item>SK_G16. <item>Ansel Communications EISA 3200. <item>Apricot Xen-II on board ethernet. <item>DE425, DE434, DE435. <item>Zenith Z-Note. <item>AT-LAN-TEC/RealTek pocket adaptor. <item>D-Link DE600 pocket adaptor and close compatibles. <item>D-Link DE620 pocket adaptor and close compatibles. </itemize> Later versions of the Kernel software may support a wider variety of cards. If you intend using an ethernet card with Linux you should read the <url url="http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO.html" name="Ethernet-HOWTO"> as it contains a lot of very useful information on the supported ethernet cards, including information on how to choose an ethernet card if you are intending to purchase some specifically for Linux. As mentioned above, Linux supports other means of network connection if you don't have access to an ethernet card or connection. Many universities and businesses worldwide offer some form of dial-up network access. Generally these forms of access will offer an option of either SLIP or PPP access, so you will be well catered for. All you will need is a telephone modem, the one you already have may well be good enough and to configure your Linux system appropriately. There are sections below that describe exactly what you need. <sect1><heading>Support for Amateur Radio <p> Linux now supports a number of features specifically for Amateur Radio. The latest alpha kernels are now distributed with standard support for: <descrip> <tag>AX.25 Support </tag>Alan Cox and Jonathan Naylor have kernel based AX.25 socket support working. <tag>NetRom Support </tag>Jonathan Naylor has developed kernel based NetRom support. It is still experimental but is progressing well. <tag>Ottawa PI Card </tag>A mature driver for the Ottawa PI card has been developed by Dave Perry of the Ottawa Packet Radio Group. <tag>Generic SCC card driver </tag>A generic driver for SCC cards is now included in alpha kernels developed by Joerg Reuter. <tag>A kernel user network link driver </tag>for linking user programs to the kernel without messy pty's. </descrip> Further detail on the Amateur Radio support can be found in the <url url="http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html" name="HAM-HOWTO">. <sect><heading>Getting the NET-2/NET-3 software. <p> Before you can configure the networking software you must obtain all of the bits and pieces that make it up. These include the current version of the kernel code (version 1.0 or later), the correct system libraries, the tcp/ip configuration programs and files (e.g. /sbin/ifconfig, /etc/hosts etc.) and finally a set of network application programs (such as telnet, ftp, rlogin etc.). If you obtained Linux from a distribution you may already have all that you need. Check and make sure that you do. For example, some Linux distributions come with all of the network configuration files, binaries, libraries and kernel installed, so there's no reason to get the following files. <bf>NOTE: they may be in directories and files different to those specified in this HOWTO document</bf> If you <bf>DO</bf> have the network software, skip to the `Configuring the kernel' section. If you <bf>DO NOT</bf> have the network software follow the following directions. <sect1><heading>The kernel source. <p> Version 1.2.* of the Linux kernel is the <em>production</em> version. Any of the Linux kernels 1.3.* are development kernels. If you feel at all concerned about the possibility of having to patch and modify the kernel source, then you should stick to this release, as it will do most of what you want it to. In the case of the networking code though, I strongly suggest you just take a deep breath and follow the newer releases of code, as there have been many changes in the newer version kernels that affect networking. I know you hear it from everyone and everywhere, but when trying out any new version of kernel software you should always ensure that you have sufficient backups of your system just in case something goes seriously wrong while you are testing. The current kernel version is found in: <bf>ftp.funet.fi</bf> <tscreen><verb> /pub/OS/Linux/PEOPLE/Linus/v1.2/linux-1.2.13.tar.gz </verb></tscreen> This is a gzipped file, so you will need <em>gzip</em> to uncompress it. To install it, try: <tscreen><verb> # cd /usr/src # mv linux linux.old # gzip -dc linux-1.2.13.tar.gz | tar xvf - </verb></tscreen> You may also find some files called <tt> patch-1.2.1.gz ...</tt> in the same directory. These are patch files. If you have a linux kernel that is version 1.2.1 then what this means is that you have linux kernel version 1.2.0 with patch 1 applied. So you don't need to patch 1. If there are any patch files that are greater than the version of kernel you have, you should obtain <bf>all</bf> of those above and apply them <bf>in sequence</bf> with something like the following commands: <tscreen><verb> # cd /usr/src # for patchfile in .../patch* > do > gzip -dc $patchfile | patch -p0 2>>patch.errs > done ... </verb></tscreen> Check the output file (patch.errs) and search for the string <tt>fail</tt>. If you can't find it then all of the patch files were applied ok. If it is there, then at least one of the patch files didn't apply correctly. If this happens what you should do is start again from a clean kernel archive and apply the patches one by one until you find the patch file that failed. If you can't work out why it didn't work then report it as a problem. <sect1><heading>The libraries. <p> You'll want at <bf>least</bf> version 4.4.2 of <em>libc</em>, as there were problems with earlier version that affected subnet masks. The current a.out libraries (libc-4.6.27) can be found in: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/GCC/ </verb></tscreen> You will need at least the following files: <itemize> <item>image-4.6.27.tar.gz <item>inc-4.6.27.tar.gz <item>extra-4.6.27.tar.gz <item>release.libc-4.6.27 </itemize> When installing libc.4.6.27 you <bf>MUST</bf> read <bf>release.libc-4.6.27</bf> before you install the libraries. Please note that to use release 4.5.26 or later you will also need at least GCC version 2.6.2 and Linux kernel 1.1.52 or later. <sect1><heading>The network configuration tool suite. <p> You will need the utility suite that provides tools to configure your network support. The current NET-2 utility suite is available from: <bf>ftp.linux.org.uk</bf> <tscreen><verb> /pub/linux/Networking/PROGRAMS/NetTools/net-tools-1.2.0.tar.gz </verb></tscreen> Because the kernel networking code is still changing some changes to the network tools have been necessary as new kernels are released, so you will need to choose the version that is appropriate for the kernel version you intend to use. The filenames reflect the earliest version of kernel that the tools will work with. Please choose the filename whose version equals, or is less than the version of kernel source you intend to use. To build and install the tools, you should try: <tscreen><verb> # cd /usr/src # mkdir net-tools # cd net-tools # gzip -dc net-tools-1.2.0.tar.gz | tar xvf - # make </verb></tscreen> This will automatically run the <tt>Configure.sh</tt> script. If everything makes ok, then: <tscreen><verb> # make install </verb></tscreen> If you use a kernel version 1.1.26 or earlier you should look in: <bf>ftp.linux.org.uk</bf> <tscreen><verb> /pub/linux/Networking/PROGRAMS/Other/net032 </verb></tscreen> In this directory you will find three versions of the network tools. The following table lists net-032 package name with the relevant kernel versions: <tscreen><verb> net-0.32d-net3.tar.gz 1.1.12+ net-0.32b.tar.gz 1.1.4+ net-0.32.old.tar.gz pre 1.1.4 kernels </verb></tscreen> These packages include the essential network configuration programs such as <em>ifconfig</em>, <em>route</em>, <em>netstat</em> etc. These will be discussed later. <sect1><heading>The network applications. <p> You will want a number of network application programs. These are programs like <em>telnet</em>, <em>ftp</em>, <em>finger</em> and their daemons at least. <tt>Florian La Roche, <flla@stud.uni-sb.de></tt> has put together a fairly complete distribution of network applications in both binary and source form. The tcp/ip application binaries and some sample config files are found in: <bf>ftp.funet.fi</bf> <tscreen><verb> /pub/OS/Linux/PEOPLE/Linus/net-source/base/NetKit-A-0.08.bin.tar.gz /pub/OS/Linux/PEOPLE/Linus/net-source/base/NetKit-B-0.06.tar.gz </verb></tscreen> If there are newer versions then use the newer versions. Please read the <tt>README</tt> file <bf>first</bf> just to make sure that you have the necessary prerequisites. Florian used to have a binary distribution of the networking applications (the B file) available but it is no longer there, so you will have to build the files yourself. You can use the following procedure: <tscreen><verb> # cd /usr/src # gzip -dc NetKit-B-0.06.tar.gz | tar xpvlf - # cd NetKit-B-0.06 </verb></tscreen> Then, read the <tt>README</tt> file. You will need to edit the <tt>Makefile</tt> and set the <tt>HAVE_SHADOW_PASSWORDS</tt> define appropriately. I don't use shadow passwords, so I commented it out by placing a <tt>#</tt> at the start of the line. The rest should not need modifying, so then all you should have to do is: <tscreen><verb> # make # make install </verb></tscreen> <bf>IMPORTANT NOTE:</bf> Florian has built and prepackaged these tar files for your convenience. Florian has attempted to make them as complete as possible and has included a distribution of the binaries found in the <tt>net-tools-n.n.nn</tt> releases. Unfortunately Florian has chosen not to use the same directory structure as Alan did when he prepared the installation script for the net-tools. This will mean that you should be very careful when installing them. Florian will change this later so that this difference is not a problem, but until then, I suggest you do the following instead of the above: <tscreen><verb> - Unpack the binaries somewhere safe: # cd /usr/src # mkdir NetKit # cd NetKit # gzip -dc NetKit-A-0.07.bin.tar.gz | tar xpvlf - # gzip -dc NetKit-B-0.06.bin.tar.gz | tar xpvlf - - Remove Florians copies of the network tools previously described: # rm ./bin/hostname ./sbin/route ./sbin/ifconfig ./sbin/netstat # rm ./usr/sbin/arp ./usr/sbin/rarp ./usr/sbin/slattach - Copy Florian's files into their new home: # cp -vrpd . / </verb></tscreen> <sect1><heading>Additional drivers or packages. <p> If you want to add some developmental, or Alpha/Beta test code, such as AX.25 support, you will need to obtain the appropriate support software for those packages. Please check the relevant sections for those packages in this document for more detail. <sect><heading>Configuring the kernel. <p> Before you can use any of the network tools, or configure any network devices, you must ensure that your kernel has the necessary network support built into it. The best way of doing this is to compile your own, selecting which options you want and which you don't. Assuming you have obtained and untarred the kernel source already and applied any patches that you might need to have applied to get any nonstandard or developmental software installed, all you have to do is edit <tt>/usr/src/linux/drivers/net/CONFIG</tt>. This file has many comments to guide you in editing it and in general you will need to edit very little, as it has sensible defaults. In my case I don't need to edit it at all. This file is really necessary if your ethernet card is an unusual one, or is one that isn't automatically detected by the ethernet driver. It allows you to hard code some of the elements of your ethernet hardware. For example, if your ethernet card is a close, but not exact clone of a WD-8013, then you might have to configure the shared memory address to ensure the driver detects and drives the card properly. Please check the The <url url="http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO" name="Ethernet-HOWTO"> for more definitive information on this file and its effect on ethernet cards. This file also contains configurable parameters for PLIP, though the defaults should again be ok unless you have a particularly slow machine. When you are happy that the CONFIG file is suitable for your purposes, then you can proceed to build the kernel. Your first step will be to edit the top level Makefile to ensure the kernel will be built with the appropriate VGA settings and then you must run the kernel configuration program: <tscreen><verb> # cd /usr/src/linux # make config </verb></tscreen> You will be asked a series of questions. There are four sections relevant to the networking code. They are the <tt>General setup</tt>, <tt>Networking options</tt>, <tt>Network device support</tt> and the <tt>Filesystems</tt> sections. The most difficult to configure is the <tt>Network device support</tt> section, as it is where you select what types of physical devices you want configured. On the whole you can just use the default values for the other sections fairly safely. The following will give you an idea of how to proceed: <tscreen><verb> * * General setup * ... ... Networking support (CONFIG_NET) [y] y ... ... </verb></tscreen> In the <tt>General setup</tt> section you simply select whether you want network support or not. Naturally you must answer yes. <tscreen><verb> * * Networking options * TCP/IP networking (CONFIG_INET) [y] IP forwarding/gatewaying (CONFIG_IP_FORWARD) [n] IP multicasting (CONFIG_IP_MULTICAST) [n] IP firewalling (CONFIG_IP_FIREWALL) [n] IP accounting (CONFIG_IP_ACCT) [n] * * (it is safe to leave these untouched) * PC/TCP compatibility mode (CONFIG_INET_PCTCP) [n] Reverse ARP (CONFIG_INET_RARP) [n] Assume subnets are local (CONFIG_INET_SNARL) [y] Disable NAGLE algorithm (normally enabled) (CONFIG_TCP_NAGLE_OFF) [n] The IPX protocol (CONFIG_IPX) [n] * </verb></tscreen> The second half of the <tt>Networking options</tt> section allows you to enable or disable some funky features that you can safely accept the defaults on until you have some idea why you want to change them. They are described briefly later if you are interested. <tscreen><verb> * * * Network device support * Network device support? (CONFIG_NETDEVICES) [y] Dummy net driver support (CONFIG_DUMMY) [n] SLIP (serial line) support (CONFIG_SLIP) [y] CSLIP compressed headers (CONFIG_SLIP_COMPRESSED) [y] 16 channels instead of 4 (SL_SLIP_LOTS) [n] PPP (point-to-point) support (CONFIG_PPP) [y] PLIP (parallel port) support (CONFIG_PLIP) [n] Do you want to be offered ALPHA test drivers (CONFIG_NET_ALPHA) [n] Western Digital/SMC cards (CONFIG_NET_VENDOR_SMC) [y] WD80*3 support (CONFIG_WD80x3) [y] SMC Ultra support (CONFIG_ULTRA) [n] AMD LANCE and PCnet (AT1500 and NE2100) support (CONFIG_LANCE) [n] 3COM cards (CONFIG_NET_VENDOR_3COM) [n] Other ISA cards (CONFIG_NET_ISA) [n] EISA, VLB, PCI and on board controllers (CONFIG_NET_EISA) [n] Pocket and portable adaptors (CONFIG_NET_POCKET) [n] * </verb></tscreen> This section is the most important and the most involved. It is where you select what hardware devices you want to support. You can see that I have selected SLIP support with header compression, PPP, the WD80*3 driver and nothing else. Other options will appear depending on what you select. If you answered <tt>`n'</tt> to the <tt>`SLIP..'</tt> option you will not be presented with the <tt>compressed SLIP</tt> or <tt>16 channel</tt> options. Simply answer <tt>`y'</tt> to whatever you want to play with and <tt>`n'</tt> to those that you don't. <tscreen><verb> * * Filesystems * ... ... /proc filesystem support (CONFIG_PROC_FS) [y] NFS filesystem support (CONFIG_NFS_FS) [y] ... ... </verb></tscreen> If you wish to run an NFS client then you will want to include the NFS filesystem type. You will need to include the <tt>/proc</tt> filesystem because a number of the network utilities use it. After you have completed the configuration, all that remains is to actually compile the kernel: <tscreen><verb> # make dep # make </verb></tscreen> Don't forget to <tt>make zlilo</tt> if the new kernel compiles and tests ok. <sect1><heading>What do all those funky Networking options actually do? <p> Newer kernels have a number of options that you are asked about when you do a <tt>make config</tt>. Generally you will not need to change these, but some of the options might be useful to you in certain circumstances. <descrip> <tag>TCP/IP networking</tag>This one is obvious, it selects whether you configure the tcp/ip suite of protocols into your kernel. Chances are if you are reading this then you will want to answer `y' to this one. <tag>Dummy networking device</tag>This was added to allow SLIP and PPP users to configure an address on their linux machine that would not be dependent on their serial link being established. It is an easy way to give your linux machine two addresses. <tag>IP forwarding/gatewaying</tag>This determines what your kernel will do when it receives a datagram that has a destination address that is not one of its own devices. You <bf>must</bf> have this option selected if you want your kernel to act as an IP router. Most SLIP and PPP servers will want this option selected. <tag>IP multicasting</tag>This is alpha test code support for IP multicasting, examples of which include services such as `Internet Talk Radio' and live video. You will need additional programs to make use of this facility, this is just the kernel support. <tag>IP firewalling</tag>This option allows you to provide flexible security options for your linux machine. You can selectively enable/disable access to tcp/ip ports from any address ranges you choose. This also needs additional programs to support it. <tag>IP accounting</tag>This option is for those people that want to use their Linux machine to provide internet connectivity to others on a commercial basis. It allows you to count and record incoming and outgoing bytes on a per port and address basis. With the addition of suitable software this would allow you to produce seperate usage charges for each person using your systems networking capabilities. <tag>PC/TCP compatibility mode</tag>This option provides a work-around for a bug that causes problems when using the PC/TCP networking programs to talk to your linux machine. There is a PC/TCP bug which provokes a difficult to remedy Linux bug and this option prevents the two clashing. Normally you would leave this disabled, but if you have users on your network who use PC/TCP then you may have to enable this option to prevent problems. <tag>Reverse ARP</tag>This option allows you to configure the RARP protocol into your kernel. This option was added to allow the booting of Sun 3 systems. This is not generally very useful otherwise. <tag>Assume subnets are local</tag>This option selects whether you assume that your whole subnet is directly connected to your linux machine, or whether it might be bridged or otherwise subdivided at a lower layer. In practice it will make little difference if you leave it set at the default. <tag>Disable NAGLE algorithm</tag>This is a timing option that determines when a datagram should be transmitted. The default setting provides for the best throughput in most situations and you should leave this set as it is, as disabling it will degrade your throughput. This option can be selectively changed from within a program with a socket option and you would normally be much better off leaving it set at the default and specifically writing your programs to disable the NAGLE algorithm if they require extremely fast interactivity. <tag>The IPX protocol</tag>This option selects whether you compile the IPX protocol support into your kernel. The IPX protocol is an inter-networking protocol similar in function to the IP protocol. This protocol is one of those used by the Novell suite. <tag>Amateur Radio AX.25 Level 2</tag>This option selects whether you compile in the Amateur Radio AX.25 protocol suite. If you select this option then a new class of network sockets are available for programming. The AX.25 protocol is used primarily by Amateur Radio Operators for packet radio use. </descrip> <sect><heading>Configuring the Network Devices. <p> If everything has gone ok so far, then you will have a Linux kernel which supports the network devices you intend to use and you also have the network tools with which to configure them. <em>Now comes the fun part!</em> You'll need to configure each of the devices you intend to use. This configuration generally amounts to telling each device things like what its IP address will be and what network it is connected to. In past versions of this document I have presented near complete versions of the various configuration files and included comments to modify or delete lines from them as appropriate. From this version onwards I will take a slightly different approach which I hope will result in you having a complete set of uncluttered configuration files that you have built from scratch so you know exactly what is in them and why. I'll describe each of these files, and their function, as we come to them. <sect1><heading>Configuring the special device files in /dev <p> You do not need to configure any special device files in the <tt>/dev</tt> directory for Linux Networking. Linux does not need or use them as other operating systems might. The devices are built dynamically in memory by the kernel and since they are only names there is no need for them to have an appearance directly to you. The kernel provides all of the programming hooks and interfaces that you need to utilize them effectively. <sect1><heading>What information do I need before I begin ? <p> Before you can configure the networking software, you will need to know a number of pieces of information about your network connection. Your network provider or administrator will be able to provide you with most of them. <sect2><heading>IP Address. <p> This is the unique machine address, in dotted decimal notation, that your machine will use. An example is <tt>128.253.153.54</tt>. Your network administrator will provide you with this information. If you will be using a SLIP or plip connection you may not need this information, so skip it until we get to the SLIP device. If you're using the loopback device only, ie no ethernet, SLIP or plip support, then you won't need an ip address as the loopback port always uses the address <tt>127.0.0.1</tt>. <sect2><heading>Network Mask (`netmask'). <p> For performance reasons it is desirable to limit the number of hosts on any particular segment of a network. For this reason it is common for network administrators to divide their network into a number of smaller networks, known as <em>subnets</em>, which each have a portion of the network addresses assigned to them. The <em>network mask</em> is a pattern of bits, which when overlayed onto an address on your network, will tell you which subnetwork it belongs to. This is very important for routing and if you find for example, that you can happily talk to people outside your network, but not to some people on your own network, then it is quite likely that you have specified an incorrect subnet mask. Your network administrators will have chosen the netmask when the network was designed and therefore they should be able to supply you with the correct mask to use. Most networks are class-C subnetworks which use <tt>255.255.255.0</tt> as their netmask. Other larger networks use class-B netmasks (<tt>255.255.0.0</tt>). The NET-2/NET-3 code will automatically select a default mask when you assign an address to a device. The default assumes that your network has <bf>not</bf> been subnetted. The NET-2/NET-3 code will choose the following masks by default: <tscreen><verb> For addresses with the first byte: 1-127 255.0.0.0 (Class A) 128-191 255.255.0.0 (Class B) 192+ 255.255.255.0 (Class C) </verb></tscreen> if one of these doesn't work for you, try another. If this doesn't work ask your network administrator or local network guru (dime a dozen) for help. You don't need to worry about a netmask for the loopback port, or if you are running SLIP/plip. <sect2><heading>Network Address. <p> This is your IP address masked (bitwise AND) with your netmask. For example: <tscreen><verb> If your netmask is: 255.255.255.0 and your IP address is: 128.253.154.32 && --------------- your Network address is: 128.253.154.0 = </verb></tscreen> <sect2><heading>Broadcast Address. <p> <em>`A shout is a whisper that everyone hears whether they need to or not'</em> This is normally your network address logically ORed with your netmask inverted. This is simpler than it sounds. For a Class-C network, with network mask <tt>255.255.255.0</tt>, your <em>Broadcast Address</em> will be your network address (calculated above), logically ORed with <tt>0.0.0.255</tt>, the network mask inverted. A worked example might look like: <tscreen><verb> If your netmask is: 255.255.255.0 ! the netmask inverted is: 0. 0. 0.255 = If your Network address is: 128.253.154.0 || ---------------- Your broadcast address is: 128.253.154.255 = </verb></tscreen> Note that for historical reasons some networks use the network address as the broadcast address. If you have any doubts contact your network administrator. If you have access to a <em>sniffer</em>, or some other device capable of providing you with a trace of your network traffic, then you might be able to determine both the network and broadcast addresses by watching other traffic on the lan. Keep an eye open for, (or filter everything except), ethernet frames destined for the ethernet broadcast address: <tt>ff:ff:ff:ff:ff:ff</tt>. If any of them has an IP source address of your local router and the protocol ID is not ARP, then check the destination IP address, because this datagram may well be a RIP routing broadcast from your router, in which case the destination IP address will be your broadcast address. Once again, if you're not sure, check with your network administrator, they'd rather help you, than have you connect your machine in a misconfigured way. <sect2><heading>Router (`Gateway') Address. <p> <em>`There must be some way out of here.'</em> This is the address of the machine that connects your network to the rest of the Internet. It is your `gateway' to the outside world. A couple of conventions exist for allocating addresses to routers which your network might follow, they are: The router is the lowest numbered address on the network, the router is the highest numbered host on the network. Probably the most common is the first, where the router will have an address that is mostly the same as your own, except with a <tt>.1</tt> as the last byte. eg. if your address is <tt>128.253.154.32</tt>, then your router might be <tt>128.253.154.1</tt>. The router can in fact have any address valid on your network and function properly, the address doesn't matter at all. There may in fact even be more than one router on your network. You will probably need to talk to your network administrator to properly identify your router address. If you're using only loopback then you don't need a router address. If you're using PPP then you also don't need your router address, because PPP will automatically determine the correct address for you. If you're using SLIP, then your router address will be your SLIP server address. <sect2><heading>Nameserver Address. <p> Most machines on the net have access to a name server which translates human tolerable hostnames into machine tolerable addresses and <em>vice versa</em>. Your network administrators will again tell you the address of your nearest nameserver. You can in fact run a nameserver on your own machine by running <em>named</em>, in which case your nameserver address will be <tt>127.0.0.1</tt>, the <em>loopback</em> port address. However it is not required that you run <em>named</em> at all; see section `named' for more information. If you're only using loopback then you don't need to know the nameserver address since you're only going to be talking to your own machine. <sect2><heading>NOTE for SLIP/PLIP/PPP users. <p> You may or may not in fact need to know any of the above information. Whether you do or not will depend on exactly how your network connection is achieved and the capabilities of the machine at the other end of the link. You'll find more detail in the section relevant to configuration of the SLIP/PLIP and PPP devices. <sect1><heading>/etc/rc.d/rc.inet1,2 or /etc/rc.net or /etc/init.d/network <p> While the commands to configure your network devices can be typed manually each time, you will probably want to record them somewhere so that your network is configured automatically when you boot your machine. The <tt>`rc'</tt> files are specifically designed for this purpose. For the non-unix-wizard: <tt>`rc'</tt> file are run at bootup time by the <em>init</em> program and start up all of the basic system programs such as <em>syslog</em>, <em>update</em> and <em>cron</em>. They are analogous to the MS-DOS <em>autoexec.bat</em> file and <em>rc</em> might stand for <em>`runtime commands'</em>. By convention these files are kept under the <tt>/etc</tt> directory. The Linux Filesystem Standard doesn't go so far as to describe exactly where your <tt>rc</tt> files should go, stating that it is ok for them to follow either the BSD (/etc/rc.*) or System-V (/etc/rc.d/rc*) conventions. Alan, Fred and I all use the System-V convention, so that is what you will see described here. This means that these files are found in <tt>/etc/rc.d</tt> and are called <tt>rc.inet1</tt> and <tt>rc.inet2</tt>. The first <tt>rc</tt> file that gets called at bootup time is <tt>/etc/rc</tt> and it in turn calls others, such as <tt>rc.inet1</tt>, which in turn might called <tt>rc.inet2</tt>. It doesn't really matter where they are kept, or what they are called, so long as <em>init</em> can find them. In some distributions the <tt>rc</tt> file for the network is called <tt>rc.net</tt> and is in the <tt>/etc</tt> subdirectory. The <tt>rc.net</tt> file on these systems is simply the <tt>rc.inet1</tt> and the <tt>rc.inet2</tt> files combined into one file that gets executed. Some equivalences: <tscreen><verb> Document Convention Slackware Debian and other newer. =================== =========== ======================= /etc/rc.d/rc.inet1 /etc/rc.net /etc/init.d/network /etc/rc.d/rc.inet2 /etc/rc.net /etc/init.d/netbase /etc/init.d/netstd_init /etc/init.d/netstd_nfs /etc/init.d/netstd_misc </verb></tscreen> <bf>It doesn't matter where the commands appear, so long as you configure the interfaces before starting the network daemons and applications.</bf> I will refer to these files as <em>rc.inet1</em> and <em>rc.inet2</em> and I keep them in the <tt>/etc/rc.d</tt>, so if you are using one of the distributions that uses some other convention, or you want to keep the files somewhere else, then you will have to make appropriate adjustments as you go. We will be building these files from scratch as we go. <sect2><heading>rc.inet1 <p> The <em>rc.inet1</em> file configures the basic tcp/ip interfaces for your machine using two programs: <em>/sbin/ifconfig</em> and <em>/sbin/route</em>. <descrip> <tag>ifconfig</tag><em>/sbin/ifconfig</em> is used for configuring your interfaces with the parameters that they require to function, such as their IP address, network mask, broadcast addresses and similar. You can use the <em>ifconfig</em> command with no parameters to display the configuration of all network devices. Please check the <em>ifconfig</em> man page for more detail on its use. <tag>route</tag><em>/sbin/route</em> is used to create, modify and delete entries in a table (the routing table) that the networking code will look at when it has a datagram that it needs to transmit. The routing table lists destination address and the interface that that address is reachable via. You can use the <em>route</em> command with no parameters to display the contents of the routing table. Please check the <em>route</em> man page for more detail on its use. </descrip> <sect2><heading>rc.inet2 <p> The <em>rc.inet2</em> file starts any network daemons such as <em>inetd</em>, <em>portmapper</em> and so on. This will be covered in more detail in section `rc.inet2', so for the moment we will concentrate on <em>rc.inet1</em>. I have mentioned this file here so that if you have some other configuration, such as a single <em>rc.net</em> file you will understand what the second half of it represents. it is important to remember that you must start your network applications and daemons <bf>after</bf> you have configured your network devices. <sect1><heading>Configuring the Loopback device (mandatory). <p> The loopback device isn't really a hardware device. It is a software construct that looks like a physical interface. Its function is to happily allow you to connect to yourself and to test network software without actually having to be connected to a network of any kind. This is great if you are developing network software and you have a SLIP connection. You can write and test the code locally and then when you are ready to test it on a live network, establish your SLIP connection and test it out. You won't hurt others users if your program misbehaves. By convention, the loopback device always has an IP address of <tt>127.0.0.1</tt> and so you will use this address when configuring it. The loopback device for Linux is called <em>`lo'</em>. You will now make the first entry into your <em>rc.inet1</em> file. The following code fragment will work for you: <tscreen><verb> #!/bin/sh # # rc.inet1 -- configures network devices. # # Attach the loopback device. /sbin/ifconfig lo 127.0.0.1 # # Add a route to point to the loopback device. /sbin/route add 127.0.0.1 # End loopback # </verb></tscreen> You have used the <em>ifconfig</em> program to give the loopback interface its IP address and <em>route</em> program to create an entry in the routing table that will ensure that all datagrams destined for <tt>127.0.0.1</tt> will be sent to the loopback port. There are two important points to note here. Firstly, the netmask and broadcast addresses have been allowed to take the default values for the loopback device described earlier in section `Network Mask'. To see what they are, try the <em>ifconfig</em> program without any arguments. <tscreen><verb> # ifconfig lo Link encap Local Loopback inet addr 127.0.0.1 Bcast 127.255.255.255 Mask 255.0.0.0 UP BROADCAST LOOPBACK RUNNING MTU 2000 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 30 errors 0 dropped 0 overrun 0 # </verb></tscreen> Secondly, its not obvious how the <em>route</em> command chose the loopback device as the device for the route to <tt>127.0.0.1</tt>. The <em>route</em> program is smart enough to know that <tt>127.0.0.1</tt> belongs to the network supported by the loopback device. It works this out by checking the IP address and the netmask. You can use the <em>route</em> command with no arguments to display the contents of the routing table: <tscreen><verb> # route Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.0 * 255.0.0.0 U 0 0 30 lo # </verb></tscreen> <bf>Note:</bf> You might want to use the <tt>-n</tt> argument if your name resolver is not yet configured properly. The <tt>-n</tt> argument tells <em>route</em> to just display the <bf>n</bf>umeric addresses and to not bother looking up the name. <sect1><heading>Configuring an ethernet device. (optional) <p> You'll only be interested in this section if you wish to configure an ethernet card, if not then skip on ahead to the next section. To configure an ethernet card is only slightly more complicated than configuring the loopback device. This time you should probably specify explicitly the network mask and the broadcast address, unless you are sure that the defaults will work ok and they probably will. For this you will need the IP address that you have been assigned, the network mask in use on your network and the broadcast address in use. The first ethernet device for a <em>Linux</em> system is called <em>`eth0'</em>, the second <em>`eth1'</em> and so forth. You will now <bf>add</bf> a section to your <em>rc.inet1</em> file. The following code fragment will work for you if you change the addresses specified for real ones: <tscreen><verb> # # Attach an ethernet device # # configure the IP address, netmask and broadcast address. /sbin/ifconfig eth0 IPA.IPA.IPA.IPA /sbin/ifconfig eth0 netmask NMK.NMK.NMK.NMK /sbin/ifconfig eth0 broadcast BCA.BCA.BCA.BCA # # add a network route to point to it: /sbin/route add -net NWA.NWA.NWA.NWA device eth0 # # End ethernet # </verb></tscreen> Where: <descrip> <tag>IPA.IPA.IPA.IPA</tag>represents your IP Address. <tag>NMK.NMK.NMK.NMK</tag>represents your netmask. <tag>BCA.BCA.BCA.BCA</tag>represents your Broadcast address. <tag>NWA.NWA.NWA.NWA</tag>represents your Network Address. </descrip> Note the use of the <tt>-net</tt> argument to the <em>route</em> command. This tells <em>route</em> that the route to be added is a route to a <em>network</em> and not to a <em>host</em>. There is an alternative method of achieving this, you can leave off the <tt>-net</tt> if you have the network address listed in the <em>/etc/networks</em> file. This is covered later in section `/etc/networks'. <sect1><heading>Configuring a SLIP device (optional) <p> SLIP (Serial Line Internet Protocol) allows you to use tcp/ip over a serial line, be that a phone line with a dialup modem, or a leased line of some sort. Of course to use SLIP you need access to a <em>SLIP-server</em> in your area. Many universities and businesses provide SLIP access all over the world. Slip uses the serial ports on your machine to carry IP datagrams. To do this it must take control of the serial device. Slip device names are named <em>sl0</em>, <em>sl1</em> etc. How do these correspond to your serial devices ? The networking code uses what is called an <em>ioctl</em> (i/o control) call to change the serial devices into SLIP devices. There are two programs supplied that can do this, they are called <em>dip</em> and <em>slattach</em> <sect2><heading>dip <p> <em>dip</em> (Dialup IP) is a smart program that is able to set the speed of the serial device, command your modem to dial the remote end of the link, automatically log you into the remote server, search for messages sent to you by the server and extract information for them such as your IP address and perform the <em>ioctl</em> necessary to switch your serial port into SLIP mode. <em>dip</em> has a powerful scripting ability and it is this that you can exploit to automate your logon procedure. <em>dip</em> used to be supplied with the <em>net-tools</em>, but since development of <em>dip</em> is now seperate, you have to source it seperately. There have been a number of other versions of <em>dip</em> produced which offer a variety of new features. The <tt>dip-uri</tt> version seems to be the more popular, but I suggest you take a close look at each to determine which offers enhancements that you find useful. Since <tt>dip-uri</tt> is is so popular, the examples described in this document are based on current versions of it. You can find it at: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Network/serial/dip337j-uri.tgz </verb></tscreen> To install it, try the following: <tscreen><verb> # # cd /usr/src # gzip -dc dip337j-uri.tgz | tar xvf - # cd dip.3.3.7j <edit Makefile> # make install # </verb></tscreen> <p> The <tt>Makefile</tt> assumes the existence of a group called <em>uucp</em>, but you might like to change this to either <em>dip</em> or <em>SLIP</em> depending on your configuration. <sect2><heading>slattach <p> <em>slattach</em> as contrasted with <em>dip</em> is a very simple program, that is very easy to use, but does not have the sophistication of <em>dip</em>. It does not have the scripting ability, all it does is configure your serial device as a SLIP device. It assumes you have all the information you need and the serial line is established before you invoke it. <em>slattach</em> is ideal to use where you have a permanent connection to your server, such as a physical cable, or a leased line. <sect2><heading>When do I use which ? <p> You would use <em>dip</em> when your link to the machine that is your SLIP server is a dialup modem, or some other temporary link. You would use <em>slattach</em> when you have a leased line, perhaps a cable, between your machine and the server and there is no special action needed to get the link working. See section `Permanent Slip connection' for more information. Configuring SLIP is much like configuring an Ethernet interface (read section `Configuring an ethernet device' above). However there are a few key differences. First of all, SLIP links are unlike ethernet networks in that there is only ever two hosts on the network, one at each end of the link. Unlike an ethernet that is available for use as soon are you are cabled, with SLIP, depending on the type of link you have, you may have to initialize your network connection in some special way. If you are using <em>dip</em> then this would not normally be done at boot time, but at some time later, when you were ready to use the link. It is possible to automate this procedure. If you are using <em>slattach</em> then you will probably want to add a section to your <em>rc.inet1</em> file. This will be described soon. There are two major types of SLIP servers: Dynamic IP address servers and static IP address servers. Almost every SLIP server will prompt you to login using a username and password when dialing in. <em>dip</em> can handle logging you in automatically. <sect2><heading>Static SLIP server with a dialup line and DIP. <p> A static SLIP server in one in which you have been supplied an IP address that is exclusively yours. Each time you connect to the server, you will configure your SLIP port with that address. The static SLIP server will answer your modem call, possibly prompt you for a username and password, and then route any datagrams destined for your address to you via that connection. If you have a static server, then you may want to put entries for your hostname and IP address (since you know what it will be) into your <tt>/etc/hosts</tt>. You should also configure some other files such as: <tt>rc.inet2</tt>, <tt>host.conf</tt>, <tt>resolv.conf</tt>, <tt>/etc/HOSTNAME</tt> and <tt>rc.local</tt>. Remember that when configuring <tt>rc.inet1</tt>, you don't need to add any special commands for your SLIP connection since it is <em>dip</em> that does all of the hard work for you in configuring your interface. You will need to give <em>dip</em> the appropriate information and it will configure the interface for you after commanding the modem to establish the call and logging you into your SLIP server. If this is how your SLIP server works then you can move to section `Using Dip' to learn how to configure <em>dip</em> appropriately. <sect2><heading>Dynamic SLIP server with a dialup line and DIP. <p> A <em>dynamic</em> SLIP server is one which allocates you an IP address randomly, from a pool of addresses, each time you logon. This means that there is no guarantee that you will have any particular address each time, and that address may well be used by someone else after you have logged off. The network administrator who configured the SLIP server will have assigned a pool of address for the SLIP server to use, when the server receives a new incoming call, it finds the first unused address, guides the caller through the login process and then prints a welcome message that contains the IP address it has allocated and will proceed to use that IP address for the duration of that call. Configuring for this type of server is similar to configuring for a static server, except that you must add a step where you obtain the IP address that the server has allocated for you and configure your SLIP device with that. Again, <em>dip</em> does the hard work and new versions are smart enough to not only log you in, but to also be able to automatically read the IP address printed in the welcome message and store it so that you can have it configure your SLIP device with it. If this is how your SLIP server works then you can move to section `Using Dip' to learn how to configure <em>dip</em> appropriately. <sect2><heading>Using DIP. <p> As explained earlier, <em>dip</em> is a powerful program that can simplify and automate the process of dialing into the SLIP server, logging you in, starting the connection and configuring your SLIP devices with the appropriate <em>ifconfig</em> and <em>route</em> commands. Essentially to use <em>dip</em> you'll write a `dip script', which is basically a list of commands that <em>dip</em> understands that tell <em>dip</em> how to perform each of the actions you want it to perform. See <tt>sample.dip</tt> that comes supplied with <em>dip</em> to get an idea of how it works. <em>dip</em> is quite a powerful program, with many options. Instead of going into all of them here you should looks at the <em>man</em> page, README and sample files that will have come with your version of <em>dip</em>. You may notice that the <tt>sample.dip</tt> script assumes that you're using a static SLIP server, so you know what your IP address is beforehand. For dynamic SLIP servers, the newer versions of <em>dip</em> include a command you can use to automatically read and configure your SLIP device with the IP address that the dynamic server allocates for you. The following sample is a modified version of the <tt>sample.dip</tt> that came supplied with <em>dip337j-uri.tgz</em> and is probably a good starting point for you. You might like to save it as <tt>/etc/dipscript</tt> and edit it to suit your configuration: <tscreen><verb> # # sample.dip Dialup IP connection support program. # # This file (should show) shows how to use the DIP # This file should work for Annex type dynamic servers, if you # use a static address server then use the sample.dip file that # comes as part of the dip337-uri.tgz package. # # # Version: @(#)sample.dip 1.40 07/20/93 # # Author: Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG> # main: # Next, set up the other side's name and address. # My dialin machine is called 'xs4all.hacktic.nl' (== 193.78.33.42) get $remote xs4all.hacktic.nl # Set netmask on sl0 to 255.255.255.0 netmask 255.255.255.0 # Set the desired serial port and speed. port cua02 speed 38400 # Reset the modem and terminal line. # This seems to cause trouble for some people! reset # Note! "Standard" pre-defined "errlevel" values: # 0 - OK # 1 - CONNECT # 2 - ERROR # # You can change those grep'ping for "addchat()" in *.c... # Prepare for dialing. send ATQ0V1E1X4\r wait OK 2 if $errlvl != 0 goto modem_trouble dial 555-1234567 if $errlvl != 1 goto modem_trouble # We are connected. Login to the system. login: sleep 2 wait ogin: 20 if $errlvl != 0 goto login_trouble send MYLOGIN\n wait ord: 20 if $errlvl != 0 goto password_error send MYPASSWD\n loggedin: # We are now logged in. wait SOMEPROMPT 30 if $errlvl != 0 goto prompt_error # Command the server into SLIP mode send SLIP\n wait SLIP 30 if $errlvl != 0 goto prompt_error # Get and Set your IP address from the server. # Here we assume that after commanding the SLIP server into SLIP # mode that it prints your IP address get $locip remote 30 if $errlvl != 0 goto prompt_error # Set up the SLIP operating parameters. get $mtu 296 # Ensure "route add -net default xs4all.hacktic.nl" will be done default # Say hello and fire up! done: print CONNECTED $locip ---> $rmtip mode CSLIP goto exit prompt_error: print TIME-OUT waiting for sliplogin to fire up... goto error login_trouble: print Trouble waiting for the Login: prompt... goto error password:error: print Trouble waiting for the Password: prompt... goto error modem_trouble: print Trouble occurred with the modem... error: print CONNECT FAILED to $remote quit exit: exit </verb></tscreen> The above example assumes you are calling a <em>dynamic</em> SLIP server, if you are calling a <em>static</em> SLIP server, then the <tt>sample.dip</tt> file that comes with <em>dip337j-uri.tgz</em> should work for you. <p> When <em>dip</em> is given the <em>get $local</em> command it searches the incoming text from the remote end for a string that looks like an IP address, ie strings numbers separated by `.' characters. This modification was put in place specifically for <em>dynamic</em> SLIP servers, so that the process of reading the IP address granted by the server could be automated. <p> The example above will automatically create a default route via your SLIP link, if this is not what you want, you might have an ethernet connection that should be your default route, then remove the <em>default</em> command from the script. After this script has finished running, if you do an <em>ifconfig</em> command, you will see that you have a device <em>sl0</em>. This is your SLIP device. Should you need to, you can modify its configuration manually, after the <em>dip</em> command has finished, using the <em>ifconfig</em> and <em>route</em> commands. Please note that <em>dip</em> allows you to select a number of different protocols to use with the <tt>mode</tt> command, the most common example is <em>cSLIP</em> for SLIP with compression. Please note that both ends of the link must agree, so you should ensure that whatever you select agrees with what your server is set to. The above example is fairly robust and should cope with most errors. Please refer to the <em>dip</em> man page for more information. Naturally you could, for example, code the script to do such things as redial the server if it doesn't get a connection within a prescribed period of time, or even try a series of servers if you have access to more than one. <sect2><heading>Permanent SLIP connection using a leased line and slattach. <p> If you have a cable between two machines, or are fortunate enough to have a leased line, or some other permanent serial connection between your machine and another, then you don't need to go to all the trouble of using <em>dip</em> to set up your serial link. <em>slattach</em> is a very simple to use utility that will allow you just enough functionality to configure your connection. Since your connection will be a permanent one, you will want to add some commands to your <tt>rc.inet1</tt> file. In essence all you need to do for a permanent connection is ensure that you configure the serial device to the correct speed and switch the serial device into SLIP mode. <em>slattach</em> allows you to do this with one command. <bf>Add</bf> the following to your <tt>rc.inet1</tt> file: <tscreen><verb> # # Attach a leased line static SLIP connection # # configure /dev/cua0 for 19.2kbps and cslip /sbin/slattach -p cslip -s 19200 /dev/cua0 & /sbin/ifconfig sl0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up # # End static SLIP. </verb></tscreen> Where: <descrip> <tag>IPA.IPA.IPA.IPA</tag>represents your IP address. <tag>IPR.IPR.IPR.IPR</tag>represents the IP address of the remote end. </descrip> <em>slattach</em> allocated the first unallocated SLIP device to the serial device specified. <em>slattach</em> starts with <em>sl0</em>. Therefore the first <em>slattach</em> command attaches SLIP device <em>sl0</em> to the serial device specified and <em>sl1</em> the next time, etc. <em>slattach</em> allows you to configure a number of different protocols with the <tt>-p</tt> argument. In your case you will use either <em>SLIP</em> or <em>cSLIP</em> depending on whether you want to use compression or not. Note: both ends must agree on whether you want compression or not. <sect1><heading>Configuring a PLIP device. (optional) <p> <em>plip</em> (Parallel Line IP), is like SLIP, in that it is used for providing a <em>point to point</em> network connection between two machines, except that it is designed to use the parallel printer ports on your machine instead of the serial ports. 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 <em>plip</em> 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. 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 <em>plip</em> interface is compatible with the <em>Crynwyr Packet Driver PLIP</em> and this will mean that you can connect your Linux machine to a DOS machine running any other sort of tcp/ip software via <em>plip</em>. You have two options in using the PLIP driver. You can either compile the driver into your kernel, or use the modules package to load the module dynamically. I recommend just compiling it into your kernel as it is probably the easiest and in most circumstances you will want the driver there all the time anyway. When compiling the kernel, there is only one file that might need to be looked at to configure <em>plip</em>. That file is <tt>/usr/src/linux/driver/net/CONFIG</tt> and it contains <em>plip</em> timers in mS. The defaults 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 <bf>other</bf> computer. The driver assumes the following defaults: <tscreen><verb> device i/o addr IRQ ------ -------- ----- plip0 0x3BC 5 plip1 0x378 7 plip2 0x278 2 (9) </verb></tscreen> If your parallel ports don't match any of the above combinations then you can change the IRQ of a port using the <em>ifconfig</em> command using the `irq' parameter. Be sure to enable IRQ's on your printer ports in your ROM BIOS if it supports this option. <p> To configure a <em>plip</em> interface, you will need to <bf>add</bf> the following lines to your <tt>rc.inet1</tt> file: <tscreen><verb> # # Attach a PLIP interface # # configure first parallel port as a plip device /sbin/ifconfig plip0 IPA.IPA.IPA.IPA pointopoint IPR.IPR.IPR.IPR up # # End plip </verb></tscreen> Where: <descrip> <tag>IPA.IPA.IPA.IPA</tag>represents your IP address. <tag>IPR.IPR.IPR.IPR</tag>represents the IP address of the remote machine. </descrip> The <em>pointopoint</em> 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 <em>plip</em> interface as though it were a <em>SLIP</em> interface, except that neither <em>dip</em> nor <em>slattach</em> need be, nor can be, used. <sect2><heading>PLIP cabling diagram. <p> <em>plip</em> has been designed to use cables with the same pinout as those commonly used by the better known of the MS-DOS based pc-pc file transfer programs. The pinout diagram (taken from <tt>/usr/src/linux/drivers/net/plip.c</tt>) looks as follows: <tscreen><verb> Pin Name Connect pin - pin --------- ------------------------------- GROUND 25 - 25 D0->ERROR 2 - 15 ERROR->D0 15 - 2 D1->SLCT 3 - 13 SLCT->D1 13 - 3 D2->PAPOUT 4 - 12 PAPOUT->D2 12 - 4 D3->ACK 5 - 10 ACK->D3 10 - 5 D4->BUSY 6 - 11 BUSY->D4 11 - 6 D5 7* D6 8* D7 9* STROBE 1* FEED 14* INIT 16* SLCTIN 17* </verb></tscreen> Notes: Do not connect the pins marked with an asterisk `*'. Extra grounds are 18,19,20,21,22,23 and 24. If the cable you are using has a metallic shield, it should be connected to the metallic DB-25 shell at <bf>one end only</bf>. <bf>Warning: A miswired PLIP cable can destroy your controller card.</bf> Be very careful and double check every connection to ensure you don't cause yourself any unnecessary work or heartache. While you may be able to run PLIP cables for long distances, you should avoid it if you can. The specifications for the cable allow for a cable length of about 1 metre or so. Please be very careful when running long plip cables as sources of strong electromagnetic fields such as lightning, power lines and radio transmitters can interfere with and sometimes even damage your controller. If you really want to connect two of your computers over a large distance you really should be looking at obtaining a pair of thin-net ethernet cards and running some coaxial cable. <sect><heading>Routing. (mandatory) <p> After you have configured all of your network devices you need to think about how your machine is going to route IP datagrams. If you have only one network device configured then your choice is easy, as all datagrams for any machine other than yours must go via that interface. If you have more than one network interface then your choice is a little more complicated. You might have both an ethernet device and SLIP connection to your machine at home. In this situation you must direct all datagrams for your machine at home via your SLIP interface and all else via the ethernet device. Routing is actually a very simple mechanism, but don't worry if you find it slightly difficult to understand at first; everybody does. You can display the contents of your routing table by using the <em>route</em> command without any options. There are four commonly used routing mechanisms for unix network configurations. I'll briefly discuss each in turn. <sect1><heading>Static/Manual Routes. <p> Static routing, as its name implies, is `hard coded' routing, that is, it will not change if your network suffers some failure, or if an alternate route becomes available. Static routes are often used in cases where you have a very simple network with no alternate routes available to a destination host, that is, there is only one possible network path to a destination host, or where you want to route a particular way to a host regardless of network changes. In Linux there is a special use for manual routes and that is for adding a route to a SLIP or plip host where you have used the <em>ifconfig pointopoint</em> parameter. If you have a SLIP/plip link and have the <em>pointopoint</em> parameter specifying the address of the remote host, then you should add a static route to that address so that the ip routing software knows how to route datagrams to that address. The <em>route</em> command you would use for the SLIP/plip link via leased line example presented earlier would be: <tscreen><verb> #/sbin/route add IPR.IPR.IPR.IPR </verb></tscreen> Where: <descrip> <tag>IPR.IPR.IPR.IPR</tag>represents the IP address of the remote end. </descrip> <sect1><heading>Default Route. <p> The <em>default route</em> mechanism is probably the most common and most useful to most end-user workstations and hosts on most networks. The <em>default</em> route is a special static route that matches every destination address, so that if there is no more specific route for a datagram to be sent to, then the <em>default</em> route will be used. If you have a configuration where you have only a single ethernet interface, or a single SLIP interface device defined then you should point your default route via it. In the case of an ethernet interface, the Linux kernel knows where to send datagrams for any host on your network. It works this out using the network address and the network mask as discussed earlier. This means that the only datagrams the kernel won't know how to properly route will be those for people not on your network. To make this work you would normally have your default route point to your <em>router</em> address, as it is your means of getting outside of your local network. If you are using a SLIP connection, then your <em>SLIP server</em> will be acting as your <em>router</em>, so your default route will be via your <em>SLIP server</em>. To configure your default route, <bf>add</bf> the following to your <tt>rc.inet1</tt> <bf>after</bf> all of your network device configurations: <tscreen><verb> # # Add a default route. # /sbin/route add default gw RGA.RGA.RGA.RGA # </verb></tscreen> Where: <descrip> <tag>RGA.RGA.RGA.RGA</tag>represents your Router/Gateway Address. </descrip> <sect1><heading>Proxy ARP. <p> <bf>This method is ugly, hazard prone and should be used with extreme care</bf>, some of you will want to use it anyway. Those with the greatest need for <em>proxy arp</em> will be those of you who are configuring your Linux machine as a SLIP dial-in server. For those of you who will be using PPP, the PPP daemon simplifies and automates this task, making it a lot safer to use. Normally when a tcp/ip host on your ethernet network wants to talk to you, it knows your IP address, but doesn't know what hardware (ethernet) address to send datagrams to. The ARP mechanism is there specifically to provide that mapping function between network address and hardware address. The ethernet protocol provides a special address that is recognised by all ethernet cards, this is called the broadcast address. ARP works by sending a specially formatted datagram containing the IP address of the host it wishes to discover the hardware address of and transmits it to the ethernet broadcast address. Every host will receive this datagram and the host that is configured with the matching IP address will reply with its hardware address. The host that performed the arp will then know what hardware address to use for the desired IP address. If you want to use your machine as a server for other machines, you must get your machine to answer ARP requests for their IP addresses on their behalf, as they will not be physically connected to the ethernet network. Lets say that you have been assigned a number of IP addresses on your local network that you will be offering to dial-in SLIP users. Lets say those addresses are: <tt>128.253.154.120-124</tt> and that you have an ethernet card with a hardware address of <tt>00:00:C0:AD:37:1C</tt>. (You can find the hardware address of your ethernet card by using the <em>ifconfig</em> command with no options). To instruct your Linux server to answer arp requests by proxy for these addresses you would need to <bf>add</bf> the following commands to the end of your <tt>rc.inet1</tt> file: <tscreen><verb> # # Proxy ARP for those dialin users who will be using this # machine as a server: # /sbin/arp -s 128.263.154.120 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.121 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.122 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.123 00:00:C0:AD:37:1C pub /sbin/arp -s 128.263.154.124 00:00:C0:AD:37:1C pub # # End proxy arps. </verb></tscreen> The <tt>pub</tt> argument stands for <em>`publish'</em>. It is this argument that instructs your machine to answer requests for these addresses, even though they are not for your machine. When it answers it will supply the hardware address specified, which is of course its own hardware address. Naturally you will need to ensure that you have routes configured in your linux server that point these addresses to the SLIP device on which they will be connecting. If you are using PPP, you don't need to worry about manually messing with the arp table, as the <em>pppd</em> will manage those entries for you if you use the <em>proxyarp</em> parameter and as long as the IP addresses of the remote machine and the server machine are in the same network. You will need to supply the netmask of the network on the server's <em>pppd</em> command line. <sect1><heading>gated - the routing daemon. <p> <em>gated</em> could be used in place of <em>proxy arp</em> in some cases and would certainly be much cleaner, but its primary use is if you want your linux machine to act as an intelligent <em>ip router</em> for your network. <em>gated</em> provides support for a number of routing protocols. Among these are RIP, BGP, EGP, HELLO and OSPF. The most commonly used in small networks being <em>rip</em>. <em>rip</em> stands for <em>`Routing Information Protocol'</em>. If you run <em>gated</em>, configured for <em>rip</em>, your linux machine will periodically broadcast a copy of its <em>routing table</em> to your network in a special format. In this way, all of the other machines on your network will know what addresses are accessible via your machine. <em>gated</em> can be used to replace <em>proxy arp</em> when all hosts on your network run either <em>gated</em> or <em>routed</em>. If you have a network where you use a mixture of manual and dynamic routes, you should mark any manual routes as <tt>passive</tt> to ensure that they aren't destroyed by <em>gated</em> because it hasn't received an update for them. The best way to add static routes if you are using <em>gated</em> is to add a <tt>static</tt> stanza to your <tt>/etc/gated.conf</tt> file. This is described below. <em>gated</em> would normally be started from your <tt>rc.inet2</tt> which is covered in the next section. You might already see a daemon called <em>routed</em> running. <em>gated</em> is superior to <em>routed</em> in that it is more flexible and more functional. So you should use <em>gated</em> and not <em>routed</em>. <sect2><heading>Obtaining <em>gated</em> <p> Gated is available from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Network/daemons/gated11_bin.tgz </verb></tscreen> <sect2><heading>Installing <em>gated</em> <p> The <em>gated</em> binary distribution comprises three programs and two sample configuration files. The programs are: <descrip> <tag>gated </tag>the actual <em>gated</em> daemon. <tag>gdc </tag>the operational user interface for <em>gated</em>. <em>gdc</em> is for controlling the <em>gated</em> daemon, stopping and starting it, obtaining its status and the like. <tag>ripquery </tag>a diagnostic tool to query the known routes of a gateway using either a `rip query' or a `rip poll'. </descrip> The configuration files are: <descrip> <tag>gated.conf </tag>this is the actual configuration file for the <em>gated</em> daemon. It allows you to specify how <em>gated</em> will behave when it is running. You can enable and disable any of the routing protocols and control the behaviour of those routing protocols running. <tag>gated.version </tag>a text file that describes the version number of the <em>gated</em> daemon </descrip> The <em>gated</em> binary distribution will not install the <em>gated</em> files in the correct place for you. Fortunately there aren't very many, so its fairly simple to do. To install the binaries try the following: <tscreen><verb> # cd /tmp # gzip -dc .../gated.linux.bin.tgz | tar xvf - # install -m 500 bin/gated /usr/sbin # install -m 444 bin/gated.conf bin/gated.version /etc # install -m 555 bin/ripquery bin/gdc /sbin # rm -rf /tmp/bin </verb></tscreen> I keep the networking daemons in <tt>/usr/sbin</tt>, if yours are somewhere else then naturally you'll have to change the target directory. The sample <em>gated</em> configuration file included configures <em>gated</em> to emulate the old <em>routed</em> daemon. It will probably work for you in most circumstances and it looks like this: <tscreen><verb> # # This configuration emulates routed. It runs RIP and only sends # updates if there are more than one interfaces up and IP forwarding is # enabled in the kernel. # # NOTE that RIP *will not* run if UDP checksums are disabled in # the kernel. # rip yes ; traceoptions all; # </verb></tscreen> If you have any static routes you wish to add, you can add them in a <tt>static</tt> stanza appended to your <tt>/etc/gated.conf</tt> as follows: <tscreen><verb> # static { 37.0.0.0 mask 255.0.0.0 gateway 44.136.8.97 ; host 44.136.8.100 gateway 44.136.8.97 ; } ; # </verb></tscreen> The above example would create a static route to the Class A network <tt>37.0.0.0</tt> via gateway <tt>44.136.8.97</tt> and a static route to a host with address <tt>44.136.8.100</tt> via gateway <tt>44.136.8.97</tt>. If you do this you do not need to add the routes using the <em>route</em> command, <em>gated</em> will add and manage the routes for you. <p> To install the <em>man</em> files, try the following: <tscreen><verb> # cd /tmp # gzip -dc .../gated.linux.man.tgz | tar xvf - # install -m 444 man/*.8 /usr/man/man8 # install -m 444 man/*.5 /usr/man/man5 # rm -rf /tmp/man </verb></tscreen> The <em>man</em> files contain concise and detailed information on the configuration and use of <em>gated</em>. For information on configuring <em>gated</em>, refer to the <tt>gated-config</tt> <em>man</em> page. <sect><heading>Configuring the network daemons. <p> As mentioned earlier, there are other files that you will need to complete your network installation. These files concern higher level configurations of the network software. Each of the important ones are covered in the following sub-sections, but you will find there are others that you will have to configure as you become more familiar with the network suite. <sect1><heading>/etc/rc.d/rc.inet2 (the second half of rc.net) <p> If you have been following this document you should at this stage have built an <em>rc</em> file to configure each of your network devices with the correct addresses and set up whatever routing you will need for your particular network configuration. You will now need to actually start some of the higher level network software. Now would be a really good time to read Olaf's <em>Network Administrators Guide</em>, as it really should be considered the definitive document for this stage of the configuration process. It will help you decide what to include in this file and more importantly perhaps, what <bf>not</bf> to include in this file. For the security conscious it is a fair statement to say that the more network services you have running, the more likely the chance of your system having a security hole: Run only what you need. There are some very important <em>daemons</em> (system processes that run in the background) that you will need to know a little about. The <em>man</em> pages will tell you more, but they are: <sect2><heading>inetd. <p> <em>inetd</em> is a program that sits in the background and manages internet connection requests and the like. It is smart enough that you don't need to leave a whole bunch of servers running when there is nothing connected to them. When it sees an incoming request for a particular service, eg <em>telnet</em>, or <em>ftp</em>, it will check the <tt>/etc/services</tt> file, find what server program needs to be run to manage the request, start it and hand the connection over to it. Imagine it as a master server for your internet servers. It also has a few simple standard services inbuilt. These are <em>echo</em>, <em>discard</em> and <em>generate</em> services used for various types of network testing. <em>inetd</em> doesn't manage <bf>all</bf> servers and services that you might run, but it manages most of the usual ones. Normally services such as <tt>udp</tt> based services, or services that manage their own connection multiplexing such as World Wide Web servers or muds would be run independently of <em>inetd</em>. Generally the documentation accompanying such servers will tell you whether to use <em>inetd</em> or not. <sect2><heading>syslogd. <p> <em>syslogd</em> is a daemon that handles all system logging. It accepts messages generated for it and will distribute them according to a set of rules contained in <tt>/etc/syslogd.conf</tt>. For example, certain types of messages you will want to send to the console and also to a log file, where others you will want only to log to a file. <em>syslogd</em> allows you to specify what messages should go where. <sect1><heading>A sample rc.inet2 file. <p> The following is a sample rc.inet2 file that Fred built. It starts a large number of servers, so you might want to trim it down to just those services that you actually want to run. To trim it down, simply delete or comment out the stanzas (<em>if</em> to <em>fi</em>) that you don't need. All each stanza does is test that the relevant module is a file, that it exists, echoes a comment that you can see when you boot your machine and then executes the commands with the arguments supplied to ensure that it runs happily in the background. For more detailed information on each of the deamons, check either the <em>Network Administrators Guide</em> or the relevant <em>man</em> pages. <tscreen><verb> #! /bin/sh # # rc.inet2 This shell script boots up the entire INET system. # Note, that when this script is used to also fire # up any important remote NFS disks (like the /usr # distribution), care must be taken to actually # have all the needed binaries online _now_ ... # # Version: @(#)/etc/rc.d/rc.inet2 2.18 05/27/93 # # Author: Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org> # # Constants. NET="/usr/sbin" IN_SERV="lpd" LPSPOOL="/var/spool/lpd" # At this point, we are ready to talk to The World... echo -e "\nMounting remote file systems ..." /bin/mount -t nfs -v # This may be our /usr runtime!!! echo -e "\nStarting Network daemons ..." # Start the SYSLOG daemon. This has to be the first server. # This is a MUST HAVE, so leave it in. echo -n "INET: " if [ -f ${NET}/syslogd ] then echo -n "syslogd " ${NET}/syslogd fi # Start the SUN RPC Portmapper. if [ -f ${NET}/rpc.portmap ] then echo -n "portmap " ${NET}/rpc.portmap fi # Start the INET SuperServer # This is a MUST HAVE, so leave it in. if [ -f ${NET}/inetd ] then echo -n "inetd " ${NET}/inetd else echo "no INETD found. INET cancelled!" exit 1 fi # Start the NAMED/BIND name server. # NOTE: you probably don't need to run named. #if [ ! -f ${NET}/named ] #then # echo -n "named " # ${NET}/named #fi # Start the ROUTEd server. # NOTE: routed is now obsolete. You should now use gated. #if [ -f ${NET}/routed ] #then # echo -n "routed " # ${NET}/routed -q #-g -s #fi # Start the GATEd server. if [ -f ${NET}/gated ] then echo -n "gated " ${NET}/gated fi # Start the RWHO server. if [ -f ${NET}/rwhod ] then echo -n "rwhod " ${NET}/rwhod -t -s fi # Start the U-MAIL SMTP server. if [ -f XXX/usr/lib/umail/umail ] then echo -n "umail " /usr/lib/umail/umail -d7 -bd &etago;dev/null >/dev/null 2>&1 & fi # Start the various INET servers. for server in ${IN_SERV} do if [ -f ${NET}/${server} ] then echo -n "${server} " ${NET}/${server} fi done # Start the various SUN RPC servers. if [ -f ${NET}/rpc.portmap ] then if [ -f ${NET}/rpc.ugidd ] then echo -n "ugidd " ${NET}/rpc.ugidd -d fi if [ -f ${NET}/rpc.mountd ] then echo -n "mountd " ${NET}/rpc.mountd fi if [ -f ${NET}/rpc.nfsd ] then echo -n "nfsd " ${NET}/rpc.nfsd fi # Fire up the PC-NFS daemon(s). if [ -f ${NET}/rpc.pcnfsd ] then echo -n "pcnfsd " ${NET}/rpc.pcnfsd ${LPSPOOL} fi if [ -f ${NET}/rpc.bwnfsd ] then echo -n "bwnfsd " ${NET}/rpc.bwnfsd ${LPSPOOL} fi fi echo network daemons started. # Done! </verb></tscreen> <sect1><heading>Other necessary network configuration files. <p> There are other network configuration files that you will need to configure if you want to have people connect to and use your machine as a host. If you have installed your linux from a distribution then you will probably already have copies of these files so just check them to make sure they look ok and if not you can use the following samples. <sect2><heading>A sample /etc/inetd.conf file. <p> Your <tt>/etc/rc.d/rc.inet2</tt> file will have started <em>inetd</em>, <em>syslogd</em> and the various <em>rpc</em> servers for you. You will now need to configure the network daemons that will be managed by <em>inetd</em>. <em>inetd</em> uses a configuration file called <tt>/etc/inetd.conf</tt>. The following is an example of how a simple configuration might look: <tscreen><verb> # # The internal services. # # Authors: Original taken from BSD UNIX 4.3/TAHOE. # Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org> # echo stream tcp nowait root internal echo dgram udp wait root internal discard stream tcp nowait root internal discard dgram udp wait root internal daytime stream tcp nowait root internal daytime dgram udp wait root internal chargen stream tcp nowait root internal chargen dgram udp wait root internal # # Standard services. # ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd ftpd telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # # Shell, login, exec and talk are BSD protocols. # shell stream tcp nowait root /usr/sbin/tcpd in.rshd login stream tcp nowait root /usr/sbin/tcpd in.rlogind exec stream tcp nowait root /usr/sbin/tcpd in.rexecd talk dgram udp wait root /usr/sbin/tcpd in.talkd ntalk dgram udp wait root /usr/sbin/tcpd in.talkd # # Status and Information services. # finger stream tcp nowait root /usr/sbin/tcpd in.fingerd systat stream tcp nowait guest /usr/sbin/tcpd /usr/bin/ps -auwwx netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat # # End of inetd.conf. </verb></tscreen> The <em>inetd</em> man page describes what each of the fields are, but put simply, each entry describes what program should be executed when an incoming connection is received on the socket listed as the first entry. Those entries which have <tt>incoming</tt> where the program name and arguments would be are those services that are provided internally by the <em>inetd</em> program. The conversion between the service name in the first column and the actual socket number it refers to is performed by the <tt>/etc/services</tt> file. <sect2><heading>A sample /etc/services file. <p> The <tt>/etc/services</tt> file is a simple table of Internet service names and the socket number and protocol is uses. This table is used by a number of programs including <em>inetd</em>, <em>telnet</em> and <em>tcpdump</em>. It makes life a little easier by allowing us to refer to services by name rather than by number. The following is a sample of what a simple <tt>/etc/services</tt> file might look like: <tscreen><verb> # # /etc/services - database of service name, socket number # and protocol. # # Original Author: # Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org> # tcpmux 1/tcp echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/tcp daytime 13/udp netstat 15/tcp chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp 21/tcp telnet 23/tcp smtp 25/tcp mail time 37/tcp timserver time 37/udp timserver name 42/udp nameserver whois 43/tcp nicname # usually to sri-nic domain 53/tcp domain 53/udp finger 79/tcp link 87/tcp ttylink hostnames 101/tcp hostname # usually to sri-nic sunrpc 111/tcp sunrpc 111/tcp portmapper # RPC 4.0 portmapper TCP sunrpc 111/udp sunrpc 111/udp portmapper # RPC 4.0 portmapper UDP auth 113/tcp authentication nntp 119/tcp usenet # Network News Transfer ntp 123/tcp # Network Time Protocol ntp 123/udp # Network Time Protocol snmp 161/udp snmp-trap 162/udp exec 512/tcp # BSD rexecd(8) biff 512/udp comsat login 513/tcp # BSD rlogind(8) who 513/udp whod # BSD rwhod(8) shell 514/tcp cmd # BSD rshd(8) syslog 514/udp # BSD syslogd(8) printer 515/tcp spooler # BSD lpd(8) talk 517/udp # BSD talkd(8) ntalk 518/udp # SunOS talkd(8) route 520/udp routed # 521/udp too timed 525/udp timeserver mount 635/udp # NFS Mount Service pcnfs 640/udp # PC-NFS DOS Authentication bwnfs 650/udp # BW-NFS DOS Authentication listen 1025/tcp listener # RFS remote_file_sharing ingreslock 1524/tcp # ingres lock server nfs 2049/udp # NFS File Service irc 6667/tcp # Internet Relay Chat # End of services. </verb></tscreen> The <em>telnet</em> entry tells us that the <em>telnet</em> service uses socket number 23 and the <em>tcp</em> protocol. The <em>domain</em> entry tells us that the Domain Name Service uses socket number 52 and both <em>tcp</em> and <em>udp</em> protocols. You should have an appropriate <tt>/etc/services</tt> entry for each <tt>/etc/inetd.conf</tt> entry. <sect2><heading>A sample /etc/protocols file. <p> The <tt>/etc/protocols</tt> file is a table of protocol name with its corresponding protocol number. Since the number of protocols in use is small this file is quite trivial. <tscreen><verb> # # /etc/protocols - database of protocols. # # Original Author: # Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org> # ip 0 IP # internet protocol icmp 1 ICMP # internet control message protocol igmp 2 IGMP # internet group multicast protocol ggp 3 GGP # gateway-gateway protocol tcp 6 TCP # transmission control protocol pup 12 PUP # PARC universal packet protocol udp 17 UDP # user datagram protocol idp 22 IDP raw 255 RAW # # End of protocols. </verb></tscreen> <sect1><heading>Name Resolution. <p> Name Resolution is the process of converting a hostname in the familiar dotted notation (e.g. <tt>tsx-11.mit.edu</tt>) into an IP address which the network software understands. There are two principal means of achieving this in a typical installation, one simple and one more complex. <sect2><heading>/etc/hosts <p> <tt>/etc/hosts</tt> contains a list of ip addresses and the hostnames they map to. In this way, you can refer to other machines on the network by name, as well as their ip address. Using a nameserver (see section `named') allows you to do the same name->ip address translation automatically. (Running <em>named</em> allows you to run your own nameserver on your linux machine). This file needs to contain at least an entry for <tt>127.0.0.1</tt> with the name <tt>localhost</tt>. If you're not only using loopback, you need to add an entry for your ip address, with your full hostname (such as <tt>loomer.vpizza.com</tt>). You may also wish to include entries for your gateways and network addresses. For example, if <tt>loomer.vpizza.com</tt> has the ip address <tt>128.253.154.32</tt>, the <tt>/etc/hosts</tt> file would contain: <tscreen><verb> # /etc/hosts # List of hostnames and their ip addresses 127.0.0.1 localhost 128.253.154.32 loomer.vpizza.com loomer # end of hosts </verb></tscreen> Once again you will need to edit this file to suit your own needs. If you're only using loopback, the only line in <tt>/etc/hosts</tt> should be for <tt>127.0.0.1</tt>, with both <tt>localhost</tt> and your hostname after it. Note that in the second line, above, there are two names for <tt>128.253.154.32</tt>: <tt>loomer.vpizza.com</tt> and just <tt>loomer</tt>. The first name is the full hostname of the system, called the "Fully Qualified Domain Name" and the second is an alias for it. The second allows you to type only <em>rlogin loomer</em> instead of having to type the entire hostname. You should ensure that you put the Fully Qualified Domain Name in the line before the alias name. <sect2><heading>named - do I need thee ? <p> <em>`I dub thee ..'</em> <em>named</em> is the nameserver daemon for many unix-like operating systems. It allows your machine to serve the name lookup requests, not only for itself, but also for other machines on the network, that is, if another machine wants to find the address for <tt>`goober.norelco.com'</tt> and you have this machines address in your <em>named</em> database, then you can service the request and tell other machines what <tt>`goobers'</tt> address is. Under older implementations of Linux tcp/ip, to create aliases for machine names, (even for your own machine), you had to run <em>named</em> on your Linux machine to do the hostname to IP address conversion. One problem with this is that <em>named</em> is comparatively difficult to set up properly and maintain. To solve this problem, a program called <tt>hostcvt.build</tt> was made available on Linux systems to translate your <tt>/etc/hosts</tt> file into the many files that make up <em>named</em> database files. However even with this problem overcome, <em>named</em> still uses CPU overhead and causes network traffic. The only reason you may want to run <em>named</em> would be if: <itemize> <item>You're setting up a network of machines and need a nameserver for one of them and don't have a nameserver out on the net somewhere. <item>Your network administrators want you to run your Linux system as a nameserver for some reason. <item>You have a slow SLIP connection and want to run a small cache-only nameserver on your Linux machine so that you don't have to go out on the serial line for every name lookup that occurs. If you're only going to be connecting to a small number of hosts on the net and you know what their addresses are, then you can put them in your <tt>hosts</tt> file and not need to query a nameserver at all. Generally namelookup isn't that slow and should work fine over a SLIP link anyway. <item>You want to run a nameserver for fun and excitement. </itemize> In general, <bf>you do NOT need to run named</bf>: this means that you can comment it out from your <tt>rc.inet2</tt> file and you don't have to run <tt>hostcvt.build</tt>. If you want to alias machine names, for example, if you want to refer to <tt>loomer.vpizza.com</tt> as just <tt>loomer</tt>, then you can add as alias in <tt>/etc/hosts</tt> instead. There is no reason to run <em>named</em> unless you have a specific requirement to do so. If you have access to a nameserver, (and your network administrators will tell you its address) and most networks do, then don't bother running <em>named</em>. If you're only using loopback, you can run <em>named</em> and set your nameserver address to <tt>127.0.0.1</tt>, but since you are the only machine you can talk to, this would be quite bizarre, as you'd never need to call it. <sect2><heading>/etc/networks <p> The <tt>/etc/networks</tt> file lists the names and addresses of your own, and other, networks. It is used by the <em>route</em> command and allows you to specify a network by name, should you so desire. Every network you wish to add a route to using the <em>route</em> command should have an entry in the <tt>/etc/networks</tt> file, unless you also specify the <tt>-net</tt> argument in the <em>route</em> command line. Its format is similar to that of <tt>/etc/hosts</tt> file above and an example file might look like: <tscreen><verb> # # /etc/networks: list all networks that you wish to add route commands # for in here # default 0.0.0.0 # default route - recommended loopnet 127.0.0.0 # loopback network - recommended mynet 128.253.154.0 # Example network CHANGE to YOURS # # end of networks </verb></tscreen> <sect2><heading>/etc/host.conf <p> The system has some library functions called the resolver library. This file specifies how your system will lookup host names. It should contain at least the following two lines: <tscreen><verb> order hosts,bind multi on </verb></tscreen> These two lines tell the <em>resolve</em> libraries to first check the <tt>/etc/hosts</tt> file and then to ask the nameserver (if one is present). The <em>multi</em> entry allows you to have multiple IP addresses for a given machine name in <tt>/etc/hosts</tt>. This file comes from the implementation of the <em>resolv+</em> bind library for Linux. You can find further documentation in the <em>resolv+(8)</em> man page if you have it. If you don't, it can be obtained from: <bf>sunsite.doc.ic.ac.uk</bf> <tscreen<verb> /computing/comms/tcpip/nameserver/resolv+/resolv+2.1.1.tar.Z </verb></tscreen> This file contains the <em>resolv+.8</em> man page for the resolver library. <sect2><heading>/etc/resolv.conf <p> This file actually configures the system name resolver and contains two types of entries: The addresses of your nameservers (if any) and the name of your domain, if you have one. If you're running your own nameserver (i.e running <em>named</em> on your Linux machine), then the address of your nameserver is <tt>127.0.0.1</tt>, the loopback address. Your domain name is your fully qualified hostname (if you're a registered machine on the Internet, for example), with the hostname component removed. That is, if your full hostname is <tt>loomer.vpizza.com</tt>, then your domain name is <tt>vpizza.com</tt>, without the hostname <tt>loomer</tt>. For example, if you machine is <tt>goober.norelco.com</tt> and has a nameserver at the address <tt>128.253.154.5</tt>, then your <tt>/etc/resolv.conf</tt> file would look like: <tscreen><verb> domain norelco.com nameserver 128.253.154.5 </verb></tscreen> You can specify more than one nameserver. Each one must have a <em>nameserver</em> entry in the <tt>resolv.conf</tt> file. Remember, if you're running on loopback, you don't need a nameserver. <sect2><heading>Configuring your Hostname - /etc/HOSTNAME <p> After you have configured everything else, there is one small task that remains, you need to configure your own machine with a name. This is so that application programs like <em>sendmail</em> can know who you are to accept mail and so that your machine can identify itself to other machines that it might be connected to. There are two programs that are used to configure this sort of information, and they are commonly misused. They are <em>hostname</em> and <em>domainname</em>. If you are using a release of <tt>net-tools</tt> earlier than <tt>1.1.38</tt> then you can include a command in your <tt>/etc/rc</tt> file that looks like this: <tscreen><verb> /bin/hostname -S </verb></tscreen> and this will cause the <em>hostname</em> command to read a file called <tt>/etc/HOSTNAME</tt> which it expects will contain a "Fully Qualified Domain Name", that is, your machines hostname <bf>including</bf> the domainname. It will split the F.Q.D.N. into its DNS hostname and domainname components and set them appropriately for you. For example, the machine above would have the file <tt>/etc/HOSTNAME</tt>: <tscreen><verb> goober.norelco.com </verb></tscreen> If you are using the <em>hostname</em> that came with <tt>net-tools-1.1.38</tt> or later, then you would add a command at the end of your <tt>/etc/rc.d/rc.inet1</tt> file like: <tscreen><verb> /bin/hostname goober.norelco.com </verb></tscreen> or if you have upgraded from a previous release, you could add: <tscreen><verb> /bin/hostname -F /etc/HOSTNAME </verb></tscreen> and it would behave in the same way as for the earlier version. The <tt>/bin/domainname</tt> command is for setting the <bf>N.I.S.</bf> domain name <bf>NOT</bf> the D.N.S. domain name. You do not need to set this unless you are running <em>NIS</em>, which is briefly described later. <sect1><heading>Other files. <p> There are of course many other files in the <tt>/etc</tt> directory which you may need to dabble with later on. Instead of going into them here, I'm going to provide the bare minimum to get you on the net. More information is available in Olaf's <em>Network Administration Guide</em>. It picks up where this <em>HOWTO</em> ends and some more information will be provided in later versions of this document. Once you have all of the files set up and everything in the right place, you should be able to reboot your new kernel and net away to your hearts content. However I strongly suggest that you keep a bootable copy of your old kernel and possibly even a `recovery disk' in case something goes wrong so that you can get back in and fix it. You might try HJLu's `single disk boot disk', or `disk1' from a Linux distribution. <sect><heading>Advanced Configurations. <p> The configurations above have described how a typical Linux workstation might be configured for normal end-user operation. Some of you will have other requirements which will require slightly more advanced configurations. What follows are examples of some the more common of these. The details of the AX.25, Ottawa PI and generic SCC drivers have been moved to the <url url="http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html" name="HAM-HOWTO">. <sect1><heading>PPP - Point to Point Protocol. <p> The <em>Point to Point Protocol</em> is a modern and efficient protocol for conveying multiple protocols, tcp/ip for one, across serial links, that a lot of people use in place of SLIP. It offers enhanced functionality, error detection and security options. It corrects a number of deficiencies that are found in SLIP and is suitable for both asynchronous links and synchronous links alike. An important feature of PPP operation is the ability to negotiate such parameters as IP address allocation automatically and with ease and this feature will almost certainly be exploited by your PPP server. This feature allows a PPP client, with a specially formatted frame, to request its address from the server. In this way configuration is somewhat less messy than with SLIP, since this ability to retrieve your address must occur outside of the protocol. The authors of the Linux port are <tt>Michael Callahan, <callahan@maths.ox.ac.uk></tt> and <tt> Al Longyear, <longyear@netcom.com></tt>. Most of this information has come from the documentation that accompanies the PPP software. The documentation is quite complete and will tell you much more than I present here. The Linux PPP code is now well and truly a public release. The 1.0.0 Linux PPP code is based on Paul Mackerras's free PPP for BSD-derivative operating systems. The 1.0.0 release is based on version 2.1.1 of the free PPP code. The PPP code comes in two parts. The first is a kernel module which handles the assembly and disassembly of the frames and the second is a set of protocols called LCP, IPCP, UPAP and CHAP, for negotiating link options, bringing the link into a functioning state and for authentication. <sect2><heading>Why would I use PPP in place of SLIP ? <p> You would use PPP in place of SLIP for a few reasons. The most common are: <descrip> <tag>Your Internet Provider supports only PPP </tag>The most obvious reason you would use PPP in favour of SLIP is when your Internet Provider supports PPP and not SLIP. Ok, I said it was obvious. <tag>You have a normally noisy serial line </tag>PPP provides a frame check sequence for each and every frame transmitted, SLIP does not. If you have a noisy serial line and you are using SLIP, your error correction will be performed end to end, that is between your machine and the destination machine, whereas with PPP the error detection occurs locally, between your machine and the PPP server. This makes for faster recovery from errors. <tag>You need to make use of some other feature PPP offers. </tag>PPP provides a number of features that SLIP does not. You might for example want to carry not only IP, but also DECNET, or AppleTalk frames over your serial link. PPP will allow you to do this. </descrip> <sect2><heading>Where to obtain the PPP software. <p> The PPP software is available from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Networking/serial/ppp-2.1.2d.tar.gz </verb></tscreen> This file contains the kernel source and the <em>pppd</em> source and binary. Version 1.0.0 is meant for use with kernels 1.0.x and 1.1.x. Version 2.1.2 is intended for kernel version 1.2.x, and the latest 2.2.0 pppd is intended for kernels 1.3.x. <sect2><heading>Installing the PPP software. <p> Installation of the PPP software is fairly straightforward. <sect3><heading>The kernel driver. <p> Some support for <em>ppp</em> has been built into the kernel for some time. so you are advised to run a modern kernel. Configuring the kernel is fairly easy, the following should work ok: <tscreen><verb> # make config (remembering to answer yes to PPP support) # make dep # make (remember to install the new kernel after recompiling!) </verb></tscreen> When you reboot with the new kernel you should see messages at boot time that look something like these: <tscreen><verb> PPP: version 0.2.7 (4 channels) NEW_TTY_DRIVERS OPTIMIZE_FLAGS TCP compression code copyright 1989 Regents of the University of California PPP line discipline registered. </verb></tscreen> These indicate that the PPP support has in fact been compiled into your kernel. Now, try looking at the contents of <tt>/proc/net/dev</tt>. You should be careful not to use <em>more</em> or <em>less</em> on the files in the <tt>/proc</tt> filesystem, as some of them check the filesize first and it is a feature of the <tt>/proc</tt> filesystem that the files are zero length, so use: <tscreen><verb> # cat /proc/net/dev </verb></tscreen> It should look something like this: <tscreen><verb> Inter-| Receive | Transmit face |packets errs drop fifo frame|packets errs drop fifo colls carrier lo: 0 0 0 0 0 0 0 0 0 0 0 ppp0: 0 0 0 0 0 0 0 0 0 0 0 ppp1: 0 0 0 0 0 0 0 0 0 0 0 ppp2: 0 0 0 0 0 0 0 0 0 0 0 ppp3: 0 0 0 0 0 0 0 0 0 0 0 </verb></tscreen> This indicates that the kernel driver is installed correctly. <sect3><heading>pppd <p> To extract the ppp software and associated utilities the following should work ok: <tscreen><verb> # cd /usr/src # gzip -dc ppp-2.1.2d.tar.gz | tar xvf - </verb></tscreen> If you want to recompile <em>pppd</em>, type <em>make</em> in the <tt>pppd</tt> subdirectory of the installation. There will be some warnings when compiling <tt>lcp.c</tt>, <tt>upap.c</tt> and <tt>chap.c</tt> but these are OK. If you want to recompile <em>chat</em>, consult <tt>README.linux</tt> in the <tt>chat</tt> directory. To install, type <em>make install</em> in the <tt>chat</tt> and <tt>pppd</tt> directories. This will put <em>chat</em> and <em>pppd</em> binaries in <tt>/usr/sbin</tt> and the <tt>pppd.8</tt> manual page in <tt>/usr/man/man8</tt>. <tt>pppd</tt> needs to be run as <tt>root</tt>. You can either make it suid root or just use it when you are root. <em>make install</em> will try to install it suid root, so if you are root when you try to install it, it should work ok. <sect2><heading>Configuring and using the PPP software. <p> Like SLIP, you can configure the PPP software as either a client or a server. The <em>chat</em> program performs a similar function to the <em>dip</em> program in that it is used to automate the dialing and login procedure to the remote machine, unlike <em>dip</em> though, it does not perform the <em>ioctl</em> to convert the serial line into a PPP line. This is performed by the <em>pppd</em> program. <em>pppd</em> can act as either the client or the server. When used as a client, it normally invokes the <em>chat</em> program to perform the connection and login and then it takes over by performing the <em>ioctl</em> to change the line discipline to <em>ppp</em>, performs a number of steps in configuring your machine to talk to the remote machine and then steps out of the way to let you operate. Please refer to the <em>pppd</em> and <em>chat</em> man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the operation of these utilities is much more complete than I have described here. <sect3><heading>Configuring a PPP client by dial-up modem. <p> This is perhaps what most of you will want to do, so it appears first. You would use this configuration when you have a network provider who supports ppp by dialup modem. When you want to establish your connection you simply invoke the <em>pppd</em> program with no arguments. This configuration assumes that your PPP server will assign you an address dynamically. What to do if you have a static address is explained later. The <em>pppd</em> program has a number of command line arguments that govern its behaviour. These arguments can all be placed in a configuration file so that the commands do not appear in the argument list when someone on the system uses the <em>ps</em> command. This is particularly important when <em>pppd</em> invokes the chat program as it needs the password to use to login to the server and you don't normally want this visible to users of the system. The file that <em>pppd</em> uses is called the <tt>/etc/ppp/options</tt> file. A good starting point for a `typical' PPP installation might look like: <tscreen><verb> connect /etc/ppp/ppp-connect /dev/ttyS1 19200 crtscts modem lock asyncmap 0 defaultroute </verb></tscreen> This specifies that: <enum> <item><em>pppd</em> should use the <tt>/etc/ppp/ppp-connect</tt> script to dial the modem and login. <item><em>pppd</em> should use the <tt>ttyS1</tt> device at <tt>19200</tt> bits per second, with <tt>crtscts</tt> hardware handshaking and respect the modem signals (Carrier Detect particularly) to detect if the modem is still on-line or if the call has finished. <item><em>pppd</em> should create a <tt>lock</tt> file for the <tt>tty</tt> device to ensure that other processes do not attempt to open it while <em>pppd</em> is using it. <item>That the line is `8 bit clean', that is, that all characters are able to pass freely across the line. The <tt>asyncmap</tt> option determines which characters the <em>pppd</em> should escape and by default this is set to all control characters. Most modern PPP servers are 8 bit clean and setting the <tt>asyncmap</tt> to <tt>0</tt> tells <em>pppd</em> not to escape any characters. <item><em>pppd</em> should create a <tt>defaultroute</tt> via the ppp device when the connection is successfully established. </enum> The next step is to configure the <tt>/etc/ppp/ppp-connect</tt> script. You would normally use the <em>chat</em> program that comes with <em>pppd</em> within this script as it is very simple to use and quite lightweight. To start, you need to know what the login sequence for your PPP server looks like. The following is a fictional example that I'll base the sample script on: <tscreen><verb> CONNECT 14400 Welcome to XYZ PPP server! login: <you enter your username>^M password: <you enter your password>^M Now entering PPP: </verb></tscreen> The <em>chat</em> program expects as arguments a send/expect sequence, meaning that it wants a series of `<em>what it should expect</em>, followed by <em>what it should send</em>' pairs. The <tt>/etc/ppp/ppp-connect</tt> should <bf>not</bf> not be world readable. A sample to deal with the hypothetical example above might look like: <tscreen><verb> #!/bin/sh # A chat script to login to the XYZ PPP server. # NUM=5552857 UID=terryd PASSWD=secret1 # /usr/sbin/chat -v "" ATZ OK ATDT$NUM CONNECT ogin: $UID word: \\q$PASSWD PPP: </verb</tscreen> I've embellished the script with a sequence to initialise the modem before dialling (the <tt>ATZ</tt>. It is good practise to initialise your modem to something sensible before you start). Note the <tt>""</tt> argument, this means `<em>wait for nothing</em>' and is used when you want to start the sequence by sending something. The <tt>-v</tt> argument tells <em>chat</em> to be <bf>verbose</bf>. In this mode it will send a transcript of the logon to <em>syslog</em> so that you can see what is happening. Note the <tt>\\q</tt> before the <tt>$PASSWD</tt> in the script. This tells <em>chat</em> not to echo the following text to <em>syslog</em>. In this way your password won't be logged in the system log. You would want to use the <tt>chmod 600 /etc/ppp/ppp-connect</tt> to ensure that other users cannot read the script file and obtain your password. To start your PPP session with the above configuration you would need only type: <em>pppd</em> and it all should happen automagically. You should observe the logon occurring in the system log and when it is finished you should see a <tt>default</tt> route in your routing table when you use the: <tt>route -n</tt> command pointed via your new <tt>ppp0</tt> device. If you use a static IP address you can specify that by including a line similar to the following in your <tt>/etc/ppp/options</tt> file: <tscreen><verb> nnn.nnn.nnn.nnn: </verb></tscreen> Where: <tt>nnn.nnn.nnn.nnn</tt> is your IP addresss. Note this will only work if your Internet Service Providers is configured to allow you to do so. The colon `:' is important. There are many other options you may want to read about that you can include in your <tt>options</tt> file. Please refer to the <em>pppd</em> and <em>chat</em> man pages for more information. <sect3><heading>Configuring a PPP client via a leased line. <p> Configuring a PPP client via a leased line is very simple. You will still use the <em>pppd</em> program, but since you won't need to establish the modem link the arguments to the chat program can be much simpler. The example I'm presenting here assumes that the ppp server doesn't require any special login procedure. I do this because every login procedure will be different and if you are simply running a local connection then it is possible that you might have it set up this way. <tscreen><verb> pppd defaultroute noipdefault debug \ kdebug 2 /dev/cua0 9600 </verb></tscreen> This will open the serial device, generate the <em>ioctl</em> to change it into a <em>ppp</em>device, set your default route via the <em>ppp</em> interface. The <em>noipdefault</em> argument instructs the <em>pppd</em> program to request the address to use for this device from the server. Debug messages will go to <em>syslog</em>. The <em>kdebug 2</em> argument causes the debug messages to be set to level 2, this will give you slightly more information on what is going on. It will use <tt>/dev/cua0</tt> at 9600 bps. If your ppp server does require some sort of login procedure, you can easily use the <em>chat</em> program as in the example for the dialup server to perform that function for you. Please refer to the <em>pppd</em> and <em>chat</em> man pages for more information. Please also refer to the README file that comes with the ppp software, as its description of the above is much more complete than I have described here. <sect3><heading>Configuring a PPP server. <p> Configuring a PPP server is similar to establishing a SLIP server. You can create a special `ppp' account, which uses an executable script as its login shell. The <tt>/etc/passwd</tt> entry might look like: <tscreen><verb> ppp:EncPasswd:102:50:PPP client login:/tmp:/etc/ppp/ppplogin </verb></tscreen> and the <tt>/etc/ppp/ppplogin</tt> script might look like: <tscreen><verb> #!/bin/sh exec /usr/sbin/pppd passive :192.1.2.23 </verb></tscreen> The address that you provide will be the address that the <bf>calling</bf> machine will be assigned. Naturally, if you want multiple users to have simultaneous access you would have to create a number of startup scripts and individual accounts for each to use, as you can only put one ip address in each script. <sect2><heading>Where to obtain more information on PPP, or report bugs. <p> The <url url="http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html" name="PPP-HOWTO"> is an excellent reference to obtain more comprehensive information than I have provided here. Most discussion on PPP for Linux takes place on the PPP mailing list. To join the Linux <bf>linux-ppp</bf> channel on the mail list server, send mail to: <tscreen><verb> Majordomo@vger.rutgers.edu </verb></tscreen> with the line: <tscreen><verb> subscribe linux-ppp </verb></tscreen> in the message body. The subject line is ignored. Please remember that when you are reporting bugs or problems you should include as much information relevant to the problem as you can to assist those that will help you understand your problem. You might also like to check out: RFCS 1548, 1331, 1332, 1333 and 1334. These are the definitive documents for PPP. W. Richard Stevens also describes PPP in his book `TCP/IP Illustrated Volume 1', (Addison-Wessley, 1994, ISBN 0-201-63346-9). <sect1><heading>Configuring Linux as a Slip Server. <p> If you have a machine that is perhaps network connected, that you'd like other people be able to dial into and provide network services, then you will need to configure your machine as a server. If you want to use SLIP as the serial line protocol, then currently you have three options as to how to configure your Linux machine as a SLIP server. My preference would be to use the first presented, <em>sliplogin</em>, as it seems the easiest to configure and understand, but I will present a summary of each, so you make your mind. <sect2><heading>Slip Server using <em>sliplogin</em>. <p> <em>sliplogin</em> is a program that you can use in place of the normal login shell for SLIP users that converts the terminal line into a SLIP line. It allows you to configure your Linux machine as either a <em>static address server</em>, users get the same address everytime they call in, or a <em>dynamic address server</em>, where users get an address allocated for them which will not necessarily be the same as the last time they called. <p> The caller will login as per the standard login process, entering their username and password, but instead of being presented with a shell after their login, <em>sliplogin</em> is executed which searches its configuration file (<tt>/etc/slip.hosts</tt>) for an entry with a login name that matches that of the caller. If it locates one, it configures the line as an 8bit clean line, and uses an <em>ioctl</em> call to convert the line discipline to SLIP. When this process is complete, the last stage of configuration takes place, where <em>sliplogin</em> invokes a shell script which configures the SLIP interface with the relevant ip address, netmask and sets appropriate routing in place. This script is usually called <tt>/etc/slip.login</tt>, but in a similar manner to <em>getty</em>, if you have certain callers that require special initialisation, then you can create configuration scripts called <tt>/etc/slip.login.loginname</tt> that will be run instead of the default specifically for them. <p> There are either three or four files that you need to configure to get <em>sliplogin</em> working for you. I will detail how and where to get the software and how each is configured in detail. The files are: <itemize> <item><tt>/etc/passwd</tt>, for the dialin user accounts. <item><tt>/etc/slip.hosts</tt>, to contain the information unique to each dial-in user. <item><tt>/etc/slip.login</tt>, which manages the configuration of the routing that needs to be performed for the user. <item><tt>/etc/slip.tty</tt>, which is required only if you are configuring your server for <em>dynamic address allocation</em> and contains a table of addresses to allocate <item><tt>/etc/slip.logout</tt>, which contains commands to clean up after the user has hung up or logged out. </itemize> <sect3><heading>Where to get <em>sliplogin</em> <p> <em>sliplogin</em> can be obtained from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Network/serial/sliplogin-2.0.tar.gz </verb></tscreen> The tar file contains both source, precompiled binaries and a <em>man</em> page. <p> To ensure that only authorised users will be able to run <em>sliplogin</em> program, you should add an entry to your <tt>/etc/group</tt> file similar to the following: <tscreen><verb> .. SLIP::13:radio,fred .. </verb></tscreen> When you install the <em>sliplogin</em> package, the <tt>Makefile</tt> will change the group ownership of the <em>sliplogin</em> program to <tt>SLIP</tt>, and this will mean that only users who belong to that group will be able to execute it. The example above will allow only users radio and fred to execute <em>sliplogin</em>. <p> To install the binaries into your <tt>/sbin</tt> directory and the <em>man</em> page into section 8, do the following: <tscreen><verb> # cd /usr/src # gzip -dc .../sliplogin-2.0.tar.gz | tar xvf - # <..edit the Makefile if you don't use shadow passwords..> # make install </verb></tscreen> If you want to recompile the binaries before installation, add a <tt>make clean</tt> before the <tt>make install</tt>. If you want to install the binaries somewhere else, you will need to edit the <tt>Makefile</tt> <em>install</em> rule. <p> Please read the <tt>README</tt> files that come with the package for more information. <sect3><heading>Configuring <tt>/etc/passwd</tt> for Slip hosts. <p> Normally you would create some special logins for Slip callers in your <tt>/etc/passwd</tt> file. A convention commonly followed is to use the <em>hostname</em> of the calling host with a capital `S' prefixing it. So, for example, if the calling host is called <tt>radio</tt> then you could create a <tt>/etc/passwd</tt> entry that looked like: <tscreen><verb> Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin </verb></tscreen> It doesn't really matter what the account is called, so long as it is meaningful to you. <p> Note: the caller doesn't need any special home directory, as they will not be presented with a shell from this machine, so <tt>/tmp</tt> is a good choice. Also note that <em>sliplogin</em> is used in place of the normal login shell. <sect3><heading>Configuring <tt>/etc/slip.hosts</tt> <p> The <tt>/etc/slip.hosts</tt> file is the file that <em>sliplogin</em> searches for entries matching the login name to obtain configuration details for this caller. It is this file where you specify the ip address and netmask that will be assigned to the caller and configured for their use. Sample entries for two hosts, one a static configuration for host <tt>radio</tt> and another, a dynamic configuration for user host <tt>albert</tt> might look like: <tscreen><verb> # Sradio 44.136.8.99 44.136.8.100 0xffffff00 normal Salbert 44.136.8.99 DYNAMIC 0xffffff00 compressed # </verb></tscreen> The <tt>/etc/slip.hosts</tt> file entries are: <enum> <item>the login name of the caller. <item>ip address of the server machine, ie this machine. <item>ip address that the caller will be assigned. If this field is coded <tt>DYNAMIC</tt> then an ip address will be allocated based on the information contained in your <tt>/etc/slip.tty</tt> file discussed later. <bf>Note:</bf> you must be using at least version 1.3 of sliplogin for this to work. <item>the netmask assigned to the calling machine in hexadecimal notation eg 0xffffff00 for a Class C network mask. <item>optional parameters to enable/disable compression and other features. </enum> Note: You can use either hostnames or IP addresses in dotted decimal notation for fields 2 and 3. If you use hostnames then those hosts must be resolvable, that is, your machine must be able to locate an ip address for those hostnames, otherwise the script will fail when it is called. You can test this by trying trying to telnet to the hostname, if you get the <em>Trying nnn.nnn.nnn...</em> message then your machine has been able to find an ip address for that name. If you get the message <em>Unknown host</em>, then it has not. If not, either use ip addresses in dotted decimal notation, or fix up your name resolver configuration (See section <tt>Name Resolution</tt>). The most commonly used optional parameters for the <tt>opt1</tt> and <tt>opt2</tt> fields are: <descrip> <tag>normal </tag>to enable normal uncompressed SLIP. <tag>compressed </tag>to enable van Jacobsen header compression (cSLIP) </descrip> Naturally these are mutually exclusive, you can use one or the other. For more information on the other options available, refer to the <em>man</em> pages. <sect3><heading>Configuring the <tt>/etc/slip.login</tt> file. <p> After <em>sliplogin</em> has searched the <tt>/etc/slip.hosts</tt> and found a matching entry, it will attempt to execute the <tt>/etc/slip.login</tt> file to actually configure the SLIP interface with its ip address and netmask. The sample <tt>/etc/slip.login</tt> file supplied with the <em>sliplogin</em> package looks like this: <tscreen><verb> #!/bin/sh - # # @(#)slip.login 5.1 (Berkeley) 7/1/90 # # generic login file for a SLIP line. sliplogin invokes this with # the parameters: # $1 $2 $3 $4 $5 $6 $7-n # SLIPunit ttyspeed loginname local-addr remote-addr mask opt-args # /sbin/ifconfig $1 $4 pointopoint $5 mtu 1500 -trailers up /sbin/route add $5 arp -s $5 <hw_addr> pub exit 0 # </verb></tscreen> You will note that this script simply uses the <em>ifconfig</em> and <em>route</em> commands to configure the SLIP device with its ipaddress, remote ip address and netmask and creates a route for the remote address via the SLIP device. Just the same as you would if you were using the <em>slattach</em> command. <p> Note also the use of <em>Proxy ARP</em> to ensure that other hosts on the same ethernet as the server machine will know how to reach the dial-in host. The <tt><hw_addr></tt> field should be the hardware address of the ethernet card in the machine. If your server machine isn't on an ethernet network then you can leave this line out completely. <sect3><heading>Configuring the <tt>/etc/slip.logout</tt> file. <p> When the call drops out, you want to ensure that the serial device is restored to its normal state so that future callers will be able to login correctly. This is achieved with the use of the <tt>/etc/slip.logout</tt> file. It is quite simple in format. <tscreen><verb> #!/bin/sh - # # slip.logout # /sbin/ifconfig $1 down /sbin/route del $5 arp -d $5 exit 0 # </verb></tscreen> All it does is `down' the interface and delete the manual route previously created. It also uses the <em>arp</em> command to delete any proxy arp put in place, again, you don't need the <em>arp</em> command in the script if your server machine does not have an ethernet port. <sect3><heading>Configuring the <tt>/etc/slip.tty</tt> file. <p> If you are using dynamic ip address allocation (have any hosts configured with the <tt>DYNAMIC</tt> keyword in the <tt>/etc/slip.hosts</tt> file, then you must configure the <tt>/etc/slip.tty</tt> file to list what addresses are assigned to what port. You only need this file if you wish your server to dynamically allocate addresses to users. <p> The file is a table that lists the <em>tty</em> devices that will support dial-in SLIP connections and the ip address that should be assigned to users who call in on that port. Its format is as follows: <tscreen><verb> # slip.tty tty -> IP address mappings for dynamic SLIP # format: /dev/tty?? xxx.xxx.xxx.xxx # /dev/ttyS0 192.168.0.100 /dev/ttyS1 192.168.0.101 # </verb></tscreen> <p> What this table says is that callers that dial in on port <tt>/dev/ttyS0</tt> who have their remote address field in the <tt>/etc/slip.hosts</tt> file set to <tt>DYNAMIC</tt> will be assigned an address of <tt>192.168.0.100</tt>. <p> In this way you need only allocate one address per port for all users who do not require an dedicated address for themselves. This helps you keep the number of addresses you need down to a minimum to avoid wastage. <sect2><heading>Slip Server using <em>dip</em>. <p> Let me start by saying that some of the information below came from the <em>dip</em> man pages, where how to run Linux as a SLIP server is briefly documented. Please also beware that the following has been based on the <em>dip337j-uri.tgz</em> package and probably will not apply to other versions of <em>dip</em>. <em>dip</em> has an input mode of operation, where it automatically locates an entry for the user who invoked it and configures the serial line as a SLIP link according to information it finds in the <tt>/etc/diphosts</tt> file. This input mode of operation is activated by invoking <em>dip</em> as <em>diplogin</em>. This therefore is how you use <em>dip</em> as a SLIP server, by creating special accounts where <em>diplogin</em> is used as the login shell. The first thing you will need to do is to make a symbolic link as follows: <tscreen><verb> # ln -sf /usr/sbin/dip /usr/sbin/diplogin </verb></tscreen> You then need to add entries to both your <tt>/etc/passwd</tt> and your <tt>/etc/diphosts</tt> files. The entries you need to make are formatted as follows: To configure Linux as a SLIP server with <em>dip</em>, you need to create some special SLIP accounts for users, where <em>dip</em> (in input mode) is used as the login shell. A suggested convention is that of having all SLIP accounts begin with a capital `S', eg `Sfredm'. A sample <tt>/etc/passwd</tt> entry for a SLIP user looks like: <tscreen><verb> Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin ^^ ^^ ^^ ^^ ^^ ^^ ^^ | | | | | | \__ diplogin as login shell | | | | | \_______ Home directory | | | | \____________ User Full Name | | | \_________________ User Group ID | | \_____________________ User ID | \_______________________________ Encrypted User Password \__________________________________________ Slip User Login Name </verb></tscreen> After the user logs in, the <em>login(1)</em> program, if it finds and verifies the user ok, will execute the <em>diplogin</em> command. <em>dip</em>, when invoked as <em>diplogin</em> knows that it should automatically assume that it is being used a login shell. When it is started as <em>diplogin</em> the first thing it does is use the <em>getuid()</em> function call to get the userid of whoever has invoked it. It then searches the <tt>/etc/diphosts</tt> file for the first entry that matches either the userid or the name of the <em>tty</em> device that the call has come in on and configures itself appropriately. By judicious decision as to whether to give a user an entry in the <tt>diphosts</tt> file, or whether to let the user be given the default configuration you can build your server in such a way that you can have a mix of static and dynamically assigned address users. <em>dip</em> will automatically add a `Proxy-ARP' entry if invoked in input mode, so you do not need to worry about manually adding such entries. <sect3><heading>Configuring <tt>/etc/diphosts</tt> <p> <tt>/etc/diphosts</tt> is used by <em>dip</em> to lookup preset configurations for remote hosts. These remote hosts might be users dialing into your linux machine, or they might be for machines that you dial into with your linux machine. The general format for <tt>/etc/diphosts</tt> is as follows: <tscreen><verb> .. Suwalt::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006 ttyS1::145.71.34.3:145.71.34.2:255.255.255.0:Dynamic ttyS1:CSLIP,296 .. </verb></tscreen> The fields are: <enum> <item><tt>login name</tt>: as returned by getpwuid(getuid()) or tty name. <item><tt>unused</tt>: compat. with passwd <item><tt>Remote Address</tt>: IP address of the calling host, either numeric or by name <item><tt>Local Address</tt>: IP address of this machine, again numeric or by name <item><tt>Netmask</tt>: in dotted decimal notation <item><tt>Comment field</tt>: put whatever you want here. <item><tt>protocol</tt>: Slip, CSlip etc. <item><tt>MTU</tt>: decimal number </enum> An example <tt>/etc/net/diphosts</tt> entry for a remote SLIP user might be: <tscreen><verb> Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:SLIP,296 </verb></tscreen> which specifies a SLIP link with remote address of 145.71.34.1 and MTU of 296, or: <tscreen><verb> Sfredm::145.71.34.1:145.71.34.2:255.255.255.0:SLIP uwalt:CSLIP,1006 </verb></tscreen> which specifies a cSLIP-capable link with remote address 145.71.34.1 and MTU of 1006. Therefore, all users who you wish to be allowed a statically allocated dial-up IP access should have an entry in the <tt>/etc/diphosts</tt> and if you want users who call a particular port to have their details dynamically allocated you must have an entry for the <tt>tty</tt> device and do not configure a user based entry. You should remember to configure at least one entry for each <tt>tty</tt> device that your dialup users use to ensure that a suitable configuration is available for them regardless of which modem they call in on. When a user logs in, they will receive a normal login and password prompt, at which they should enter their SLIP-login userid and password. If they check out ok, then the user will see no special messages, they should just change into SLIP mode at their end and then they should be able to connect ok and be configured with the parameters from the <tt>diphosts</tt> file. <sect2><heading>SLIP server using the <em>dSLIP</em> package. <p> Matt Dillon <tt><dillon@apollo.west.oic.com></tt> has written a package that does not only dial-in but also dial-out SLIP. Matt's package is a combination of small programs and scripts that manage your connections for you. You will need to have <em>tcsh</em> installed as at least one of the scripts requires it. Matt supplies a binary copy of the <em>expect</em> utility as it too is needed by one of the scripts. You will most likely need some experience with <em>expect</em> to get this package working to your liking, but don't let that put you off. <p> Matt has written a good set of installation instructions in the README file, so I won't bother repeating them. <p> You can get the <em>dSLIP</em> package from its home site at: <bf>apollo.west.oic.com</bf> <tscreen><verb> /pub/linux/dillon_src/dSLIP203.tgz </verb></tscreen> or from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Network/serial/dSLIP203.tgz </verb></tscreen> Read the <tt>README</tt> file and create the <tt>/etc/passwd</tt> and <tt>/etc/group</tt> entries <bf>before</bf> doing a <tt>make install</tt>. <sect1><heading>Using the Automounter Daemon - AMD. <p> This section has been supplied by <tt>Mitch DSouza</tt> and I've included it with minimal editing, as he supplied it. Thanks Mitch. <sect2><heading>What is an automounter and why would I use one ? <p> An <em>automounter</em> provides a convenient means of mounting filesystems on demand, i.e. when required. This will reduce both the server and the client load and provides a great deal of flexibility even with non-NFS mounts. It also offers a redundancy mechanism whereby a mount point will automatically switch to a secondary server should a primary one be unavailable. A rather useful mount called the <em>union</em> mount gives the <em>automounter</em> the ability to <em>merge</em> the contents of multiple directories into a single directory. The documentation MST be read thoroughly to make full use of its extensive capabilities. A few important points must be remembered - (in no particular order): <itemize> <item><em>amd</em> maps are <bf>not</bf> compatible with Sun maps, which in turn are <bf>not</bf> compatible with HP maps <em>ad infinitum</em>. The point here however is that <em>amd</em> is freely available and compatible with all the systems mentioned above and more, thus giving you the ability to share maps if <em>amd</em> is installed throughout your network. Mitch uses it with a mixture of Linux/Dec/NeXt/Sun machines. <item><em>Sun</em> automount maps can be converted to <em>amd</em> style maps by using the <em>perl</em> script in the <tt>contrib</tt> directory - <tt>automount2amd.pl</tt>. <item>You <bf>must</bf> have the <em>portmapper</em> running <bf>before</bf> starting <em>amd</em>. <item>UFS mounts <bf>do not</bf> timeout. <item>UFS mounts, in the case of Linux <bf>only</bf>, have been extended to deal with <bf>all</bf> varieties of native filesystems (i.e. minix, ext, ext2, xiafs ...) with the default being minix. This undocumented feature is accessed in the <em>opts</em> option like: <tscreen><verb> ..., opts:=type=msdos,conv=auto </verb></tscreen> <item>Do not mount over existing directories unless you use a <em>direct</em> automount option, otherwise it is like mounting your disk on <tt>/home</tt> when some user directory is <tt>/home/fred</tt>. <item><bf>Always</bf> turn on full logging with the `-x all' option to <em>amd</em> if you have any troubles. Check also what the command: <tscreen><verb> % amq -ms </verb></tscreen> reports, as it will indicate problems as they occur. <item>GNU <em>getopt()</em> is too clever for its own good sometimes. You should always use `--' before the non-options e.g. <tscreen><verb> # /etc/amd -x all -l syslog -a /amd -- /net /etc/amd.net </verb></tscreen> </itemize> <sect2><heading>Where to get AMD, the automounter daemon. <p> <em>amd</em> can be obtained from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Misc/mount/amd920824upl67.tar.gz </verb></tscreen> This contains ready-to-run binaries, full sources and documentation in texinfo format. <sect2><heading>An example AMD configuration. <p> You do not configure the <em>automounter</em> from the <tt>/etc/fstab</tt> file, which you will already be using to contain information about your filesystems, instead it is command line driven. To mount two <em>nfs</em> filesystems using your <tt>/etc/fstab</tt> file you would use two entries that looked like: <tscreen><verb> server-1:/export/disk /nfs/server-1 nfs defaults server-2:/export/disk /nfs/server-2 nfs defaults </verb></tscreen> i.e. you were <em>nfs</em> mounting <tt>server-1</tt> and <tt>server-2</tt> on your linux disk on the <tt>/nfs/server-1</tt> and <tt>/nfs/server-2</tt> directories. After commenting out, or deleting the above lines from your <tt>/etc/fstab</tt> file, you could <em>amd</em> to perform the same task with the following syntax: <tscreen><verb> /etc/amd -x all -l syslog -a /amd -- /nfs /etc/amd.server | | | | | | | | | | | | | | | | | | | | | | | | | | `------' `----' `-------' `-----' -' `--' `-------------' | | | | | | | (1) (2) (3) (4) (5) (6) (7) </verb></tscreen> Where: <enum> <item>The full <em>amd</em> binary path (obviously optional) depending on your $PATH setting, so just <em>`amd'</em> may be specified here. <item>`-x all' means turn full logging on. Read the documentation for the other logging levels <item>`-l syslog' means log the message via the <em>syslog</em> daemon. This could mean put it to a file, dump it, or pass it, to an unused tty console. This (<em>syslog</em>) can be changed to the name of a file, i.e. `-l foo' will record to a file called <em>foo</em>. <item>`-a /amd' means use the <tt>/amd</tt> directory as a temporary place for automount points. This directory is created automatically by <em>amd</em> and should be removed before starting <em>amd</em> in your <tt>/etc/rc</tt> scripts. <item>`--' means tell <em>getopt()</em> to stop attempting to parse the rest of the command line for options. This is especially useful when specifying the `type:=' options on the command line, otherwise <em>getopt()</em> tries to decode it incorrectly. <item>`/nfs' is the <bf>real</bf> nfs mount point. Again this is automatically created and should <bf>not</bf> generally contain subdirectories unless the `type:=direct' option is used. <item>The <em>amd</em> map (i.e. a file) named `amd.server' contains the lines: <tscreen><verb> # /etc/amd.server /defaults opts:=rw;type:=nfs server-1 rhost:=server-1;rfs:=/export/disk server-2 rhost:=server-2;rfs:=/export/disk </verb></tscreen> </enum> Once started and successfully running, you can query the status of the mounts with the command: <tscreen><verb> % amq -ms </verb></tscreen> Now if you say: <tscreen><verb> % ls /nfs </verb></tscreen> you should see no files. However the command: <tscreen><verb> % ls /nfs/server-1 </verb></tscreen> will mount the host `server-1' automatically. <em>voila</em>! <em>amd</em> is running. After the default timeout has expired, this will automatically be unmounted. Your <tt>/etc/password</tt> file could contain entries like: <tscreen><verb> ... linus:EncPass:10:0:God:/nfs/server-1/home/linus:/bin/sh mitch:EncPass:20:10:Mitch DSouza:/nfs/server-1/home/mitch:/bin/tcsh matt:EncPass:20:10:Matt Welsh:/nfs/server-1/home/matt:/bin/csh </verb></tscreen> which would mean that when Linus, Matt, or Mitch are logged in, their home directory will be remotely mounted from the appropriate server and unmounted when they log out. <sect1><heading>Using Linux as a router <p> Linux will function just fine as a router. You should run a routing daemon such as <em>gated</em>, or if you have simple routing requirements use hard coded routes. If you are using a late version kernel (1.1.*) then you should ensure that you have answered `y' to: <tscreen><verb> IP forwarding/gatewaying (CONFIG_IP_FORWARD) [y] y </verb></tscreen> when building your kernel. Olaf Kirch's Network Administrators Guide discusses network design and routing issues and you should read it for more information. A reference to it is in the "Related Documentation" section of this document. <sect1><heading>NIS - Sun Network Information System. <p> There is now an <url url="http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html" name="NIS-HOWTO"> which you should read if you are interested in using NIS. It details how to obtain, install and configure the NIS system for Linux. <sect><heading>Experimental and Developmental modules. <p> There are a number of people developing new features and modules for the Linux networking code. Some of these are in quite an advanced state (read <em>working</em>) and it is these that I intend to include in this section until they are standard release code, when they will be moved forward. <p> The AX25 section has been relocated into the <url url="http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html" name="HAM-HOWTO"> because it was fairly specific to Amateur Radio. <sect1><heading>snmp agent. <p> There is an experimental snmp agent for linux, ported from the cmu-snmp source by <tt>Erik Schoenfelder, <schoenfr@ibr.cs.tu-bs.de></tt>. It is available from: <bf>ftp.ibr.cs.tu-bs.de</bf> <tscreen><verb> /pub/local/cmu-snmp2.1.2l3-src.tar.gz </verb></tscreen> Please <bf>read</bf> the file called <tt>cmu-snmp2.1.2l3.README</tt>, as it contains information that you will need to know about the package. This package provides a nearly complete MIB-II variable set. and parts of the host MIB. Setting of system group variables is provided. The private community string is settable in the config file. <tt>nstat.tar.gz</tt> contains a formatter of the output from <tt>/proc/net/snmp</tt> called <em>nstat</em>. You will need Linux v1.1.60 and libc v4.6.27 or higher to compile and run the agent. <sect1><heading>Experimental Token Ring driver <p> An experimental Token Ring driver is being developed by <tt>Peter De Schrijver <stud11@cc4.kuleuven.ac.be></tt>. His latest version, at the time of writing is available in the Linux 1.3.* kernel release kernels. For older kernel versions the driver patches are located at: <bf>linux3.cc.kuleuven.ac.be</bf> <tscreen><verb> /pub/Linux/TokenRing/TokenRing.patch-1.2.0.gz </verb></tscreen> <bf>ftp.cs.kuleuven.ac.be</bf> <tscreen><verb> /pub/unix/linux/TokenRing.patch-1.1.64.gz </verb></tscreen> There are a number of patch files against various kernel versions. Just pick the one that suits your kernel. Note also that there are versions of the network tools to suit Token Ring in the same directory at <tt>linux3.cc.kuleven.ac.be</tt>. Most boards based on IBM's TROPIC chipset should work now. The following boards are known to be working with the driver : <itemize> <item>IBM Token Ring Adapter II <item>IBM Token Ring 16/4 Adapter <item>IBM Token Ring Adapter/A <item>IBM Token Ring 16/4 Adapter/A <item>HyperRing Classic 16/4 </itemize> Boards which use the TI chipset or busmastering DMA won't work with the current driver. However someone is working on a driver for the IBM busmaster adapters. <sect1><heading>V.35 interface board <p> V.35 is a C.C.I.T.T. standard interface that provides a high speed balanced serial interface suitable for speeds up to about 2 Mbps. The use of differential pair balanced transmission allows the V.35 interface to support longer cables than can the more familiar V.24/RS232C type interface and higher data rates. <sect2><heading>Internet Technologies International XNET-1 <p> Matti Aarnio <tt><mea@mea.utu.fi></tt> represents <url url="mailto:intec@digiw.fi" name="Internet Technologies International">. They have an 8 bit X.21 card available called the <tt>XNET-1</tt> which will work for V.35 with an appropriate cable. You can obtain information on the card itself from: <tscreen><verb> Internet Technologies International OY, Helsinki, Finland <intec@digiw.fi> Internet Technologies International OY (Ltd) PO BOX 51 00641 Helsinki FINLAND Fax: +356-0-7523939 </verb></tscreen> <p> The driver for the card is available from <url url="ftp://ftp.funet.fi/pub/Linux/kernel/xnet-sync-driver.tar.gz" name="ftp.funet.fi">. <sect2>SDL Communications N2 card. <p> <url url="http://www.ici.net/cust_pages/sdl/sdl.html" name="SDL Communications"> produce a variety of controller cards supporting V.35 for ISA based machines. The beta release driver can be found at: <bf>ftp.sdlcomm.com</bf> <tscreen><verb> /business/sdlcomm/n2/linux </verb></tscreen> For further information you can contact <url url="mailto:sales@sdlcomm.com" name="Rubin Dhillon at SDL Sales"> <sect1><heading>Demand Dial SLIP/PPP package <p> Eric Schenk <tt><schenk@cs.toronto.edu></tt> has written a demand dial daemon that will work with either SLIP or PPP. It relies on you having a SLIP device configured which the daemon connects to via a pty. When your SLIP connection is not active all datagrams for non local hosts will be routed to this device and the daemon will detect them, when it receives a datagram it executes a script to activate your network link and then reroutes datagrams to that link. <p> The software is available at: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/system/Network/serial/diald-0.7.tar.gz </verb></tscreen> <bf>Note:</bf> You must configure your kernel so that it includes the SLIP driver, even if you only want to run PPP. The included documentation describes how to install and configure the software. <sect1><heading>ISDN support <p> There are various ISDN support efforts underway. The ones that I know of are: <sect2><heading>3Com-Sonix PC/Arpeggio driver <p> Alan Cox has started a driver for the 3Com arpeggio ISDN card. It is currently capable of supporting Async PPP only. <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/kernel/patches/network/sonix.tgz </verb></tscreen> <sect2><heading>DIEHL SCOM card <p> <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/kernel/patches/network/isdndrv-0.1.1.tar.gz </verb></tscreen> <sect2><heading>ICN ISDN and/or Teles ISDN card and/or Creatix AVM ISDN board <p> Fritz Elfert, Jan den Ouden and Thinking Objects have written a linux driver for the ICN ISDN card. Some of the documentation for this driver is in German. There seem to be various versions of this driver around that apparently support other ISDN cards, if you obtain one and it doesn't support your card take a look at another of the sites. You can obtain them from: <bf>ftp.franken.de</bf> <tscreen><verb> /pub/isdn4linux/ </verb></tscreen> or: <bf>ftp.gwdg.de</bf> <tscreen><verb> /pub/linux/misc/isdn4linux/ </verb></tscreen> <sect2><heading>Euro-ISDN card ? <p> Matthias Urlichs <tt><urlichs@smurf.noris.de></tt> has developed some experimental Streams based ISDN support for Linux. The most recent version was for kernel version 1.3.* and is reported to work. It is available at: <bf>ftp.uni-stuttgart.de</bf> <tscreen><verb> /pub/systems/linux/isdn/ftp.noris.de/ </verb></tscreen> Be warned, the documentation is in German and the code is designed to support the european ISDN network. Matthias is working on a english version of the documentation. <sect2><heading>Combinet's Everyware 1000 ISDN card <p> Joel Katz <tt><stimpson@panix.com></tt> has developed a driver for Combinet's <tt>Everyware 1000</tt> series of plug-in ISDN cards. It is available from: <bf>sunsite.unc.edu</bf> <tscreen><verb> /pub/Linux/kernel/patches/network/combinet1000isdn-1.02.tar.gz </verb></tscreen> <sect2><heading>More information: <p> Harald Milz has put together a World Wide Web page for Linux ISDN support and it is available at <url url="http://www.ix.de/ix/linux/linux-isdn.html" name="Linux ISDN Web Page">. A more generic site containing information about ISDN is available at <url url="http://alumni.caltech.edu/~dank/isdn/" name="Dan Kegel's ISDN home page">. <sect1><heading>System-V Streams <p> The LiS (Linux Streams) project has formed to develop and implement System-V Streams for Linux. They have a World Wide Web page at <url url="http://www.uc3m.es/~LiS/" name="Linux Streams Web Page"> where the status of the project can be obtained and where you can locate contact information and test code. <sect1><heading>ATM (Asynchronous Transfer Mode) support. <p> Werner Almesberger has put together a World Wide site on the topic of Linux support for ATM. It is available at <url url="http://lrcwww.epfl.ch/linux-atm/" name="lrcwww.epfl.ch">. There is experimental software which supports raw ATM connections and some basic IP over ATM available at the pre-alpha stage and this can be obtained from the Web Site. The site contains a good deal of interesting information on ATM. A mail list has been established to discuss ATM for Linux and you can subscribe by sending a mail message with the body <tt>subscribe linux-atm</tt> to: <tt>majordomo@vger.rutgers.edu</tt> <sect1><heading>X.25 support. <p> Many people have enquired about X.25 support for Linux. There is some development work taking place but the apparently small community of people that are interested in it don't seem to have enough momentum to produce very quickly. If you are interested in X.25 support then you might volunteer some assistance to help accelerate the existing development effort. The only information that I have available on X.25 development efforts are a note on Alan Cox's webserver to say that someone has volunteered to do the job and the following World Wide Web site which provides information about two development efforts that seem to be making some progress: X.25 for Linux is at: <url url="http://www.ping.be/~ping0778/linux-x.25/" name="www.ping.be"> <sect1><heading>Appletalk support. <p> If you have some Apple machines on your network that you'd like your linux machine to be able to share filesystems and printers with then the linux appletalk support is what you are after. The following information was supplied mostly by Cees de Groot <tt><cg@tricbbs.fn.sub.org</tt> who compiled it from his own experience with assistance from Dana Basken <tt><dana@millenium.tiac.net></tt> and others on the net. <sect2><heading>Building the kernel with Appletalk DDP support <p> Alan Cox has developed some experimental and working support for the Apple Ethertalk specification. It is now a part of the later 1.2.* revision kernels and the new linux 1.3.* revision kernels so to build the kernel support for it you need only compile up a recent kernel, make sure you select the following configuration option: <tscreen><verb> # # cd /usr/src/linux # make config ... ... Appletalk DDP ? y ... ... # </verb></tscreen> <sect2><heading>Building the Appletalk configuration tools and daemons. <p> You will need some additional software as the kernel support only provides enough to do basic networking, none of the higher layer protocols are implemented in the kernel. Wesley Craig <tt><netatalk@umich.edu</tt> represents a team called the Research Systems Unix Group at the University of Michigan and they have produced a package called <em>netatalk</em> which provides software that implements the Appletalk protocol stack and some useful utilities. You can obtain it from: <url url="ftp://terminator.rs.itd.umich.edu/unix/netatalk/" name="University of Michigan"> you will need at least version 1.3.3b2 as earlier versions did not support Linux. To build and install that package something like: <tscreen><verb> # cd /usr/src # tar xvfz .../netatalk - You may want to edit the `Makefile' at this point, specifically to change the DESTDIR variable which defines where the files will be installed later. The default of /usr/local/atalk is fairly safe. - You should then just have to make the software. My `uname' program wasn't in the /bin directory so I edited the Makefile to reflect this change too. # make - as root: # make install </verb></tscreen> You should then end up with a whole range of new commands to play with. <sect2><heading>Configuring the Appletalk software. <p> The first thing you need to do to make it all work is add the contents of the services.atalk file to your /etc/services file, just append it to the end of the file. The next step is to create the appletalk configuration files in the <tt>/usr/local/atalk/etc</tt> directory (or wherever you installed the package). The first file to create is the <tt>/usr/local/atalk/etc/Atalkd.conf</tt> file. To start this file needs only one line that gives the name of the network device that support the network that your Apple machines are on: <tscreen><verb> eth0 </verb></tscreen> The Appletalk daemon program will add extra details after it is run. <sect2><heading>Exporting a Linux filesystems via Appletalk. <p> You can export filesystems from your linux machine to the network so that Apple machine on the network can share them. To do this you must configure the <tt>/usr/local/atalk/etc/AppleVolumes.system</tt> file. Full details on how to do this and what the various options are can be found in the <em>afpd</em> man page. A sample would look like: <tscreen><verb> /tmp Scratch /home/ftp/pub Public </verb></tscreen> Which would export your <tt>/tmp</tt> filesystem as AppleShare Volume `Scratch' and your ftp public directory as AppleShare Volume `Public'. The volume names are not mandatory, the daemon will choose some for you, but it won't hurt to specify them anyway. <sect2><heading>Sharing your Linux printer across Appletalk. <p> You can share your linux printer with your Apple machines quite simply. You need to run the <em>papd</em> program which is the Appletalk Printer Access Protocol Daemon. When you run this program it will accept requests from your Apple machines and spool the print job to your local line printer daemon for printing. You need to edit the <tt>/usr/local/atalk/etc/papd.conf</tt> file to configure the daemon. The syntax of this file is the same as that of your usual <tt>/etc/printcap</tt> file. The name you give to the definition is registered with the Appletalk naming protocol, NBP. A sample configuration might look like: <tscreen><verb> TricWriter:\ :pr=lp:op=cg: </verb></tscreen> Which would make a printer named `TricWriter' available to your Appletalk network and all accepted jobs would be printed to the linux `lp' printer using <em>lpd</em>. <sect2><heading>Starting the appletalk software. <p> Ok, you should now be ready to test this basic configuration. There is an <em>rc</em> file supplied with the <em>netatalk</em> package that should work ok for you, so all you should have to do is: <tscreen><verb> # /usr/local/atalk/etc/rc.atalk </verb></tscreen> and all should startup and run ok. You should see no error messages and the software will send messages to the console indicating each stage as it starts. <sect2><heading>Testing the appletalk software. <p> To test that the software is functioning properly, go to one of your Apple machines, pull down the Apple menu, select the Chooser, click on AppleShare, and your Linux box should appear. <sect2><heading>Caveats of the appletalk software. <p> <itemize> <item>You may need to start the Appletalk support before you configure your IP network. If you have problems starting the Appletalk programs, or if after you start them you have trouble with your IP network, then try starting the Appletalk software before you run your <tt>/etc/rc.d/rc.inet1</tt> file. <item>The <em>afpd</em> (Apple Filing Protocol Daemon) severely messes up your hard disk. Below the mount points it creates a couple of directories: <tt>.AppleDesktop</tt> and <tt>Network Trash Folder</tt>. Then, for each directory you access it will create a <tt>.AppleDouble</tt> below it so it can store resource forks, etc. So think twice before exporting <tt>/</tt>, you will have a great time cleaning up afterwards. <item>The <em>afpd</em> program expects clear text passwords from the Macs. Security could be a problem, so be very careful when you run this daemon on a machine connected to the Internet, you have yourself to blame if somebody nasty does something bad. <item>The existing diagnostic tools such as <em>netstat</em> and <em>ifconfig</em> don't support Appletalk. The raw information is available in the <tt>/proc/net/</tt> directory if you need it. </itemize> <sect1><heading>IP_MASQUERADE - allow a number of hosts to pretend to be one. <p> If you are one of the many people who have some sort of local network at home, whether it be a couple of machine connected via a SLIP/plip/ppp link to each other, or a number of machines connected to a private ethernet network who also has a dial-up Internet connection then you have probably at one time or another wanted the machines not directly connected to be able to communicate with the Internet. This is normally achieved by getting a valid register IP network address for your local network and asking your Internet Service Provider to kindly provide a network route to your network connection instead of the single host route they were previously providing. Unfortunately many Internet Service Providers will ask you to provide a good deal more dollars for the privilege of better utilising the bandwidth of your connection and you probably don't much like that idea. IP_MASQUERADING provides a clever solution to this problem by making all of the machines on your network look like one very active networked machine. It does this by performing real-time, on the fly address translations. Most of the code was authored by Pauline Middelink <tt><middelin@polyware.iaf.nl></tt>. Ken Eaves <tt><keves@eves.com</tt> provided most the information contained below so if you find the following helpful, thank Ken. <sect2>Obtaining the `masq' software. <p> The IP_Masquerade software currently comes as a patch to the later linux 1.2.* series kernels and a new version of the <em>ipfw</em> command. The <em>ipfw</em> program that comes with the <tt>net-tools</tt> software releases to configure it does not yet have the `masquerade' option built into it. The kernel you are using must support the <tt>ip_firewalling</tt> option for ip_masquerade to work. The patch file is available from: <bf>ftp.eves.com</bf> <tscreen><verb> /pub/masq </verb></tscreen> In this directory you will find patch files, new versions of the <em>ipfw</em> command and Ken's original Masquerade FAQ on which this text is based. The patch file is called <tt>masq-patch.1.2.n</tt>, so you must retrieve it. The files <tt>ipfw</tt> and <tt>ipfw-for-1.3.10</tt> are for kernel version 1.2.* and 1.3.10 respectively. <sect2><heading>How do I install and compile the patch ? <p> Assuming you have the source to a recent 1.2.* version kernel installed in the <tt>/usr/src/linux</tt> directory you would do the following: <tscreen><verb> # # cd /usr/src # patch -p0 <.../masq-patch.1.2.n 2>patch.errs - check the patch.errs file for the string `fail'. If you can't find it then the patch applied successfully. If you can find it then something may have gone wrong double check that you have the correct version of kernel source. # cd /usr/src/linux # make config - You must answer `y' to: ... IP: forwarding/gatewaying (CONFIG_IP_FORWARD) [y] IP: firewalling (CONFIG_IP_FIREWALL) [y] IP: masquerading (ALPHA) [y] ... - The rest of the options you should answer as you normally would. # make dep # make clean - Build as you normally would, normally this would be: # make zlilo # </verb></tscreen> After making sure that you are actually running your newly built kernel you need only ensure that you have a working copy of the <em>ipfw</em> program. <em>ipfw</em> is normally installed in the <tt>/sbin</tt> so after testing the masquerade version you can simply copy it to <tt>/sbin/ipfw</tt>. This is all that is necessary to get the kernel support installed. <sect2>How do I configure the IP_MASQUERADE software ? <p> How you configure the IP_MASQUERADE function depends completely on how your network is built. The general idea is as follows: all of your local machine that you want to have access to the Internet must have their network default route pointing to your linux machine supporting IP_MASQUERADE. Secondly, you must have an entry in the linux firewall table that says that your local machines should be masqueraded. To configure the IP-MASQUERADE function you use the <em>ipfw</em> command. The <em>ipfw</em> command is normally used to configure the Linux firewall facility and because your masquerading host is acting as a firewall of sorts <em>ipfw</em> has been modified to take on this additional function. I'll present two example configurations that will probably cover most situations, if you have anything more complicated than these designs then you probably have the experience to work it out for yourself. Two machines connected to each other by SLIP or ppp: <tscreen><verb> .-------. .-------. | | SLIP | linux | SLIP/ppp | local |-----//------| masq |-----//-------> To ISP | | | svr | ._______. ._______. ^ ^ ^ | | | 192.168.0.2 192.168.0.1 dynamically assigned </verb></tscreen> Your /etc/rc.d/rc.inet1 file would have something like the following appended: <tscreen><verb> ... ... # Allow machine 192.168.0.2 to be masqueraded to everybody ipfw a m all from 192.168.0.2/32 to 0.0.0.0/0 ... ... </verb></tscreen> Note the <tt>iii.iii.iii.iii/nn</tt> syntax. You might wonder what the <tt>/nn</tt> means and how you calculate it. This syntax is a means of encoding both an ip address and a netmask. What this syntax says is all addresses in which the first <tt>nn</tt> bits match those of <tt>iii.iii.iii.iii</tt>. The above example is for a single host, so all bits must match, since there are 32 bits in an IP address the syntax is <tt>/32</tt>. A private ethernet network of machines sharing a single internet link: <tscreen><verb> .-------. _ | | .2 | | local |----| | | | <-- Ethernet lan ._______. | 192.168.0.0 netmask 255.255.255.0 | | .-------. | .-------. | | .3 | .1 | linux | SLIP/ppp | local |----|--------| masq |-----//-------> To ISP | | | | svr | ._______. - ._______. ^ | dynamically assigned </verb></tscreen> For this configuration you have a single entry that describes the whole network, so you would use something like: <tscreen><verb> ... ... # Allow all machines on network 192.168.0.0 to be masqueraded to everybody ipfw a m all from 192.168.0.2/24 to 0.0.0.0/0 ... ... </verb></tscreen> Again note the relationship between the netmask (255.255.255.0) and the <em>ipfw</em> syntax. A class C network (255.255.255.0) has 24 bits in its netmask. To make the job a little easier for you, here is a table of common network masks against matching bits: <tscreen><verb> netmask ipfw --------------- ---- 255.0.0.0 /8 255.255.0.0.0 /16 255.255.255.0 /24 255.255.255.128 /25 255.255.255.192 /26 255.255.255.224 /27 255.255.255.240 /28 255.255.255.248 /29 255.255.255.255 /32 </verb></tscreen> <sect2><heading>Where is IP_MASQUERADE being discussed ? <p> There was a support mailing list at masq@eves.com. Unfortunately it has now closed down. <sect1><heading>IPALIAS - multiple address per interface. <p> If you are running a world wide web server and want to supports multiple virtual servers, or your network support multiple subnets on the same piece of wire then you'll need to be able to have your machine respond to more than one address per interface. A facility called <em>ipalias</em> allows you to configure more than one address per interface. Robert Sanders <tt><rsanders@mindspring.com></tt> has written linux support for this feature as patches against version 1.2.* kernels and Juan Jose Ciarlante <tt><jjciarla@raiz.uncu.edu.ar></tt> has developed a brand new and very sophisticated implementation for version 1.3.50++ kernels. <sect2><heading>Support for 1.2.* kernels <p> You can obtain the patch from: <bf>ftp.procyon.com</bf> <tscreen><verb> /pub/linux/ipalias </verb></tscreen> To install it you need the 1.2.1 kernel source installed and then: <tscreen><verb> # cd /usr/src/linux # patch -p1 .../alias-patch-1.2.1-v1 # make config # make dep; make clean; make zlilo </verb></tscreen> You will also need to get the <tt>alias-net-tools.tar.gz</tt> file as it contains new versions of the <em>ifconfig</em> and <em>netstat</em> commands. <sect3><heading>Configuring ip aliases for 1.2.*. <p> To configure an ip alias use the new <em>ifconfig</em> command as follows: <tscreen><verb> # ifconfig eth0 alias 198.71.200.5 </verb></tscreen> This presumes that you already have the device configured to operate on your network and that you want <tt>198.71.200.5</tt> configured as a second address. <sect2><heading>Support for 1.3.50++ kernels <p> You do not need any patches, simply answer yes to the question: <tt>Network aliasing (CONFIG_NET_ALIAS) [N/y/?]</tt> when prompted during <tt>make config</tt>. <sect3><heading>Configuring IP_ALIAS for 1.3.50++ <p> The new ip_alias facilities actually create new network interfaces to more properly. To check if your kernel actually has proper support for the new facility you should look for <tt>/proc/net/alias*</tt>. If your kernel has been properly built then two file will exist, <tt>aliases</tt> and <tt>alias_types</tt> in the <tt>/proc/net</tt> directory. <p> To configure aliases you use a special trick using a normal unmodified <em>ifconfig</em> program. The new alias ports are specified by including a suffix for the physical port name as follows: <tscreen><verb> # ifconfig eth0:0 192.168.1.1 # route add -host 192.168.1.1 dev eth0:0 </verb></tscreen> Note that aliases start at '0'. So <tt>eth0:1</tt> would be the second alias for the physical <tt>eth0</tt> device. <p> To delete an alias you again use the <em>ifconfig</em> command as follows: <tscreen><verb> # ifconfig eth0:0- 0 </verb></tscreen> The '-' character signifies to the kernel that the alias should be deleted and all routes and arp entries that point to it should be deleted. <sect><heading>Diagnostic tools - How do I find out what is wrong? <p> In this section I'll briefly describe some of the commonly used diagnostic tools that are available for your Linux network and how you might use them to identify the cause of your network problems, or to teach yourself a bit more about how tcp/ip networking works. I'll gloss over some of the detail of how the tools work because this document is not an appropriate forum for describing that sort of detail, but I hope I'll have presented enough information that you'll have an understanding of how to use the tool and to better understand the relevant <em>man</em> page or other documentation. <sect1><heading>ping - are you there? <p> The <em>ping</em> tool is located in the NetKit-B distribution as detailed above in the `Network Applications' section. <em>ping</em>, as the name implies, allows you to transmit a datagram at another host that it will reflect back at you if it is alive and working ok and the network in between is also ok. In its simplest form you would simply say: <tscreen><verb> # ping gw PING gw.vk2ktj.ampr.org (44.136.8.97): 56 data bytes 64 bytes from 44.136.8.97: icmp_seq=0 ttl=254 time=35.9 ms 64 bytes from 44.136.8.97: icmp_seq=1 ttl=254 time=22.1 ms 64 bytes from 44.136.8.97: icmp_seq=2 ttl=254 time=26.0 ms ^C --- gw.vk2ktj.ampr.org ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 22.1/28.0/35.9 ms # </verb></tscreen> What <em>ping</em> has done is resolved the hostname to an address and using the <em>icmp</em> protocol has transmitted an <em>icmp echo request</em> datagram to the remote host periodically. For each <em>echo request</em> that the remote host receives it will formulate an <em>icmp echo reply</em> datagram which it will transmit back to you. Each line beginning with `64 bytes from ...' represents an <em>echo reply</em> received in response to an <em>echo request</em>. Each line tells you the address of the host that sent you the reply, the sequence number to which the reply was for, the <em>time to live</em> field and the total <em>round trip time</em> that was taken. The <em>round trip time</em> is the time between when the <em>echo request</em> datagram is transmitted and the corresponding <em>echo reply</em> is received. This can be used as a measure of how fast or slow the network connection between the two machines is. <p> The last two lines tell you how many datagrams were transmitted, how many valid responses were received and what percentage of the datagrams were lost. The percentage lost figure is a measure of how good or error free the network connection is. High percentage lost figures indicate such problems as a high error rate on a link somewhere between the hosts, exhausted capacity on a router or link somewhere, or high collision rate on an ethernet lan. You can use <em>ping</em> to identify where this problem might be by running <em>ping</em> sessions to each of the routed points that make up the network path. When you find that you can ping somewhere without any datagram loss, but pinging anywhere past there causes you packet loss, you can deduce that the problem lies somewhere between those two points. <sect1><heading>traceroute - How do I get there? <p> The <em>traceroute</em> tool is found in the NetKit-A distribution detailed earlier. <em>traceroute</em> is primarily used for testing and displaying the path that your network connection would take to a destination host. <em>traceroute</em> also uses the <em>icmp</em> protocol, but it uses a clever trick to get each point along the path to send it back a reply as it creeps its way along. Its trick is to manually manipulate the <em>time to live</em> field of the datagrams it transmits. The <em>time to live</em> field is a mechanism that ensures that rogue datagrams do not get caught in a routing loop. Each time a datagram passes through a router it decrements the <em>time to live</em> field by one. If the <em>time to live</em> reaches zero then that router or host sends an <em>icmp time to live expired</em> message back to the host who transmitted the datagram to let it know the datagram has expired. <em>traceroute</em> uses this mechanism by sending a series of <em>udp</em> datagrams with the <em>time to live</em> beginning set at one and incrementing each step it takes. By recording the addresses from the <em>icmp time to live expired</em> replies it receives in response to the datagrams dying it can determine the path taken to get to the destination. An example of its use would look something like: <tscreen><verb> # traceroute minnie.vk1xwt.ampr.org traceroute to minnie.vk1xwt (44.136.7.129), 30 hops max, 40 byte packets 1 gw (44.136.8.97) 51.618 ms 30.431 ms 34.396 ms 2 gw.uts (44.136.8.68) 2017.322 ms 2060.121 ms 1997.793 ms 3 minnie.vk1xwt (44.136.7.129) 2205.335 ms 2319.728 ms 2279.643 ms # </verb></tscreen> The first column tells us how many hops away (what the <em>ttl</em> value was), the second column is the hostname and address that responded if it could be resolved or just its address if it could not. The third, fourth and fifth columns are the round trip time for three consecutive datagrams to that point. This tells us that the first hop in the network route is via gw.vk2ktj and the three figures following are the round trip times to that router. The next hop was via gw.uts.ampr.org and minnie.vk1xwt.ampr.org is one hop further away. You can deduce information about the network route by looking at the difference in times between each step in the route. You can see that the round trip times to gw are fairly fast, it is an ethernet connected host. gw.uts is substantially slower to get to than gw, it is across a low speed radio link, so you have the ethernet time plus the radio link time added together. minnie.vk1xwt is only slightly slower than gw.uts, they are connected via a high speed network. <p> If you perform a traceroute and you see the string <tt>!N</tt> appear after the time figure, this indicates that your traceroute program received a <em>network unreachable</em> response. This message tells you that the host or router who sent you the message did not know how to route to the destination address. This normally indicates that there is a network link down somewhere. The last address listed is as far as you get before you find the faulty link. <p> Similarly if you see the string <tt>!H</tt> this indicates that a <em>host unreachable</em> message has been received. This might suggest that you got as far as the ethernet that the remote host is connected to, but the host itself is not responding or is faulty. <sect1><heading>tcpdump - capturing and displaying network activity. <p> Adam Caldwell <acaldwel@103mort2.cs.ohiou.edu> has ported the <em>tcpdump</em> utility to linux. <em>tcpdump</em> allows you to take traces of network activity by intercepting the datagrams on their way in and out of your machine. This is useful for diagnosing difficult to identify network problems. You can find the source and binaries at: <url url="ftp://ftp.funet.fi/pub/OS/Linux/PEOPLE/Linus/net-source/tools/tcpdump-3.0.3.tar.gz" name="103mor2.cs.ohiou.edu"> <em>tcpdump</em> decodes each of the datagrams that it intercepts and displays them in a slightly cryptic looking format in text. You would use <em>tcpdump</em> if you were trying to diagnose a problem like protocol errors, or strange disconnections, as it allows you to actually see what has happened on the network. To properly use <em>tcpdump</em> you would need some understanding of the protocols and how they work, but it is useful for simpler duties such as ensuring that datagrams are actually leaving your machine on the correct port if you are trying to diagnose routing problems and for seeing if you are receiving datagrams from remote destinations. A sample of tcpdump output looks like this: <tscreen><verb> # tcpdump -i eth0 tcpdump: listening on eth0 13:51:36.168219 arp who-has gw.vk2ktj.ampr.org tell albert.vk2ktj.ampr.org 13:51:36.193830 arp reply gw.vk2ktj.ampr.org is-at 2:60:8c:9c:ec:d4 13:51:37.373561 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request 13:51:37.388036 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply 13:51:38.383578 albert.vk2ktj.ampr.org > gw.vk2ktj.ampr.org: icmp: echo request 13:51:38.400592 gw.vk2ktj.ampr.org > albert.vk2ktj.ampr.org: icmp: echo reply 13:51:49.303196 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: S 700506986:700506986(0) win 512 <mss 1436> 13:51:49.363933 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 1103372289 win 14261 13:51:49.367328 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: S 1103372288:1103372288(0) ack 700506987 win 2048 <mss 432> 13:51:49.391800 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: . ack 134 win 14198 13:51:49.394524 gw.vk2ktj.ampr.org.telnet > albert.vk2ktj.ampr.org.1104: P 1:134(133) ack 1 win 2048 13:51:49.524930 albert.vk2ktj.ampr.org.1104 > gw.vk2ktj.ampr.org.telnet: P 1:28(27) ack 134 win 14335 .. # </verb></tscreen> When you start <em>tcpdump</em> without arguments it grabs the first (lowest numbered) network device that is not the loopback device. You can specify which device to monitor with a command line argument as shown above. <em>tcpdump</em> then decodes each datagram transmitted or received and displays them, one line each, in a textual form. The first column is obviously the time the datagram was transmitted or received. The remainder of the line is then dependent on the type of datagram. The first two lines in the sample are what an arp request from albert.vk2ktj for gw.vk2ktj look like. The next four lines are two pings from albert.vk2ktj to gw.vk2ktj, note that <em>tcpdump</em> actually tells you the name of the <em>icmp</em> datagram transmitted or received. The greater-than (>) symbol tells you which way the datagram was transmitted, that is, from who, to who. It points from the sender, to the receiver. The remainder of the sample trace are the establishment of a telnet connection from albert.vk2ktj to gw.vk2ktj. <p> The number or name at the end of each hostname tells you what socket number is being used. <em>tcpdump</em> looks in your /etc/services file to do this translation. <p> <em>tcpdump</em> explodes each of the fields and so you can see the values of the window and mss parameters in some of the datagrams. <p> The <em>man</em> page documents all of the options available to you. <bf>Note for PPP users</bf>: The version of <em>tcpdump</em> that is currently available does not support the PPP suite of protocols. Al Longyear has produced a pair of patches to correct this, but these have not been built into a <em>tcpdump</em> distribution yet. The patch files are located in the same directory on <tt>sunsite.unc.edu</tt> as the <em>tcpdump</em> package. <sect1><heading>icmpinfo - logs icmp messages received. <p> ICMP then Internet Control Message Protocol conveys useful information about the health of your IP network. Often ICMP messages are received and acted on silently with you never knowing of their presence. <em>icmpinfo</em> is a tool that will allow you to view ICMP messages much like tcpdump does. Laurent Demailly <tt><dl@hplyot.obspm.fr></tt> took the bsd ping source and modified it heavily. Version 1.10 is available from: <bf>hplyot.obspm.fr</bf> <tscreen><verb> /net/icmpinfo-1.10.tar.gz </verb></tscreen> Compilation is as simple as: <tscreen><verb> # cd /usr/src # cd icmpinfo-1.10 # gzip -dc icmpinfo-1.10.tar.gz | tar xvf - # make </verb></tscreen> You must be root to run <em>icmpinfo</em>. <em>icmpinfo</em> can either decode to the tty it was called from or send its output to the <em>syslog</em> utility. To test out how it works, try running <em>icmpinfo</em> and starting a <em>traceroute</em> to a remote host. You will see the icmp messages that <em>traceroute</em> uses listed on the output. <sect><heading>Some Frequently Asked Questions, with brief Answers. <p> Following are some questions and answers that are commonly asked. <sect1><heading>General questions: <p> <descrip> <tag>I have only a dialin terminal access to a machine on the net, can I use this as a network connection ? </tag>Yes you can, take a look at TERM. TERM allows you you to run network connections over a normal terminal session. It requires some modifications to the network applications to work with it, but binaries and sources are available for the most common ones already. take a look at the <url url="http://sunsite.unc.edu/mdw/HOWTO/Term-HOWTO.html" name="TERM-HOWTO"> for lots more information. <tag>When I telnet/ftp/rlogin to my machine it takes forever, why? </tag>You do not have your name resolver configured properly. Reread the section on <tt>/etc/resolv.conf</tt>. You must have at least a nameserver entry configured. <tag>I want to build my own standalone network, what addresses do I use ? </tag>RFC1597 has specifically reserved some IP addresses for private networks. You should use these as they prevent anything nasty happening if you accidentally get connected to the Internet. The addresses reserved are: <tscreen><verb> 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 </verb></tscreen> Note, reserved network addresses are of classes A, B and C, so you are not restricted in your network design or size. Since you won't be connecting to the Internet it doesn't matter if you use the same address as some other group or network, just so long as the addresses you use are unique within your network. <tag>I want the machines on my local network to work via my dial-ip Internet connection, how do I do it? </tag>You have three options. They are as follows: <itemize> <item>Ask your Internet Service Provider to provide a network route to you instead of a host route. This is likely to be expensive but is the best performing and technical option. <item>Set up your machine that supports your dial-up link as a `SOCKS' based firewall. This will inherently provide a <em>proxy</em> function where the outside world thinks it is your router machine doing the talking where in fact it is doing it on behalf of the machines on your network. Check the <url url="http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html" name="Firewall-HOWTO"> for detailed information on how to do this. This will require the machines on your network to have client programs that support the SOCKS capability. <item>Configure and run the <tt>IP-Masquerade</tt> software. This is probably the simplest way, as it is fairly straightforward to do and doesn't require special clients on your machines. This software very cleverly performs address translations that make the machines on your network look like they are the machine supporting your dial-up connection. There are some limitations to how well this will work, but it is much lighter-weight than running a full firewall gateway. </itemize> <tag>If ftp.linux.org.uk is down, how do I get the files specified ? </tag>Alan's archive is mirrored on: <bf>ftp.Uni-Mainz.DE</bf> <tscreen><verb> /pub/Linux/packages/Net2Debugged </verb></tscreen> and/or: <bf>ftp.infomagic.com</bf> <tscreen><verb> /pub/mirrors/linux/sunacm </verb></tscreen> <tag>How do I know what version of kernel/net code I am running ? </tag>The network code and kernel now have synchronised version numbers, so try: <tt>uname -a</tt> or: <tt>cat /proc/version</tt> <tag>How do I change the message that telnet users are given at connect? </tag>The <tt>/etc/issue</tt> is the message that is given to normal getty users when they login. Some <em>telnetd</em> programs use a different file <tt>/etc/issue.net</tt> instead. So if you find that changing your <tt>issue</tt> file doesn't work, try changing the other. </descrip> <sect1><heading>Error messages: <p> <descrip> <tag>I keep getting the error `eth0: transmit timed out'. What does this mean? </tag>This usually means that your Ethernet cable is unplugged, or that the setup parameters for your card (I/O address, IRQ, etc.) are not set correctly. Check the messages at boot time and make sure that your card is recognized with the correct Ethernet address. If it is, check that there is no conflict with any other hardware in your machine, eg you might have a soundblaster sharing the same IRQ or i/o control port. <tag>I get errors `check Ethernet cable' when using the network. </tag>You probably have your Ethernet card configured incorrectly. Double check the settings in /usr/src/linux/drivers/net/CONFIG. If this checks out ok, you may in fact have a cabling problem, check the cables are plugged in securely. </descrip> <sect1><heading>Routing questions: <p> <descrip> <tag>Why do I get the message `obsolete route request' when I use the route command ? </tag> You are using a version of route that is older than your kernel. You should upgrade to a newer version of route. Refer to the "The network configuration tool suite" section of this document for information on where to obtain the tool set. <tag>Why do I get a `network unreachable' message when I try and network? </tag>This message means that yours, or some other, machine doesn't know how to route to the host that you are attempting to ping or connect to. If it occurs for all hosts that you try, then it is probable that you don't have your default route set up properly, reread the `routing' section. <tag>I can ping my server/gateway, but can't ping or connect to anyone remote. </tag>This is probably due to a routing problem. Reread the `routing' section in this document. If this looks ok, then make sure that the host you are attempting to connect to has a route to you. If you are a dialin user then this is a common cause of problems, ensure that your server is either running a routing program like <em>gated</em> or <em>routed</em>, or that it is <em>`proxy arping'</em> for you, otherwise you will be able to get datagrams to the remote host, but it won't know how to return datagrams to you. </descrip> <sect1><heading>Using Linux with Novell fileservers or NFS: <p> <descrip> <tag>How do I use my existing Novell fileserver with my Linux machine ? </tag>You should read the <url url="http://sunsite.unc.edu/mdw/HOWTO/IPX-HOWTO.html" name="IPX-HOWTO"> as it has information on Linux software that will allow you to do this without having to worry about using NFS. <tag>Files get corrupted when running NFS over a network. </tag>Certain vendors (Sun primarily) shipped many machines running NFS without UDP checksums. Great on ethernet, suicide otherwise. UDP checksums can be enabled on most file servers. Linux has it enabled by default from pl13 onwards - but both ends need to have it enabled... <tag>Why are my NFS files all read only ? </tag>The Linux NFS server defaults to read only. RTFM the `exports' and nfsd manual pages. With non Linux servers you may also need to alter /etc/exports </descrip> <sect1><heading>SLIP questions: <p> <descrip> <tag>What do I do if I don't know my SLIP servers address ? </tag><em>dip</em> doesn't really need to know the address of your SLIP server for SLIP to function. The <em>remote</em> option was added as a convenience so that <em>dip</em> could automate the <em>ifconfig</em> and <em>route</em> commands for you. If you don't know and cannot find out the address of your SLIP server then Peter D. Junger <tt>Junger@samsara.law.cwru.edu</tt> has suggested that he simply used his own address wherever a dip script called for a remote address. This is a small kludge but it works ok, as the server's address never actually appears in the SLIP headers anyway. <tag>`dip' only works for root. How do I make it work for others? </tag><em>dip</em> needs to be setuid root to do some of the things it needs to do, such as modifying the routing table. Uri Blumenthal recommends the following: <itemize> <item>Create a new group called <em>dip</em> in your <tt>/etc/group</tt> file and place each person who you want to allow dial out operation in it. <item>Then when logged in as root, do the following: <verb> # chown root.dip /usr/bin/dip # chmod u=rx,g=x,o= /usr/bin/dip # chmod u+s /usr/bin/dip </verb> </itemize> Dial-In users will be restricted in what they can do by what is contained in the <tt>/etc/diphosts</tt> file. <tag>I get `<tt>DIP: tty: set_disc(1): Invalid argument</tt>', why? </tag>This usually suggests that your kernel has not been compiled with <em>SLIP</em> support in it. Check that <tt>/proc/net/dev</tt> contains devices called <tt>sl0</tt>, <tt>sl1</tt> etc. It could also mean that your version of dip is very old. You should upgrade to a newer version. <tag>When I ping a host I get `<tt>wrong data byte #17...</tt>', why? </tag>This generally means that you have your modem configured for XON/XOFF flow control. SLIP <bf>must</bf> have an eight bit clean line, so you cannot use XON/XOFF flow control. Hardware handshaking works better anyway, use it. <tag>With SLIP I can ping my server and other hosts, but telnet or ftp don't work. </tag>This is most likely caused by a disagreement on the use of header compression between your server and your machine. Double check that both ends either are, or are not, using compression. They must match. <tag>How can I hang up the phone line when I'm done using SLIP? </tag>If you use dip to dial out on the SLIP line, just `dip -k' should do the trick. If not, try to kill the dip process that is running. When dip dies it should hang up the call. To give it the best chance to clean up after itself, try killing the process in the following sequence: `kill <pid>', `kill -hup <pid>' and finally, if the dip process still refuses to die, try `kill -9 <pid>'. The same philosophy should be applied to all unix processes that you are attempting to kill. <tag>I see a lot of overrun errors on my SLIP port, why ? </tag>The older network tools incorrectly report number of packets compressed as the number of packets overrun. This has been corrected and shouldn't occur of you are running the new version kernel and tools. If it still is it probably indicates that your machine isn't keeping up with the rate of data incoming. If you are not using 16550AFN UARTs then you should upgrade to them. 16450, or 8250 generate an interrupt for every character they receive and are therefore very reliant on the processor to be able to find time to stop what it is doing an collect the character from them to ensure none get lost. The 16550AFN has a 16 character FIFO and they only generate interrupts when the FIFO is nearly full, or when they have had character waiting, this means that less interrupts get generated for the same amount of data and that less time is spent servicing your serial port. If you want to use multiple serial ports you should mandatorily upgrade to 16550AFN UARTs anyway. <tag>Can I use two SLIP interfaces ? </tag>Yes. If you have, for example, three machines which you would like to interconnect, then you most certainly could use two SLIP interfaces on one machine and connect each of the other machines to it. Simply configure the second interface as you did the first. NOTE that the second interface will require a different IP address to the first. You may need to play with the routing a bit to get it to do what you want, but it should work. <tag>I have a multiport i/o card, how do I use more than 4 SLIP ports ? </tag>The kernel SLIP comes with a default of a maximum of 4 SLIP devices configured, this is set in the <tt>/usr/src/linux/drivers/net/slip.h</tt> file. To increase it, say to <tt>16</tt>, change the <tt>#define SL_NRUNIT</tt> to <tt>16</tt>, in place of the <tt>4</tt> that will be there. You also need to edit <tt>/usr/src/linux/drivers/net/Space.c</tt> and add sections for <tt>sl4</tt>, <tt>sl5</tt> etc. You can copy the existing driver definition as a template to make it easier. You will need to recompile the kernel for the change to take effect. </descrip> <sect1><heading>PPP questions. <p> You should refer to the <url url="http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html" name="PPP-HOWTO"> for a list of PPP questions and answers compiled by Al Longyear. <sect><heading>Quick Guide - SLIP or PPP Server <p> Configuring your linux machine as a SLIP or PPP server is a deceptively simple thing to do. The actual process is simple, but there are a number of different aspects to the configuration and understanding how each of the stages interact with each other is what will help you diagnose any problems you experience. Here are the steps that you must follow to configure your linux machine as a SLIP or PPP server: <enum> <item>Assemble your hardware. Avoid IRQ and shared memory conflicts. Test each of the serial ports by connecting a dumb terminal to each of the ports and use a null modem cable and a comms program like <em>minicom</em> or <em>seyon</em> to talk to each. Make sure you can send and receive characters. If you intend running a number of serial ports then try to use a smart serial board and use <tt>16550AFN</tt> UART's. This will help ease some of the work of handling interrupts generated by the serial ports. <item>Build your kernel, make sure it has networking configured, <tt>IP Forwarding</tt> enabled if you want users to route via your server and <tt>SLIP</tt> or <tt>PPP</tt> configured as is appropriate for your configuration. Make sure you configure <tt>CSLIP</tt> if you wish to use it. Double check you have <tt>IP Forwarding</tt> enabled if you don't then dialin users will only be able to connect directly to your machine. <item>Install your kernel. Test the kernel. Check the <tt>/proc/net/dev</tt> file and make sure that you have <tt>sl*</tt> <tt>ppp*</tt> devices listed. If not then you have probably made some error in configuring your kernel, or you are not actually running your new kernel. Double check that you have actually run lilo to install the new kernel. <item>Configure a <em>getty</em> on the serial port(s) that you wish to use for your incoming calls. You should refer to the <url url="http://sunsite.unc.edu/mdw/HOWTO/Serial-HOWTO.html" name="Serial-HOWTO"> for a description of how to do this. Remember to configure your modem so that the <tt>DCD</tt> pin tracks received carrier, this is how most <em>getty</em> programs detect an incoming call (<tt>mgetty</tt> is an exception to this and uses the <tt>RING</tt> message so you must be sure you have your modem configured to generate it: <tt>ATQ0V1</tt> is usually enough). <item>Test the <em>getty</em> to make sure it works. It is important that you do this before you start worrying about the actual SLIP or PPP configuration. Try dialing into your system, you should get a <tt>login:</tt> prompt and be able to login to a shell account normally. Check for lost or garbled characters that might indicate a flow control problem. <item>Decide how you want your server to allocate addresses. If you want your users to get the same address each time they call then you want a <tt>static</tt> server, if you want to minimise the number of addresses you use and don't care what address your users are allocated then you want a <tt>dynamic</tt> server. <item>Decide how you are going to build the SLIP or PPP server, whether you are going to use <em>sliplogin</em>, <em>dip</em> or <em>dSLIP</em> for SLIP for example. If you wish to use the <em>sliplogin</em> package then refer to the "Slip Server using Sliplogin" section. If you are going to use <em>dip</em> then refer to section "Slip Server using DIP". If you want to build your SLIP server using the <em>dSLIP</em> package then refer to section "Slip Server using dSLIP". For PPP you will need to use the <em>pppd</em> program, so make sure you read the <url url="http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html" name="PPP-HOWTO"> on how to configure this. Ensure you have the appropriate software, that it is a recent version and that it is compiled and installed if necessary. <item>If the addresses you are allocating to you SLIP users are part of your ethernet network, then make sure you read the Proxy ARP section and configure a proxy arp for each address. You may do this in the <tt>/etc/sliplogin<tt> and </tt>/etc/SLIPlogout</tt> files if you are using the <em>sliplogin</em> package. If you are configuring a PPP server then make sure you use the <em>pppd</em> <tt>proxyarp</tt> option. If the addresses you are allocating are from a network seperate to your ethernet network then you will need to use a routing daemon program like <em>gated</em>. If you use <em>gated</em> then refer to the "gated" section. <item>Test your SLIP/PPP server. <item>Get someone else to test your SLIP/PPP server. </enum> <sect><heading>Known Bugs. <p> The Linux networking code is still an evolving thing. It still has bugs though they are becoming less frequently reported now. The <url url="http://iifeak.swan.ac.uk/NetNews.html" name="Linux Networking News"> is a World Wide Web page maintained by Alan Cox which contains information on the status of the NET-3 networking code. You can obtain information on what is known and what isn't, by reading the <tt>/usr/src/linux/net/inet/README</tt> file that accompanies the kernel source, or by joining the <tt>linux-net</tt> channel. <sect><heading>Copyright Message. <p> The NET-2-HOWTO is Copyright (c) 1995 Terry Dawson and Matt Welsh. Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copies above, provided a notice clearly stating that the document is a modified version is also included in the modified document. Permission is granted to copy and distribute translations of this document into another language, under the conditions specified above for modified versions. Permission is granted to convert this document into another media under the conditions specified above for modified versions provided the requirement to acknowledge the source document is fulfilled by inclusion of an obvious reference to the source document in the new media. Where there is any doubt as to what defines 'obvious' the copyright owner reserves the right to decide. <sect><heading>Miscellaneous and Acknowledgements. <p> There are so many people who have contributed comments and suggestions for this update that I have forgotten who you are. <bf>Thanks</bf>. Please, if you have any comments or suggestions then mail them to me. I'm fairly busy these days, so I might not get back to you straight away, but I will certainly consider any suggestion you have. The Linux networking code has come a long way and it hasn't been an easy trip, but the developers, all of them, have done an excellent job in getting together something that is functional, versatile, flexible and free for us to use. We all owe them a great debt of thanks. Linus, Ross, Fred, Alan, the Alpha/Beta testers, the tools developers and those offering moral support have all contributed to the code as it is today. For those that have an itch they want to scratch, happy hacking, here it is. <p> regards <tt>Terry Dawson, vk2ktj.</tt> <p> <tt><94004531@postoffice.csu.edu.au>, or <terry@perf.no.telecom.com.au></tt> </article> 
