Fast alle Internetzugänge – ob über Modem, ISDN oder DSL – setzen auf eine PPP-Verbindung zwischen Kunden-PC und Provider-Rechner. Daher ist es wichtig, die Grundlagen des Point-to-Point-Protokolls und die wichtigsten Einstellungen zum PPP-Daemon »pppd« zu kennen. Dieser Artikel stellt sie vor.

Einen Linux-PC ins Internet bringen erfordert keinerlei Aufwand, wenn er an einem Hardware-DSL-Router hängt, der die Verbindung aufbaut und gleichzeitig via DHCP IP-Adressen und Routing-Informationen im lokalen Netz verteilt. Für die Router-lose Einwahl über Modem, ISDN oder DSL gibt es den PPP-Daemon »pppd«. (ISDN-Anwender haben, je nach ISDN-Gerät, die Wahl zwischen »pppd« und der ISDN-spezifischen Variante »ipppd«.) Dieser Artikel erklärt, passend zur LPIC-1-Prüfung, die Grundlagen des Point-to-Point-Protokolls (PPP) und die Einrichtung von »pppd« für Modem-Einwahlverbindungen.

Von einem Punkt zum anderen

PPP [1] baut logische Direktverbindungen (von einem Punkt zum anderen) zwischen zwei Rechnern auf, die auf die eine oder andere Weise bereits miteinander Kontakt haben, klassisch etwa über die Einwahl mit einem Modem. Die Verbindung ist dabei symmetrisch: Auf beiden Seiten läuft ein PPP-Daemon. Welcher die Rolle des Providers oder die des einwählenden Rechners übernimmt, ist ein Konfigurationsdetail.

Während es vor einigen Jahren noch üblich war, nach der Einwahl im Klartext Benutzername und Passwort abzufragen, setzt PPP heute auf eines der beiden Protokolle PAP (Password Authentication Protocol) und CHAP (Challenge Handshake Authentication Protocol). PAP ist die üblichere Variante.

PPPD von Hand

Die meisten Distributionen enthalten ein Konfigurationstool für den Internetzugang, das die PPP-Einstellungen in die richtigen Dateien schreibt. Das manuelle Setup ist aber nicht viel schwieriger. Um sich mit dem Benutzernamen »xyname« und dem Passwort »xypass« bei einem Provider einzuwählen, der die Rufnummer 01234/567890 verwendet, legt der Administrator im Verzeichnis »/etc/ppp/peers« eine neue Datei an, die den Namen des Providers trägt, etwa »local-provider«. Sie enthält nur die vier in Listing 1 abgedruckten Zeilen.

01 ttyS0 38400 crtscts
02 connect '/usr/sbin/chat -v -f /etc/ppp/chat/local-provider'
03 defaultroute
04 user xyname

Die erste Zeile definiert die Gerätedatei des Modems (erste serielle Schnittstelle »/dev/ttyS0«), die Verbindungsgeschwindigkeit und das Hardware-Handshaking (RTS/CTS, siehe Manpage zu »stty«). Zeile 2 (»connect …«) gibt ein externes Kommando an, das den Verbindungsaufbau in die Wege leitet, bevor sich der lokale »pppd« mit einem gleichartigen Programm auf der Gegenseite über das Point-to-Point-Protokoll austauscht.

Die dritte Zeile sorgt dafür, dass »pppd« nach der Einwahl die Standardroute auf die Gegenstelle der neuen Einwahlverbindung legt, und in der letzten Zeile steht der Benutzername für die Anmeldung beim Internetprovider.

Chatskripte

Das über »connect« aufgerufene Hilfsprogramm »chat« hat die Aufgabe, einfache Dialoge zu automatisieren. Es liest dazu das mit der Option »-f« übergebene Chatskript ein, das aus einer Abfolge von Expect- und Send-Befehlen besteht. Prinzipiell ist es auch möglich, »chat« in eigenen Shellskripten einzusetzen. Ein kleines Beispiel eignet sich gut, um die Funktionsweise näher zu erklären: Der Befehl

/usr/sbin/chat "" "Passwort:n" "xyz" "Danken"

hat vier Argumente, die »chat« mangels Angabe eines Chatskripts als Expect- und Send-Befehle interpretiert. Zunächst erwartet das Programm einen leeren String – diese Bedingung ist sofort erfüllt. Dann gibt das Tool »Passwort:« einen Zeilenumbruch aus. Danach liest es die Standardeingabe so lange, bis es das Passwort »xyz« erkennt; dabei dürfen vor diesen drei Buchstaben noch andere Zeichen stehen. Schließlich sagt »chat« noch »Danke« und beendet sich.

Ein Chatskript »read-password.chat«, das die gleiche Aufgabe übernimmt, hätte diesen Aufbau:

"" "Passwort:n"
"xyz" "Danken"

Der Aufruf »/usr/sbin/chat -f Pfad/read-password.chat« bewirkt dann das Gleiche wie das erste »chat«-Beispiel. Die Aufteilung in je einen erwarteten und den darauf angegebenen String ist nicht zwingend, das Chatskript könnte auch alle Strings in einer Zeile enthalten oder sie auf vier Zeilen verteilen.

In der Kommunikation mit dem Modem arbeitet »chat« genauso, nur geht es hier um den Austausch von AT-Befehlen (die das Modem versteht) und die darauf erfolgenden Antworten. Ein »chat«-Skript, das das Modem anweist, die fiktive Provider-Rufnummer 01234/567890 anzurufen, zeigt Listing 2.

01 ABORT "NO CARRIER"
02 ABORT "NO DIALTONE"
03 ABORT "ERROR"
04 ABORT "NO ANSWER"
05 ABORT "BUSY"
06 TIMEOUT 90
07 "" at
08 OK
09 atdt01234567890
10 "~"

Die eigentliche Chat-Sequenz beginnt dort erst in Zeile 7, davor stehen einige Abbruchbedingungen: Wenn »chat« vom Modem eine der Meldungen »NO CARRIER«, »NO DIALTONE«, »ERROR«, »NO ANSWER« oder »BUSY« erhält, soll es abbrechen; außerdem gilt ein Timeout von 90 Sekunden – bleibt die Gegenseite so lange untätig, ist der Einwahlversuch ebenfalls gescheitert.

PAP-Passwort

In die Datei »/etc/ppp/pap-secrets« gehört nun noch eine neue Zeile der Form »Loginname Providername Passwort«, wobei sich »Providername« auf den Rechnernamen der Gegenstelle bezieht. Es ist üblich, hier ein Wildcardzeichen einzutragen. Im Beispiel ergibt sich also:

xyname * xypass

Der »pppd« wird nach erfolgreichem Verbindungsaufbau versuchen den in »peers/local-provider« angegebenen Benutzer (»xyname«) über PAP beim Server anzumelden. Das zugehörige Passwort sucht der Daemon in der Datei »pap-secrets«. Gibt es zwei konfigurierte Zugänge bei verschiedenen Providern, aber mit gleichen Benutzernamen, ist etwas mehr Arbeit nötig (siehe Kasten “Internetprovider eindeutig zuordnen”).

User1  *  Passwort1
User2  *  Passwort2
User3  *  Passwort3

User   Provider1  Passwort1
User   Provider2  Passwort2
User3  *          Passwort3

Sind diese Dateien alle vorhanden, ist der Aufbau der Verbindung leicht: Der Befehl »pppd call Providername« (für den Root-Rechte nötig sind) startet den PPP-Daemon, der die Option »call Name« so interpretiert, dass er im Verzeichnis »/etc/ppp/peers« nach einer Datei »Name« sucht. Er liest die dort abgelegten Informationen ein, lädt das Chatskript nach und wählt sich ein. Ein »killall pppd« beendet die Verbindung wieder.

Der PPP-Daemon sucht sich Optionen für den Verbindungsaufbau aus zahlreichen Quellen. Die Standard-Konfigurationsdatei ist »/etc/ppp/options«, die ähnlich benannte Datei »ioptions«, die oft im gleichen Verzeichnis liegt, hat mit »pppd« nichts zu tun, sondern gehört zum ISDN-PPP-Daemon »ipppd«.

PPP-Optionen

Außerdem ist es möglich, für jede verwendete Schnittstelle (etwa »/dev/ttyS0«) eine zusätzliche Optionsdatei zu erzeugen, deren Name mit »options.« beginnt und mit dem Gerätenamen (ohne »/dev/«) endet, für die erste serielle Schnittstelle also »options.ttyS0«.

Auf einem Rechner, der über mehrere PPP-fähige Geräte verfügt, kann der Administrator so die Konfiguration in einen allgemein gültigen Teil und individuelle Optionen für die einzelnen Modems oder sonstigen Komponenten aufteilen. Typische Optionen sind:

modem
crtscts
defaultroute
asyncmap 0
mtu Zahl
mru Zahl

Dabei teilt »modem« dem »pppd« mit, dass die Kommunikation über ein Modem läuft; »crtscts« aktiviert das schon erwähnte Hardware-Handshaking. Mit »defaultroute« setzt »pppd« die Standardroute auf das neue PPP-Interface. Die Option »asyncmap 0« lässt alle Zeichen für die Kommunikation zu, es gibt also keine Escape-Sequenzen, und »mtu Zahl« und »mru Zahl« setzen die Maximum Transfer Unit und die Maximum Receive Unit.

Findet der PPP-Daemon die Option »persist«, wählt er sich nach jedem Verbindungsabbruch sofort wieder ein. Das ist vor allem bei DSL-Flatrates sinnvoll, da es hier meist nach 24 Stunden zu einem automatischen Disconnect kommt. Die Manpage zu »pppd« nennt unter “Frequently used options” noch weitere Optionen in diesem Zusammenhang.

Leichter mit Wvdial

Wvdial [2] reduziert den Konfigurationsaufwand und bietet gegenüber distributionsspezifischen Lösungen wie Yast den Vorteil, dass es auf jedem Linux-System läuft. Teil des Programmpakets ist das Tool »wvdialconf«, das beim Aufruf den Namen einer zu erzeugenden Konfigurationsdatei (Standard: »/etc/wvdial.conf«) erwartet und dann nach benutzbaren Modems fahndet. Findet es ein Gerät, fragt es mit diversen AT-Kommandos die Modem-Features ab, Abbildung 1 zeigt eine Beispielausgabe.

Abbildung 1: »wvdialconf« hat ein Modem gefunden und erfolgreich getestet.

Nach der Geräte-Erkennung stehen in der angegebenen Konfigurationsdatei die Zeilen aus Listing 4, wobei die Angaben zur Gerätedatei (»/dev/ttySL0«) und zu den Modem-Initialisierungsstrings abweichen werden. Für die Einrichtung der Einwahl passt der Admin die letzten drei Zeilen an: Sie nehmen Rufnummer, Benutzername und Passwort auf. Die Semikola am Anfang dieser Zeilen dienen als Kommentarzeichen, die zu entfernen sind. Für den Verbindungsaufbau reicht nun ein Aufruf von »wvdial« ohne Argumente. [Strg]+[C] baut die Verbindung wieder ab und beendet das Programm.

01 [Dialer Defaults]
02 Modem = /dev/ttySL0
03 Baud = 460800
04 Init1 = ATZ
05 Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
06 ISDN = 0
07 Modem Type = Analog Modem
08 ; Phone = <Target Phone Number>
09 ; Username = <Your Login Name>
10 ; Password = <Your Password>

Ip-up und Ip-down

Nach dem Verbindungsaufbau, wenn bereits die neue IP-Adresse bekannt ist und das Routing steht, startet der »pppd« das Skript »/etc/ppp/ip-up« und übergibt ihm dabei neben anderen Informationen auch die von der PPP-Gegenseite zugewiesene IP-Adresse und den Namen des neuen Netzwerk-Interface, meist »ppp0«. Dieses Skript ist der richtige Ort, um Vorgänge zu automatisieren, die nach jeder Einwahl nötig sind – etwa die Aktualisierung einer Dyn-DNS-Adresse mit einem Tool wie »ddclient« [3].

Statt Programmaufrufe direkt in die Datei »ip-up« einzutragen, empfiehlt sich das Verzeichnis »/etc/ppp/ip-up.d« als Ablageort für Skripte, die »ip-up« bei jedem Lauf automatisch startet, vorausgesetzt sie sind ausführbar.

• Debian verwendet für diese Aufgabe ein spezielles Tool
  namens »run-parts«, das alle Skripte in einem als
  Argument übergebenen Verzeichnis aufruft.
• Open Suse führt eine einfache Schleife über die
  Dateien im Verzeichnis »ip-up.d« aus und startet alle
  gefundenen Skripte, sofern sie nicht eine der Endungen
  ».rpmsave«, ».rpmnew«,
  ».rpmorig« und »~« haben.

Um nach korrekter Einrichtung etwa den Befehl »ddclient« automatisch nach jedem Login zu starten, legt der Administrator im Verzeichnis ein kleines, ausführbares Skript »ddclient.sh« ab, das nur die Zeilen

#!/bin/bash
/usr/sbin/ddclient

enthält. Dass »pppd« das Skript »ip-up« aufruft, vermerkt der Daemon auch im Syslog, und zwar mit Anfangs- und Endzeit. Er meldet dort:

Aug 11 10:33:09 amd64 pppd[26648]: Script /etc/ppp/ip-up started (pid 26665)
Aug 11 10:33:09 amd64 pppd[26648]: Script /etc/ppp/ip-up finished (pid 26665), status = 0x0

In gleicher Weise hilft der PPP-Daemon dabei, Aufgaben zu automatisieren, die beim Beenden der Verbindung anfallen. Nach dem Trennen ruft er das Skript »/etc/ppp/ip-down« auf, das Aufräumarbeiten durchführt. Auch zu »ip-down« gibt es ein Unterverzeichnis »/etc/ppp/ip-down.d«, das analog zu »/etc/ppp/ip-up.d« weitere Skripte enthalten kann, die »ip-down« abarbeitet. Bei Open Suse ist »ip-down« übrigens ein Link auf »ip-up«; das Skript erkennt am Aufruf, was es tun muss. Debian verwendet zwei separate Skriptdateien.

Neben den beiden Skripten »ip-up« und »ip-down« gibt es manchmal ergänzend die Dateien »ip-up.local« und »ip-down.local«. Sie waren vor der Einführung der beiden Unterverzeichnisse der Standardort für lokale Anpassungen. Wenn ein Update auf eine neue »pppd«-Version eine der Dateien »ip-up« und »ip-down« überschreibt, bleiben die Einträge in »*.local« erhalten.

Modemprobleme? Minicom hilft

Funktioniert die Kommunikation mit dem Modem nicht auf Anhieb, ist es oft hilfreich, das Terminalprogramm Minicom [4] als Diagnosetool zu verwenden. Mit Root-Rechten gestartet, versucht es meist auf »/dev/modem« zuzugreifen und das Modem zu initialisieren. Wenn das nicht gelingt, ruft [Strg]+[A], [O] das Setup-Menü auf. Nach Anpassungen über die Menüpunkte »Serial port setup« und »Modem and dialing« sind weitere Tests möglich. Abbildung 2 zeigt, wie das Modem auf verschiedene AT-Befehle mit passenden Antworten reagiert, im Beispiel verraten die Reaktionen auf einige »ATI«-Anfragen, dass es ein Softmodem ist. Abbildung 2: Minicom erlaubt die direkte Kommunikation mit dem Modem.

ISDN und DSL

Auch die ISDN- und DSL-Einwahl läuft über PPP, DSL-Verbindungen nutzen dabei meist PPP over Ethernet (PPPoE). Für ISDN führen mit »ipppd« und einem (ISDN-)Capi-Plugin für den klassischen »pppd« bei vielen Karten zwei Wege zum Ziel. Für die LPI-Prüfung reichen die in diesem Artikel beschriebenen PPP-Kenntnisse jedoch aus.