  Deutsches Linux NET-2/3-HOWTO
  bersetzung durch Peter Stterlin (pit@uni-sw.gwdg.de)
  v3.5d, August 1996

  Ziel dieses Textes ist die Beschreibung, wie man die NET-2 und NET-3
  Software fr Linux bekommt und wie sie installiert und konfiguriert
  wird.  Einige Antworten auf fters gestellte Fragen sind im Anhang
  enthalten.  Dieses Dokument ist nicht dazu gedacht, dem Leser eine
  Einfhrung in das TCP/IP Netzprotokoll zu geben, auch wenn diesbetref
  fende Informationen wo immer mglich mitaufgenommen wurden.  Eine
  Liste mit Texten, die eine solche TCP/IP-Einfhrung aufweisen, ist
  aber angegeben.  Der Text ist eine deutsche bersetzung des englischen
  Originaltextes, den Terry Dawson (terry@perf.no.itg.telecom.com.au)
  mit viel Sorgfalt zusammengestellt hat.  Basis der bersetzung ist die
  Version 3.5 vom 16 Januar 1996.

  1.  Einleitung

  Dies ist das Linux NET-2/3-HOWTO.  Der Text ist eine vllige
  Neufassung des lteren NET-FAQ und der darauf basierenden NET-2-HOWTOS
  der 1.0+ Versionen.  Das Dokument beschreibt den neuen NET-2/3 TCP/IP
  Netzwerk Code der Linux Kernels von Version 1.0 ab aufwrts.

  Es mag seltsam erscheinen, einige Monate nach Erscheinen des 2.0
  Kernels noch einen Text zu verffentlichen, der noch Kernelversionen
  1.2.13 und 1.3.x beschreibt.  Diese Abschnitte des Linux NET-2/3-HOWTO
  mssen neu geschrieben werden (Terry sitzt gerade daran).  Sobald
  seine neue Version erschienen ist, werde ich mich an die bersetzung
  machen...  Der Groteil des Textes hat aber auch fr die neuen Kernels
  Gltigkeit.

  1.1.  Eine Kurze Geschichte des Linux Netzwerk Systems

  Ross Biro (biro@yggdrasil.com) schrieb den ursprnglichen Netzwerk-
  Code im Linux Kernel.  Er benutzte dazu Ethernet-Treiber von Donald
  Becker (becker@cesdis1.gsfc.nasa.gov), einen SLIP-Treiber von Laurence
  Culhane (loz@holmes.demon.co.uk) und einen D-Link Treiber von Bj0rn
  Ekwall (bj0rn@blox.se).

  Die Weiterentwicklung des Linux Netzwerk Codes wurde spter von Fred
  van Kempen (waltje@hacktic.nl) bernommen, der basierend auf den
  Quellen von Ross die NET-2 Version zusammenstellte.  NET-2 machte
  einige Revisionen durch bis zur Version NET-2d.  Zu diesem Zeitpunkt
  begann Alan Cox (iialan@iifeak.swan.ac.uk), den Code von Fred nach
  Fehlern abzusuchen mit dem Ziel, eine wirklich stabiles Code-Paket fr
  die bernahme in den Standard-Kernel zu schaffen.  Dieser Code wurde
  ursprnglich als NET-2D(ebugged) bezeichnet und wurde kurz vor der
  Linux Version 1.0 in die Standard-Kernels aufgenommen.

  Untersttzung fr das PPP-Protokoll wurde von Michael Callahan
  (callahan@maths.ox.ac.uk) und Al Longyear (longyear@netcom.com)
  implementiert, zunchst als ein Satz von Patches, spter als fester
  Bestandteil der Standard-Kernel-Distribution.

  Die letzte Revision des Codes, NET-3, erscheint in den Kernelversionen
  ab 1.1.5.  Obwohl prinzipiell noch derselbe Code, wurden viele Fehler
  behoben und Erweiterungen eingebracht.

  Alan hat die IPX und AX.25 Module mitimplementiert, eine auf den
  neuesten Stand gebrachte Distribution der Netzwerk-Applikationen wurde
  von Florian La Roche (flla@stud.uni-sb.de) zusammengestellt.

  NIIBE Yutaka hat den PLIP-Treiber verbessert.

  Jonathan Naylor bernahm die Weiterentwicklung des AX.25-Codes und hat
  viele Dinge wie z.B. die NetROM-Untersttzung hinzugefgt.

  Viele weiter Personen haben durch Fehlermeldungen und -Korrekturen
  sowie durch das Schreiben von Hardware-Treibern mitgeholfen.

  2.  Disclaimer

  Der Linux Netzwerk Code ist eine vllig neue Implementation des
  TCP/IP-Netzwerkes auf Kernelebene.  Er wurde von Grund auf neu
  geschrieben und ist keine Portierung eines bestehenden Netzwerk-Codes.

  Das Netzwerk-System unter Linux ist einer der neuesten und am meisten
  innovativen Codes, die derzeit bekannt sind.  Eine groe Zahl an
  Entwicklern arbeiten daran, ihn fr viele neue Anwendungen anzupassen,
  und aus diesem Grund ist er einem schnellen Wachstum unterworfen.  Er
  unterliegt starken Vernderungen und mag immer noch einige Fehler oder
  Ungereimtheiten aufweisen, und es werden wohl auch noch Patches zur
  Fehlerbehebung auftauchen.  Wer vor solchen Problemen sicher sein
  will, sollte bei einer der Versionen bleiben, die in den stabilen
  Standard-Kernels implementiert sind.  Derartige Kernel-Versionen haben
  eine gerade Versionsnummer an der zweiten Stelle, 1.2.7 ist zum
  Beispiel eine solche, 2.0.0 ebenfalls.  Kernel-Versionen mit einer
  ungeraden Nummer an zweiter Stelle sind alpha Versionen und man mu
  immer damit rechnen, da ein solcher Kernel Fehler enthlt oder einige
  Probleme bereitet.  Es sind eben Testversionen.  Der eigentliche
  Netzwerk-Code wird von einer kleinen Gruppe von Leuten entwickelt,
  einige tausend weitere testen diesen Code, suchen Fehler und liefern
  auch Vorschlge zu deren Behebung.  Wer also selber Probleme hat:
  Diese sind vermutlich bereits gemeldet und werden bald behoben.  Etwas
  Geduld hilft meistens.  Wer auf der anderen Seite in der Lage ist,
  selber aktiv mitzuarbeiten, sollte seine Mithilfe anbieten.

  Ein einzelner kann kaum alles ber die Linux Netzwerk Software wissen.
  Aus diesem Grund ist es mglich, das dieser Text Fehler enthlt.
  Bitte lesen Sie alle README-Dateien, die mit neu zu installierender
  Software mitgeliefert werden.  Diese enthalten meist weitergehende und
  detailliertere Informationen.  Die angegebenen Software-Versionen
  waren zum Zeitpunkt, als dieser Text geschrieben wurde, die jeweils
  aktuellsten.

  Achtung Obwohl der Name hnlich wie derjenige der Berkeley Software
  Distribution NET-2 release klingt, hat der Linux Netzwerk Code
  berhaupt nichts mit diesem zu tun und sollte nicht verwechselt
  werden.

  3.  Gibt es bereits Fragen ?

  `Die einzige wirklich dmliche Frage ist die, die keiner stellt.'

  Wer allgemeine Fragen zur Konfiguration hat, und die Antworten darauf
  nicht in den diversen HOWTO und FAQ Texten gefunden hat, ist am besten
  bedient, wenn er seine Fragen in der Newsgroup
  de.comp.os.linux.networking postet, oder, falls er glaubt, da es sich
  um ein spezielles Problem des Linux-Codes handelt, auch in der NET
  mailing list (in Englisch).  Auf jeden Fall: Geben Sie so viele
  Informationen wie mglich an, denn es ist nicht rgerlicher als ein
  Fehlerbericht, bei dem man nicht die leiseste Idee hat, wo man mit der
  Suche beginnen soll!

  Die Versionsnummern und Revisionen des verwendeten Codes sowie die
  genaue Beschreibung des Fehlers und der Umstnde, unter denen er
  auftritt, sind wesentlich.  Ergebnisse eines trace-Aufrufs sowie die
  Ausgabe von debug-Meldungen sollten wo immer mglich ebenfalls
  angegeben werden.

  Wer Fragen zur Konfiguration irgendeiner Linux-Distribution hat, oder
  Probleme mit deren Netzwerk-Teil hat, sollte auf jeden Fall zuerst die
  Autoren/Vertreiber dieser Distribution kontaktieren, bevor er das
  Problem an die Entwickler des Netzwerk-Codes schickt.  Der Grund
  hierfr ist, da einige Distributionen eine nicht dem Standard
  entsprechende Verzeichnis-Struktur aufweisen oder nicht-
  standardisierte oder sogar Testversionen des Codes und der
  Hilfsprogramme verwenden.  Die Entwickler des NET-2 Codes knnen nur
  fr den Code, wie er hier beschrieben ist, Untersttzung geben, bzw.
  entsprechend dem in den Instruktionen fr Alpha-Tester angegebenen
  Rahmen.

  Zur Aufnahme in die Linux Mailing-Liste linux-net gengt eine email
  an:

       Majordomo@vger.rutgers.edu

  mit der Zeile:

       subscribe linux-net

  als Text (die subject:-Zeile wird ignoriert).  Aber denken Sie dran:
  linux-net ist ausschlielich zur Diskussionen rund um die Software-
  Entwicklung gedacht!

  Weiterhin gibt es inzwischen eine PPP-Liste.  Um daran teilzunehmen
  gelte dieselben Regeln wie gerade bei linux-net angegeben, lediglich
  mu im Text der email stattdessen subscribe linux-ppp angegeben
  werden.
  In einer weiteren Liste, linux-hams, werden Programme und Probleme
  diskutiert, die sich mit Amateur Radio befassen.  Zur Teilnahme gilt
  wiederum: email an die obengenannte Adresse mit dem Text subscribe
  linux-hams .

  4.  Weiterfhrende Literatur (ber TCP/IP)

  Wer nach Informationen ber das TCP/IP-Netzwerk-Protokoll sucht, die
  in diesem HOWTO nicht behandelt werden, wird vielleicht an den
  folgenden Stellen fndig.  Sie enthalten einige sehr ntzliche
  Informationen..

  Olaf Kirch hat im Rahmen des Linux Documentation Project ein
  substantielles Dokument mit dem Namen Linux Network Administration
  Guide verfat.  Es ist ein exzellentes Buch, welches alle Aspekte des
  TCP/IP unter Linux abdeckt, inklusive NFS, UUCP, mail, News,
  nameserver usw.

  Olaf's Buch ist in gewisser Weise eine Ergnzung zu diesem HOWTO, da
  es dort einsetzt, wo dieser Text aufhrt.  Es behandelt die
  Installation und Konfiguration des Netzwerk-Codes, also `wie man
  seinen Rechner an's Netz hngt'.  Wer sich noch nicht mit dem Unix-
  Netzwerk auskennt, dem kann nur wrmstens empfohlen werden, sich eine
  Kopie davon zu besorgen.  Es wird sicherlich einige der Fragen
  beantworten, deren Beantwortung den Rahmen dieses HOWTO bersteigen
  wrde.

  Die aktuelle Version ist via ftp erhltlich:

       sunsite.unc.edu:/pub/Linux/docs/linux-doc-project/network-guide/

  In diesem Verzeichnis befinden sich unterschiedliche Versionen des
  NAG.  Die gngigen Formate werden untersttzt: reines ASCII,
  PostScript, DVI, LaTeX und groff.

  Der Linux Network Administrators Guide ist Copyright (c) by Olaf
  Kirch.

  Es gibt inzwischen einige Verlage, die die Linux Dokumentationen
  vertreiben.  Wem also das Herunterladen ber ftp und ausdrucken auf
  dem Drucker zu viel Aufwand ist, sollte Olaf's Buch in gebundener Form
  in jedem besseren Buchladen finden.  Inzwischen ist es auch in
  deutscher Sprache erhltlich.

  Auerdem sollte man die anderen fr Netzwerke relevanten Linux HOWTOs
  lesen.

  Dies sind:

  Das Ethernet-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Ethernet-
  HOWTO.html), das jeder lesen sollte, der eine Ethernet-Karte unter
  Linux benutzen will.  Es liefert jede Menge Hilfen bei der Auswahl,
  Installation und Konfiguration einer Netzwerkkarte unter Linux und
  Anleitungen, wie man Probleme mit den Treibern diagnostizieren kann.

  Das PPP-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html) fr
  alle an PPP Interessierten.

  Das IPX-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/IPX-HOWTO.html) gibt
  Informationen ber die IPX-Untersttzung in Linux.

  Das Serial-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Serial-HOWTO.html),
  falls SLIP oder PPP im Server-Modus betrieben werden sollen.
  Das NIS-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html).
  Information ber den Betrieb einer Version des Network Information
  Service von Sun.

  Das HAM-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html) fr
  diejenigen, die die Amateur Radio Software unter Linux benutzen
  wollen.

  Das Mail-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Mail-HOWTO.html) und
  das News-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/News-HOWTO.html)
  geben genauere Anleitungen, wie Mail und News korrekt aufgesetzt
  werden.

  Das UUCP-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/UUCP-HOWTO.html),
  falls die Verbindung zum Internet ber UUCP erfolgt.

  Das Firewall-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Firewall-
  HOWTO.html) fr alle, die ihr Netzwerk durch einen Linux-Rechner als
  Firewall nach auen absichern wollen.

  Wer einige Informationen zum TCP/IP-Netzwerk generell sucht, dem
  knnen die folgenden Dokumente empfohlen werden:

     tcp/ip introduction
        Text Version (ftp://athos.rutgers.edu/runet/tcp-ip-intro.doc),

        PostScript Version (ftp://athos.rutgers.edu/runet/tcp-ip-
        intro.ps).

     tcp/ip administration
        Text Version (ftp://athos.rutgers.edu/runet/tcp-ip-admin.doc),

        PostScript Version (ftp://athos.rutgers.edu/runet/tcp-ip-
        admin.ps).

  Eine sehr viel detaillierteres Buch zum Thema TCP/IP ist:

       "Internetworking with TCP/IP"
       by Douglas E. Comer

       ISBN 0-13-474321-0
       Prentice Hall publications.

  Wer selber Netzwerk-Anwendungen unter Unix schreiben will, sollte
  folgendes Buch unbedingt lesen:

       "Unix Network Programming"
       by W. Richard Stevens

       ISBN 0-13-949876-1
       Prentice Hall publications.

  4.1.  Aktuelle Versionen dieses Dokuments

  Die Netzwerk-Untersttzung fr Linux ndert sich sehr schnell, mit
  laufend neuen Erweiterungen und Verbesserungen.  Gleiches mu deshalb
  auch fr diesen Text gelten.  Ist er bereits deutlich lter als ein
  halbes Jahr ist mittlerweile vielleicht bereits eine aktuellere
  Version erschienen, nachsehen lohnt sich in diesem Fall!

  Die neueste englische Version des NET-2-HOWTO kann immer ber
  anonymous ftp bezogen werden:

       sunsite.unc.edu:/pub/Linux/docs/HOWTO/NET-2-HOWTO

  Die jeweils aktuelle deutsche Version gibt es hier:

       ftp.heise.de:/pub

  oder

       ftp.uni-stuttgart.de:/pub/systems/linux/local/doc/

  oder via World Wide Web auf der Homepage des Deutschen Linux HOWTO
  Projekts (http://www.tu-harburg.de/~semb2204/dlhp/index.html).

  Auerdem werden beide Versionen des NET-2-HOWTO regelmig in den
  folgenden Newsgroups gepostet: comp.os.linux.networking,
  comp.os.linux.answers und news.answers.

  Die FAQ-Postings aus news.answers, also auch dieses HOWTO, werden auf
  rtfm.mit.edu:/pub/usenet archiviert.

  4.2.  Feedback

  Korrekturen und Vorschlge zu dieser deutschen Version bitte an mich
  (pit@uni-sw.gwdg.de) senden.  Ich werde dann Dinge, die nicht auf
  meine Kappe gehen, an den Autor des englischen Originals weiterleiten.

  5.  Einige in diesem Dokument verwendete Begriffe

  In diesem Text werden sehr oft die Begriffe Klient und Server
  verwendet.  Das sind normalerweise recht genau definierte Begriffe,
  die aber in diesem Text sehr viel allgemeiner benutzt werden.  Sie
  sollen im Folgenden bedeuten:

     Klient
        Derjenige Rechner oder das Programm, das eine Aktion oder
        Verbindung initiiert, um einen Service in Anspruch zu nehmen
        oder Daten zu empfangen.

     Server
        Derjenige Rechner oder das Programm, welches die eingehenden
        Verbindungen von verschiedenen Rechnern im Netzwerk
        entgegennimmt und die verlangten Services oder Daten zur
        Verfgung stellt.
  Diese Definitionen sind zwar auch nicht sehr genau, aber immerhin
  erlauben sie eine eindeutige Unterscheidung der beiden Enden eines
  Peer-to-Peer-Systems wie zum Beispiel SLIP oder PPP, bei denen es in
  Wirklichkeit so etwas wie Klient und Server nicht gibt.

  Weiter Begriffe, die auftauchen werden, sind:

     IP-Adresse
        Dies ist eine Nummer, die einen TCP/IP Rechner in einem Netzwerk
        eindeutig identifiziert.  Diese Adresse ist 4 Bytes lang und
        wird normalerweise in einer punktierten Dezimalschreibweise
        genannt, bei der der Wert eines jeden Bytes, getrennt durch
        Dezimalpunkte `.', angegeben wird.

     Hardware-Adresse
        Dies ist eine Nummer, die den jeweiligen Rechner in einem
        Netzwerk auf dem untersten Zugriffs-Niveau eindeutig
        identifiziert.  Beispiele hierfr sind die Ethernet-Adresse oder
        die AX.25-Adresse.

     Datagramm
        Ein Datagramm ist ein einzelnes Datenpaket, bestehend aus den
        eigentlichen Daten sowie einem Header, der die Adresse enthlt.
        Sie sind die Basiseinheiten der Verbindungen ber ein IP-
        Netzwerk.  Manchmal wird ein Datagramm auch als Paket
        bezeichnet.

     MTU
        Die maximale bertragungseinheit (Maximum Transmission Unit) ist
        ein Parameter der festlegt, wie gro ein Datagramm maximal sein
        darf, das ber eine IP-Schnittstelle weitergegeben werden kann,
        ohne da es in kleinere Pakete zerlegt werden mu.  Die MTU
        sollte grer sein als das grte Datagramm, welches man
        unfragmentiert senden mchte.  Dies verhindert eine solche
        Fragmentierung allerdings nur lokal, da ein anderer Rechner in
        der bertragungskette eine kleinere MTU haben kann, soda das
        Paket dann dort aufgespalten wird.  Typische Werte fr die MTU
        sind 1500 fr eine Ethernet-Schnittstelle oder 576 fr SLIP.

     MSS
        Die maximale Segmentgre (Maximum Segment Size) ist die grte
        Datenmenge, die auf einmal bertragen werden kann.  Um lokale
        Fragmentierung zu vermeiden sollte MSS die Differenz aus MTU und
        IP-Header-Gre sein.

     Window
        Das Window (Fenster) ist die grte Datenmenge, die ein
        Empfnger zum jeweiligen Zeitpunkt entgegennehmen kann.

     Route
        Die Route ist der Weg, den die Datagramme auf ihrem Weg zur
        Empfangsstation nehmen.

     ARP
        Dies ist ein Akronym fr das Address Resolution Protokoll
        welches festlegt, wie ein Netzwerkrechner eine IP-Adresse in
        eine Hardware-Adresse bersetzt.
  6.  Von NET-3 untersttzte Funktionalitt

  Der NET Code ist eine vollstndige, Kernel-basierte Implementation von
  TCP/IP fr Linux.

  6.1.  Generelle Untersttzung

     Ethernet-Karten
        Die meisten gngigen Ethernet-Karten werden untersttzt,
        inklusive einiger tragbarer, Pocket-Adapter und PCI-Karten.

     SLIP (Serial Line IP) und PPP (Point to Point Protocol)
        zur Realisierung eines TCP/IP-Netzes ber serielle Verbindungen
        wie Modems oder lokale Kabelverbindungen.

     Van Jacobsen Header Komprimierung
        packt und komprimiert die TCP/IP Header Blcke, um die
        Leistungsfhigkeit von SLIP/PPP zu erhhen.

     PLIP (Parallel Line IP)
        zur Verbindung zweier Rechner ber den parallelen Druckerport.

     EQL Load Balancing
        Erlaubt es, zwei oder mehr Verbindungen simultan zwischen zwei
        Maschinen aufzubauen und so den Datendurchsatz effektiv zu
        vervielfachen.  Dies wird nur von neueren Kernel-Versionen
        untersttzt.

     NFS (Networked File System)
        erlaubt das mounten von Partitionen entfernter Rechner ber eine
        Netzwerkverbindung.

     IPX (Novell)
        erlaubt es, IPX Anwendungen zu schreiben und Linux als Router in
        einem IPX-Netzwerk zu betreiben.

     NIS (Sun's Network Information System)
        eine Implementation des NIS ist auch fr Linux verfgbar.

     ARCNet
        neuere Kernels untersttzen auch ARCNet.  Es ist zwar langsamer
        als Ethernet, dafr ist die Hardware (Karten) billiger.

     IBM's Token Ring
        ein experimenteller Token-Ring-Treiber ist Bestandteil der
        aktuellen Kernels, damit kann ein Linux-Rechner in einem
        entsprechenden lokalen Netzwerk (LAN) betrieben werden.

     AppleTalk
        (oder heit es EtherTalk?) Egal, ich glaube es ermglicht es,
        Dateien und Drucker gemeinsam mit einem Macintosh zu verwenden.
        Nhere Hinweise gibt es weiter unten im Abschnitt
        `Experimentelle und in der Entwicklung befindliche Module'.

     WaveLan drahtloses Netzwerk
        die `WaveLan wireless Lan Card' wird von den aktuellen
        Kernelversionen untersttzt.  Sie erlaubt es, einen Linux-
        Rechner mobil und in einiger Entfernung zum Netzwerk zu
        betreiben.

     ISDN
        es gibt experimentelle Untersttzung fr einige ISDN-Karten.
        Nhere Hinweise gibt es weiter unten im Abschnitt
        `Experimentelle und in der Entwicklung befindliche Module'.

     ATM
        eine Gruppe von Programmierern arbeitet an der Untersttzung von
        ATM.

     IP Firewall
        hilft, den Linux-Rechner fr ein Netzwerk als sicheren Gateway
        nach auen zu konfigurieren.

     IP Accounting
        erlaubt die genaue Aufschlsselung, wer welche Netzwerk-Dienste
        in Anspruch nimmt.

     IP Tunneling
        interessant um mit IP zu experimentieren.

  Gegenwrtig wird vom NET-3-Code nicht untersttzt:

     SPX/NCP (Novell Netware)
        wrde es Linux erlauben, Novell Netzwerk Dateisysteme als Server
        oder Klient zu benutzen und auf Druckern im Novell Netz zu
        drucken.  An diesem Projekt wird zwar gearbeitet, aber durch den
        propietren Charakter des Novell Netzwerkes kann das noch einige
        Zeit brauchen.

     FDDI
        FDDI-Karten werden meines Wissens von Linux derzeit nicht
        untersttzt.

     System V Streams
        einige Leute arbeiten an Sys-V Streams fr Linux, Details wurden
        aber bislang noch nicht publik gemacht.

  6.2.  Untersttzte Ethernet-Karten

  Der 1.2.0 Kernel Release untersttzt die folgenden Karten:

    WD80*3 und dazu Kompatible.

    SMC Ultra.

    AMD LANCE und PCnet (AT1500 and NE2100) und dazu Kompatible.

    3Com 3c501 (veraltet und sehr langsam).

    3Com 3c503.

    3Com 3c505.

    3Com 3c507.

    3Com 3c509/3c579.

    Cabletron E21xx.

    DEPCA und dazu Kompatible.

    EtherWorks 3.

    ARCNet.

    AT1700 (keine Nachbauten).

    EtherExpress.

    NI5210 und dazu Kompatible.

    NI6510.

    WaveLAN.

    HP PCLAN+ (27247B and 27252A).

    HP PCLAN (27245 und weitere Modelle der 27xxx Serien).

    NE2000/NE1000 und dazu Kompatible

    SK_G16.

    Ansel Communications EISA 3200.

    Apricot Xen-II on board ethernet.

    DE425, DE434, DE435.

    Zenith Z-Note.

    AT-LAN-TEC/RealTek Pocket-Adapter.

    D-Link DE600 Pocket-Adapter und dazu kompatible.

    D-Link DE620 Pocket-Adapter und dazu kompatible.

  Sptere Kernelversionen untersttzen vermutlich eine noch grere
  Menge an Karten.

  Wer beabsichtigt, unter Linux eine Ethernet-Karte zu betreiben, sollte
  auch das Ethernet-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Ethernet-
  HOWTO.html) lesen, da es viele ntzliche Informationen ber
  untersttzte Karten enthlt, vor allem auch fr diejenigen, die eine
  Ethernet-Karte speziell fr Linux kaufen wollen.

  Wie bereits erwhnt untersttzt Linux auch einige andere Netzwerk-
  Protokolle, falls kein Zugang zu einem Ethernet oder einer
  entsprechenden Netzwerkkarte besteht.  Viele Universitten und Firmen
  bieten weltweit die eine oder andere Mglichkeit zu einem Dial-Up-
  Zugang zum Internet an.  Normalerweise wird dabei ein Zugang entweder
  via SLIP oder PPP zur Verfgung gestellt, soda man kaum eine andere
  Wahl als diese Protokolle besitzt.  Alles was man dazu bentigt ist
  ein Telefonanschlu, ein Modem (ein bereits vorhandenes mag fr den
  Anfang sicherlich gut genug sein) und ein entsprechend konfiguriertes
  Linux-System.  Im weiteren Verlauf dieses Textes beschftigen sich
  einige Abschnitte damit und zeigen genau auf, was man dazu braucht.

  6.3.  Untersttzung fr Amateur Radio

  Inzwischen untersttzt Linux einige Dinge die speziell fr Amateur
  Radio gedacht sind.  Die neuesten Kernels schlieen Standardmig ein:

     AX.25
        Alan Cox und Jonathan Naylor haben funktionierende AX.25-Sockets
        im Kernel implementiert.

     NetRom
        Jonathan Naylor hat eine kernelbasierte NetRom-Untersttzung
        implementiert.  Sie ist noch im Versuchsstadium, macht aber gute
        Fortschritte.

     Ottawa PI Karte
        Dave Perry von der Ottawa Packet Radio Group hat einen
        funktionierenden Treiber fr diese Karte geschrieben.

     SCC Karten
        ein generischer Treiber fr SCC-Karten ist Bestandteil der
        neuesten Kernels.  Er wird von Jrg Reuter entwickelt.

     Ein Kernel-Nutzer-Verbindungs Treiber
        er erlaubt die Kommunikation von Nutzerprogrammen mit dem Kernel
        ohne strende pty's.

  Weitere Details zur Amateur Radio Untersttzung finden sich im HAM-
  HOWTO (http://sunsite.unc.edu/mdw/HOWTO/HAM-HOWTO.html).

  7.  Woher bekomme ich die NET-2/NET-3 Software ?

  Bevor mit der eigentlichen Konfigurationsarbeit begonnen werden kann
  mu sichergestellt werden, da das komplette Netzwerk-Paket vorhanden
  ist.  Das umfat eine aktuelle Kernelversion (1.0 oder neuer), die
  richtigen Libraries, die TCP/IP Konfigurationsprogramme und -Dateien
  wie z.B. /sbin/ifconfig und /etc/hosts, und schlielich auch eine
  Reihe von Anwendungsprogrammen wie telnet, ftp, rlogin usw.

  Wer ein komplettes Linux-System ber einen Distributor bezogen hat,
  besitzt hchstwahrscheinlich schon alles, was er bentigt.  Viele
  Linux-Distributionen sind von vorneherein mit den notwendigen
  Konfigurationsdateien, ausfhrbaren Programmen, Bibliotheken und
  Kernelversionen ausgestattet.  Dann erbrigt es sich, sich die
  folgenden Dateien zu besorgen.

  ACHTUNG: Es kann durchaus sein, da sich manche Dateien an einer
  anderen als der in diesem HOWTO angegebenen Stelle im Verzeichnisbaum
  befinden.

  Wer bereits die vollstndige Netzwerk-Software besitzt, kann jetzt
  direkt zum Abschnitt Kernelkonfiguration weitergehen.  Alle anderen
  sollten die folgenden Anweisungen befolgen.

  7.1.  Der Kernel Quellcode

  Die Versionen 1.2.x des Linux-Kernels sind die stabilen Versionen, sie
  werden auch gerne als `Production Release' bezeichnet.  Die Kernels
  1.3.*, und allgemein alle Kernels mit ungerader zweiter Ziffer,  sind
  Entwicklerversionen.  Wer keine Lust hat, sich mit dem Einspielen von
  Patches und Neukompilieren von Kernels zu befassen, sollte bei den
  stabilen Versionen bleiben.  Dennoch, gerade im Falle des Netzwerk-
  Codes kann ich nur jedem empfehlen, trotzdem den geringen Aufwand in
  Kauf zu nehmen und einen der aktuellen Releases zu verwenden, da
  gerade hier viele Vernderungen und vor allem Verbesserungen am
  Netzwerk-Code vorgenommen wurden.  Es wird zwar immer und berall
  erwhnt, trotzdem:  Wer einen neuen Kernel ausprobieren will, sollte
  eine aktuelle Sicherungskopie seines Systems besitzen, nur fr den
  Fall das dabei etwas Schwerwiegendes daneben geht.

  Die aktuelle Kernelversion kann gefunden werden auf

       ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/v1.2/linux-1.2.13.tar.gz

  Es handelt sich um ein gezipptes TAR-Archiv, man bentigt deshalb das
  Programm gzip zum Wiederauspacken.

  Zum Auspacken der Kernel-Quellcodes sollte man so vorgehen:

       % cd /usr/src
       % mv linux linux.old
       % gzip -dc linux-1.2.13.tar.gz | tar xvf -

  Im selben Verzeichnis befinden sich auch  einige Dateien
  patch-1.2.1.gz ....  Es handelt sich dabei um Patch-Dateien.  Eine
  Kernelversion 1.2.1 besagt z.B. da es sich um die Version 1.2.0 mit
  dem eingespielten Patch 1.2.1 handelt.  Wenn sich also im Verzeichnis
  Patch-Dateien befinden, deren Versionsnummer grer ist als die des
  gegenwrtig installierten Kernels, so mssen alle diese Patch-Dateien
  heruntergeladen und hintereinander eingespielt werden.  Dies geschieht
  jeweils mit dem Befehl

       % cd /usr/src
       % for patchfile in .../patch*
       > do
       > gzip -dc $patchfile | patch -p0 2>>patch.errs
       > done

        ...

  Die dabei erzeugte Datei patch.errs mu dann nach dem Wort fail
  durchsucht werden.  Taucht es nicht in dieser Datei auf, ist der Patch
  einwandfrei abgelaufen.  Andernfalls sollte man sich eine Originale
  Kernelversion besorgen und die Patches einen nach dem anderen
  einspielen, bis derjenige Patch gefunden ist, der den Fehler
  verursacht hat.  Erst wenn man nicht herausfinden kann, was schief
  gegangen ist, kann man einen Fehlerbericht schreiben.

  7.2.  Die Bibliotheken (libraries)

  Es empfiehlt sich, mindestens die Version 4.4.2 der libc zu verwenden,
  da frhere Versionen einige Probleme mit Subnet-Masken hatten.

  Die aktuelle a.out-Version (libc-4.6.27) befindet sich auf:

       sunsite.unc.edu:/pub/Linux/GCC/

  Auerdem bentigt man mindestens folgende Dateien:

    image-4.6.27.tar.gz

    inc-4.6.27.tar.gz

    extra-4.6.27.tar.gz

    release.libc-4.6.27

  Vor der Installation der neuen libc-Version mu man unbedingt die
  Release-Notes release.libc-4.6.27 lesen.  Auerdem sollten fr libc-
  Versionen ab 4.6.26 mindestens GCC Version 2.6.2 und Kernelversionen
  ab 1.1.52 verwendet werden.

  7.3.  Das Programmpaket zur Netzwerk-Konfiguration

  Auf jeden Fall wird das Paket der Hilfsprogramme zur Netzwerk-
  Konfigurierung bentigt.  Die aktuelle Version bekommt man hier:

       ftp.linux.org.uk:/pub/linux/Networking/PROGRAMS/NetTools/net-
       tools-1.2.0.tar.gz

  Da sich der Netzwerk-Code im Kernel immer noch recht hufig ndert
  sind auch fr diese Hilfsprogramme Anpassungen notwendig.  Man mu
  sich deshalb die fr den benutzten Kernel ausgewiesenen Pakete
  besorgen.

  Die Dateinamen geben dabei die erste Versionsnummer des Kernels an, ab
  der die Programme funktionieren.  Die richtige Datei ist also
  diejenige mit derselben oder der nchstkleineren Versionsnummer wie
  der benutzte Kernel.

  Um die Hilfsprogramme zu kompilieren und installieren sollte man
  folgendes machen:

       % cd /usr/src
       % mkdir net-tools
       % cd net-tools
       % gzip -dc net-tools-1.2.0.tar.gz | tar xvf -
       % make

  Dadurch wird automatisch das Shell-Script Configure.sh aufgerufen.
  Wenn der make-Proze erfolgreich beendet wird, beendet

       % make install

  die Installation.

  Wer eine Kernel-Version vor 1.1.26 benutzt, sollte sich auch folgendes
  ansehen:

       ftp.linux.org.uk:/pub/linux/Networking/PROGRAMS/Other/net032

  In diesem Verzeichnis befinden sich drei Versionen der Netzwerk-
  Programme.  Die folgende Tabelle zeigt, fr welche Kernel-Versionen
  die jeweiligen Pakete gedacht sind:

       net-0.32d-net3.tar.gz     1.1.12+
       net-0.32b.tar.gz          1.1.4+
       net-0.32.old.tar.gz       vor 1.1.4

  Die Pakete enthalten die wichtigsten Konfigurationsprogramme wie
  ifconfig, route, netstat usw.  Deren Benutzung wird spter erlutert.

  7.4.  Anwendungsprogramme

  Selbstverstndlich bentigt man auch eine Reihe von Applikationen, die
  die Netzwerkfhigkeiten auch ausnutzen, wie z.B. telnet, ftp oder
  finger und ihre entsprechenden Dmonen.  Florian La Roche,
  (flla@stud.uni-sb.de) hat eine sehr umfassende Distribution dieser
  Programme zusammengestellt, die sowohl in Binrform wie auch als
  Quellcode erhltlich ist. Die kompilierten TCP/IP-Applikationen und
  einige beispielhafte Konfigurationsdateien befinden sich in:

  ftp.funet.fi

       /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

  Es sollten jeweils die neuesten Versionen verwendet werden.  Aber
  unbedingt zunchst die Datei README lesen um sicherzustellen, da das
  eigene System auch die notwendigen Voraussetzungen fr die neue
  Version erfllt.

  Die von Florian zusammengestellte Binr-Distribution (B-Datei) gibt es
  derzeit nicht mehr, deshalb mssen die Quellen selber kompiliert
  werden. Dies geschieht so:

       % cd /usr/src
       % gzip -dc NetKit-B-0.06.tar.gz | tar xpvlf -
       % cd NetKit-B-0.06

  Dann mu das Makefile editiert und angepat werden.  Die Datei README
  gibt hierzu Hinweise.  Wichtig ist, da die Variable
  HAVE_SHADOW_PASSWORDS richtig definiert wird.  Wer keine benutzt,
  sollte den entsprechenden Eintrag im Makefile durch ein  # am
  Zeilenanfang auskommentieren.  Der Rest sollte nicht verndert werden
  mssen, deshalb gengt nun ein

       % make
       % make install

  um die Installation abzuschlieen.

  Wichtiger Hinweis: Florian hat diese TAR-Archive zusammengestellt und
  zur leichteren Installation mit den net-tools-n.n.nn auch ein
  vorkompiliertes Paket erstellt.  Leider hat er aber hierfr eine
  andere Verzeichnis-Struktur zugrundegelegt als dies Alan bei der
  Zusammenstellung der Installations-Scripte der net-tools tat.  Dies
  bedeutet, da man bei der Installation besondere Vorsicht walten
  lassen sollte.  Dies wird von Florian demnchst angepat, so da es
  auf Dauer kein Problem sein wird.  Aber bis dahin empfehle ich statt
  der oben angegebenen Prozedur die folgende:

       -  Auspacken der Programme an einem sicheren Ort
       % 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 -

       -  Loeschen von Florians Versionen der erwaehnten 
          Konfigurationsprogramme
       % rm ./bin/hostname ./sbin/route ./sbin/ifconfig ./sbin/netstat
       % rm ./usr/sbin/arp ./usr/sbin/rarp ./usr/sbin/slattach

       -  Kopieren der Programme in ihre endgueltigen Verzeichnisse
       % cp -vrpd . /

  7.5.  Zustzliche Treiber oder Pakete

  Wer zustzliche, im Alpha oder Beta Stadium befindlichen Code oder
  Treiber verwenden will oder mu, der noch nicht in der Standard-
  Distribution des Kernels mitaufgenommen wurde, mu die entsprechende
  Software separat besorgen und installieren.  In den entsprechenden
  Abschnitten dieses HOWTO sind dazu genauere Angaben gemacht.

  8.  Konfiguration des Kernels

  Bevor mit der Arbeit der Konfiguration des Netzwerkes begonnen werden
  kann mu sichergestellt sein, da der verwendete Kernel die
  gewnschten Netzwerkprotokolle und Hardware untersttzt.  Der
  sicherste Weg hierfr besteht darin, sich seinen Kernel selber zu
  kompilieren.  Dies ist generell anzuraten, da auf diese Weise nicht
  bentigte Treiber weggelassen werden knnen und der resultierende
  Kernel weniger Speicher belegt.

  Vorausgesetzt, die Kernel-Quellen sind bereits an der richtigen Stelle
  entpackt und die bentigten Patches eingespielt worden, sollte
  zunchst ein Blick in die Datei /usr/src/linux/drivers/net/CONFIG
  geworfen werden.  Sie enthlt viele Kommentare, die bei der Auswahl
  der Optionen helfen, aber normalerweise sind keine Vernderungen
  notwendig.  Wirklich notwendig sind nderungen nur bei exotischen
  Ethernet-Karten oder bei solchen, die von den Treibern nicht
  automatisch erkannt werden.  In diesem Fall knnen einige
  Einstellungen der Karte direkt im Code festgelegt werden.  Ein
  Beispiel sind die (Fast-)nachbauten der WD-8013, hier mu die Adresse
  des Shared-Memory-Bereiches eingestellt werden, damit auch diese
  Karten korrekt erkannt und betrieben werden knnen.  Ebenfalls in
  dieser Datei knnen einige Parameter fr den PLIP-Treiber eingestellt
  werden, jedoch sind die Standard-Einstellungen auer fr extrem
  langsame Rechner ausreichend.

  Das Ethernet-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/Ethernet-HOWTO)
  gibt genauere Informationen ber diese Datei und darber, wie sie das
  Verhalten der Treiber beeinflut.

  Ist die Konfigurationsdatei zufriedenstellend zusammengestellt, kann
  mit der eigentlichen Kernel-Kompilation begonnen werden.  Der erste
  Schritt besteht darin, das Makefile im obersten Verzeichnis zu
  editieren um Sicherzustellen, da die korrekten VAG-Einstellungen
  verwendet werden.  Danach mu man das Kernel-Konfigurationsprogramm
  starten:

       % cd /usr/src/linux
       % make config

  Nun werden eine ganze Reihe an Fragen gestellt.  Sie gliedern sich in
  vier Hauptgruppen: Generelle Einstellungen, Netzwerk-Einstellungen,
  Netzwerk-Hardware-Untersttzung und Dateisysteme.  Der komplexeste ist
  der Abschnitt ist die Hardware-Untersttzung fr das Netzwerk, da hier
  die richtigen Gerte ausgewhlt werden mssen, die hinterher
  untersttzt werden.  Fr die meisten anderen Einstellungen knnen die
  vorgegebenen Werte ohne groe Bedenken verwendet werden.  Der Ablauf
  wird in etwa so aussehen:

       *
       * General setup
       *
        ...
        ...
       Networking support (CONFIG_NET) [y] y
        ...
        ...

  Im allgemeinen Abschnitt wird zunchst nur festgelegt, ob berhaupt
  Netzwerk-Untersttzung gewnscht ist.  Selbstverstndlich mu man
  darauf mit Ja antworten ;-)

       *
       * 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]
       *

  Die zweite Hlfte des Abschnittes Netzwerk-Optionen erlaubt es, einige
  seltsame Dinge an- oder abzuschalten.  Die Standardeinstellungen sind
  hier immer die sichere Wahl.  Was sie im einzelnen bedeuten, wird
  spter noch erklrt.  Doch wer andere als die Standard-Einstellung
  verwenden will sollte schon genau wissen, was er vorhat.

       *
       *
       * 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]
       *

  Dieser Abschnitt ist der wichtigste.  Hier wird eingestellt, welche
  Hardware-Untersttzung eingebunden werden soll.  Im obenstehenden
  Beispiel sind Untersttzung fr SLIP mit komprimierten Heraderdateien,
  fr PPP und der WD80*3-Treiber ausgewhlt, und sonst alles andere
  abgeschaltet.  Weitere Optionen knnen auftauchen, je nachdem, welche
  Antworten man gibt.  So taucht z.B. die Frage nach dem komprimierten
  SLIP und den 16 Kanlen nicht auf, wenn man bei der Frage fr SLIP...
  mit n antwortet.  Generell sollte man bei all den Dingen, mit denen
  man herumspielen will, mit y antworten und alle anderen mit n
  abschalten.

       *
       * Filesystems
       *
        ...
        ...
       /proc filesystem support (CONFIG_PROC_FS) [y]
       NFS filesystem support (CONFIG_NFS_FS) [y]
        ...
        ...

  Wer einen NFS-Klienten aufbauen will, um Dateisysteme von anderen
  Rechnern zu importieren, der mu auf die Frage nach Untersttzung fr
  NFS mit y antworten.  Meist ist es auch notwendig, das /proc-
  Filesystem einzubinden, da es von einigen Netzwerkprogrammen benutzt
  wird.

  Nach vollendeter Konfiguration verbleibt es nur noch, den Kernel auch
  wirklich zu kompilieren:

       % make dep
       % make

  Geht alles glatt, darf man ein abschlieendes make zlilo nicht
  vergessen, damit der neue Kernel auch installiert wird.

  8.1.  Was bedeuten denn alle diese Netzwerk-Optionen ?

  Die neueren Kernels haben eine Vielzahl an Konfigurations-Optionen,
  die bei einem make config abgefragt werden.  Normalerweise mssen sie
  Standard-Einstellungen nicht verndert werden, doch einige Optionen
  knnen unter Umstnden hilfreich sein.

     TCP/IP Netzwerk
        Dies ist offensichtlich: Damit wird eingestellt, ob der Kernel
        das TCP/IP-Protokoll untersttzt.  Wer dieses HOWTO liest, wird
        mit ziemlicher Sicherheit mit y darauf antworten.

     Dummy Networking Device
        Dies ist ein Pseudo-Gert.  Es wurde eingefhrt, damit SLIP und
        PPP-Nutzer ihren Rechner auch dann auf eine Netzwerkadresse
        konfigurieren knnen, wenn gerade keine serielle Verbindung zum
        Provider besteht.  Es stellt weiterhin eine sehr einfache
        Mglichkeit dar, einen Linux-Rechner mit zwei verschiedenen
        Adressen zu versehen.

     IP forwarding/gatewaying
        Diese Einstellung legt fest, was der Linux-Kernel mit einem
        Datagramm macht, das an keines der konfigurierten Gerte
        adressiert ist.  Ist sie abgeschaltet, so ignoriert der Kernel
        solche Pakete.  Wer seinen Rechner als Router verwenden will,
        mu diese Option aktivieren.  Dies gilt z.B. auch fr SLIP und
        PPP Server.

     IP multicasting
        Dabei handelt es sich um eine experimentelle Untersttzung von
        Anwendungen wie `Internet Talk Radio' oder `Live Video'.  Es ist
        jedoch eine reine Kernel-Untersttzung fr die bentigten
        Protokolle, um sie zu benutzen sind spezielle
        Anwendungsprogramme ntig.

     IP Firewalling
        Diese Einstellung ermglicht es, sehr flexible
        Sicherheitsschranken fr das Linux-Netzwerk zu konfigurieren.
        So knnen z.B. TCP/IP-Verbindungen auf der Basis der
        Netzwerkadressen erlaubt und abgeschaltet werden.  Es sind aber
        auch zustzliche Programme ntig, um diese Mglichkeiten zu
        nutzen.

     IP Accounting
        Diese Option kann von Leuten benutzt werden, die mit ihrem
        Linux-Rechner Internet-Verbindungen auf kommerzieller Basis
        anbieten wollen, z.B. ber einen SLIP-Server.  Sie erlaubt es,
        ein- und ausgehende Datagramme nach Adresse oder serieller
        Verbindung zu zhlen.  Mit der geeigneten Software knnen so
        detaillierte Rechnungen fr jeden Nutzer des Netzwerkes
        aufgestellt werden.

     PC/TCP Compatibility Mode
        Dieser Modus bietet eine Umgehung von Problemen, die auftauchen,
        wenn PC/TCP-Netzwerk-Programme mit dem Linux-Rechner
        kommunizieren wollen: Es gibt einen Fehler im PC/TCP-Protokoll,
        der wiederum einen schwer zu beseitigenden Fehler auf der Linux-
        Seite hervorruft.  Diese Option verhindert, da solche Probleme
        auftreten.  Normalerweise wird sie nicht bentigt und bleibt
        ausgeschaltet.  Wer jedoch in seinem Netz Benutzer hat, die
        PC/TCP verwenden, sollte diesen Modus aktivieren, um Problemen
        vorzubeugen.

     Reverse ARP
        Damit kann das Protokoll zur umgekehrten Adress-Auflsung (RARP)
        in den Kernel aufgenommen werden.  Es wurde eingefhrt, damit
        Sun-3 Systeme booten knnen.  Fr andere Rechner ist es
        normalerweise nicht sinnvoll.

     Assume subnets are local
        Hiermit wird eingestellt, ob das gesamte Unter-Netzwerk direkt
        an den Linux-Rechner angeschlossen ist, oder ob es noch weiter
        unterteilt und z.B. durch Bridges (Brcken) verbunden ist.  Es
        macht fr gewhnlich keinen Unterschied, ob man die Standard-
        Einstellung verwendet oder nicht.

     Disable NAGLE algorithm
        Der NAGLE-Algorithmus legt fest, wann ein Datagramm losgeschickt
        werden kann.  Die Standard-Einstellung ist auf optimalen
        Datendurchsatz fr die meisten Situationen eingestellt und
        sollte so belassen werden, da andernfalls die Leistungsfhigkeit
        der Netzverbindung abnimmt.  Da die Verwendung des NAGLE-
        Algorithmus auch von einem Programm aus ber eine Socket-Option
        verndert werden kann fhrt man normalerweise besser, sie
        standardmig zu aktivieren und ihn fr Flle, in denen
        Programme eine besonders schnelle Reaktionszeit ber das Netz
        bentigen, aus diesem Programm heraus temporr zu deaktivieren.

     The IPX protocol
        Legt fest, ob das IPX-Protokoll vom Kernel untersttzt werden
        soll.  Es handelt sich dabei um Inter-Netzwerk-Protokoll hnlich
        wie IP und ist eines der von Novell verwendeten Protokolle.

     Amateur Radio AX.25 Level2
        Damit aktiviert man die Untersttzung fr das AX.25-Protokoll
        von Amateur Radio.  Dadurch werden eine Reihe zustzlicher
        Sockets zur Programmierung freigegeben.  Das AX.25-Protokoll
        wird vorrangig fr Packet Radio verwendet.

  9.  Konfiguration der Netzwerk-Schnittstelle

  Ist bis hierher alles glatt gelaufen, besitzt man einen Kernel, der
  alle Gerte, die man benutzen mchte, untersttzt, auerdem sollten
  auch alle bentigten Hilfsprogramme vorhanden sein.  Der Spa kann
  also beginnen.  Jedes der gewnschten Gerte mu nun konfiguriert
  werden.  Das bedeutet normalerweise, da jeder Gerteschnittstelle
  eine IP-Adresse zugeteilt und das Netzwerk, an das sie angeschlossen
  ist, mitgeteilt wird.

  In den frheren Versionen dieses Textes wurden praktisch smtliche
  relevanten Konfigurationsdateien zusammen mit Kommentaren, welche
  Vernderungen mglich und ntig sind, in vollem Umfang zitiert.  Der
  vorliegende Text geht in dieser Beziehung etwas unterschiedlich vor.
  Smtliche Konfigurationsdateien werden von Grund auf neu
  zusammengestellt, so da man hinterher genau wei, was drinnen steht,
  und vor allem warum.  Dies geschieht an den jeweiligen Stellen, an
  denen diese Dateien bentigt werden.

  9.1.  Die Device-Eintrge in /dev

  Die Netzwerk-Implementation unter Linux verwende keinerlei Device-
  Eintrge im Verzeichnis /dev.  Darin unterscheidet es sich von den
  Versionen anderer Betriebssysteme.  Die bentigten Eintrge werden
  dynamisch im Speicherbereich des Kernels angelegt, und da es sich
  sowieso nur um Namen handelt gibt es auch keinen Grund, warum sie nach
  auen hin sichtbar sein sollten.  Der Kernel selber bietet alle
  notwendigen Schnittstellen Kommunikationskanle, um die Fhigkeiten
  des Netzwerks effizient zu nutzen.

  9.2.  Welche Informationen mssen bereitstehen ?

  Bevor mit der Konfiguration begonnen werden kann sollte sichergestellt
  sein, da einige relevante Daten ber die Netzwerk-Verbindung zur
  Verfgung stehen.  Die meisten davon erfhrt man vom
  Netzwerkadministrator oder Internet-Provider.

  9.2.1.  Die IP Adresse

  Dies ist die eindeutige Identifizierungsadresse des Rechners, in der
  blichen punktierten Dezimalschreibweise, z.B. 128.253.153.54.  Diese
  mu man beim Netzwerk-Administrator erfragen.

  Wer eine Verbindung ber SLIP oder PLIP anstrebt, braucht diese Nummer
  eventuell nicht.  Genaueres steht dann im Abschnitt ber SLIP.
  Wer nicht plant, eine externe Netzverbindung ber SLIP, PPP oder
  Ethernet aufzubauen und nur das loopback-device verwendet, braucht
  ebenfalls keine IP-Adresse, da loopback immer die Adresse 127.0.0.1
  verwendet.

  9.2.2.  Die Netz-Maske

  Aus Grnden der Leistungsfhigkeit ist es fr jedes Netzwerk
  wnschenswert, die Anzahl der angeschlossenen Rechner mglichst gering
  zu halten.  Deshalb werden groe Netzwerke von deren Administratoren
  oft in kleinere Unterstrukturen aufgeteilt, die man als subnet
  bezeichnet.  Die Network Mask ist eine Bytemaske, die, wenn man sie
  mit der IP-Adresse berlagert, die Zugehrigkeit zu einem solchen
  subnet angibt.  Sie ist von essentieller Bedeutung fr das Routing in
  einem Netzwerk, und wer feststellt, da er zwar problemlos mit
  Rechnern auerhalb des lokalen Netzwerkes kommunizieren kann, nicht
  aber mit den lokalen Computern, der hat mit Sicherheit eine falsche
  Network Mask eingestellt.

  Diese Maske wurde normalerweise vom Netzwerk-Administrator bereits bei
  der Erstellung des Netzwerkes gewhlt, er kann deshalb auch diese
  Information liefern.  Die meisten Netzwerke sind Klasse-C Unternetze,
  die als Netzwerk-Maske den Wert 255.255.255.0 verwenden.  Andere,
  grere Netzwerke (Klasse B) benutzen 255.255.0.0.  Die
  NET-2/NET-3-Software whlt automatisch eine Standard-Maske aus, wenn
  einer Schnittstelle eine Adresse zugeordnet wird.  Diese
  Standardeinstellung geht davon aus, da das Netzwerk nicht weiter
  unterteilt ist.  Welche Netz-Maske verwendet wird, hngt von der
  verwendeten Adresse ab.  Im einzelnen gilt folgende Zuordnung:

       Adressen mit dem ersten Byte:
       1-127         255.0.0.0         (Class A)
       128-191       255.255.0.0       (Class B)
       192+          255.255.255.0     (Class C)

  Wenn die Standardeinstellung nicht funktioniert, kann man zunchst
  einfach die anderen Mglichkeiten durchprobieren.  Einfacher ist es
  natrlich, den Administrator oder sonst einen rtlichen Fachman zu
  fragen.

  Lediglich das Loopback-Device bentigt keine Netzwerk-Maske, dasselbe
  gilt auch fr Netzverbindungen via SLIP/PLIP.

  9.2.3.  Die Netzwerk-Adresse

  Die Netzwerkadresse (Network Address) ist die IP-Adresse, durch
  bitweises AND mit der Netmask verknpft. Ein Beispiel:

       Netzwerk-Maske:              255.255.255.0
       IP-Adresse:                  128.253.154.32   &&
                                   ----------------
       Netzwerk-Adresse:            128.253.154.0    =

  9.2.4.  Die Broadcast-Adresse

  Dies ist im Normalfall die Netzwerkadresse, logisch OR-verknpft mit
  der invertierten Netzwerk-Maske.  Man sieht am besten an einem
  Beispiel, wie das funktioniert:

       Netzwerk-Maske:              255.255.255.0    !
       invertierte Maske:             0.  0.  0.255  =
       Netzwerk-Adresse (s.o.):     128.253.154.0    ||
                                   -----------------
       Broadcast-Adresse:           128.253.154.255  =

  Aus historischen Grnden verwenden jedoch einige Netzwerke die
  Netzwerk-Adresse auch als Broadcast-Adresse.  Im Zweifelsfall sollte
  man sicherheitshalber beim Netzwerkadministrator nachfragen.

  Wer Zugriff auf einen sniffer oder eine hnliche Mglichkeit, den
  Datenverkehr auf dem Netzwerk zu berwachen, hat, kann die Broadcast-
  Adresse eventuell auch durch aufmerksames Verfolgen der Vorgnge auf
  dem Netz herausbekommen.  Hierbei mu man auf Ethernet-Pakete achten,
  die an die Ethernet-Broadcast-Adresse ff:ff:ff:ff:ff:ff adressiert
  sind.  Wenn der Absender eine IP-Adresse aus dem lokalen Netzwerk
  besitzt und die Protokoll-Identifikation nicht ARP ist, dann handelt
  es sich vermutlich um eine RIP Routing Anfrage des Routers, die
  Zieladresse ist dann die lokale Broadcast-Adresse.

  Wie gesagt, im Zweifelsfall immer den Netzwerk-Administrator fragen,
  denn der gibt meist viel lieber einige Ratschlge, als hinterher einen
  falsch konfigurierten Rechner in seinem Netz zu haben.

  9.2.5.  Router (`Gateway') Adresse

  In fast jedem lokalen Netzwerk gibt es einen Rechner, der dieses Netz
  mit dem Rest des Internet verbindet.  Diesen Rechner bezeichnet man
  als Gateway (Tor) oder Router (Wegbereiter).  Fr die Vergabe der IP-
  Adressen der Router gibt es zwei Konventionen: Entweder hat er die
  hchste Adresse im Netzwerk, oder die kleinste.  Da 0 und meist auch
  255 keine gltigen Adressen sind (Netzwerk-Adresse und Broadcast-
  Adresse) sind das 1 oder 254.  Neben dieser Konvention kann der Router
  aber jede beliebige IP-Adresse haben, ohne da die Funktionalitt des
  Netzwerkes beeintrchtigt wird, solange die angeschlossenen Rechner
  diese Adresse kennen.  Manche Netzwerke besitzen auch mehrere Router,
  um das Netz zu entlasten.  Deshalb sollte auch hier der Netzwerk-
  Administrator zu Rate gezogen werden.

  Wer das Netzwerk nur im loopback-Modus betreiben will braucht wiederum
  keine Router-Adresse.  Gleiches gilt auch fr PPP-Verbindungen, da das
  PPP-Protokoll diese Adresse automatisch ermittelt.  Fr SLIP-
  Verbindungen ist der Router der SLIP-Server und mu beim Provider
  erfragt werden.

  9.2.6.  Nameserver-Adressen

  Da die IP-Adressen fr Menschen eher schlecht zu behalten sind,
  erhalten Rechner und Netzwerke auch leichter merkbare Namen, z.B.
  sunsite.unc.edu.  Um zwischen diese Namen in gltige IP-Adressen zu
  bersetzen (und umgekehrt) gibt es spezielle Nameserver.  Die Adresse
  des nchsten Nameservers erfhrt man vom Netzwerk-Administrator.  Die
  andere Mglichkeit besteht darin, auf dem eigenen Rechner einen
  solchen Nameserver mittels named zu konfigurieren.  In diesem Fall
  wre die Nameserver-Adresse die Loopback-Adresse 127.0.0.1.  Nheres
  dazu steht im Abschnitt `named'.  Es knnen auch mehrere Nameserver-
  Adressen konfiguriert werden, falls einer nicht erreichbar ist.

  Fr Loopback bentigt man keinen Nameserver, da man sich sowieso nur
  mit dem eigenen Rechner unterhlt.

  9.2.7.  Hinweis fr SLIP/PLIP/PPP Nutzer

  Viele der obengenannten Informationen knnen fr SLIP/PPP/PLIP-
  Benutzer gar nicht notwendig sein.  Das hngt davon ab, wie die
  Netzwerk-Verbindung genau hergestellt wird, und ber welche
  Fhigkeiten der Rechner am anderen Ende der Verbindung besitzt.
  Darauf wird in den entsprechenden Abschnitten zur Konfiguration von
  SLIP/PPP und PPP eingegangen.

  9.3.  /etc/rc.d/rc.inet1,2

  Je nach Distribution knnen diese beiden Dateien auch in einer
  einzigen mit dem Namen /etc/rc.net oder /etc/init.d/network
  zusammengefat sein

  Prinzipiell knnten alle Kommandos zur Konfiguration des Netzwerkes
  auch von Hand in der Kommandozeile eingegeben werden, um das Netzwerk
  zu starten.  Gerade bei dauerhaften Verbindungen wie Ethernet ist es
  aber wnschenswert, da der Rechner automatisch beim Einschalten diese
  Konfiguration durchfhrt.

  Die rc-Dateien (kurz fr runtime command) sind genau fr solche Zwecke
  vorgesehen.  Fr diejenigen, die sich nicht so genau mit Unix
  auskennen: Bei diesen Dateien handelt es sich um Shell-Scripts, die
  beim Systemstart vom init-Programm ausgefhrt werden.  die rc-Dateien
  starten u.a. die grundlegenden Systemprogramme wie syslog, update oder
  cron.  Sie sind das Analogon zur Datei autoexec.bat bei MS-DOS.  Diese
  Dateien residieren unterhalb des /etc-Verzeichnisses.  Der Linux
  Filesystem Standard legt aber nicht exakt fest, wo diese Dateien
  stehen mssen.  Es knnen entweder die BSD-Konventionen (/etc/rc.*)
  oder die System-V-Konventionen (/etc/rc.d/rc.*) realisiert sein.  Da
  die System-V Version etwas bersichtlicher ist (alle Dateien stehen in
  einem Verzeichnis) und sie auerdem auch von den Entwicklern (Alan,
  Fred) verwendet wird, wird im folgenden diese Konvention verwendet.
  Das bedeutet, da die Netzwerk-Dateien sich in /etc/rc.d befinden und
  die Namen rc.inet1 und rc.inet2 besitzen.  Teilweise gibt es eine
  Datei /etc/rc, die dann die einzelnen Programme in /etc/rc.d startet,
  manchmal ist auch init bereits so kompiliert, da es selber in
  /etc/rc.d sucht.  Wo die Dateien stehen ist im Prinzip egal, solange
  init sie findet.

  System-V               Debian und andere
  ==================     =======================
  /etc/rc.d/rc.inet1     /etc/init.d/network

  /etc/rc.d/rc.inet2     /etc/init.d/netbase
                         /etc/init.d/netstd_init
                         /etc/init.d/netstd_nfs
                         /etc/init.d/netstd_misc

  Es ist nicht wichtig, wo genau die Konfigurationsbefehle fr die
  Schnittstellen auftauchen, solange dies geschieht, bevor Netzwerk-
  Dmonen oder -Anwendungen gestartet werden.

  Im weiteren werden die Netzwerk-Dateien als rc.inet1 und rc.inet2 im
  Verzeichnis /etc/rc.d referiert.  Wer also eine Distribution
  verwendet, die diese Daten an einer anderen Stelle verwaltet, der mu
  jeweils selbst nachschauen, wo die besprochenen Optionen eingestellt
  werden und sie dort entsprechend anpassen.

  9.3.1.  rc.inet1

  Die Datei rc.inet1 konfiguriert das TCP/IP-Basissystem.  Dazu werden
  die beiden Programme /sbin/ifconfig und /sbin/route benutzt .

     ifconfig
        /sbin/ifconfig konfiguriert die Schnittstelle mit allen ntigen
        Parametern, die zum Betrieb notwendig sind, also IP-Adresse,
        Netzwerk-Maske, Broadcast-Adresse usw.  Der Befehl ifconfig ohne
        weitere Parameter zeigt die Konfiguration aller existierenden
        Netzwerk-Devices an.  Die Online-Hilfe zu ifconfig (8) gibt
        weitere Informationen zur Benutzung.

     route
        Das Programm /sbin/route erzeugt und verwaltet eine Tabelle (die
        Routing-Table), in der eingetragen ist, welche IP-Adressen ber
        welche Schnittstellen erreicht werden knnen.  Der Netzwerk-Code
        im Kernel schaut fr jedes zu sendende Datagramm in dieser
        Tabelle nach, ber welchen Weg (Route) das Paket zugestellt
        werden soll.  Ohne Parameter gestartet, zeigt route den Inhalt
        der momentanen Routing-Table an.  Nheres steht in der Online-
        Hilfe.

  9.3.2.  rc.inet2

  In rc.inet2 werden alle bentigten Netzwerk-Dmonen gestartet, also
  Programme wie inetd oder portmapper.  Auf die Einzelheiten dieser
  Programme wird weiter unten genauer eingegangen, die Datei ist hier
  nur erwhnt, um die Aufgabentrennung zwischen rc.inet1 und rc.inet2
  darzulegen.  Die Trennung in zwei Dateien 1 und 2 zeigt auch
  deutlicher die Notwendigkeit, die Schnittstellen zu konfigurieren,
  bevor Netz-Dmonen oder -Anwendungen gestartet werden.  Dies ist
  besonders wichtig fr diejenigen, die nur eine einzige rc.net-Datei
  besitzen, um zu verstehen, was in der zweite Hlfte dieser Datei
  geschieht.

  9.4.  Die Konfiguration des Loopback-Device (immer)

  Das Loopback-Device ist keine wirkliche Hardware.  Es ist eine reine
  Software-Implementation, die sich aber wie eine physikalische
  Schnittstelle verhlt.  Sie ermglicht es dem Rechner, mit sich selbst
  zu kommunizieren und erlaubt es, Netzwerk-Programme zu testen, ohne
  wirklich an ein Netzwerk angeschlossen zu sein.  Die ist von groem
  Vorteil wenn man eine nicht dauerhafte SLIP-Verbindung hat oder selber
  Netzwerk-Software schreibt.

  Das Loopback-Device verwendet per Konvention immer die IP-Adresse
  127.0.0.1, obwohl beliebige Adressen eingestellt werden knnen.  Diese
  wird  deshalb bei der Konfiguration angegeben.

  Unter Linux trgt das Loopback-Device den Namen lo.  Der erste Eintrag
  in der Datei rc.inet1 sieht also so aus:

  ______________________________________________________________________

  #!/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
  #
  ______________________________________________________________________

  Hierbei wurde ifconfig werwendet, um der Loopback-Schnittstelle die
  IP-Adresse zuzuweisen, und route, um in der Routing-Table einen
  Eintrag zu erzeugen der sicherstellt, da alle Datagramme an die
  Adresse 127.0.0.1 ber die Loopback-Schnittstelle gesandt werden.

  Zwei sehr wichtige Dinge mssen hier noch erwhnt werden:

  Erstens, die Netzwerk-Maske und Broadcast-Adresse wurden beim
  ifconfig-Befehl nicht angegeben, deshalb werden automatisch die
  Standard-Werte verwendet.  Diese werden mit allen anderen
  Schnittstellenparametern angezeigt, wenn man ifconfig ohne Parameter
  aufruft:

       % 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
       %

  Zweitens, es ist aus dem angegebenen Befehl nicht ersichtlich, woher
  route wei, da als Schnittstelle fr die Adresse 127.0.0.1 das
  Loopback-Device verwendet werden soll.  Aber da es sich um einen
  Standard-Wert handelt, schliet das route-Programm aus Adresse und
  Netzwerk-Maske automatisch, da es sich um die Loopback-Adresse
  handelt.  Die so erstellte Routing-Table kann durch den Befehl route
  ohne Parameter angezeigt werden:

       % 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
       %

  Achtung: Es empfiehlt sich, route hierfr mit der Option -n zu
  verwenden, wenn der Name-Resolver (gegenseitige Zuordnung von Namen
  und IP-Adressen) noch nicht korrekt konfiguriert ist.  Diese Option
  bewirkt dann, da lediglich die IP-Adresse angezeigt wird und nicht
  versucht wird, diese Adressen in Rechnernamen zu bersetzen.

  9.5.  Die Konfiguration des Ethernet-Device (optional)

  Dieser Abschnitt ist nur von Interesse fr denjenigen, der eine
  Ethernet-Karte in seinem Rechner betreiben will.  Alle anderen knnen
  ihn berspringen.

  Die Konfiguration einer Ethernet-Karte ist nur geringfgig
  komplizierter als die des Loopback-Device, da Netzwerk-Maske und
  Broadcast-Adresse mitangegeben werden sollten.  Die Standard-Werte
  sollten nur verwendet werden wenn man auch sicher ist, da diese fr
  das lokale Netzwerk auch korrekt sind.

  Bentigt werden also die zugeteilte IP-Adresse, die lokale Netzwerk-
  Maske und die Broadcast-Adresse.

  Das erste Ethernet-Device in einem Linux-System trgt die Bezeichnung
  eth0, das zweite eth1 und so weiter.  Der folgende Code-Abschnitt mu
  in der Datei rc.inet1 angefgt werden, damit die Karte richtig
  eingetragen wird.  Die IP-Adresse mu dabei natrlich durch die eigene
  ersetzt werden:

  ______________________________________________________________________

  #
  # 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
  #
  ______________________________________________________________________

  Dabei bezeichnet

     IPA.IPA.IPA.IPA
        die IP-Adresse,
     NMK.NMK.NMK.NMK
        die Netzwerk-Maske,

     BCA.BCA.BCA.BCA
        die Broadcast-Adresse und

     NWA.NWA.NWA.NWA
        die Netzwerk-Adresse.

  Die Option -net teilt dem route-Kommando mit, da es sich bei der
  angegebenen Adresse um ein hinzuzufgendes Netzwerk und nicht um einen
  einzelnen Host (Rechner) handelt.  Die Option kann entfallen, wenn die
  zu konfigurierenden Netzwerke in der Datei /etc/networks eingetragen
  sind, route nutzt dann diese Datei, um Netzwerkadressen automatisch zu
  erkennen.  Das Format dieser Datei wird spter in einem eigenen
  Abschnitt erlutert.

  9.6.  Die Konfiguration eines SLIP-Device (optional)

  SLIP (Serial Line Internet Protocoll) erlaubt es, TCP/IP ber eine
  serielle Datenleitung zu benutzen.  Dies kann eine Telefonverbindung
  ber ein Modem sein oder eine dauerhafte, z.B. gemietete Standleitung.
  Natrlich bentigt man fr SLIP einen zweiten Rechner als Gegenstelle,
  den SLIP-Server.  Derartige SLIP-Server werden von vielen
  Universitten und inzwischen auch von kommerziellen Anbietern
  bereitgestellt.

  SLIP nutzt die seriellen Ports eines Rechners, um IP-Datagramme
  weiterzuleiten.  Hierzu mu es die Kontrolle ber das serielle Device
  bernehmen.  Die SLIP-Devices tragen die Bezeichnungen sl0, sl1 usw.
  Wie sind diese nun den seriellen Devices zugeordnet?  Der Netzwerk-
  Code benutzt dazu einen ioctl (i/o control), um die seriellen Devices
  in SLIP-Devices umzundern.  Es werden zwei Programme zur Verfgung
  gestellt, die dies bewerkstelligen knnen: dip und slattach.

  9.6.1.  dip

  dip (Dialup IP) ist ein komfortables und sehr leistungsfhiges
  Programm, das smtliche notwendigen Schritte ausfhren kann, um einen
  Rechner ber SLIP an das Internet anzuschlieen:  Setzten der
  Kommunikationsgeschwindigkeit auf dem seriellen Port, Herstellen der
  Modem-Verbindung, automatischer Login, Extrahieren von notwendigen
  Informationen wie IP-Nummern fr dynamische Adressvergabe aus den
  Rckmeldungen des Servers und Ausfhrung des ioctl, um die serielle
  Leitung auf den SLIP-Modus zu schalten.  Dies alles kann durch eine
  leistungsfhige Script-Sprache einfach konfiguriert und
  vollautomatisch durchgefhrt werden.

  Die Weiterentwicklung von dip verluft mittlerweile getrennt von
  restlichen Netzwerk-Code und ist deshalb nicht mehr bei den net-tools
  enthalten.  Man mu es sich also separat besorgen.  Es gibt inzwischen
  verschiedene Versionen von dip, die eine Vielzahl an zustzlichen
  neuen Optionen und Mglichkeiten bieten.  Es lohnt sich durchaus, die
  einzelnen Versionen anzusehen und dann diejenige zu verwenden, die den
  eigenen Wnschen am besten entspricht.  Am weitesten verbreitet
  scheint aber die Version dip-uri zu sein, deshalb werden die Beispiele
  im Text auf dessen derzeitigen Version basieren.

  dip-uri findet man auf:

       sunsite.unc.edu:/pub/Linux/system/Network/serial/dip337o-uri.tgz

  Um es zu installieren, geht man folgendermassen vor:

       % cd /usr/src
       % gzip -dc dip337o-uri.tgz | tar xvf -
       % cd dip.3.3.7o

       <Makefile editieren>

       % make install

  Das Makefile geht davon aus, da eine Group namens uucp existiert,
  unter deren Group-ID die Programme installiert werden.  Wer will, kann
  dies je nach lokaler Konfiguration in dip oder SLIP umndern.

  9.6.2.  slattach

  Im Gegensatz zu dip ist slattach ein recht spartanisches Programm, das
  zwar sehr einfach zu bedienen ist, aber bei weitem nicht die
  Mglichkeiten von dip bietet.  Es hat keinerlei Script-Fhigkeiten und
  wird vollstndig ber die Kommandozeile gesteuert.  Seine einzige
  Aufgabe ist es, den seriellen Port fr SLIP zu konfigurieren.  Dabei
  geht es davon aus, da bereits eine serielle Verbindung zum anderen
  Rechner besteht und alle notwendigen Parameter bekannt sind, da es
  keine Standardwerte gibt.  Dadurch eignet sich slattach ganz besonders
  fr dauerhafte Verbindungen zum Server, sei es ber ein (Null-Modem)
  Kabel oder eine Standleitung.

  9.6.3.  Und wann benutze ich welches Programm ?

  dip ist das Programm der Wahl wenn die SLIP-Verbindung ber ein Modem
  hergestellt wird.  slattach hingegen ist fr dauerhafte Verbindungen
  besser geeignet, wenn zu deren Herstellung keine spezielle Aktionen
  notwendig sind.  Im Abschnitt `Permanente SLIP Verbindung' werden
  hierzu genauere Details gegeben.

  Die Konfiguration des SLIP-Device verluft fast genauso so wie fr das
  Ethernet-Device (siehe den vorigen Abschnitt).  Ein paar entscheidende
  Unterschiede gibt es dennoch.

  Zunchst gibt es im Gegensatz zu einem Ethernet-Netzwerk bei SLIP nur
  zwei Rechner, einen an jedem Ende der Verbindung.  Anders als beim
  Ethernet besteht auch nicht sofort eine Netzwerkverbindung, sobald die
  Rechner physikalisch verbunden sind, vielmehr sind, je nach Art der
  Verbindung, zustzliche Initialisierungen notwendig.

  Bei der Verwendung von dip geschieht dies normalerweise nicht beim
  Systemstart sondern zu einem spteren Zeitpunkt, wenn die Verbindung
  auch wirklich benutzt werden soll.  Der gesamte Vorgang lt sich aber
  auch in diesem Fall vollstndig automatisieren.  (Dauerhafte)
  Verbindungen, die ber slattach konfiguriert werden, werden meist
  bereits beim Systemstart aufgebaut und die notwendigen Befehle in die
  Datei rc.inet1 aufgenommen.  Dies wird spter beschrieben.

  Es gibt zwei unterschiedliche Arten von SLIP-Servern: Solche, die
  statische IP-Adressen benutzen und solche, die die IP-Adressen
  dynamisch vergeben.  Fr gewhnlich meldet sich ein SLIP-Server
  zunchst mit einer Login-Meldung und fragt dann nach Benutzername und
  Pawort.  dip kann in beiden Fllen den Login-Proze automatisch
  durchfhren.

  9.6.4.  Dip bei statischem SLIP-Server ber Modem-Verbindung

  Ein statischer SLIP-Server vergibt an jeden Benutzer eine eigene IP-
  Adresse.  Bei jedem Verbindungsaufbau wird der SLIP-Server, basierend
  auf dem Login-Namen, eine bestimmte IP-Adresse verwenden und alle
  Datagramme, die an diese Adresse sind, ber die serielle Leitung an
  den eigenen Rechner weiterleiten.  Da sich somit die IP-Adresse
  niemals ndert, kann sie dauerhaft in der Datei /etc/hosts eingetragen
  werden.  Auch in den Dateien rc.inet2, host.conf, resolv.conf,
  /etc/HOSTNAME und rc.local kann die Adresse dann an entsprechenden
  Stellen fest eingetragen werden.  In rc.inet1 sind wie bereits gesagt
  keine Eintrge betreffend das SLIP-Device ntig, da alle Konfiguration
  von dip bernommen wird.  Die Netzwerk-Parameter mssen deshalb dip
  mitgeteilt werden.

  Benutzer statischer SLIP-Server knnen direkt im Abschnitt `Die
  Benutzung von dip' weiterlesen.

  9.6.5.  Dip bei dynamischem SLIP-Server ber Modem-Verbindung

  Ein dynamischer SLIP-Server verteilt die IP-Adressen nicht anhand der
  Benutzer-ID, sondern weist jedem, der sich einlogged eine gerade freie
  Nummer aus einem Pool von Adressen zu.  Es gibt also keine Garantie,
  da man jedesmal eine bestimmte IP-Nummer zugewiesen bekommt, auerdem
  kann (und wird) dieselbe Nummer einem anderen zugeteilt werden,
  nachdem die Verbindung beendet ist.  Bei jedem Verbindungsaufbau wird
  so die nchste freie IP-Adresse aus dem vom Administrator des SLIP-
  Servers eingestellten Bereich herausgesucht und dann dieser einen
  Verbindung zugeordnet.  Nach der normalen Login-Prozedur wird der
  SLIP-Server diese Adresse zusammen mit der Login-Meldung mitteilen und
  ab diesem Moment alle Datagramme an diese Adresse ber die Modem-
  Verbindung weiterleiten.

  Die Konfiguration fr diesen Typ von Server unterscheidet sich kaum
  von demjenigen fr statische Server.  Es mu lediglich ein Schritt
  eingefgt werden, bei dem die zugeteilte Adresse aus der Rckmeldung
  des Servers herausgesucht wird, um danach wie beim statischen Server
  das SLIP-Device damit zu konfigurieren.

  Auch hier verrichtet dip die Hauptarbeit, neuere Versionen sind sogar
  schlau genug, selbstndig die IP-Adresse in der Willkommens-Meldung
  des Servers zu finden und fr die Konfiguration des SLIP-Device zu
  verwenden.

  Auch fr Benutzer von dynamischen SLIP-Servern ist das wichtigste also
  die richtige Konfigurierung von dip, was im folgenden Abschnitt
  beschrieben wird.

  9.6.6.  Die Benutzung von dip

  Wie bereits dargestellt handelt es sich bei dip um ein uerst
  leistungsfhiges Programm, das den Verbindungsaufbau stark
  vereinfachen, ja sogar automatisieren kann.  dip bernimmt dabei das
  Anwhlen des SLIP-Servers, die gesamte Login-Kommunikation, es
  konfiguriert den seriellen Port fr das SLIP-Protokoll und fhrt die
  ntigen ifconfig und route Befehle aus, um das SLIP-Device richtig zu
  konfigurieren.
  Die `Konfiguration' von dip besteht dabei darin, ein dip-Script zu
  erstellen.  Dieses besteht aus einer Reihe von Befehlen, die dip
  versteht, und die angeben, welche Aktionen ausgefhrt werden sollen.
  Das dip-Paket kommt mit einem Beispiel fr eine solche Script-Datei,
  dieses hat den Namen sample.dip.  An ihm kann man sehr gut den Aufbau
  einer solchen Script-Datei erkennen und lernen, wie alles abluft.
  dip ist ein sehr leistungsfhiges Programm mit zu vielen Optionen, als
  da diese hier alle erlutert werden knnten.  Man sollte die Online-
  Hilfe lesen, um sich ber den ganzen Umfang an Mglichkeiten zu
  informieren und die README-Dateien und Beispiele ansehen, die zusammen
  mit dip geliefert werden.

  Wer sich das Beispiel sample.dip ansieht wird feststellen, da es von
  einem statischen SLIP-Server ausgeht, also die Kenntnis der IP-Nummer
  vorausgesetzt wird.  Die neueren Versionen von dip umfassen aber auch
  ein Kommando, um bei dynamischen SLIP-Servern die zugeteilte IP-
  Adresse zu erkennen und entsprechend zu konfigurieren.  Das folgende
  Beispiel ist eine modifizierte Version des sample.dip aus dip337o-
  uri.tgz.  Es stellt vermutlich eine gute Ausgangsbasis fr die meisten
  Anwendungen dar.  Es empfiehlt sich, dieses Script z.B. nach
  /etc/dipscript zu kopieren und dann den eigenen Anforderungen
  entsprechend anzupassen.

  ______________________________________________________________________

  #
  # sample.dip    Dialup IP connection support program.
  #
  #       Diese Datei zeigt (soll zeigen) wie man DIP benutzt.
  #       Es sollte mit den gaengigen dynamischen Servern funktionieren.
  #       Wer seinen Zugang ueber einen statischen Server hat, sollte
  #       die Standard-Version von sample.dip aus dem dip-Paket
  #       verwenden.
  #
  #
  # Version:      @(#)sample.dip  1.40    07/20/93
  #
  # Author:       Fred N. van Kempen, <waltje@uWalt.NL.Mugnet.ORG>
  #

  main:
  # Festlegen von Name und Adresse der Gegenseite
  # Mein Verbindungs-Rechner ist 'xs4all.hacktic.nl' (== 193.78.33.42)
  get $remote xs4all.hacktic.nl
  # Setze die Netzmaske fr sl0 auf 255.255.255.0
  netmask 255.255.255.0
  # Setze den gewuenschten seriellen Port und dessen Geschwindigkeit
  port cua02
  speed 38400

  # Reset fuer das Modem und das Terminal.
  # Dies verursacht evtl Probleme bei manchen Leuten!
  reset

  # Die vordefinierten "Errlevel" sind:
  #  0 - OK
  #  1 - CONNECT
  #  2 - ERROR
  #
  # Sie koennen geaendert werden, dazu sucht man (mit grep) in den
  # Quelldateien (*.c) nach "addchat()"

  # Vorbereitung zum Waehlen
  send ATQ0V1E1X4\r
  wait OK 2
  if $errlvl != 0 goto modem_trouble
  dial 555-1234567
  if $errlvl != 1 goto modem_trouble

  # OK, die Verbindung steht.  Jetzt der Login
  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:

  # Jetzt sind wir eingelogged
  wait SOMEPROMPT 30
  if $errlvl != 0 goto prompt_error

  # Setze den Server in den SLIP-Modus
  send SLIP\n
  wait SLIP 30
  if $errlvl != 0 goto prompt_error

  # Finde die vom Server zugeteilte IP-Adresse.
  #  Dabei wird davon ausgegangen, da der Server, nachdem er in den
  #  SLIP-Modus uebergewechselt ist, diese Adresse ausgibt.
  get $locip remote 30
  if $errlvl != 0 goto prompt_error

  # Lege die SLIP-Parameter fest
  get $mtu 296
  # Dies stellt sicher, da der Befehl
  # "route add -net default xs4all.hacktic.nl" ausgefuehrt wird.
  default

  # Eine Meldung auf die Console, da alles funktioniert, und dann wird
  # die eigene Seite in den (C)SLIP-Modus geschaltet.
  done:
  print CONNECTED $locip ---> $rmtip
  mode CSLIP
  goto exit

  prompt_error:
  print TIME-OUT beim Warten auf den SLIP-Start
  goto error

  login_trouble:
  print Probleme beim Warten auf den Login: prompt...
  goto error

  password:error:
  print  Probleme beim Warten auf den Password: prompt...
  goto error

  modem_trouble:
  print  Probleme mit dem Modem...
  error:
  print CONNECT mit $remote GESCHEITERT
  quit

  exit:
  exit
  ______________________________________________________________________

  Dieses Beispiel geht von einem dynamischen SLIP-Server aus.  Beim
  Zugang ber einen statischen SLIP-Server gengt die originale Datei
  sample.dip aus dem dip337o-uri.tgz Paket.

  Die interessante Stelle in diesem Script ist der Befehl get $local.
  Daraufhin untersucht dip allen eingehenden Text auf eine Zeichenkette,
  die wie eine IP-Adresse aussieht, also Ziffern, die durch Punkte `.'
  getrennt sind.  Diese Spezialitt wurde speziell wegen der Zunahme von
  dynamischen Servern eingefhrt, damit auch fr diese der
  Verbindungsaufbau automatisch und ohne Eingreifen des Benutzers
  durchgefhrt werden kann.

  Das obige Beispiel legt automatisch die Default-Route auf die SLIP-
  Verbindung.  Wer das nicht braucht, weil er z.B. eine Ethernet-
  Verbindung als Default besitzt, mu im Script den default Befehl
  entfernen.  Nachdem das Script erfolgreich abgearbeitet wurde zeigt
  ein ifconfig, da jetzt ein Device sl0 existiert.  Dies ist das SLIP-
  Device.  Seine Konfiguration kann, wenn dies notwendig ist, manuell
  verndert werden.  Hierfr mssen die geeigneten ifconfig und route
  Befehle benutzt werden.

  Es mu noch darauf hingewiesen werden, da dip eine ganze Reihe von
  unterschiedlichen Protokollen untersttzt, die mit dem mode Befehl
  aktiviert werden knnen.  Die gngigste Variante ist cSLIP, das ist
  SLIP mit Komprimierung.  Es ist zwingend notwendig, da beide Seiten
  dieselbe Einstellung verwenden, da sonst keine Kommunikation mglich
  ist.  Das vom Server verwendete Protokoll mu deshalb beim Provider
  erfragt werden.

  Das aufgefhrte Beispiel ist ziemlich stabil und fngt einige mgliche
  Fehler ab.  Die Online-Hilfe man dip gibt weitere Hinweise dazu.
  Natrlich kann das Script auch dahingehend erweitert werden, da z.B.
  im Falle einer milungenen Verbindungsaufnahme ein erneuter
  Whlversuch gestartet wird, oder da nacheinander verschiedene Server
  probiert werden, bis es zu einer Erfolgreichen Verbindung kommt.

  9.6.7.  Permanente SLIP Verbindung (Standleitung) mit slattach

  Wer ein Verbindungskabel zwischen zwei Rechnern hat oder sogar das
  Glck, eine Standleitung oder eine hnliche dauernde serielle
  Verbindung zu besitzen, der braucht sich nicht mit dip zu befassen, um
  die Verbindung herzustellen.  slattach ist ein sehr einfach zu
  bedienendes Programm, welches gerade genug Funktionalitt bietet, um
  eine solche Verbindung aufzubauen.

  Da diese Verbindung eine permanente sein soll ist es angebracht, die
  ntigen Befehle in die Datei rc.inet1 aufzunehmen.  Kurz gesagt mu
  man nur sicherstellen, da das serielle Device die korrekte
  Geschwindigkeit eingestellt hat und es danach in den SLIP-Modus
  umschalten.  slattach fhrt diese beiden Dinge mit einem einzigen
  Befehl aus.  Dafr mssen die folgenden Zeilen zum bestehenden
  rc.inet1 hinzugefgt werden:

  ______________________________________________________________________

  #
  # 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.
  ______________________________________________________________________

  Wie gehabt mssen fr

     IPA.IPA.IPA.IPA
        die eigene IP Adresse und fr

     IPR.IPR.IPR.IPR
        die IP Adresse des anderen Rechners

  angegeben werden.

  slattach teilt dem angegebenen seriellen Device das erste freie SLIP-
  Device zu, im angegeben Fall also sl0.  Dieses wird dann im folgenden
  ifconfig konfiguriert.  Ein weiteres slattach-Kommando fr eine
  zustzliche Leitung wrde dieser dann das Device sl1 zuteilen.

  Auch slattach kennt unterschiedliche Protokolle, die mit dem -p
  Schalter aktiviert werden knnen.  Meist wird hier SLIP oder cSLIP
  verwendet, je nachdem, ob Kompression eingeschaltet werden soll.  Wie
  auch bei dip gilt:  Beide Seiten der Verbindung mssen dasselbe
  Protokoll konfigurieren, sonst geht nichts!

  9.7.  Die Konfiguration des PLIP Device (optional)

  PLIP (Parallel Line IP) dient, wie auch SLIP, zum Aufbau einer point
  to point Netzwerk-Verbindung, die also genau zwei Punkte miteinander
  verbindet.  Im Unterschied zu SLIP, welches die seriellen Ports
  verwendet, ist PLIP aber dazu gedacht, diese Verbindung ber die
  parallele Schnittstelle des Rechners zu verwirklichen.  Da ber eine
  parallele Schnittstelle mehr als ein Bit gleichzeitig bertragen
  werden kann, knnen ber eine PLIP-Verbindung hhere bertragungsraten
  erreicht werden als ber eine normale serielle Leitung.  Hierfr kann
  auch die billigste parallele Schnittstelle, der Drucker-Port,
  verwendet werden.  hnliche Geschwindigkeiten sind fr SLIP nur bei
  Verwendung der recht teuren 16550AFN UART's in den seriellen
  Schnittstellen mglich.

  Unerfreulicherweise verwenden einige Notebooks Chipstze, die nicht
  mit PLIP zusammenarbeiten, da einige Kombinationen von Signalen, die
  PLIP unbedingt bentigt, nicht erlaubt sind, da sie von Druckern nicht
  verwendet werden.

  Das PLIP-Interface von Linux ist kompatibel zum Crynwyr Packet Driver
  PLIP.  Das bedeutet, da ein Linux-Rechner via PLIP auch mit einem
  DOS-Rechner verbunden werden kann.

  Der PLIP-Treiber kann auf zwei unterschiedliche Weisen eingebunden
  werden, er kann entweder dauerhaft in den Kernel einkompiliert oder
  unter Verwendung des modules Paketes bei Bedarf hinzugeladen werden.
  Da PLIP meist eine dauerhafte Verbindung darstellt empfiehlt sich
  meist die Variante, den Treiber fest in den Kernel einzubinden.

  Bei der Kernel-Kompilation gibt es nur eine einzige Datei, die man
  eventuell ansehen mu.  Diese ist /usr/src/linux/driver/net/CONFIG,
  und sie enthlt die plip Timer in mS.  Die Standardeinstellungen sind
  aber in den meisten Fllen ausreichend.  Nur auf besonders langsamen
  Computern mu der eingestellte Wert unter Umstnden vergrert werden,
  wobei dadurch tatschlich der Timer des anderen Computers beeinflut
  wird.

  Der Treiber nimmt folgende Standard-Werte an:

       device  i/o addr    IRQ
       ------  --------    -----
       plip0   0x3BC           5
       plip1   0x378           7
       plip2   0x278           2 (9)

  Wessen parallele Schnittstelle nicht mit einer dieser Einstellungen
  bereinstimmt, der kann den IRQ eines Ports mit der irq-Option des
  ifconfig-Befehles verndern.  Eventuell mssen auch die IRQs fr die
  Druckerschnittstelle im ROM BIOS freigegeben werden, falls dieses das
  untersttzt.

  Um das plip-Device zu konfigurieren, mssen die folgenden Zeilen zur
  Datei rc.inet1 hinzugefgt werden:

  ______________________________________________________________________

  #
  # 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
  ______________________________________________________________________

  Auch hier gilt:

     IPA.IPA.IPA.IPA
        ist die eigene IP Adresse.

     IPR.IPR.IPR.IPR
        ist die IP Adresse des anderen Rechners.

  Der Parameter pointopoint hat dieselbe Bedeutung wie bei der
  Konfiguration des SLIP-Device, es gibt die Adresse des Rechners am
  anderen Ende der Leitung an.

  In fast allen Belangen kann man das plip Interface genauso behandeln
  als wenn es sich um ein SLIP Interface handeln wrde.  Lediglich die
  Verwendung von dip ist weder ntig noch mglich.

  9.7.1.  Diagramm eines PLIP-Kabels

  PLIP wurde so ausgelegt da die Kabel dieselbe Pin-Belegung aufweisen
  wie diejenigen, die von den meisten DOS-Programmen zur
  Datenbertragung zwischen zwei PCs verwendet werden.

  Dieses Pin-Belegungs-Schema sieht folgendermaen aus (es ist der Datei
  /usr/src/linux/drivers/net/plip.c entnommen):

       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*

  Achtung: Pins, die mit einem Stern `*' markiert sind, drfen nicht
  verbunden werden.  18,19,20,21,22,23 und 24 sind zustzliche GROUND-
  Anschlsse.

  Werden geschirmte Kabel verwendet, sollte die Abschirmung nur auf
  einer Seite mit dem Metall des Steckers verbunden werden

  Warnung! Falsch verdrahtete PLIP-Kabel knnen die Controller-Karte
  zerstren.  Also lieber einmal zuviel berprfen, da alle Pins
  korrekt verbunden sind, das erspart unntigen rger.

  Obwohl PLIP-Kabel im Prinzip sehr lang sein knnen, sollte man es nach
  Mglichkeit vermeiden.  Die Spezifikationen erlauben Kabellngen von
  etwa einem Meter.  Aber je lnger ein Kabel ist, desto empfindlicher
  reagiert es auf Strungen durch elektromagnetische Felder wie sie z.B.
  durch Blitze, Stromkabel oder Radiosender verursacht werden.  Im
  Extremfall kann durch solche Fremdeinstrahlungen sogar der Controller
  in Mitleidenschaft gezogen werden.  Wer seine Rechner unbedingt ber
  eine lngere Strecke miteinander vernetzen will sollte sich wirklich
  berlegen, ob er sich nicht doch lieber zwei Netzwerk-Karten und ein
  koaxiales Kabel zulegen sollte.

  10.  Routing

  Nachdem jetzt alle Netzwerk-Devices konfiguriert sind, mu man sich
  Gedanken darber machen, auf welchen Wegen der Computer die Datagramme
  weiterleitet.  Ist berhaupt nur ein einziges Device vorhanden ist
  diese Frage sehr leicht zu beantworten: Alle Datagramme, die nicht an
  den eigenen Rechner adressiert sind, mssen ber diese Schnittstelle
  transferiert werden.  Bei mehr als einer Schnittstelle wird es aber
  komplizierter.  Hier mu man bei jedem Datagramm nachsehen, ber
  welche Schnittstelle der Rechner, an den das Datagramm adressiert ist,
  angeschlossen ist.  Dieses `Routing' ist im Prinzip aber recht
  einfach, auch wenn es manchem auf den ersten Blick nicht so erscheinen
  mag.

  Den Inhalt der momentanen Routing-Tabelle kann man sich ansehen, indem
  man das route-Kommando ohne Parameter aufruft.

  Unter Unix gibt es vier unterschiedliche Routing- Mechanismen, auf die
  im folgenden kurz eingegangen werden soll.

  10.1.  Statisches Routing

  Wie der Name bereits andeutet handelt es sich dabei um ein quasi `fest
  verdrahtetes' Routing.  Das bedeutet, da der angegebene Weg unter
  allen Umstnden benutzt wird, auch wenn zu einem spteren Zeitpunkt
  eine bessere Verbindung zur Verfgung stehen wrde, oder wenn die
  angegebene Verbindung zusammenbricht.  Auch wenn noch eine alternative
  Verbindung bestehen wrde, sie wrde bei statischem Routing nicht
  benutzt.  Aus diesem Grunde werden sie normalerweise nur fr sehr
  einfache Netze verwandt, wenn es sowieso keine weitere
  Verbindungsmglichkeit zum anderen Rechner gibt.

  Unter Linux wird dieses statische Routing insbesondere fr SLIP- und
  PLIP-Verbindungen angelegt, wenn der Befehl ifconfig mit dem Parameter
  pointopoint verwendet wird.  Der entsprechende route-Befehl, um eine
  solche statische Verbindung in die Routing-Tabelle einzutragen,
  lautet:

  %/sbin/route add IPR.IPR.IPR.IPR

     IPR.IPR.IPR.IPR
        ist dabei die Adresse des Rechners am anderen Ende der Leitung.

  10.2.  Default Route

  Fr die meisten Rechner, die als Benutzer-Workstations im Netzwerk
  angeschlossen sind und keine speziellen Aufgaben in diesem Netzwerk
  wahrnehmen ist die Deklaration einer Default Route das
  Standardvorgehen.  Eine solche Route ist eine besondere Art von
  statischer Route, die fr alle Adressen angewandt wird, fr die nicht
  explizit eine andere Route angegeben ist.

  Wer also nur ber eine einzige Netzwerk-Schnittstelle verfgt, sei es
  nun eine SLIP-Verbindung oder eine Ethernet-Karte, der sollte seine
  Default Route auf dieses Device einrichten.  Dazu ist weiterhin eine
  Adresse notwendig, diejenige des Routers.  Dies lt sich am besten am
  Beispiel eines (lokalen) Ethernet-Netzwerkes sehen:  Soll ein
  Datagramm an einen Rechner innerhalb des lokalen Netzes gesandt
  werden, so kann dies der Kernel selstndig erkennen (er macht dies
  anhand der bereits erluterten Netzwerk-Maske).  Soll das Datagramm
  aber an einen Rechner auerhalb dieses Netzes gehen, so bentigt der
  Kernel die Adresse eines anderen Rechners, an den er das datagramm
  weiterreichen kann, und der dann die weitere Zustellung bernimmt.
  Einen solchen Rechner bezeichnet man als Router oder Gateway.  Im
  Falle eines Internet-Zuganges ber SLIP bernimmt der SLIP Server
  diese Aufgabe, seine IP-Adresse mu dann als Router eingetragen
  werden.  In lokalen Ethernet-Netzen erfhrt man die Adresse des
  Routers vom Systemadministrator.

  Um nun die Default Route festzulegen, mssen die folgenden Zeilen in
  der Datei rc.inet1 nach der Konfiguration smtlicher Netzwerk-Devices
  eingefgt werden:

  ______________________________________________________________________

  #
  # Add a default route.
  #
  /sbin/route add default gw RGA.RGA.RGA.RGA
  #
  ______________________________________________________________________

     RGA.RGA.RGA.RGA
        ist die Router/Gateway Adresse.

  10.3.  Proxy ARP

  Diese Methode ist unschn, birgt einige Gefahren und sollte nur unter
  besonderer Vorsicht verwendet werden.  Da aber manche darauf schwren,
  soll es hier nicht unerwhnt bleiben.

  Bei weitem das grte Bedrfnis fr Proxy ARP besteht bei all
  denjenigen, die einen Linux-Rechner als SLIP-Server konfigurieren
  wollen.  Soll hingegen ein PPP-Server aufgebaut werden, so bernimmt
  der PPP-Dmon die meisten Aufgaben, dadurch wird PPP viel einfacher
  und sicherer.

  Will ein anderer Rechner im TCP/IP-Netzwerk mit einem anderen Rechner
  kommunizieren, so kennt er zwar dessen IP-Adresse, nicht jedoch (im
  Falle eines Ethernet) die Hardware-Adresse, an die die Datagramme
  gesandt werden mssen.  Der ARP-Mechanismus fhrt nun genau diese
  bersetzung von Netzwerk- und Hardware-Adressen durch.  Zu diesem
  Zweck wird ein spezielles Datagramm, welches die Adresse desjenigen
  Rechners enthlt, dessen Hardware-Adresse gesucht ist, an die
  Broadcast-Adresse gesandt.  Damit `hren' alle Rechner im Netz diesen
  Aufruf, und derjenige, dessen Adresse gesucht ist, reagiert darauf,
  indem er seine Hardware-Adresse zurcksendet.  Damit kennt nun der
  Rechner, der die ARP-Anfrage gestartet hatte, die Hardware-Adresse und
  kann seine Datagramme weiterleiten.

  Ist ein Rechner nun als Server fr weitere Rechner konfiguriert, so
  mu er auch auf alle ARP-Anfragen reagieren, die an diese Klienten
  gerichtet sind, da sie ja nicht physikalisch im Ethernet-Netzwerk
  eingebunden sind.  Dies erlutert sich am besten an einem praktischen
  Beispiel:  Ein Rechner hat in seinem lokalen Netzwerk einige IP-
  Adressen, die er fr SLIP-Verbindungen ber Modem zur Verfgung
  stellt.  Dies seien die Adressen 128.253.154.120-124.  Dieser Rechner
  ist weiter ber eine Ethernet-Karte mit der Hadrware-Adresse
  00:00:C0:AD:37:1C mit dem lokalen Netz verbunden (die Hardware-Adresse
  kann man mit dem ifconfig-Befehl herausfinden).  Um diesem Linux-
  Server nun mitzuteilen, da er auch die ARP-Anfragen fr die SLIP-
  Adressen beantworten soll, mssen die folgenden Zeilen an die Datei
  rc.inet1 angefgt werden:

  ______________________________________________________________________

  #
  # 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.
  ______________________________________________________________________

  Der Parameter pub steht fr publish (ffentlich machen).  Dies ist der
  Befehl fr den lokalen Rechner, auch die Anfragen fr die angegebene
  Adresse zu beantworten, obwohl es nicht die eigene ist.  Dabei wird
  mit der angegebenen Hardware-Adresse geantwortet, welches natrlich
  wiederum die eigene ist.

  Selbstverstndlich ist es auerdem notwendig, da auf dem Linux-Server
  auch Routes zu diesen Adressen konfiguriert sind, die auf die
  jeweiligen SLIP-Devices zeigen.

  Bei der Benutzung von PPP braucht man sich nicht darum kmmern, diese
  ARP-Tabelle manuell auf dem laufenden zu halten, denn dies wird von
  pppd automatisch durchgefhrt, wenn die Option proxyarp angegeben
  wurde.  Voraussetzung dabei ist, da die IP-Adresse von Server und
  Klient zum selben Netzwerk gehren.  Aus diesem Grund mu man auf dem
  Server beim Start des pppd die Netzwerk-Maske in der Kommandozeile
  mitangeben.

  10.4.  Gated - der Routing Dmon

  Anstelle von Proxy ARP htte man im vorangegangenen Beispiel auch
  gated verwenden knnen.  Dessen Hauptaufgabe liegt aber darin, einen
  Linux-Rechner als intelligenten IP Router in einem Netzwerk zu
  konfigurieren.  gated bietet Untersttzung fr eine ganze Reihe an
  Routing-Protokollen: RIP, BGP, EGP, HELLO, OSPF und ein paar mehr.
  Insbesondere in kleineren Netzen ist RIP das verbreitetste.  RIP steht
  dabei fr Routing Information Protocol.  Ein Linux-Rechner, auf dem
  gated fr RIP konfiguriert ist, verbreitet in regelmigen Abstnden
  seine eigene Routing-Tabelle in einem besonderen Format ber die
  Broadcast-Adresse.  Auf diese Weise sind alle Rechner im Netz stets
  darber informiert, welche Adressen ber diesen Rechner erreicht
  werden knnen.

  Wenn auf allen Rechnern in einem Netzwerk entweder gated oder routed
  luft, kann Proxy ARP durch gated ersetzt werden.  In einem gemischen
  Netzwerk, welches sowohl statische als auch dynamische Routes
  verwendet, sollten smtliche statischen Routes als passiv erklrt
  werden um sicherzustellen, da sie von gated nicht gelscht werden,
  weil er fr sie keine wiederholten Gltigkeitsmeldungen bekommt.
  Statische Routes deklariert man bei der Verwendung von gated am besten
  durch einen static-Eintrag in der Datei /etc/gated.conf.  Dies wird
  weiter unten beschrieben.

  Wie es sich fr einen Netzwerk-Dmon gehrt, wird gated fr gewhnlich
  in der rc-Datei rc.inet2 gestartet.  Eventuell wird man feststellen,
  da bereits ein Dmon namens routed luft.  Da gated weit flexibler
  ist als routed sollte man dessen Verwendung vorziehen und den routed-
  Prozess nicht weiter verwenden.

  10.4.1.  Woher bekomme ich gated ?

  gated kann per Anonymous FTP bezogen werden von:

       sunsite.unc.edu:/pub/Linux/system/Network/daemons/gated11_bin.tgz

  10.4.2.  Die Installation von gated

  Die binre Paket von gated besteht aus drei Programmen und zwei
  beispielhaften Konfigurationsdateien.  Diese sind:

     gated
        der eigentliche gated Dmon.

     gdc
        die (optionale) Benutzerschnittstelle zu gated.  Mittels gdc
        kann man den gated-Dmon anhalten, neu straten, Statusabfragen
        durchfhren usw.

     ripquery
        Ein Diagnoseprogramm, mit dem man die bekannten Routes entweder
        durch eine `rip query' oder ein `rip poll' abfragen kann.

  Die Konfigurations-Dateien sind:

     gated.conf
        dies ist die zentrale Konfigurations-Datei fr den gated-Dmon.
        Hier kann das gesamte Verhalten von gated festgelegt werden, es
        knnen die verschiedenen Protokolle aktiviert und deaktiviert
        werden und die aktiven Protokolle knnen in ihrem Verhalten
        beeinflut werden.

     gated.version
        eine kleine Text-Datei, die die Versionsnummer des gated-Dmons
        enthlt.

  Unerfreulicherweise werden die verschiedenen Dateien von der Binr-
  Distribution nicht an die richtigen Stellen installiert.  Da es aber
  nur wenige sind, kann man das sehr einfach beheben.

  Um sie zunchst temporr zu entpacken und dann an die richtigen
  Stellen zu installieren dienen die folgenden Befehle:

       % 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

  /usr/sbin ist dabei der bliche Platz fr Netzwerk-Dmonen.  Wer sie
  auf seinem System in einem anderen Verzeichnis hat, mu das Script
  natrlich entsprechend abndern.  Die mitgelieferte
  Beispielkonfiguration setzt gated so auf, da das Verhalten des
  lteren routed-Dmons emuliert wird.  In den meisten Fllen wird dies
  funktionieren.  Die Datei /etc/gated.conf sieht dafr folgendermassen
  aus:

  ______________________________________________________________________

  #
  #  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;
  #
  ______________________________________________________________________

  Gibt es im Netz irgendwelche statischen Routes, sollten diese
  ebenfalls in diese Datei eingetragen werden.  Dies geschieht, indem
  ein solcher Eintrag hinzugefgt wird:

  ______________________________________________________________________

  #
  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 ;
  } ;
  #
  ______________________________________________________________________

  In diesem Beispiel wird eine statische Route zu einem Class-A Netzwerk
  37.0.0.0 ber den Gateway 44.136.8.97 angelegt sowie eine weitere zu
  dem Rechner mit der Adresse 44.136.8.100 ebenfalls ber den Gateway
  44.136.8.97.

  Will man auch die Dateien der Online-Hilfe fr gated installieren,
  geht man wie folgt vor:

       % 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

  Diese man Dateien enthalten sehr przise und ausfhrliche Hinweise zur
  Benutzung von gated.  Informationen zur Konfiguration erhlt
  insbesondere das gated-config Manual.

  11.  Die Konfiguration der Netzwerk-Dmonen

  Zur Vervollstndigung der Netzwerk-Konfiguration sind auer den beiden
  rc.inet*-Dateien noch weitere Konfigurationsdateien ntig.  Diese
  kontrollieren das Verhalten des Netzwerk-Codes auf einer etwas hheren
  Ebene, nmlich dasjenige der Netzwerk-Dmonen, die u.a. in rc.inet2
  gestartet werden.  Die folgenden Unterabschnitte erlutern die
  wichtigsten davon.

  11.1.  /etc/rc.d/rc.inet2 (bzw. zweite Hlfte von rc.net)

  Wer den Anweisungen des Textes bis zu diesem Punkt gefolgt ist besitzt
  nun eine rc-Datei, die jedes der vorhandenen Netzwerk-Devices korrekt
  konfiguriert und alle bentigten Routes zu den erreichbaren Netzwerken
  deklariert.  Nun mssen die eigentlichen, hheren Netzwerk-Programme
  gestartet werden.

  Das wre genau der richtige Zeitpunkt, den Network Administrators
  Guide von Olaf Kirch zu lesen, denn er ist das Buch zu diesem Thema
  schlechthin.  Es gibt alle notwendigen Hinweise, was in diese Datei
  aufgenommen werden sollte, und, fast noch wichtiger, was man hier
  nicht hineintun sollte.  Im Hinblick auf die Systemsicherheit kann man
  nmlich ganz knapp sagen: Je mehr Netzwerk-Dienste konfiguriert und
  angeboten werden, desto hher ist das Risiko, ein Sicherheitsloch
  aufzutun.  Also immer nur das konfigurieren, was auch wirklich
  bentigt wird.

  In jedem Fall mu man einiges ber die wichtigen Dmonen wissen, das
  sind Programme, die im Hintergrund ablaufen und viele Dinge
  automatisch regeln.  Die Online-Hilfe mittels man gibt hier genauere
  Information, hier deshalb nur eine kurze Zusammenfassung:

  11.1.1.  inetd

  inetd verwaltet smtliche Anfragen zu Internet-Verbindungen und
  hnlichem.  Der groe Vorteil von inetd ist, da man nicht fr alle
  angebotenen Dienste einen eigenen Serverproze laufen lassen mu, auch
  wenn momentan dieser Dienst gar nicht angefordert ist.  Erst wenn eine
  Anfrage fr einen bestimmten Dienst, z.B. telnet, eintrifft, sieht
  inetd in der Datei /etc/services nach, welches Programm diesen Dienst
  zur Verfgung stellt.  Dieses Programm wird dann gestartet und die
  Verbindung an es weitergegeben.  Man kann sich inetd also als eine Art
  Internet-Hauptserver vorstellen.  Einige Standard-Dienste sind
  brigens direkt in inetd implementiert, dies sind echo, discard ud
  generate, die fr diverse Netzwerk-Tests verwendet werden.  inetd kann
  nicht alle Dienste und Server-Programme verwalten, aber doch die am
  meisten verwendeten.  Dienste wie z.B. solche die auf udp basieren,
  oder solche, die das Multiplexing ihrer Verbindungen selber regeln,
  wie World Wide Web oder MUDs mssen unabhngig von inetd gestartet
  werden.  Im Normalfall wird in der Dokumentation solcher Pakete ein
  Hinweis gegeben, ob der jeweilige Dienst ber inetd verwaltet werden
  sollte oder nicht.

  11.1.2.  syslogd

  syslogd verwaltet das System Logging, also all die vielen Meldungen,
  die die verschiedenen Dmonen und Kernel-Module bei ihrer Arbeit
  produzieren.  syslogd verteilt diese Meldungen gem einem Schema,
  welches in der Datei /etc/syslogd.conf festgelegt wird, entweder auf
  unterschiedliche Protokoll-Dateien oder verwirft sie.  So knnen z.B.
  bestimmte Meldungen sowohl auf der Konsole ausgegeben als auch
  mitprotokolliert werden, andere hingegen nur ein einer Datei
  gespeichert werden.

  11.2.  Beispiel fr eine rc.inet2 Datei

  Das folgende Beispiel wurde von Fred van Kempen erstellt.  Es startet
  eine groe Zahl an Servern, es sollte also genau studiert und auf den
  fr den eigenen Bedarf angemessenen Umfang reduziert werden.  Die
  geschieht am besten, indem man die nicht bentigten Abschnitte durch
  ein Kommentarzeichen # deaktiviert, dann knnen sie zu einem spteren
  Zeitpunkt leichter wieder implementiert werden, sollte sich das eigene
  Anforderungsprofil ndern.  Diese einzelnen Abschnitte bestehen
  jeweils aus einem Aufruf des entsprechenden Programms, welcher in
  einer if ... fi-Abfrage eingebettet ist.  Diese tut nichts anderes als
  zu prfen, ob die angegebene Datei auch existiert und ausfhrbar ist,
  um Fehlermeldungen zu vermeiden.  Weiterhin wird ein kurzer Hinweis
  ber das gestartete Programm ausgegeben.  Hinweise zu den hier
  aufgefhrten Dmonen entnimmt man entweder dem Network Administrators
  Guide oder der Online-Hilfe mittels man.

  ______________________________________________________________________

  #! /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>
  #

  # Konstanten
  NET="/usr/sbin"
  IN_SERV="lpd"
  LPSPOOL="/var/spool/lpd"

  # Jetzt koennen auch NFS-Dateisysteme gemounted werden, das kann
  # z.B. auch der gesamte /usr-Verzeichnisbaum sein
  echo -e "\nMounting remote file systems ..."
  /bin/mount -t nfs -v

  echo -e "\nStarting Network daemons ..."
  # Als erste wird der SYSLOG Daemon gestartet.  Dies muss der
  # erste Server sein, er ist IN JEDEM FALLE notwendig!
  echo -n "INET: "
  if [ -f ${NET}/syslogd ]
  then
  echo -n "syslogd "
  ${NET}/syslogd
  fi

  # Starte den SUN RPC Portmapper.
  if [ -f ${NET}/rpc.portmap ]
  then
  echo -n "portmap "
  ${NET}/rpc.portmap
  fi

  # Starte den INET SuperServer
  # Auch dieser ist IMMER NOTWENDIG!
  if [ -f ${NET}/inetd ]
  then
  echo -n "inetd "
  ${NET}/inetd
  else
  echo "no INETD found.  INET cancelled!"
  exit 1
  fi

  # Starte den NAMED/BIND Nameserver.
  # HINWEIS: named wird fuer endbenutzer-Rechner meist nicht benoetigt.
  #if [ ! -f ${NET}/named ]
  #then
  #        echo -n "named "
  #        ${NET}/named
  #fi

  # Starte den ROUTEd Server.
  # HINWEIS: routed ist veraltet, stattdessen wird gated benutzt.
  #if [ -f ${NET}/routed ]
  #then
  #        echo -n "routed "
  #        ${NET}/routed -q #-g -s
  #fi

  # Starte den GATEd Server.
  if [ -f ${NET}/gated ]
  then
  echo -n "gated "
  ${NET}/gated
  fi

  # Starte den RWHO Server.
  if [ -f ${NET}/rwhod ]
  then
  echo -n "rwhod "
  ${NET}/rwhod -t -s
  fi

  # Starte den U-MAIL SMTP Server.
  if [ -f XXX/usr/lib/umail/umail ]
  then
  echo -n "umail "
  /usr/lib/umail/umail -d7 -bd </dev/null >/dev/null 2>&1 &
  fi

  # Starte die verschiedenen INET Server.
  for server in ${IN_SERV}
  do
  if [ -f ${NET}/${server} ]
  then
                  echo -n "${server} "
                  ${NET}/${server}
  fi
  done

  # Starte die diversen SUN RPC Server.
  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

  # Starte den/die PC-NFS Daemon(en).
  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.
  # Fertig!
  ______________________________________________________________________

  11.3.  Weitere notwendige Netzwerk-Konfigurationsdateien

  Soll es anderen Personen ermglicht werden, Verbindung mit dem eigenen
  Rechner aufzunehmen, so sind einige weitere Konfigurationsdateien
  notwendig.  Wer ein Linux-System aus einer zusammengestellten
  Distribution installiert hat, wird diese Dateien vermutlich schon an
  den entsprechenden Stellen besitzen.  Dann gengt es, diese auf
  Korrektheit zu berprfen.  Ansonsten sind hier Standardbeispiele
  aufgefhrt.

  11.3.1.  Beispiel fr eine /etc/inetd.conf Datei

  In /etc/rc.d/rc.inet2 werden der inetd- und der syslogd-Dmon sowie
  diverse rpc Server gestartet.  Die von inetd verwalteten Dienste
  mssen in der Datei /etc/inetd.conf konfiguriert werden.  Das folgende
  Beispiel zeigt eine solche einfache Konfiguration:

  ______________________________________________________________________

  #
  # 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.
  ______________________________________________________________________

  Die Online-Hilfe zu inetd beschreibt ausfhrlich, was jedes dieser
  Felder darstellt.  Kurz gesagt wird fr jeden der in der ersten Spalte
  aufgefhrten Dienste angegeben, welches Programm gestartet werden
  soll, wenn dieser Dienst angefordert wird.  Diejenigen Eintrge, bei
  denen im letzten Feld internal steht, werden von inetd selbst zur
  Verfgung gestellt.

  Die bersetzung vom Namen eines Dienstes (aus der ersten Zeile) und
  der Socket Nummer, ber die dieser Dienst erreichbar ist, wird in der
  Datei /etc/services festgelegt.

  11.3.2.  Beispiel fr die Datei /etc/services

  Die Datei /etc/services ist eine einfache Tabelle der Namen der
  Internet-Dienste, ihrer Socket-Nummern und des verwendeten Protokolls.
  Diese Tabelle wird von einigen Programmen verwendet, darunter inetd,
  telnet und tcpdump.  Die Zuordnung von Namen dient dabei brigens nur
  dazu, da man sich die Dienste leichter merken kann.  Dem Rechner ist
  es egal, ob er mit Namen oder Nummern arbeitet.

  Eine typische /etc/services Datei sieht so aus:

  ______________________________________________________________________
  #
  # /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.
  ______________________________________________________________________

  Hier zeigt z.B. der Eintrag bei telnet, da dieser Dienst Socket 23
  und das tcp-Protokoll verwendet, und da der Domain Name Service
  domain Socket 52 benutzt und als Protokoll sowohl tcp als auch udp.
  Wichtig ist in jedem Fall, das fr jeden Eintrag in /etc/inetd.conf
  ein entsprechender in /etc/services vorhanden ist.

  11.3.3.  Beispiel fr die Datei /etc/protocols

  Die Datei /etc/protocols enthlt eine Tabelle der Protokollnamen und
  ihrer Protokollnummern.  Da es nur recht wenig verwendete Protokolle
  gibt, ist diese Datei recht kurz und einfach:

  ______________________________________________________________________

  #
  # /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.
  ______________________________________________________________________

  11.4.  Name Resolution

  Als Name Resolution bezeichnet man den Proze, einen Rechnernamen
  (z.B. tsx-11.mit.edu) in die entsprechende IP-Adresse in punktierter
  Dezimalschreibweise zu bersetzen, die die Netzwerk-Software bentigt.
  Hierfr gibt es zwei prinzipielle Mglichkeiten, eine einfache und
  eine etwas komplexere.

  11.4.1.  /etc/hosts

  /etc/hosts enthlt eine Liste von IP-Adressen und der Rechnernamen,
  die dieser Adresse entsprechen.  Auf diese Weise knnen die dort
  angegebenen Rechner durch ihre Namen angesprochen werden, anstatt die
  (Nummern)-Adresse zu verwenden.  Die Benutzung eins Nameservers (siehe
  Abschnitt `named') erlaubt, dasselbe automatisch durchzufhren
  (mittels named kann man auch seinen eigenen Rechner als Nameserver
  konfigurieren).  /etc/hosts mu mindestens einen Eintrag fr die
  Adresse 127.0.0.1 mit dem Namen localhost enthalten, wer kein Loopback
  benutzt, mu auerdem die eigene Adresse mit vollem Rechnernamen (also
  Hostname und Domainname, loomer.vpizza.com) hinzufgen.  Ebenfalls
  empfehlenswert ist es, Eintrge fr die verwendeten Gateways,
  Nameserver und evtl. lokale Adressen anzulegen.

  Wenn zum Beispiel der Rechner loomer.vpizza.com die IP-Adresse
  128.253.154.32 besitzt, she ein entsprechender Eintrag in /etc/hosts
  folgendermassen aus:

  ______________________________________________________________________

  # /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
  ______________________________________________________________________

  Diese Datei mu in jedem Fall editiert und den eigenen Bedrfnissen
  angepat werden.  Wer Loopback verwendet, bentigt darin aber
  lediglich einen einzigen Eintrag:  127.0.0.1, wobei sowohl localhost
  als auch der Rechnername eingetragen sind.

  In der zweiten Zeile im obigen Beispiel sind brigens zwei Namen fr
  die Adresse 128.253.154.32 eingetragen: loomer.vpizza.com und nur
  loomer.  Der erste Eintrag ist der volle Name des Rechners, den man
  als "Fully Qualified Domain Name" (FQDN) bezeichnet, der zweite
  Eintrag ist ein alias dafr.  Dies erlaubt es, den Rechner unter
  diesem Namen anzusprechen und z.B. nur rlogin loomer einzugeben,
  anstatt den vollen Namen zu verwenden.  In jedem Fall sollte der FQDN
  der erste Eintrag nach der IP-Adresse sein.

  11.4.2.  Named - brauche ich das ?

  named ist der Nameserver Dmon in vielen Unix-hnlichen
  Betriebssystemen.  Er erlaubt es dem Rechner, die Adressen-Namens-
  Zuordnung nicht nur fr sich selbst sondern auch fr anderer Rechner
  im Netzwerk durchzufhren.  D.h. wenn ein anderer Rechner z.B. die
  Adresse des Rechners goober.norelco.com sucht und sich dieser Name in
  der Datenbasis von named befindet, dann kann der eigene Rechner dem
  anderen die gesuchte IP-Adresse mitteilen.

  Unter frheren Implementationen von TCP/IP unter Linux war es
  erforderlich, einen named-Server zu installieren, wenn man Aliase fr
  Rechnernamen verwenden wollte, selbst wenn es fr den eigenen Rechner
  war.  Das Problem dabei ist, da named relativ kompliziert zu
  konfigurieren ist.  Hierfr gab es ein Hilfsprogramm mit dem Namen
  hostcvt.build.  Dieses konvertierte die Datei /etc/hosts in die vielen
  Einzeldateien, die die Datenbasis fr named darstellen.  Doch selbst
  mit dieser Vereinfachung verursacht named einiges an zustzlicher CPU-
  und Netzwerk-Belastung.

  Aus diesem Grund lohnt sich der Einsatz von named nur in folgenden
  Fllen:

    Es soll ein ganzes Netzwerk von Rechnern zusammengestellt werden,
     und es steht kein externer Nameserver zur Verfgung.

    Der Netzwerk-Administrator mchte den Linux-Rechner als Nameserver
     verwenden.

    Es besteht nur eine langsame SLIP-Verbindung zum Netz.  Dann lohnt
     es sich, einen kleinen Nameserver zu konfigurieren, der nur einen
     Cache anlegt, damit nicht fr jede Adresse eine (langsame) Anfrage
     ber die serielle Leitung gemacht werden mu.  Wer allerdings
     bereits absehen kann, da er nur mit einer kleinen Zahl von
     Rechnern Verbindung aufnehmen will, deren IP-Adressen er kennt, fr
     den empfiehlt sich die bernahme dieser Nummern/Adressen-Paare in
     die Datei /etc/hosts.  Ein Nameserver ist dann nicht ntig.

    Der Nameserver soll zu Lernzwecken oder `just for fun' installiert
     werden.

  Generell kann man zusammenfassen: named wird nicht bentigt.  Er kann
  deshalb in der Datei rc.inet2 auskommentiert werden.  Aliasing von
  Rechnernamen ist unter den aktuellen Implementationen auch ber die
  Datei /etc/hosts mglich, es mssen lediglich die gewnschten
  zustzlichen Namen hinter dem vollen Namen (FQDN) angegeben werden.
  Solange man Zugriff auf einen Nameserver hat (dessen Adresse kann man
  vom Netzwerk-Administrator erfahren) gibt es keinen Grund, selber
  named zu benutzen.

  Wer Loopback verwendet kann trotzdem einen Nameserver mittels named
  konfigurieren, als Adresse fr den Nameserver mu man dann 127.0.0.1
  verwenden.  Allerdings ist das recht bizarr, denn der eigene Rechner
  ist ja der einzige, mit dem man kommunizieren kann, soda eine Anfrage
  an named nie stattfinden wird.

  11.4.3.  /etc/networks

  Die Datei /etc/networks enthlt eine Liste der Namen und Adressen der
  bekannten Netzwerke, also zumindest diejenige des lokalen Netzwerkes.
  route benutzt diese Datei, wenn das Netzwerk mit dem Namen anstatt
  seiner Adresse angegeben wird, um aus diesem Namen eine gltige
  Adresse zu erfahren.

  Es empfiehlt sich, fr jedes Netzwerk, zu dem explizit eine Route
  angelegt werden soll, einen solchen Eintrag in /etc/networks
  anzufgen.  Ist ein Netzwerk nicht in dieser Datei aufgefhrt, so mu
  der Parameter -net mit route-Befehl benutzt werden um anzuzeigen, da
  es sich bei der Adresse um ein Netzwerk und nicht einen einzelnen
  Rechner handelt.

  Das Format der Datei ist ganz hnlich zu demjenigen von /etc/hosts,
  eine typische Datei sieht folgendermassen aus:

  ______________________________________________________________________

  #
  # /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
  ______________________________________________________________________

  11.4.4.  /etc/host.conf

  Das System stellt einige Bibliotheks-Routinen zur Verfgung, die man
  die Resolver Library nennt.  Die Datei /etc/host.conf legt fest, wie
  das System bei der bersetzung von Rechnernamen in gltige IP-Adressen
  vorgeht.  Mindestens zwei Eintrge sollten vorhanden sein:

  ______________________________________________________________________

  order hosts,bind
  multi on
  ______________________________________________________________________

  Diese beiden Zeilen weisen die Bibliotheksroutinen an, die
  Rechneradressen zunchst in der Datei /etc/hosts zu suchen und dann,
  falls die gesuchte Adresse dort nicht gefunden wurde, einen Nameserver
  zu fragen.  Der Eintrag multi erlaubt es dabei, in der Datei
  /etc/hosts mehrere Adresseintrge fr einen bestimmten Rechnernamen zu
  haben.

  Diese Datei entstammt der Implementation der resolv+ bind Library
  unter Linux.  Weitere Informationen dazu enthlt die Online-Hilfe zu
  resolv+(8), allerdings ist sie nicht bei allen Distributionen
  standardmig enthalten.  In diesem Fall kann man sie sich hier
  besorgen:

       sunsite.doc.ic.ac.uk:/computing/comms/tcpip/nameserver/resolv+/resolv+2.1.1.tar.Z

  11.4.5.  /etc/resolv.conf

  /etc/resolv.conf konfiguriert den Name-Resolver des Systems, der die
  Rechnernamen in IP-Adressen bersetzt.  Es gibt zwei unterschiedliche
  Arten von Eintrgen in dieser Datei:  Die Adressen des oder der
  Nameserver(s) sowie die Domain-Adresse.  Wer auf dem lokalen Rechner
  selber named als Nameserver betreibt, der mu als Nameserveradresse
  die Loopbackadresse 127.0.0.1 angeben.

  Der Domain Name besteht aus dem vollen Rechnernamen (FQDN) ohne den
  eigentlichen Namensanteil, also fr das Beispiel von vorhin
  (loomer.vpizza.com) wre der Domain Name vpizza.com.

  Fr einen Rechner mit dem (vollen) Namen goober.norelco.com, dessen
  Nameserver die Adresse 128.253.154.5 besitzt, she die Datei
  /etc/resolv.conf dann folgendermaen aus:

  ______________________________________________________________________

  domain norelco.com
  nameserver 128.253.154.5
  ______________________________________________________________________

  Es knnen auch mehrere Nameserver eingetragen werden, dann mu jede
  Adresse in eine eigene Zeile geschrieben werden, jeweils mit dem
  Schlsselwort nameserver am Zeilenanfang.

  Wer lediglich im Loopbackbetrieb arbeitet braucht wie bereits erwhnt
  keinen Nameserver.

  11.4.6.  Die Festlegung des Rechnernamens - /etc/HOSTNAME

  Nachdem nun alles andere konfiguriert ist fehlt nur noch eine
  Kleinigkeit:  der eigene Rechner mu seinen Namen mitgeteilt bekommen.
  Denn Programme wie sendmail mssen schlielich wissen, fr welchen
  Rechner sie die mail in Empfang nehmen sollen, und sie mssen sich ja
  auch anderen Rechnern gegenber identifizieren.

  Diese Konfiguration des Namens geschieht ber zwei unterschiedliche
  Programme, hostname und domainname.  Leider wird ihre Anwendung
  manchmal durcheinandergebracht.

  Wer eine Version der net-tools lter als 1.1.38 benutzt, kann in seine
  /etc/rc-Datei folgenden Befehl aufnehmen:

       /bin/hostname -S

  hostname wird dann die Datei /etc/HOSTNAME lesen, in der der volle
  Rechnername (FQDN), also Rechnername und Domain-Name, stehen mu.
  Dieser Name wird dann von hostname in Host- und Domain-Name
  aufgespalten und zur Konfiguration verwendet.

  Die Versionen der net-tools-1.1.38 spter sollten in ihrer Datei
  /etc/rc.d/rc.inet1 folgende Zeilen am Ende einfgen:

       /bin/hostname goober.norelco.com

  oder, falls man en Upgrade einer frheren Version durchgefhrt hat
  oder einfach den Rechnernamen lieber in /etc/HOSTNAME stehen hat:

       /bin/hostname -F /etc/HOSTNAME

  Dadurch erreicht man dasselbe Verhalten wie bei der frheren Version.

  Der Befehl /bin/domainname dient nicht der Festlegung des DNS Domain
  Namens, sondern er bestimmt den N.I.S. Domain Namen.  Dieser wird aber
  nur bentigt, wenn auch NIS verwendet werden soll, das spter noch
  kurz beschrieben wird.

  11.5.  Weitere Dateien

  Natrlich gibt es im Verzeichnis noch eine ganze Menge an Dateien, mit
  denen man sich frher oder spter wird befassen mssen.  Hier soll
  aber nur eine Minimalkonfiguration beschrieben werden, um den Rechner
  netztauglich zu machen.  Fr weitere Informationen sei nochmals auf
  den Network Administration Guide von Olaf Kirch verwiesen.  Er steigt
  dort ein, wo dieses HOWTO aufhrt.

  Nachdem nun alles notwendige konfiguriert ist steht einem Reboot des
  neuen Kernels nichts mehr entgegen, um nach Herzenslust im Netz zu
  surfen.  In jedem Fall empfiehlt es sich aber, eine Version des alten
  Kernels aufzubewahren, entweder in Form einer Boot-Diskette oder als
  zustzlicher Menpunkt fr LILO.  Der sicherste Weg ist in jedem Fall
  eine Rettungsdiskette mit einem eigenen lauffhigen System, nur fr
  den Fall, da etwas schiefgeht.  Inzwischen gibt es einige solcher
  Rettungssysteme, z.B. HJLu's `single disk boot disk', die boot/root
  Disketten einer beliebigen Distribution oder ein mit yard selber
  zusammengestelltes System.

  12.  Fortgeschrittene Konfiguration

  Die oben beschriebene Konfiguration hat gezeigt wie eine typische
  Linux-Workstation fr den normalen Endbenutzer-Betrieb konfiguriert
  wird.  Einige werden aber besondere Wnsche und Bedrfnisse haben, die
  eine etwas fortgeschrittenere Konfiguration bentigt.  Einige der
  gngigsten sollen in den kommenden Abschnitten beschrieben werden.

  Die Details zu AX.25, Ottawa PI und den generischen SCC Treibern
  wurden aus diesem Text herausgenommen, ihnen widmet sich ein eigenes
  HOWTO, das HAM-HOWTO (http://sunsite.unc.edu/mdw/HOWTO/HAM-
  HOWTO.html).

  12.1.  PPP - Point to Point Protocol

  Das Point to Point Protocol ist ein modernes und effizientes Protokoll
  das mehrere verschiedene Protokolle zur Verbindung ber serielle
  Leitungen in sich vereint.  Es wird von vielen anstelle von SLIP
  verwendet, dem es erweiterte Funktionalitt, Fehlererkennung und
  Sicherheitsoptionen voraushat.  Es behebt einige SLIP-typische
  Nachteile und kann sowohl ber synchrone wie auch ber asynchrone
  Verbindungen benutzt werden.

  Einer der groen Vorteile von PPP ist die Tatsache, da die
  bermittelung von solchen Daten wie der IP-Adresse im Protokoll
  implementiert ist, und von dieser Mglichkeit machen die meisten
  Server auch Gebrauch.  Dabei sendet der Klient zunchst ein speziell
  formatiertes Datagramm an den Server und bekommt daraufhin die
  gewnschte Information - in diesem Falle z.B. die IP-Adresse - zurck,
  ebenfalls in einer genau festgelegten Form.  Dies erleichtern
  natrlich deutlich den automatischen Aufbau einer dynamischen
  Verbindung gegenber SLIP, bei dem man - auerhalb des Protokolls -
  auf eine `schlaue' Software wie dip zurckgreifen mu, um diese
  Aufgabe zu erfllen.

  Die Autoren der Linux-Portierung von PPP sind Michael Callahan,
  (callahan@maths.ox.ac.uk) und Al Longyear, (longyear@netcom.com),
  Linux-PPP basiert auf Paul Mackerras's free PPP fr BSD-hnliche
  Systeme.  Der Groteil der hier gegebenen Informationen entstammt der
  Dokumentation der PPP-Software.  Sie ist sehr vollstndig und geht
  ber das hier gesagte weit hinaus.

  12.1.1.  Warum PPP statt SLIP ?

  Es gibt mehrere Grnde, warum man PPP anstelle von SLIP verwenden
  sollte, wenn man die Wahl hat:

     Der Internet Provider bietet nur PPP an.
        In diesem Falle hat mein natrlich keine Wahl sondern mu PPP
        verwenden.  Dies ist aber sicherlich kein Nachteil ;-)

     Schlechte/verrauschte serielle Verbindung.
        Im Gegensatz zu SLIP bietet PPP eine Fehlerberprfung fr jedes
        einzelne Datenpaket.  Deshalb mu unter SLIP die berprfung der
        Daten zwischen Sender und Empfnger eines Datenpaketes erfolgen
        whrend unter PPP dies zwischen dem eigenen Rechner und dem PPP-
        Server erfolgt.  Insbesondere wenn zwischen dem PPP/SLIP-Server
        und dem eigentlichen Sender/Empfnger noch weitere Router im
        Netz zwischengeschaltet sind erlaubt PPP dadurch eine schnellere
        Reaktion auf fehlerhafte Datagramme.

     Es werden spezielle Mglichkeiten von PPP bentigt.
        PPP bietet einige Dinge, die mit SLIP nicht mglich sind.  So
        knnen z.B. nicht nur IP-Datagramme ber die serielle Leitung
        bermittelt werden sondern auch andere wie DECNET, oder
        AppleTalk.

  12.1.2.  Bezugsquellen fr die PPP Software

       sunsite.unc.edu:/pub/Linux/system/Networking/serial/ppp-2.1.2d.tar.gz
       sunsite.unc.edu:/pub/Linux/system/Networking/serial/ppp-2.2.0f.tar.gz

  Diese Dateien enthalten Kernel Quelltexte sowie Quellen und das
  ausfhrbare Programm von pppd.  Wer noch einen Kernel 1.2.x verwendet
  bentigt die Version 2.1.2d, die andere Version 2.2.0f ist fr die
  neuen 2.0.x-Kernels gedacht.

  12.1.3.  Installation und Konfiguration der PPP Software

  Das PPP-HOWTO beschreibt ausfhrlich alle Schritte die notwendig sind
  um die PPP-Software richtig zu installieren, den Rechner ber eine
  PPP-Verbindung mit dem Internet zu verbinden oder selber einen PPP-
  Server aufzubauen.  Auch das PPP-HOWTO gibt es in einer deutschen
  bersetzung.

  12.2.  Linux als SLIP-Server

  Es gibt drei verschiedene Mglichkeiten, wie man einen Linux-Rechner
  als SLIP-Server konfigurieren kann und es so anderen ermglicht sich
  ber Modem einzuwhlen und Netzwerk-Dienste in Anspruch zu nehmen.
  Die erste, ber sliplogin, ist wohl am ehesten zu empfehlen, da sie
  sehr einsichtig und leicht zu konfigurieren ist.

  12.2.1.  Slip Server mittels sliplogin

  sliplogin kann anstelle der normalen Login-Shell dazu verwendet
  werden, die Terminalverbindung fr SLIP-Benutzer in den bentigten
  SLIP-Modus umzuschalten.  Dabei kann der Linux-Rechner sowohl als
  statischer Server arbeiten, der den Nutzern, basierend auf ihrer ID,
  jedesmal dieselbe IP-Adresse zuweist, oder auch als dynamischer
  Server, wobei eine gerade freie Adresse aus einem vorgegebenen
  Adressbereich vergeben wird.

  Der SLIP-Benutzer fhrt dann zunchst einen ganz normalen Login-Proze
  durch, d.h. er meldet sich mit seinem Benutzernamen an und gibt sein
  Pawort ein.  Normalerweise wrde jetzt die Login-Shell gestartet, die
  den Benutzer durch ihren Prompt zur Eingabe von Befehlen auffordert.
  Stattdessen wird fr den SLIP-Benutzer nun sliplogin ausgefhrt.
  Dieses Programm sucht in seiner Konfigurationsdatei (/etc/slip.hosts)
  nach einem Eintrag, der dem Login-Namen des Benutzers entspricht.
  Wird dieser gefunden so wird die serielle Verbindung fr 8-bit
  konfiguriert und der Modus durch einen entsprechenden ioctl auf SLIP
  umgesetzt.  Als letzten Schritt der Konfiguration fhrt sliplogin dann
  ein Shellscript aus, welches die SLIP-Schnittstelle mit den
  entsprechenden Werten fr IP-Adresse, Netzwerk-Maske und den
  dazugehrenden Routing-befehlen konfiguriert.  Dieses Script heit
  normalerweise /etc/slip.login,  aber hnlich wie bei getty knnen
  benutzerspezifische Scripts mit dem Namen /etc/slip.login.loginname
  angelegt werden, um fr jeden Benutzer ein eigens Konfigurationsscript
  zu haben.  Dieses wird dann anstelle des Standardscripts ausgefhrt.

  Damit sliplogin richtig arbeitet mssen drei oder vier Dateien die
  richtigen Eintrge enthalten.  Dies sind:

    /etc/passwd, zur Verwaltung der Accounts.

    /etc/slip.hosts, hierin stehen Informationen fr jeden
     registrierten SLIP-Benutzer.

    /etc/slip.login, Konfiguration des Routing fr jeden Benutzer.

    /etc/slip.tty, diese Datei wird bentigt, wenn der Linux-Rechner
     als dynamischer SLIP-Server arbeiten soll, sie enthlt eine Liste
     der mglichen zu vergebenden Adressen.

    /etc/slip.logout, dies sind die Befehle, die zur Beendigung einer
     SLIP-Verbindung auf der Server-Seite notwendig sind, wenn der
     Benutzer die Verbindung beendet.

  12.2.1.1.  Woher bekomme ich sliplogin ?

  Die aktuelle Version ist

       sunsite.unc.edu:/pub/Linux/system/Network/serial/sliplogin-2.0.1.tar.gz

  Die TAR-Datei enthlt die Quellen, vorkompilierte Binrdateien und die
  Online-Hilfetexte fr man.

  Um sicherzustellen, da nur autorisierte Benutzer das Programm
  sliplogin ausfhren knnen empfiehlt es sich, dafr eine eigene Gruppe
  anzulegen, indem in der Datei /etc/group ein entsprechender Eintrag
  eingefgt wird, der ungefhr so aussehen sollte:

        ..
       SLIP::13:radio,fred
        ..

  Bei der Installation des sliplogin Paketes wird das Makefile dann
  automatisch die Gruppenzugehrigkeit von sliplogin auf SLIP setzen und
  die Permissions so einstellen, da nur Benutzer dieses Programm
  starten knnen, die der Gruppe SLIP zugehren, im obigen Beispiel als
  die Benutzer fred und radio.

  Die Installation (Programme in /sbin, Online-Hilfetexte in Sektion 8)
  ist Standard:

  % cd /usr/src
  % gzip -dc .../sliplogin-2.0.tar.gz | tar xvf -
     <..editieren des Makefile je nachdem ob Shadow
       Passwoerter verwendet werden oder nicht...>
  % cd sliplogin
  % make install

  Damit werden die mitgelieferten Binrdateien installiert.  Wer sie
  lieber selbst kompiliert, mu vor dem make install noch ein make clean
  ausfhren.

  Weitere Informationen enthlt die README-Datei.

  12.2.1.2.  /etc/passwd fr einen SLIP-Server

  Fr die Login-Namen der SLIP-Benutzer, die in /etc/passwd festgelegt
  werden, gibt es eine Konvention, die meist eingehalten wird: Der Name
  setzt sich zusammen aus dem Namen des einwhlenden Rechners, dem ein
  groes `S' vorangestellt wird.  Der Eintrag fr einen Rechner mit dem
  Namen radio she dann also folgendermaen aus:

       Sradio:FvKurok73:1427:1:radio SLIP login:/tmp:/sbin/sliplogin

  Hinweis: Als Heimatverzeichnis fr diesen Benutzer ist /tmp
  eingetragen, er hat also kein eigenes Verzeichnis.  Dieses ist aber
  fr SLIP-Nutzer auch nicht ntig, da anstelle der normalen Login-Shell
  sliplogin ausgefhrt wird und es so nie zu einem Dialogbetrieb kommen
  kann.

  12.2.1.3.  /etc/slip.hosts

  Wenn sliplogin bei einem erfolgreichen Einwhlversuch gestartet wurde
  so durchsucht es die Datei /etc/slip.hosts nach einem Eintrag der dem
  Login-Namen des Anrufers entspricht, um die Einzelheiten der
  Konfiguration fr diesen Rechner zu erfahren.  Hier knnen also fr
  statische Accounts IP-Adresse und Netz-Maske festgelegt werden, sowie
  einige weitere Eigenschaften der SLIP-Verbindung.  Das folgende
  Beispiel zeigt zwei typische Eintrge in der Datei /etc/slip.hosts:

       #
       Sradio    44.136.8.99    44.136.8.100   0xffffff00   normal
       Salbert   44.136.8.99    DYNAMIC        0xffffff00   compressed
       #

  Es treten der Reihe nach folgende Eintrge auf:

  1. Der Login-Name des Anrufers.

  2. Die IP-Adresse des Servers, also die eigene Adresse.

  3. Die IP-Adresse, die dem einwhlenden Rechner zugewiesen wird.
     Enthlt dieses Feld den Eintrag DYNAMIC dann wird die IP-Adresse
     entsprechend den Informationen in der Datei /etc/slip.tty vergeben,
     dies wird spter behandelt. Wichtig: Das funktioniert erst ab
     Version 1.3 von sliplogin!

  4. Die zuzuweisende Netz-Maske in hexadezimaler Schreibweise, fr ein
     Klasse-C Netzwerk also z.B. 0xffffff00=255.255.255.0.

  5. Optionale Parameter, z.B. um Kompression ein- oder auszuschalten.

  Hinweis: Im 2. und 3. Feld knnen sowohl IP-Adressen in der blichen
  punktierten Dezimalschreibweise (wie im Beispiel) als auch die
  Rechnernamen verwendet werden.  Voraussetzung ist dann aber, da diese
  Namen auf dem eigenen Rechner auch aufgelst werden knnen (d.h.
  entsprechende Eintrge in /etc/hosts vorhanden sind), da dem anderen
  Rechner sonst keine gltige IP-Adresse zugewiesen werden kann und der
  Login-Versuch fehlschlgt.  Zur richtigen Konfiguration dieser
  Namensauflsung siehe das Kapitel `Name Resolution'.

  Hufig verwendete Eintrge fr die optionalen Einstellungen sind:

     normal
        verwendet das `normale', unkomprimierte SLIP.

     compressed
        schaltet die van Jacobsen Header-Komprimierung ein (cSLIP).

  Diese beiden Eintrge schlieen sich gegenseitig aus, es darf also nur
  eine davon eingetragen werden.  Nheres dazu steht in den
  entsprechenden Abschnitten der man-Online-Hilfe.

  12.2.1.4.  /etc/slip.login

  Wenn sliplogin in der Datei /etc/slip.hosts einen passenden Eintrag
  fr den einwhlenden Rechner gefunden hat versucht es als Nchstes,
  die Datei /etc/slip.login auszufhren, um die endgltige Konfiguration
  des SLIP Device mit IP-Adresse und Netz-Maske durchzufhren.  Das
  sliplogin-Paket enthlt ein Beispiel fr diese Datei:

  ______________________________________________________________________

  #!/bin/sh -
  #
  #       @(#)slip.login  5.1 (Berkeley) 7/1/90
  #
  # Generische Login-Datei fuer eine SLIP-Verbindung.  Sie wird von
  # sliplogin mit folgenden Parametern aufgerufen:
  #     $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
  #
  ______________________________________________________________________

  Dieses Script macht also nichts anderes als die ifconfig und route
  Befehle mit den bergebenen Parametern auszufhren um das Device
  richtig zu konfigurieren und eine Route fr den neu hinzugekommenen
  Rechner ber das SLIP-Device anzulegen.
  Auerdem wird noch Proxy ARP verwendet um den anderen Rechnern im
  lokalen Ethernet des Servers mitzuteilen da der neue Rechner unter
  derselben Hardware-Adresse wie der Server erreicht werden kann.
  Hierzu mu <hw_addr> im obigen Beispiel durch die Hardware-Adresse der
  Ethernet-Karte des Servers ersetzt werden. Diese kann durch ein
  ifconfig eth0 angezeigt werden.

  Wer keine Ethernet-Karte in seinem Rechner hat sollte die gesamte
  Zeile auskommentieren.

  12.2.1.5.  /etc/slip.logout

  Nach Beendigung der Verbindung mu die serielle Schnittstelle wieder
  in ihren Normalzustand zurckgesetzt werden, damit der nchste Anrufer
  wieder einen definierten Zustand vorfindet und ein Login mglich ist.
  Dies wird in der Script-Datei /etc/slip.logout durchgefhrt:

  ______________________________________________________________________

  #!/bin/sh -
  #
  #               slip.logout
  #
  /sbin/ifconfig $1 down
  /sbin/route del $5
  arp -d $5
  exit 0
  #
  ______________________________________________________________________

  Es wird lediglich das SLIP-Interface als `down' konfiguriert und die
  angelegte statische Route wieder aus der Routing-Tabelle gelscht.
  Besitzer von Ethernet-Karten mssen weiterhin die Proxy ARPs fr
  diesen Rechner wieder lschen, dies geschieht mit dem arp Befehl.  Wer
  keine Ethernet-Karte hat sollte diese Zeile wiederum auskommentieren.

  12.2.1.6.  /etc/slip.tty

  Soll eine dynamische Adressvergabe fr SLIP-Benutzer stattfinden
  (angezeigt durch das Schlsselwort DYNAMIC in der Adress-Spalte der
  Datei /etc/slip.hosts) so mu in der Datei /etc/slip.tty eine Liste
  aufgefhrt sein, welchem seriellen Port welche IP-Adresse zugeordnet
  werden soll.  Wer ausschlielich statische Adressen vergeben will
  bentigt diese Datei nicht.

  In /etc/slip.tty sind diejenigen seriellen Devices aufgefhrt, ber
  die ein SLIP-Login mglich ist, sowie die IP-Adresse, die einem
  Anrufer, der sich ber diese Schnittstelle einwhlt, zugewiesen werden
  soll.  Das Format dieser Datei ist wie folgt:

  ______________________________________________________________________

  # slip.tty    tty -> IP Adressenzuweisung fuer dynamisches SLIP
  # Format: /dev/tty?? xxx.xxx.xxx.xxx
  #
  /dev/ttyS0      192.168.0.100
  /dev/ttyS1      192.168.0.101
  #
  ______________________________________________________________________

  Diese Tabelle legt also fest da ein Anrufer, der sich ber die
  Schnittstelle /dev/ttyS0 einwhlt und in der Datei /etc/slip.hosts
  einen DYNAMIC Eintrag hat, die Adresse 192.168.0.100 zugewiesen
  bekommt.

  Es mu also nur eine Adresse je Schnittstelle angegeben werden,
  unabhngig von der Anzahl der Benutzer des dynamischen SLIP.  Dadurch
  kann die Anzahl der verwendeten Adressen gering gehalten werden.

  12.2.2.  Ein SLIP-Server unter dip

  Einige der Informationen aus diesem Kapitel stammen aus der man
  Online-Hilfe zu dip, in der ebenfalls beschrieben wird, wie mittels
  dip ein Linux SLIP-Server konfiguriert werden kann.  Ausgangspunkt ist
  die Version dip337o-uri.tgz, wer eine andere Version verwendet sollte
  sicherheitshalber auch in der originalen Anleitung nachlesen.

  dip besitzt auch einen speziellen Empfangsmodus, bei dem es
  automatisch anhand des Benutzernamens desjenigen, der dip gestartet
  hat, die serielle Leitung als SLIP-Verbindung konfiguriert, und zwar
  basierend auf den Informationen in der Datei /etc/diphosts.  Dieser
  spezielle Modus von dip wird aktiviert, indem man es unter dem Namen
  diplogin startet.  Zu diesem Zweck legt man einen symbolischen Link
  an:

       % ln -sf /usr/sbin/dip /usr/sbin/diplogin

  Um nun mit dip einen SLIP-Server zu konfigurieren mssen auch wieder
  spezielle Accounts angelegt werden, wobei diplogin als Login-Shell
  verwendet wird.  Dies geschieht durch entsprechende Eintrge in der
  Datei /etc/passwd.  Als Benutzernamen fr SLIP-Accounts sollte wieder
  die bliche Form `S'+Rechnername verwendet werden, soda ein typischer
  Eintrag so aussehen knnte:

       Sfredm:ij/SMxiTlGVCo:1004:10:Fred:/tmp:/usr/sbin/diplogin
       ^^         ^^        ^^  ^^   ^^   ^^   ^^
       |          |         |   |    |    |    \__ diplogin als Login Shell
       |          |         |   |    |    \_______ Home directory
       |          |         |   |    \____________ Voller Benutzername
       |          |         |   \_________________ User Group ID
       |          |         \_____________________ User ID
       |          \_______________________________ Verschluesseltes Passwort
       \__________________________________________ SLIP User Login Name

  Wenn sich nun ein Benutzer mit dem Namen Sfredm einlogged und das
  korrekte Pawort eingibt, wird der login(1)-Proze den Benutzer als
  rechtmig anerkennen und die die Login-Shell, also das Programm
  diplogin, starten.  Dadurch da dip ber dem Umweg eines symbolischen
  Links unter dem Namen diplogin gestartet wird wei das Programm
  automatisch, da es als Login-Shell aufgerufen wurde.  Als erstes ruft
  es dann die Unix-Funktion getuid() auf um die User-ID (UID) des
  Aufrufenden herauszufinden.  Danach durchsucht es die Datei
  /etc/diphosts nach dem ersten Eintrag, der entweder dieser UID oder
  aber dem Namen des tty entspricht, ber das die Verbindung luft.
  Entsprechend den darin gegebenen Parametern wird dann die Verbindung
  konfiguriert.

  Einfach anhand der Entscheidung, ob fr einen Benutzer ein Eintrag in
  diphosts angelegt wird, oder ob die Standard-Behandlung anhand der
  ttys zum tragen kommt, kann ein gemischter Server aus statischen und
  dynamischen Adressen zusammengestellt werden.

  dip fhrt weiterhin automatisch einen Proxy-ARP Eintrag durch, soda
  man sich darum nicht selbst kmmern mu.

  12.2.2.1.  /etc/diphosts

  In der Datei /etc/diphosts sind die Konfigurationsparameter fr die
  Klienten-Rechner zusammengestellt, dip verwendet sie, um die SLIP-
  Devices richtig zu konfigurieren. Das generelle Format dieser Datei
  sieht so aus:

        ..
       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
        ..

  Die Felder bedeuten im Einzelnen:

  1. Login Name: Entsprechend dem Ergebnis von getpwuid(getuid()) oder
     tty Name.

  2. unbenutzt: Zur Kompatibilitt mit passwd

  3. Remote Adresse: IP Adress des einwhlenden Rechners, entweder
     numerisch oder als Name.

  4. Lokale Adresse: IP Adress des eigenen Rechners, ebenfalls numerisch
     oder als Name.

  5. Netz-Maske: in punktierter Dezimalschreibweise.

  6. Kommentar: Beliebig.

  7. Protokoll: SLIP, cSLIP usw.

  8. MTU: Dezimaler Wert.

  Fr alle diejenigen Benutzer, fr die eine statische Adresse verwendet
  werden soll, mu ein solcher Eintrag in /etc/diphosts angefgt werden.
  Erlaubte SLIP-Benutzer, die ihre IP-Adresse dynamisch zugewiesen
  bekommen sollen werden hier nicht eingetragen, dadurch wird dann
  automatisch der Eintrag des verwendeten tty benutzt.  Aus diesem Grund
  sollte man fr jedes tty, ber das sich Benutzer in das System
  einwhlen knnen, ein solcher Eintrag angefgt werden um
  sicherzustellen, da immer eine adquate Konfiguration durchgefhrt
  werden kann.

  Ein Benutzer der sich in ein so konfiguriertes System einwhlt sollte
  zunchst einen ganz normalen Login-Promt sehen.  Er mu dann seinen
  SLIP-Benutzernamen sowie sein Pawort eingeben.  Wenn alles glatt geht
  bekommt er keine weitere Meldung und mu nun auf seiner Seite nur noch
  die Verbindung in den SLIP-Modus schalten, und die Verbindung steht.

  12.2.3.  SLIP Server mit dem dSLIP Paket

  Matt Dillon (dillon@apollo.west.oic.com) hat ein Paket von kleinen
  Programmen und Shell-Scripts geschrieben, mit denen SLIP sowohl im
  Dial-in wie im Dial-out betrieben werden kann.  Allerdings mu die
  Shell tcsh installiert sein, da mindestens eines der Scripts auf deren
  Syntax angewiesen ist.  Jedoch ist dies keine groe Einschrnkung, da
  die tcsh bei den meisten Distributionen mitgeliefert wird.  Auerdem
  gehrt zu Matts Paket auch eine ausfhrbare Kopie des Programmes
  expect, das ebenfalls an einigen Stellen bentigt wird.  Es ist von
  Vorteil wenn man sich mit expect bereits auskennt, da andernfalls bei
  der Konfiguration leicht Fehler gemacht werden knnen.  Aus diesem
  Grunde empfiehlt sich das Paket mehr fr die bereits mit Unix
  vertrauten, man sollte sich aber trotzdem nicht davon abhalten lassen,
  sich das Programm einmal anzusehen, zumal Matt eine sehr gute
  Installationsanleitung im README gibt.

  Das dSLIP Paket bekommt man von:

       apollo.west.oic.com:/pub/linux/dillon_src/dSLIP203.tgz

  oder

       sunsite.unc.edu:/pub/Linux/system/Network/serial/dSLIP203.tgz

  Wichtig ist, das README aufmerksam zu lesen und vor allem die dort
  angegebenen Eintrge in den Dateien /etc/passwd und /etc/group
  einzufgen, bevor ein make install ausgefhrt wird.

  12.3.  Der Automounter Dmon - AMD

  Dieser Abschnitt basiert auf einem Text, den Mitch DSouza
  zusammengestellt hat.

  12.3.1.  Was ist ein Automounter, warum sollte ich einen verwenden ?

  Ein Automounter stellt ein bliches Mittel dar um ein Dateisystem
  (meist ber NFS) nur bei Bedarf zu mounten (der Fachausdruck hierfr
  ist on demand).  Dadurch wird die Belastung sowohl des Servers wie
  auch des Klienten verringert, auerdem bietet dieses Vorgehen ein
  grtes Ma an Flexibilitt, auch dann, wenn es sich nicht um NFS-
  Dateisysteme handelt.  Er bietet sogar ein Sicherheitsmechanismus an
  durch den ein Dateisystem von einem anderen Server angefordert und
  gemounted werden kann, wenn der ursprngliche Server nicht erreicht
  werden kann.  Durch eine besonders ntzliche Art des mounts, einen
  sogenannten union mount, knnen sogar die Inhalte unterschiedlicher
  Verzeichnisse in einem einzelnen Verzeichnis zusammengefat werden.
  Um diese hochentwickelten Optionen auszunutzen ist es aber auf jeden
  Fall ntig, die Dokumentationen sehr ausfhrlich und genau zu lesen.

  Auf einige Dinge mu besonders geachtet werden:

    Die Maps von amd sind nicht kompatibel zu denen von Sun, diese
     wiederum inkompatibel zu HP usw.  Der Vorteil ist aber, da amd ein
     frei erhltliches Programm ist, welches auf den angegebenen und
     vielen weiteren Systemen installiert werden kann.  Dann fallen die
     Kompatibilittsprobleme weg, und maps knnen auch in heterogenen
     Systemen gemeinsam benutzt werden.  Es gibt inzwischen schon viele
     Beispiele von solchen gemischten Linux/Dec/NeXt/Sun usw.
     Netzwerken.

    Es gibt im Verzeichnis contrib ein perl Script mit dem Namen
     automount2amd.pl, mit dem die vom Sun automounter verwendeten Maps
     in das amd-Format konvertiert werden knnen.

    Der portmapper mu unbedingt vor amd gestartet werden.

    Fr UFS Mounts gibt es kein Timeout.

    Ausschlielich fr Linux wurden UFS Mounts derart erweitert, da
     sie mit allen Arten von Dateisystemen (also minix, ext, ext2,
     xiafs...) umgehen knnen, wobei minix die Standardeinstellung ist.
     Diese undokumentierte Besonderheit kann ber die opts-Option
     angesprochen werden:

        ..., opts:=type=msdos,conv=auto

    Nach Mglichkeit nie einen existierenden Verzeichnisbaum
     `bermounten', und wenn, dann nur mit der direct Option.

    Bei Problemen immer die vollstndige Mitprotokollierung von amd mit
     der Option -x all aktivieren.  Ebenfalls hilfreich ist oft auch die
     Information die der Befehl

       % amq -ms

  liefert.  Dadurch werden alle auftretenden Probleme sofort gemeldet.

    Das getopt() von GNU ist manchmal etwas zu schlau.
     Sicherheitshalber sollte deshalb `--' zwischen den amd-Optionen und
     den Parametern eingefgt werden, also z.B. so:

       % /etc/amd -x all -l syslog -a /amd -- /net /etc/amd.net

  12.3.2.  Woher bekomme ich AMD ?

       sunsite.unc.edu:/pub/Linux/system/Misc/mount/amd920824upl67.tar.gz

  Das Paket enthlt sowohl Quelltexte und die vollstndige Dokumentation
  im texinfo-Format als auch bereits kompilierte Binrdateien, die
  sofort installiert werden knnen.

  12.3.3.  Beispiel fr eine AMD Konfiguration

  Der Automounter wird nicht ber die Datei /etc/fstab konfiguriert, die
  in einem gewhnlichen System die Informationen ber die Dateisysteme
  enthlt.  Vielmehr wird er ber die Kommandozeile gesteuert.

  Nehmen wir folgendes Beispiel: In der Datei /etc/fstab sind zwei nfs
  Dateisysteme eingetragen,

       server-1:/export/disk  /nfs/server-1  nfs  defaults
       server-2:/export/disk  /nfs/server-2  nfs  defaults

  es werden also immer die Verzeichnisse /nfs/server-1 und /nfs/server-2
  von den beiden Servern server-1 und server-2 via nfs gemountet.
  Genausogut knnte man diese beiden Eintrge auskommentieren und amd
  mit dem folgenden Befehl starten:

       /etc/amd -x all -l syslog -a /amd -- /nfs /etc/amd.server
       |      | |    | |       | |     |  | |  | |             |
       |      | |    | |       | |     |  | |  | |             |
       `------' `----' `-------' `-----' -' `--' `-------------'
       |        |      |         |      |   |    |
       (1)      (2)    (3)       (4)    (5) (6)  (7)

  Die Einzelnen Komponenten bedeuten dabei

  1. Den vollen Pfadnamen des ausfhrbaren Programmes amd.  Befindet
     sich amd in einem Verzeichnis, das in der Variable $PATH enthalten
     ist gengt auch einfach nur amd.

  2. -x all' schaltet die volle Protokollierung ein, um Fehler leichter
     verfolgen zu knnen.

  3. -l syslog bewirkt, das die Protokollierung ber den syslog Dmon
     erfolgt.  Dadurch kann man getrennt entscheiden, was mit diesen
     Informationen geschieht, ob sie in eine freie Konsole geschrieben
     werden oder dauerhaft in einer Datei gespeichert werden.  Anstelle
     von syslog kann auch ein Dateiname angegeben werden, dort werden
     dann alle Meldungen abgelegt.

  4. -a /amd weist amd an, das Verzeichnis /amd als temporren Platz fr
     die automounts zu verwenden.  Es wird von amd automatisch angelegt
     und sollte vor dem Start von amd in den /etc/rc.d/rc* Scripts
     gelscht werden.

  5. -- dient wieder dazu, der getopt() Funktion das Ende der
     Kommandozeilenoptionen mitzuteilen.  Dies ist insbesondere ntig
     wenn man die Option type:= verwendet, da getopt() diese falsch
     interpretieren wrde.

  6. /nfs ist der wahre Mount Punkt.  Auch dieser wird automatisch
     angelegt und sollte normalerweise keine Unterverzeichnisse
     aufweisen, wenn nicht die Option type:=direct verwendet wird.

  7. Die Map fr amd ist eine Datei, hier /etc/amd.server, die - fr
     dieses Beispiel - folgende Zeilen enthlt:

     ___________________________________________________________________

     # /etc/amd.server
     /defaults    opts:=rw;type:=nfs
     server-1     rhost:=server-1;rfs:=/export/disk
     server-2     rhost:=server-2;rfs:=/export/disk
     ___________________________________________________________________

  Ist der amd Proze gestartet und luft zufriedenstellend, kann der
  Zustand der Mount-Tabelle abgefragt werden:

       % amq -ms

  Ein einfaches

       % ls /nfs

  wird keine Dateien anzeigen.  Jedoch wird ein

       % ls /nfs/server-1

  bewirken, da automatisch das gesuchte Verzeichnis von dem Rechner
  `server-1' ber nfs gemountet wird, soda dessen Inhalt angezeigt
  wird!  Nachdem eine einstellbare Zeit vorber ist, innerhalb der nicht
  auf das Verzeichnis zugegriffen wurde, wird das Dateisystem
  automatisch wieder ent-mounted.

  12.4.  Linux als Router

  Linux als Router in einem Netzwerk zu verwenden ist problemlos.  Fr
  gewhnlich verwendet man zu diesem Zweck gated oder einen hnlichen
  Router-Dmon, fr kleinere Netzwerke knnen aber auch einfache
  statische Routes verwendet werden.  Auf jeden Fall ist es aber
  wichtig, die folgende Frage bei der Konfiguration des Kernels zu
  bejahen:

       IP forwarding/gatewaying (CONFIG_IP_FORWARD) [y] y

  Wer selber ein Netzwerk zu betreiben gedenkt sollte sich in jedem Fall
  den Network Administrators Guide von Olaf Kirch zulegen, dort sind
  auch zum Thema Routing alle notwendigen Details fachkundig
  zusammengefat.

  12.5.  NIS - Das Sun Network Information System

  Zu diesem Thema gibt es ein eigenes HOWTO, das NIS-HOWTO
  (http://sunsite.unc.edu/mdw/HOWTO/NIS-HOWTO.html).  Wer beabsichtigt,
  NIS auf seinem Rechner zu verwenden wird darin ber alles Notwendige
  informiert.

  13.  Experimentelle Module

  Eine ganze Reihe von Programmierern entwickeln dauernd neue
  Erweiterungen und Module fr den Netzwerk-Code von Linux.  Viele sind
  bereits in einem sehr fortgeschrittenen Stadium, und einige sind mit
  der 2.0 Version auch in den Standard-Kernel aufgenommen worden.  Fr
  viele dieser Module gibt es inzwischen eigene HOWTOs:

  13.1.  On-Demand SLIP/PPP

  Eric Schenk (schenk@cs.toronto.edu) hat einen Dmon geschrieben, der
  sowohl mit SLIP als auch mit PPP arbeitet und eine solche serielle
  Verbindung aufbaut, sobald ein Netzwerkdienst angefordert wird.  Er
  setzt dabei voraus, da ein SLIP-Device konfiguriert ist, mit dem der
  Dmon ber ein pty kommuniziert.  Solange die Verbindung nicht
  aufgebaut ist werden alle Datagramme ber dieses Device geroutet.  Der
  Dmon registriert diese und fhrt ein Script aus, welches die
  Netzwerkverbindung aufbaut und sendet dann die zwischengespeicherten
  Datagramme ber diese Schnittstelle weiter.

  Bekommen kann man diese Software von

       sunsite.unc.edu:/pub/Linux/system/Network/serial/diald-0.14.tar.gz

  Wichtig: Der Kernel mu unbedingt mit SLIP-Untersttzung kompiliert
  werden, auch wenn man PPP verwenden will.  Installation und Betrieb
  werden von der mitgelieferten Dokumentation beschrieben.

  13.2.  System-V Streams

  Das LiS (Linux Streams) Projekt wurde ins Leben gerufen, um unter
  Linux eine Implementation der System-V Streams zu entwickeln.  Sie
  haben eine Seite im World Wide Web: die Linux Streams Web Page
  (http://www.uc3m.es/~LiS/).  Dort kann man sich ber den derzeitigen
  Stand der Entwicklung informieren und erfhrt auch, wo es die Software
  gibt.

  13.3.  Untersttzung von ATM (Asynchronous Transfer Mode)

  Auch hierzu gibt es eine Seite im World Wide Web, die von Werner
  Almesberger zusammengestellt wurde: Linux-ATM
  (http://lrcwww.epfl.ch/linux-atm/).  Es gibt experimentelle Software
  im Alpha-Stadium, um reine ATM-Verbindungen sowie IP ber ATM zu
  ermglichen, man kann sie auch ber die angegebene Adresse bekommen,
  auerdem jede Menge Information zu ATM im Allgemeinen.

  Es gibt auch eine Mailing Liste zu diesem Thema, an der man teilnehmen
  kann, wenn man eine mail mit dem Inhalt subscribe linux-atm an die
  Adresse majordomo@vger.rutgers.edu sendet.

  14.  Diagnose-Hilfsmittel: Wenn etwas nicht funktioniert

  In diesem Abschnitt werden einige der Standard-Diagnoseprogramme fr
  das Linux Netzwerk beschrieben.  Man kann sie einsetzen um die Ursache
  von Strungen nher einzukreisen, oder einfach nur damit spielen, um
  mehr ber die Interna eines TCP/IP-Netzwerkes zu lernen.  Einige der
  vorgestellten Programme sind weit mchtiger als hier beschrieben, sie
  in ihrem vollen Leistungsumfang zu erlutern ist aber weit auerhalb
  der Intention dieser Einfhrung.  Die gegebene Information sollte aber
  ausreichen um diese Programme fr einfache Zwecke zu benutzen.

  14.1.  Ping - ist da wer ?

  ping ist Teil der NetKit-B Distribution.  Das Programm sendet ein
  spezielles Datagramm ber das Netzwerk an einen anderen Rechner.  Wenn
  dieser eingeschaltet ist und es empfngt sendet er es wieder zurck
  und man weit, da Rechner und Netzwerk in Ordnung sind.  In der
  einfachsten Form sieht das so aus:

       % 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

  ping sucht zunchst die richtige IP-Adresse zu dem angegebene
  Rechnernamen heraus (Voraussetzung ist natrlich, da /etc/hosts und
  der Nameserver richtig konfiguriert sind) und sendet dann in
  regelmigen Abstnden ein bestimmtes Datagramm an diese Adresse.  Fr
  jeden dieser icmp echo requests wird der andere Rechner dann ein icmp
  echo reply als Antwort zurcksenden.  Jede der Zeilen 64 bytes from
  ... stellt eine solche empfangene Rckantwort dar.  In jeder Zeile ist
  auch die Adresse des Absenders dieses Paketes angegeben, die Nummer
  des echo requests, auf den mit diesem Paket geantwortet wurde, die
  time to live (Lebensdauer) sowie die round trip time, das ist die Zeit
  in Millisekunden zwischen Absendung des request und Empfang des
  entsprechenden echo reply.  Damit ist dies in gewissen Grenzen ein Ma
  fr die Geschwindigkeit des Netzwerkes.

  ping wrde endlos weiter seine Pakete senden, deshalb mu es
  abgebrochen werden. Dies geschieht durch gleichzeitiges Drcken der
  Tasten Control (Strg) und C.  Danach gibt ping noch eine Statistik der
  gesendeten Pakete aus, dies sind die letzten beiden Zeilen: Die Anzahl
  der gesendeten, empfangenen sowie unbeantworteten Pakete sowie
  krzeste, lngste und mittlere Antwortzeit.  Eine hohe Verlustrate an
  Paketen deutet auf Probleme mit der Verbindung hin, diese knnen durch
  schlechte Verbindungen, berlastete Router oder Kollisionen im lokalen
  Ethernet verursacht werden.  Man kann mit ping die schadhafte Stelle
  lokalisieren, indem man nacheinander alle Knotenpunkte der Verbindung
  an-pingt und nachsieht, ab welchem Punkt die Verlustrate stark
  ansteigt.

  14.2.  Traceroute - Wo gehts lang ?

  Mit traceroute, einem Teil der NetKit-A Distribution, kann man den
  Weg, den die Datagramme bei einer Verbindung zwischen zwei Rechnern
  zurcklegen, testen und anzeigen.  Wie auch ping verwendet traceroute
  dazu das icmp Protokoll.  Es verwendet jedoch einen Trick, um von
  jeder durchlaufenen Knotenstelle eine Rckmeldung zu bekommen, und das
  geht so:  Das Feld time to live eines icmp-Datagramms dient eigentlich
  dazu zu verhindern, das das Datenpaket ewig im Netz herumgeschickt
  wird, z.B. wenn es in eine Routing-Endlosschleife gert.  Zu diesem
  Zweck verringert jeder Router, der das Paket weiterleitet, den Zhler
  in diesem Datenfeld um eins.  Wird dabei der Wert Null erreicht, so
  wird der Router, bei dem dies geschehen ist, eine icmp time to live
  expired Meldung an den ursprnglichen Absender des Datagramms senden
  um ihm mitzuteilen da das Datagramm `abgelaufen' ist.  traceroute
  sendet nun nacheinander Datagramme ab, deren time to live, beginnend
  bei eins, jeweils um eins erhht wird.  Indem es nun die eingehenden
  icmp time to live expired Meldungen auswertet kann es genau den Weg,
  den die Datagramme nehmen, verfolgen, bis der wirkliche Zielrechner
  erreicht ist.  Das sieht dann so aus:

       % 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

  Die erste Spalte gibt die `Entfernung' an, also der wievielte Knoten
  (Hop) in der Verbindung der bezeichnete Rechner ist.  Dies entspricht
  dem Eintrag im time to live Feld des Datagramms, das vom angegebenen
  Rechner als expired gemeldet wurde.  Der nchste Eintrag ist der
  Rechnername (falls dieser anhand der IP-Adresse herausgefunden werden
  kann) und dessen IP-Adresse.  Dann kommen drei Eintrge mit den
  Antwortzeiten fr drei aufeinanderfolgende Datagramme an diesen
  Rechner.  Der erste Punkt in der Verbindung ist also der Rechner gw.
  Seine Antwortzeiten sind sehr kurz, die Verbindung ist ein lokales
  Ethernet.  Der nchste Router ist gw.uts, von dort kommen die
  Datagramme sehr viel langsamer zurck als von gw.  Der Grund ist hier
  eine sehr langsame Verbindung ber eine Funkstrecke.  Der nchste
  Knoten ist bereits der gesuchte Rechner, minnie.vk1xwt.  Auch hier
  kommen die Antworten nur sehr langsam.  Dies liegt aber daran, da die
  Antwortzeit jedes Rechners natrlich die Summe der Verbindungszeiten
  aller dazwischenliegenden Teilstrecken ist, in diesem Falle also vom
  eigenen Rechner zu gw, von dort zu gw.uts und schlielich von gw.uts
  zu minnie.vk1xwt.  Bercksichtigt man diese Aufsummierung der Zeiten
  sieht man, da die letzte Verbindung von gw.uts zu minnie.vk1xwt
  ebenfalls sehr schnell ist, diese beiden Rechner hngen also
  vermutlich auch an einem lokalen, schnellen Netzwerk.

  Taucht bei einem traceroute Aufruf hinter den Zeiten ein !N auf so
  weist dies auf ein nicht erreichbares Netzwerk hin.  Es ist ein
  Zeichen dafr, da ein Router nicht wute, wohin er das Datagramm
  weiterleiten soll.  Er sendet dann ein network unreachable Datagramm
  an den Absender zurck.  Meist deutet es darauf hin, da eine
  Netzverbindung (zeitweise) zusammengebrochen ist.  Anhand der letzten
  angegebenen Adresse vor dieser Fehlermeldung kann man die defekte
  Stelle lokalisieren.

  Ebenfalls auftauchen kann ein !H als Hinweis darauf, da ein Rechner
  (Host) nicht erreicht werden konnte.  Dies bedeutet i.A. da man bis
  in das lokale Netzwerk des Zielrechners gelangt ist, dieser sich aber
  nicht meldet weil er z.B. abgeschaltet ist.

  14.3.  Tcpdump - Was tut sich im Netz ?

  Adam Caldwell (acaldwel@103mort2.cs.ohiou.edu) hat das Hilfprogramm
  tcpdump fr Linux portiert.  tcpdump kann die gesamte Aktivitt auf
  dem Netzwerk berwachen indem es smtlich Datagramme auf dem Weg in
  den eigen Rechner hinein oder heraus abhrt.  Damit lassen sich vom
  erfahrenen Administrator auch schwer zu identifizierende
  Netzwerkprobleme lokalisieren.

  Quellen und ausfhrbare Programme bekommt man von

       ftp.funet.fi:/pub/OS/Linux/PEOPLE/Linus/net-
       source/tools/tcpdump-3.0.3.tar.gz

  tcpdump dekodiert jedes abgefangene Datagramm und zeigt es - in einer
  etwas kryptischen Form - als Text an.  tcpdump bietet sich an um
  Protokollfehler oder pltzliche Verbindungsabbrche aufzuspren, denn
  man kann damit sehen, was auf dem Netzwerk passiert.  Um es jedoch
  sinnvoll einsetzen zu knnen bedarf es eines tieferen Verstndnisses
  der Protokolle und wie sie arbeiten, doch es kann auch einfach dazu
  benutzt werden um sicherzustellen, da z.B. Datagramme den eigenen
  Rechner wirklich ber die richtige Schnittstelle verlassen oder um zu
  berprfen, ob irgendwelche Datagramme von auerhalb empfangen werden.
  Eine typische Ausgabe von  tcpdump sieht etwa so aus:

       % 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

        ..

  tcpdump ohne Argumente gestartet berwacht das Netzwerk-Device mit der
  kleinsten Nummer, das kein Loopback-Device ist.  Es kann aber - wie im
  Beispiel - auch ein spezielles Device angegeben werden.  tcpdump
  dekodiert dann jedes Datagramm das ber diese Device bertragen wird
  und zeigt es in einer lesbaren Form an.  Der erste Eintrag ist wie
  leicht zu ersehen der Zeitpunkt, zu dem das Datagramm gesendet oder
  empfangen wurde.  Der weitere Inhalt der Zeile hngt dann von der Art
  des Datagramms ab.  Die ersten beiden Zeilen im Beispiel zeigen, wie
  ein arp request von albert.vk2ktj nach der Adresse von gw.vk2ktj
  aussieht.  Die nchsten vier Zeilen sind zwei pings von albert.vk2ktj
  an gw.vk2ktj, tcpdump gibt dabei auch die genaue Art des icmp
  Datagramms an.  Das Grer-Zeichen (>) gibt die Richtung an, in der
  das Datagramm bermittelt wurde, es zeigt vom Sender zum Empfnger.
  Die restlichen Zeilen protokollieren den Aufbau einer telnet
  Verbindung von albert.vk2ktj zu gw.vk2ktj.

  Die Zahl am Ende jeden Rechnernamens gibt die verwendete Socket Nummer
  an, zu diesem Zweck wertet tcpdump die Datei /etc/services aus.

  Alle weiteren Optionen werden in der Online-Hilfe behandelt.

  Vorsicht PPP-Benutzer: Die derzeitige Version von tcpdump untersttzt
  das PPP-Protokoll nicht.  Es gibt zwei Patches von Al Longyear die
  diese Untersttzung implementieren, es wurde jedoch bislang noch kein
  vollstndiges tcpdump-Paket damit zusammengestellt.  Diese
  Patchdateien sind auf sunsite.unc.edu im selben Verzeichnis wie
  tcpdump.

  14.4.  icmpinfo - bersicht ber empfangene icmp Meldungen

  Das Internet Control Message Protocol (icmp) liefert hilfreiche
  Informationen ber den Zustand des IP-Netzwerkes.  Meist werden
  derartige Meldungen vom System direkt empfangen und verarbeitet, ohne
  da man als Benutzer oder Netzwerkadministrator etwas davon
  mitbekommt.  icmpinfo ist ein Programm, da alle derartigen Meldungen
  hnlich wie tcpdump mitprotokolliert und anzeigt.  Laurent Demailly
  (dl@hplyot.obspm.fr) hat dieses Programm basierend auf den Quellen des
  BSD ping geschrieben.

  Version 1.10 ist erhltlich ber:

       hplyot.obspm.fr:/net/icmpinfo-1.10.tar.gz

  Kompilierung und Installation sind sehr einfach:

       % cd /usr/src
       % gzip -dc icmpinfo-1.11.tar.gz | tar xvf -
       % cd icmpinfo-1.11
       % make

  Um icmpinfo zu benutzen mu man als root eingelogged sein.  Die
  entschlsselten Meldungen knnen wahlweise auf der Konsole ausgegeben
  oder via syslog protokolliert werden.

  Um zu sehen wie icmpinfo arbeitet ist es sehr lehrreich, das Programm
  zu starten und dann ein traceroute auf einen entfernten Rechner
  auszufhren.  Es werden dann die icmp-Meldungen, die traceroute
  verwendet, angezeigt.
  15.  FAQ - Oft gestellte Fragen und ihre Antworten

  15.1.  Generelle Fragen

     Kann ich eine einfache Terminal-Verbindung ber Modem als
        Netzverbindung verwenden?"  Das ist mglich, und zwar mit dem
        TERM-Paket.  TERM erlaubt es, Netzwerkverbindungen ber eine
        normale Terminal-Sitzung aufzubauen.  Es verlangt allerdings
        diverse Modifikationen an den Netzprogrammen, die man verwenden
        will.  Fr die meisten Anwendungsprogramme gibt es aber bereits
        fertig kompilierte Versionen mit TERM-Untersttzung.  Nheres
        dazu findet sich im TERM-HOWTO
        (http://sunsite.unc.edu/mdw/HOWTO/Term-HOWTO.html).

     Es dauert ewig, eine telnet/ftp/rlogin-Verbindung aufzubauen.
        Der Name-Resolver ist nicht richtig konfiguriert, siehe den
        Abschnitt ber /etc/resolv.conf.  Es mu mindestens ein
        Nameserver eingetragen sein.

     Ich will ein eigenes Netzwerk ohne Verbindung nach auen
        konfigurieren.  RFC1597 reserviert einige Adressbereiche
        speziell fr die private Nutzung.  Sie sollten unbedingt
        verwendet werden damit keine greren Probleme auftreten, wenn
        man doch einmal Verbindung mit dem Internet bekommt.  Die
        reservierten Adressen sind:

          10.0.0.0        -   10.255.255.255
          172.16.0.0      -   172.31.255.255
          192.168.0.0     -   192.168.255.255

     Es gibt reservierte Netzwerkadressen fr die Klassen A, B und C.
     Man ist also in der Wahl von Gre und Design des privaten Netzw
     erkes nicht eingeschrnkt.  Da das Netzwerk nie mit dem Internet
     oder einem anderen Netzwerk in Kontakt tritt ist es egal, ob jemand
     anders dieselben Adressen verwendet.  Lediglich innerhalb des eige
     nen lokalen Netzes mssen sie eindeutig sein.

     Ich habe ein lokales Netzwerk und will von allen Rechnern aus die
        Modem-Internetverbindung benutzen."  Hier gibt es drei
        Mglichkeiten:

       Man fragt beim Internet-Provider nach, ob er anstelle einer
        Host-Route eine Netzwerk-Route zur Verfgung stellt.  Dies ist -
        wenn berhaupt mglich - meist sehr teuer, stellt aber die
        einfachste und leistungsfhigste Variante dar.

       Man konfiguriert den Rechner, der die Modemverbindung aufbaut,
        als `SOCKS'-basierten Firewall.  Dadurch wird eine proxy-
        Funktionalitt zur Verfgung gestellt.  Die `Auenwelt' denkt,
        sie wrde ausschlielich mit diesem einen Rechner kommunizieren,
        dabei arbeitet er nur stellvertretend fr die anderen Rechner im
        Netzwerk.  Das Firewall-HOWTO
        (http://sunsite.unc.edu/mdw/HOWTO/Firewall-HOWTO.html) gibt
        weitere Informationen zu diesem Thema.  Voraussetzung ist
        allerdings, da die Anwendungsprogramme der lokalen Rechner
        SOCKS-fhig sind.

       Man verwendet die IP-Masquerade Software.  Dies geht recht
        problemlos, da keinerlei spezielle Anwendungsprogramme verwendet
        werden mssen.  Die Software fhrt lediglich alle notwendigen
        Adress-bersetzungen durch soda alle Rechner des lokalen
        Netzwerkes nach auen hin erscheinen, als handle es sich um den
        einen Rechner mit der Modem-Verbindung.  Es gibt einige
        Einschrnkungen im Leistungsumfang dieser Methode, aber sie ist
        sehr viel leichter als einen kompletten Firewall zu
        konfigurieren.

     Ich kann ftp.linux.org.uk nicht erreichen, woher bekomme ich nun
        die Software?"  Alan's Archiv wird an verschiedenen Stellen
        gespiegelt, z.B.:

          ftp.Uni-Mainz.de:/pub/Linux/packages/Net2Debugged

          ftp.infomagic.com:/pub/mirrors/linux/sunacm

     Woher wei ich, welche Version des Kernels und/oder der
        Netzwerksoftware ich verwende?"  Netzwerkcode und Kernel
        verwenden inzwischen angepate Versionsnummern, die
        Kernelversion erfhrt man entweder mit

          % uname -a

     oder

          % cat /proc/version

     Wie verndere ich die Meldung, die telnet-Benutzer beim
        Verbindungsaufbau angezeigt bekommen?"  Die normale System-
        Meldung steht in der Datei /etc/issue.  Einige telnetd Programme
        verwenden fr Netzwerk-Logins eine andere Datei, /etc/issue.net.

     Ich habe eine neue Login-Meldung in /etc/issue geschrieben.  Nach
        einem Reboot ist sie wieder verschwunden."  Einige
        Distributionen (Slackware) erstellen /etc/issue bei jeden
        Bootvorgang neu.  Dies geschieht in der Datei /etc/rc.d/rc.S.
        Wem die dort erzeugte Meldung nicht gefllt, mu die
        entsprechenden Zeilen auskommentieren.

  15.2.  Fehlermeldungen

     Ich bekomme andauernd die Meldung `eth0: transmit timed out'.  Was
        bedeutet das?"  Normalerweise deutet es darauf hin da das
        Ethernet-Kabel nicht korrekt eingesteckt ist, oder da die
        Setup-Parameter der Ethernet-Karte (I/O-Adresse, IRQ usw.)
        falsch eingestellt sind.  Man berprfe (mit dmesg) die
        Bootmeldungen und stelle sicher, da die Karte mit der richtigen
        Ethernet-Adresse gefunden wird.  Ist dies der Fall liegt
        eventuell ein Konflikt mit einer anderen Karte im Rechner vor,
        z.B. eine Soundblaster, die denselben IRQ oder I/O-Port
        verwendet.

     Wenn ich das Netzwerk benutzen will kommt die Meldung `check
        Ethernet cable'."  Auer dem offensichtlichen Fall eines
        defekten Ethernet-Kabels kann diese Meldung auch durch eine
        falsch konfigurierte Ethernet-Karte hervorgerufen werden.
        Eventuell sollte man die Einstellungen in
        /usr/src/linux/drivers/net/CONFIG berprfen.

  15.3.  Fragen zum Routing

     Wieso bekomme ich die Meldung `obsolete route request' wenn ich
        route verwenden will?"  Die verwendete Version von route ist fr
        den Kernel zu alt.  Im Abschnitt `Das Programmpaket zur
        Netzwerk-Konfiguration' ist beschrieben, woher man die aktuelle
        Version bekommt.

     Wieso bekomme ich die Meldung `network unreachable' wenn ich eine
        Verbindung herstellen will?"  Die Meldung bedeutet, da der
        eigene oder ein anderer Rechner nicht wei, wohin er die
        Datagramme routen soll, die man an den angestrebten Zielrechner
        abgeschickt hat.  Wenn die Meldung fr alle Rechner auftritt,
        mit denen man sich in Verbindung setzen mchte, ist vermutlich
        die Default Route nicht oder falsch gesetzt, vergleiche dazu den
        Abschnitt ber `routing'.

     Ich kann meinen Server/Gateway anpingen, aber keinen Rechner
        darberhinaus."  Das Problem liegt vermutlich im Routing, die
        Konfiguration sollte nochmals anhand des entsprechenden
        Abschnittes `routing' berprft werden.  Ist sie in Ordnung
        berprft man als nchstes, da der Host, mit dem man
        kommunizieren will, eine Route zum eigenen Rechner konfiguriert
        hat.  Bei Modem-Verbindungen ist dies eine hufige Ursache.  Es
        mu sichergestellt sein da auf dem Server ein Router-Dmon wie
        gated oder routed luft, und da er ein Proxy ARP fr die
        einwhlenden Rechner durchfhrt, da sonst die Gegenseite die
        Datagramme zwar empfngt aber nicht wei, wohin sie die
        Antworten senden soll.

  15.4.  Linux in Verbindung mit Novell Fileservern oder NFS

     Wie benutze ich meinen vorhandenen Novell Fileserver mit meinem
        Linux-Rechner?"  Im IPX-HOWTO
        (http://sunsite.unc.edu/mdw/HOWTO/IPX-HOWTO.html) wird Software
        beschrieben, mit der diese Verbindung ohne NFS verwirklicht
        werden kann.

     Dateien werden bei Verwendung von NFS bers Netzwerk
        verstmmelt."  Einige Hersteller (vornehmlich Sun) haben Rechner
        ausgeliefert, auf denen NFS standardmig ohne eine UDP
        Prfsumme luft.  Dies bringt zwar Vorteile in einem Ethernet-
        Netzwerk, grenzt aber sonst schon an Daten-Mord.  UDP Prfsummen
        knnen auf jedem Server bei Bedarf eingeschaltet werden, Linux
        hat sie seit pl13 standardmig aktiviert.  Wichtig ist, da sie
        auf beiden Seiten verwendet werden.

     Warum sind meine NFS-Dateien Schreibgeschtzt?
        Dies ist unter Linux die Standard-Einstellung fr NFS-
        Dateisysteme.  Nheres dazu steht in der man Online-Hilfe zu
        exports(5) und nfsd(8).

  15.5.  Fragen zu SLIP

     Was mache ich, wenn ich die IP-Adresse meines SLIP-Servers nicht
        kenne?"  dip bentigt die Adresse des Servers nicht wirklich, um
        eine funktionierende SLIP-Verbindung aufzubauen.  Die remote-
        Option wurde eingefhrt, damit dip die ifconfig und route
        Befehle automatisieren kann.  Wer die Adresse des Servers nicht
        kennt und partout nicht herausbekommt, dem hilft vielleicht ein
        Tip von Peter D. Junger (Junger@samsara.law.cwru.edu): Er gibt
        immer die eigene Adresse an, wenn im dip-Script nach der remote
        Adresse gefragt wird.  Dies fhrt zu keinen weiteren
        Komplikationen, da die Server-Adresse nie in einem SLIP-Header
        auftaucht.

     dip funktioniert nur fr root.  Wie kann ich normalen
        Benutzern seine Verwendung ermglichen?"  dip mu setuid root
        laufen um einige der notwendigen Dinge wie z.B. die Modifikation
        der Routing-Tabelle, durchzufhren.  Versionen lter als dip337o
        enthalten aber eine Sicherheitslcke und sollten deshalb nicht
        setuid root laufen!  In jedem Fall empfiehlt Uri Blumenthal
        folgendes Vorgehen:

       Anlegen einer neuen Group mit dem Namen dip in der Datei
        /etc/group, in die alle diejenigen Benutzer aufgenommen werden,
        die eine Modem-Verbindung mit dip aufbauen drfen.

       Als root folgende Befehle ausfhren:

          % chown root.dip /usr/bin/dip
          % chmod u=rx,g=x,o= /usr/bin/dip
          % chmod u+s /usr/bin/dip

     Ich bekomme die Meldung `DIP: tty: set_disc(1): Invalid
        argument', was bedeutet das?"  Normalerweise deutet es darauf
        hin, da der Kernel ohne Untersttzung fr SLIP kompiliert
        wurde.  Man berprfe, ob /proc/net/dev die Devices sl0, sl1
        usw. aufzeigt.  Eine andere Mglichkeit ist, da die verwendete
        Version von dip bereits sehr alt ist, in diesem Fall sollte man
        sich eine neuere besorgen.

     Wenn ich einen Rechner anpinge, bekomme ich die Meldung `wrong
        data byte #17...'."  In diesem Fall ist meist das Modem fr das
        XON/XOFF Flow Protokoll konfiguriert.  Fr SLIP mu die
        Verbindung 8-bit-clean sein, XON/XOFF darf also nicht verwendet
        werden.  Die andere Alternative, Hardware handshaking,
        funktioniert sowieso besser, man sollte also diese verwenden.
        Wie man sie einstellt wird im Handbuch zum Modem beschrieben.

     Ich kann ber SLIP zwar alle Rechner anpingen, aber ein telnet
        schlgt fehl."  Vermutlich liegt der Grund in einer
        uneinheitlichen Verwendung der Header-Kompression.  Beide Seiten
        mssen in dieser Einstellung bereinstimmen.

     Wie kann ich die Telefonverbindung beenden, wenn ich mit SLIP
        fertig bin?"  Wer dip benutzt, fr den gengt ein einfaches dip
        -k, dann werden alle ntigen Schritte durchgefhrt.  Wenn dip
        dennoch weiterluft sollte man versuchen, es manuell mit kill zu
        beenden.  Wenn der dip-Proze gestorben ist, sollte das Modem in
        jedem Fall aufgehngt haben.  Das sicherste Vorgehen beim
        manuellen `abschieen' von dip ist folgendes: kill <pid>, kill
        -hup <pid> und, wenn dip immernoch luft, schlielich kill -9
        <pid>.  Dies ist brigens nicht auf dip beschrnkt sondern gilt
        fr alle Unix-Prozesse.

     Ich sehe eine Menge `Overrun'-Fehler auf meinem SLIP-Port.
        Die lteren Network Tools haben flschlicherweise die
        komprimierten Pakete als `Overrun' gemeldet.  Dies wurde aber
        inzwischen behoben und sollte unter neueren Kernels und Netz-
        Software nicht mehr auftreten.  Treten die Fehler trotz neuer
        Versionen auf so kann der Rechner eventuell die ankommenden
        Datenpakete nicht schnell genug in Empfang nehmen.  Wer in
        seiner seriellen Schnittstelle noch keine 16550AFN UARTs hat
        sollte sich berlegen, aufzursten.  16450er, oder 8250er
        generieren fr jedes eingehende Byte einen Interrupt und sind
        deshalb darauf angewiesen, da der Prozessor seine momentane
        Beschftigung unterbrechen kann um dieses Byte zu bernehmen,
        damit es nicht verlorengeht.  Der 16550AFN dagegen hat einen
        16-Byte FIFO (first in first out, ein linearer Zwischenspeicher)
        und generiert einen Interrupt erst kurz bevor der FIFO voll ist.
        Dadurch werden weniger Interrupts erzeugt und das System mu
        weniger Zeit fr die Bedienung der seriellen Schnittstelle
        aufwenden.  Wer sogar mehrere serielle Schnittstellen betreiben
        will sollte also in jedem Fall die 16550AFN UARTs verwenden.

     Kann ich auch zwei SLIP Verbindungen benutzen?
        Ja.  Hat man zum Beispiel drei Rechner, die man verbinden will,
        kann man ohne weiteres auf einem der Rechner zwei SLIP-
        Verbindungen, je eine zu jedem der beiden anderen,
        konfigurieren.  Die zweite Verbindung unterscheidet sich dabei
        in nichts von der ersten, jedoch bentigt das zweite Interface
        eine andere IP-Adresse als das erste.  Eventuell mu man etwas
        mit dem Routing herumexperimentieren, aber es sollte
        funktionieren.

     Ich habe eine Multiport I/O-Karte, wie kann ich mehr als vier
        SLIP-Ports verwenden?"  Der SLIP-Code im Kernel verwendet eine
        Standardeinstellung von maximal 4 SLIP Devices.  Dies wird
        festgelegt in der Datei /usr/src/linux/drivers/net/slip.h.  Um
        den Grenzwert zu erhhen mu er in der Definition #define
        SL_NRUNIT anstelle der dort angegebenen 4 eingesetzt werden.
        Weiterhin mu man die Datei /usr/src/linux/drivers/net/Space.c
        editieren und Abschnitte fr sl4, sl5 usw. einfgen.  Die
        bestehenden Definitionen knnen dabei als Basis verwendet
        werden.  Nach diesen Vernderungen mu dann der Kernel neu
        kompiliert und installiert werden.

  15.6.  Fragen zu PPP

  Diese werden ausfhrlich im PPP-HOWTO
  (http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html) behandelt.

  16.  Kurzanleitung: SLIP- oder PPP-Server

  Einen Linux-Rechner als SLIP oder PPP Server zu konfigurieren ist
  vermeintlich eine leichte Aufgabe.  Der eigentliche Proze ist sehr
  einfach, aber es gibt eine ganze Reihe von Aspekten der Konfiguration,
  und ein Verstndnis darber, wie jeder dieser Abschnitte mit den
  anderen verknpft ist wird es einem hinterher ermglichen, eventuellen
  Schwierigkeiten viel schneller auf die Schliche zu kommen.  Doch nun
  zu der eigentlichen Arbeit:

  1. Zusammenstellen der Hardware.  IRQ und Shared-Memory Konflikte
     mssen vermieden werden.  Jeder der seriellen Ports sollte mit
     einem Nullmodemkabel und einem Terminalprogramm wie minicom oder
     seyon auf einwandfreie Funktion geprft werden.  Zeichen mssen
     einwandfrei gesendet und empfangen werden.  Sollen mehrere serielle
     Ports verwendet werden empfiehlt sich die Verwendung von Multiport-
     Karten und in jedem Fall 16550AFN UART's.  Dies erleichtert den
     Umgang mit den von den seriellen Schnittstellen erzeugten
     Interrupts.

  2. Kompilierung des Kernels.  Netzwerkuntersttzung mu aktiviert
     sein, ebenfalls IP Forwarding, wenn der Server auch das Routing
     bernehmen soll.  Ohne diese Fhigkeit knnen die einwhlenden
     Rechner ausschlielich mit dem Server kommunizieren.  SLIP und/oder
     PPP mssen aktiviert sein, je nachdem welches Protokoll angeboten
     werden soll.  CSLIP mu getrennt eingeschaltet werden, wenn es
     verwendet werden soll.

  3. Installation und Test des neuen Kernels.  /proc/net/dev mu die
     gewnschten sl* oder ppp* Devices aufzeigen.

  4. Fr jeden der seriellen Ports, auf dem sich Benutzer in das System
     einwhlen knnen, mu ein getty Proze gestartet werden.  Hilfe zu
     dessen Konfiguration bietet das Serial-HOWTO
     (http://sunsite.unc.edu/mdw/HOWTO/Serial-HOWTO.html).  Wichtig ist
     da das Modem so eingestellt ist, da der DCD Pin einen `Carrier
     Detect' anzeigt, da getty diesen benutzt, um eingehende Anrufe zu
     erkennen.  Eine Ausnahme stellt hier lediglich mgetty dar, dieses
     verwendet die RING Meldung des Modems.  Deshalb mu fr mgetty das
     Modem so eingestellt sein, da es diese Meldung bei einem Anruf
     erzeugt.  Normalerweise geschieht dies durch die Hayes-Sequenz
     ATQ0V1.

  5. Der getty sollte - unabhngig vom SLIP/PPP Protokoll - auf Korrekte
     Funktion getestet werden.  Bei einem normalen Einwahlversuch sollte
     zunchst die Loginmeldung erscheinen, und ein gewhnlicher Login
     sollte mglich sein.  Verschluckte oder verflschte Zeichen bei
     diesem Vorgang deuten auf Probleme im Datenflu hin.

  6. Nun mu festgelegt werden, wie der Server die IP-Adressen vergibt,
     ob sliplogin, dip oder dSLIP (fr SLIP-Server) verwendet werden
     soll usw.  Die Konfiguration von dip/diplogin wurde bereits in
     Kapitel `Ein SLIP-Server unter dip' beschrieben, die fr das dSLIP
     Paket in `SLIP Server mit dem dSLIP Paket'.  Das PPP-HOWTO
     (http://sunsite.unc.edu/mdw/HOWTO/PPP-HOWTO.html) beschreibt die
     Konfiguration des pppd Dmons fr PPP-Server.

  7. Nun kann man den SLIP/PPP-Server testen, zunchst selber und dann
     mglichst auch von anderen: Viele Augen sehen mehr als zwei.

  17.  Bekannte Fehler

  Der Netzwerk-Code unter Linux befindet sich in steter Entwicklung.
  Sicherlich enthlt er noch einige Fehler, doch es werden immer weniger
  gemeldet.  Alan Cox unterhlt eine Seite im World Wide Web, die Linux
  Networking News (http://iifeak.swan.ac.uk/NetNews.html), in der er
  ber den gegenwrtigen Stand der NET-3 Software informiert.  Ebenfalls
  aktuelle Infos liefert die Datei /usr/src/linux/net/inet/README, die
  zu jeder Kernel-Distribution gehrt.

  18.  Copyright

  Das NET-2-HOWTO ist Copyright  1995 Terry Dawson und Matt Welsh,
  deutsche bersetzung  1996 Peter Stterlin.

  Dieses Dokument darf gem der GNU GPL kostenlos verbreitet werden.
  Das bedeutet, da der Text sowohl ber elektronische wie auch
  physikalische Medien ohne die Zahlung von Lizenzgebhren verbreitet
  werden darf, solange dieser Copyright Hinweis nicht entfernt wird.
  Eine kommerzielle Verbreitung ist erlaubt und sogar erwnscht. Bei
  einer Verbreitung in Papierform ist das deutsche HOWTO-Projekt
  hierber zu informieren.

  19.  Danksagungen, Vermischtes

  Der grte Dank gebhrt Terry Dawson, der den englischen Originaltext
  in mhevoller Arbeit und von vielen ungenannten Mithelfern untersttzt
  zusammengestellt hat.  Ohne seine Vorarbeit gbe es keine deutsche
  Version.

  Der Linux Netzwerk-Code hat bereits eine lange Strecke mit Hhen und
  Tiefen hinter sich.  Die Entwickler - nicht nur die des Netzwerk-
  Codes, sondern alle Linux-Programmierer - haben ihr bestes gegeben um
  etwas zusammenzustellen das funktionell, wandlungsfhig, flexibel und
  vor allen Dingen frei nutzbar fr uns alle ist.  Wir alle sind ihnen
  zu Dank verpflichtet.  Jeder sollte sich einmal die Zeit nehmen und
  die Datei /usr/src/linux/CREDITS durchlesen.

  Peter Stterlin (pit@uni-sw.gwdg.de)

