Zurück Weiter Inhalt

9. Konfiguration der Netzwerk-Schnittstelle

Ist bis hierher alles glatt gelaufen, besitzt man einen Kernel, der alle Geräte, die man benutzen möchte, unterstützt, außerdem sollten auch alle benötigten Hilfsprogramme vorhanden sein. Der Spaß kann also beginnen. Jedes der gewünschten Geräte muß nun konfiguriert werden. Das bedeutet normalerweise, daß jeder Geräteschnittstelle eine IP-Adresse zugeteilt und das Netzwerk, an das sie angeschlossen ist, mitgeteilt wird.

In den früheren Versionen dieses Textes wurden praktisch sämtliche relevanten Konfigurationsdateien zusammen mit Kommentaren, welche Veränderungen möglich und nötig sind, in vollem Umfang zitiert. Der vorliegende Text geht in dieser Beziehung etwas unterschiedlich vor. Sämtliche 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 benötigt werden.

9.1 Die Device-Einträge in /dev

Die Netzwerk-Implementation unter Linux verwende keinerlei Device-Einträge im Verzeichnis /dev. Darin unterscheidet es sich von den Versionen anderer Betriebssysteme. Die benötigten Einträge werden dynamisch im Speicherbereich des Kernels angelegt, und da es sich sowieso nur um Namen handelt gibt es auch keinen Grund, warum sie nach außen hin sichtbar sein sollten. Der Kernel selber bietet alle notwendigen Schnittstellen Kommunikationskanäle, um die Fähigkeiten des Netzwerks effizient zu nutzen.

9.2 Welche Informationen müssen bereitstehen ?

Bevor mit der Konfiguration begonnen werden kann sollte sichergestellt sein, daß einige relevante Daten über die Netzwerk-Verbindung zur Verfügung stehen. Die meisten davon erfährt man vom Netzwerkadministrator oder Internet-Provider.

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.

Die Netz-Maske

Aus Gründen der Leistungsfähigkeit ist es für jedes Netzwerk wünschenswert, die Anzahl der angeschlossenen Rechner möglichst gering zu halten. Deshalb werden große 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 Zugehörigkeit zu einem solchen subnet angibt. Sie ist von essentieller Bedeutung für das Routing in einem Netzwerk, und wer feststellt, daß er zwar problemlos mit Rechnern außerhalb 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 gewählt, 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, größere Netzwerke (Klasse B) benutzen 255.255.0.0. Die NET-2/NET-3-Software wählt 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, hängt 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 zunächst einfach die anderen Möglichkeiten durchprobieren. Einfacher ist es natürlich, den Administrator oder sonst einen örtlichen Fachman zu fragen.

Lediglich das Loopback-Device benötigt keine Netzwerk-Maske, dasselbe gilt auch für Netzverbindungen via SLIP/PLIP.

Die Netzwerk-Adresse

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

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

Die Broadcast-Adresse

Dies ist im Normalfall die Netzwerkadresse, logisch OR-verknüpft 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 Gründen 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 Möglichkeit, den Datenverkehr auf dem Netzwerk zu überwachen, hat, kann die Broadcast-Adresse eventuell auch durch aufmerksames Verfolgen der Vorgänge 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 Ratschläge, als hinterher einen falsch konfigurierten Rechner in seinem Netz zu haben.

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). Für die Vergabe der IP-Adressen der Router gibt es zwei Konventionen: Entweder hat er die höchste Adresse im Netzwerk, oder die kleinste. Da 0 und meist auch 255 keine gültigen 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 Funktionalität des Netzwerkes beeinträchtigt 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 für PPP-Verbindungen, da das PPP-Protokoll diese Adresse automatisch ermittelt. Für SLIP-Verbindungen ist der Router der SLIP-Server und muß beim Provider erfragt werden.

Nameserver-Adressen

Da die IP-Adressen für Menschen eher schlecht zu behalten sind, erhalten Rechner und Netzwerke auch leichter merkbare Namen, z.B. sunsite.unc.edu. Um zwischen diese Namen in gültige IP-Adressen zu übersetzen (und umgekehrt) gibt es spezielle Nameserver. Die Adresse des nächsten Nameservers erfährt man vom Netzwerk-Administrator. Die andere Möglichkeit besteht darin, auf dem eigenen Rechner einen solchen Nameserver mittels named zu konfigurieren. In diesem Fall wäre die Nameserver-Adresse die Loopback-Adresse 127.0.0.1. Näheres dazu steht im Abschnitt `named'. Es können auch mehrere Nameserver-Adressen konfiguriert werden, falls einer nicht erreichbar ist.

Für Loopback benötigt man keinen Nameserver, da man sich sowieso nur mit dem eigenen Rechner unterhält.

Hinweis für SLIP/PLIP/PPP Nutzer

Viele der obengenannten Informationen können für SLIP/PPP/PLIP-Benutzer gar nicht notwendig sein. Das hängt davon ab, wie die Netzwerk-Verbindung genau hergestellt wird, und über welche Fähigkeiten 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 können diese beiden Dateien auch in einer einzigen mit dem Namen /etc/rc.net oder /etc/init.d/network zusammengefaßt sein

Prinzipiell könnten 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 wünschenswert, daß der Rechner automatisch beim Einschalten diese Konfiguration durchführt.

Die rc-Dateien (kurz für runtime command) sind genau für solche Zwecke vorgesehen. Für diejenigen, die sich nicht so genau mit Unix auskennen: Bei diesen Dateien handelt es sich um Shell-Scripts, die beim Systemstart vom init-Programm ausgeführt 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 müssen. Es können 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 außerdem 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 für die Schnittstellen auftauchen, solange dies geschieht, bevor Netzwerk-Dämonen 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.

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 nötigen 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 können. Der Netzwerk-Code im Kernel schaut für 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. Näheres steht in der Online-Hilfe.

rc.inet2

In rc.inet2 werden alle benötigten Netzwerk-Dämonen gestartet, also Programme wie inetd oder portmapper. Auf die Einzelheiten dieser Programme wird weiter unten genauer eingegangen, die Datei ist hier nur erwähnt, 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-Dämonen oder -Anwendungen gestartet werden. Dies ist besonders wichtig für diejenigen, die nur eine einzige rc.net-Datei besitzen, um zu verstehen, was in der zweite Hälfte 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 verhält. Sie ermöglicht 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 großem 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 können. Diese wird deshalb bei der Konfiguration angegeben.

Unter Linux trägt 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 müssen hier noch erwähnt 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 für die Adresse 127.0.0.1 das Loopback-Device verwendet werden soll. Aber da es sich um einen Standard-Wert handelt, schließt 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 hierfür 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 für denjenigen, der eine Ethernet-Karte in seinem Rechner betreiben will. Alle anderen können ihn überspringen.

Die Konfiguration einer Ethernet-Karte ist nur geringfügig 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 für das lokale Netzwerk auch korrekt sind.

Benötigt werden also die zugeteilte IP-Adresse, die lokale Netzwerk-Maske und die Broadcast-Adresse.

Das erste Ethernet-Device in einem Linux-System trägt die Bezeichnung eth0, das zweite eth1 und so weiter. Der folgende Code-Abschnitt muß in der Datei rc.inet1 angefügt werden, damit die Karte richtig eingetragen wird. Die IP-Adresse muß dabei natürlich 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 hinzuzufügendes 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 später in einem eigenen Abschnitt erläutert.

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. Natürlich benötigt man für SLIP einen zweiten Rechner als Gegenstelle, den SLIP-Server. Derartige SLIP-Server werden von vielen Universitäten 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 umzuändern. Es werden zwei Programme zur Verfügung gestellt, die dies bewerkstelligen können: dip und slattach.

dip

dip (Dialup IP) ist ein komfortables und sehr leistungsfähiges Programm, das sämtliche notwendigen Schritte ausführen kann, um einen Rechner über SLIP an das Internet anzuschließen: Setzten der Kommunikationsgeschwindigkeit auf dem seriellen Port, Herstellen der Modem-Verbindung, automatischer Login, Extrahieren von notwendigen Informationen wie IP-Nummern für dynamische Adressvergabe aus den Rückmeldungen des Servers und Ausführung des ioctl, um die serielle Leitung auf den SLIP-Modus zu schalten. Dies alles kann durch eine leistungsfähige Script-Sprache einfach konfiguriert und vollautomatisch durchgeführt werden.

Die Weiterentwicklung von dip verläuft 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 zusätzlichen neuen Optionen und Möglichkeiten bieten. Es lohnt sich durchaus, die einzelnen Versionen anzusehen und dann diejenige zu verwenden, die den eigenen Wünschen 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 umändern.

slattach

Im Gegensatz zu dip ist slattach ein recht spartanisches Programm, das zwar sehr einfach zu bedienen ist, aber bei weitem nicht die Möglichkeiten von dip bietet. Es hat keinerlei Script-Fähigkeiten und wird vollständig über die Kommandozeile gesteuert. Seine einzige Aufgabe ist es, den seriellen Port für 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 für dauerhafte Verbindungen zum Server, sei es über ein (Null-Modem) Kabel oder eine Standleitung.

Und wann benutze ich welches Programm ?

dip ist das Programm der Wahl wenn die SLIP-Verbindung über ein Modem hergestellt wird. slattach hingegen ist für 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 verläuft fast genauso so wie für das Ethernet-Device (siehe den vorigen Abschnitt). Ein paar entscheidende Unterschiede gibt es dennoch.

Zunächst 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, zusätzliche Initialisierungen notwendig.

Bei der Verwendung von dip geschieht dies normalerweise nicht beim Systemstart sondern zu einem späteren Zeitpunkt, wenn die Verbindung auch wirklich benutzt werden soll. Der gesamte Vorgang läßt sich aber auch in diesem Fall vollständig 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 später beschrieben.

Es gibt zwei unterschiedliche Arten von SLIP-Servern: Solche, die statische IP-Adressen benutzen und solche, die die IP-Adressen dynamisch vergeben. Für gewöhnlich meldet sich ein SLIP-Server zunächst mit einer Login-Meldung und fragt dann nach Benutzername und Paßwort. dip kann in beiden Fällen den Login-Prozeß automatisch durchführen.

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 Einträge betreffend das SLIP-Device nötig, da alle Konfiguration von dip übernommen wird. Die Netzwerk-Parameter müssen deshalb dip mitgeteilt werden.

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

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, außerdem kann (und wird) dieselbe Nummer einem anderen zugeteilt werden, nachdem die Verbindung beendet ist. Bei jedem Verbindungsaufbau wird so die nächste 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 für diesen Typ von Server unterscheidet sich kaum von demjenigen für statische Server. Es muß lediglich ein Schritt eingefügt werden, bei dem die zugeteilte Adresse aus der Rückmeldung 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, selbständig die IP-Adresse in der Willkommens-Meldung des Servers zu finden und für die Konfiguration des SLIP-Device zu verwenden.

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

Die Benutzung von dip

Wie bereits dargestellt handelt es sich bei dip um ein äußerst leistungsfähiges Programm, das den Verbindungsaufbau stark vereinfachen, ja sogar automatisieren kann. dip übernimmt dabei das Anwählen des SLIP-Servers, die gesamte Login-Kommunikation, es konfiguriert den seriellen Port für das SLIP-Protokoll und führt die nötigen 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 ausgeführt werden sollen. Das dip-Paket kommt mit einem Beispiel für 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 abläuft. dip ist ein sehr leistungsfähiges Programm mit zu vielen Optionen, als daß diese hier alle erläutert werden könnten. Man sollte die Online-Hilfe lesen, um sich über den ganzen Umfang an Möglichkeiten 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 für 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 für 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 genügt 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 Spezialität wurde speziell wegen der Zunahme von dynamischen Servern eingeführt, damit auch für diese der Verbindungsaufbau automatisch und ohne Eingreifen des Benutzers durchgeführt 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 verändert werden. Hierfür müssen die geeigneten ifconfig und route Befehle benutzt werden.

Es muß noch darauf hingewiesen werden, daß dip eine ganze Reihe von unterschiedlichen Protokollen unterstützt, die mit dem mode Befehl aktiviert werden können. Die gängigste Variante ist cSLIP, das ist SLIP mit Komprimierung. Es ist zwingend notwendig, daß beide Seiten dieselbe Einstellung verwenden, da sonst keine Kommunikation möglich ist. Das vom Server verwendete Protokoll muß deshalb beim Provider erfragt werden.

Das aufgeführte Beispiel ist ziemlich stabil und fängt einige mögliche Fehler ab. Die Online-Hilfe man dip gibt weitere Hinweise dazu. Natürlich kann das Script auch dahingehend erweitert werden, daß z.B. im Falle einer mißlungenen Verbindungsaufnahme ein erneuter Wählversuch gestartet wird, oder daß nacheinander verschiedene Server probiert werden, bis es zu einer Erfolgreichen Verbindung kommt.

Permanente SLIP Verbindung (Standleitung) mit slattach

Wer ein Verbindungskabel zwischen zwei Rechnern hat oder sogar das Glück, 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 Funktionalität bietet, um eine solche Verbindung aufzubauen.

Da diese Verbindung eine permanente sein soll ist es angebracht, die nötigen 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 führt diese beiden Dinge mit einem einzigen Befehl aus. Dafür müssen die folgenden Zeilen zum bestehenden rc.inet1 hinzugefügt 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 müssen für

IPA.IPA.IPA.IPA

die eigene IP Adresse und für

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 für eine zusätzliche Leitung würde dieser dann das Device sl1 zuteilen.

Auch slattach kennt unterschiedliche Protokolle, die mit dem -p Schalter aktiviert werden können. Meist wird hier SLIP oder cSLIP verwendet, je nachdem, ob Kompression eingeschaltet werden soll. Wie auch bei dip gilt: Beide Seiten der Verbindung müssen 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, können über eine PLIP-Verbindung höhere Übertragungsraten erreicht werden als über eine normale serielle Leitung. Hierfür kann auch die billigste parallele Schnittstelle, der Drucker-Port, verwendet werden. Ähnliche Geschwindigkeiten sind für SLIP nur bei Verwendung der recht teuren 16550AFN UART's in den seriellen Schnittstellen möglich.

Unerfreulicherweise verwenden einige Notebooks Chipsätze, die nicht mit PLIP zusammenarbeiten, da einige Kombinationen von Signalen, die PLIP unbedingt benötigt, 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 enthält die plip Timer in mS. Die Standardeinstellungen sind aber in den meisten Fällen ausreichend. Nur auf besonders langsamen Computern muß der eingestellte Wert unter Umständen vergrößert werden, wobei dadurch tatsächlich der Timer des anderen Computers beeinflußt 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 verändern. Eventuell müssen auch die IRQs für die Druckerschnittstelle im ROM BIOS freigegeben werden, falls dieses das unterstützt.

Um das plip-Device zu konfigurieren, müssen die folgenden Zeilen zur Datei rc.inet1 hinzugefügt 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 würde. Lediglich die Verwendung von dip ist weder nötig noch möglich.

Diagramm eines PLIP-Kabels

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

Dieses Pin-Belegungs-Schema sieht folgendermaßen 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, dürfen nicht verbunden werden. 18,19,20,21,22,23 und 24 sind zusätzliche GROUND-Anschlüsse.

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

Warnung! Falsch verdrahtete PLIP-Kabel können die Controller-Karte zerstören. Also lieber einmal zuviel überprüfen, daß alle Pins korrekt verbunden sind, das erspart unnötigen Ärger.

Obwohl PLIP-Kabel im Prinzip sehr lang sein können, sollte man es nach Möglichkeit vermeiden. Die Spezifikationen erlauben Kabellängen von etwa einem Meter. Aber je länger ein Kabel ist, desto empfindlicher reagiert es auf Störungen 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 längere Strecke miteinander vernetzen will sollte sich wirklich überlegen, ob er sich nicht doch lieber zwei Netzwerk-Karten und ein koaxiales Kabel zulegen sollte.


Zurück Weiter Inhalt