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.
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.
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.
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.
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 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 =
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.
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.
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.
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.
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.
Die Datei rc.inet1
konfiguriert das TCP/IP-Basissystem. Dazu
werden die beiden Programme /sbin/ifconfig
und
/sbin/route
benutzt .
/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.
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.
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.
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.
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
die IP-Adresse,
die Netzwerk-Maske,
die Broadcast-Adresse und
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.
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
(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.
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.
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.
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.
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.
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.
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
die eigene IP Adresse und für
die IP Adresse des anderen Rechners
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!
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:
ist die eigene IP Adresse.
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.
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.