Installation und Konfiguration

Der Kernel

Es war einmal der Kernel 1.2.13, der den meisten Distributionen als Standardkernel begegeben war. Dieser lief in Zusammenhang mit i4l, als noch keine ISDN-Kerneltreiber existierten, bereits ganz gut, aber die Entwicklung blieb bei der Version 0.7.3beta stehen. I4l-Benutzer wichen daher in der Regel schnell auf die sogenannten "Hackerkernel" ab 1.3.69 aus, die den ISDN-Teil enthielten.

Derzeit empfiehlt sich ein Kernel frühestens ab 1.3.97 (erst seit Kernel 1.3.69 ist der Einsatz von Kernel-internen ISDN-Treibern überhaupt möglich, und erst ab 1.3.97 laufen die Treiber hinreichend stabil). Nachdem nun der Kernel 2.0 herausgekommen ist, werden wir ihn hier auch besprechen. Es empfiehlt sich derzeit die Kernelversion 2.0.27, die mit isdn4linux ziemlich problemlos zusammenarbeitet. Man besorgt sich den Kernel z.B. unter

  ftp.leo.org/pub/comp/os/linux/Linus/v2.0/

(zum Beispiel linux-2.0.27.tar.gz; dieser Kernel läuft seit Monaten ohne Probleme beim Autor) und sollte auch gleich das neue modules-Paket mit holen:

  ftp.leo.org/pub/comp/os/linux/Linus/v2.0/modules-2.0.0.tar.gz

Mit dem Kernel geht man wie gewohnt um - siehe dazu auch das Kernel-HOWTO, zu finden beim nächsten SunSite, beispielsweise unter

  ftp.leo.org/pub/comp/os/linux/sunsite/docs/HOWTO/Kernel-HOWTO.gz

Die Modules sollte man vorher noch entpacken und entsprechend der Anweisungen im Kernel-HOWTO einbauen.

Wer isdn4linux einsetzen will, um eine ISDN-Karte zu bedienen, muß keinerlei Patches mehr einspielen (das war nur beim Kernel 2.0.0 erforderlich - dort mußte man noch die zwei Patches isdn4kernel-2.0-patch1+2 einbauen). Aber: Die meisten passiven Karten mit Siemens-Chipsatz (Teles, Creatix, AVM, Elsa, ...) laufen nur mit einem Treiberpaket, das noch nicht im Kernel integriert ist: "HiSax". Wer so eine Karte einsetzt, muß sich den aktuellen Treiber in's Verzeichnis /usr/src holen:

  ftp.franken.de/pub/isdn4linux/HiSax/

(z.B. Version 1.5; die unterstützten Karten finden sich im README!) und ihn in den Kernel patchen:

  root:# cd /usr/src
  root:# tar zxfv HiSax_1.5.patch_for_2.0.tar.gz
  root:# patch -p <HiSax_1.5.patch_for_2.0
  root:# _

Beim Compilieren des Kernels muß man nun folgendes bei "make config" (bzw. seinen graphischen Verwandten "make menuconfig" oder "make xconfig") eingestellt werden:

Sektion "Code maturity level options":
  Prompt for development and/or incomplete code/drivers: No
Sektion "General Setup":
  Networking support: Yes
Sektion "Networking options":
  TCP/IP networking: Yes
  alle anderen je nach Bedarf.
Sektion "Network device support":
  Network device support: Yes
  PPP (point-to-point) support: Yes  
  alle anderen je nach Bedarf
Sektion "ISDN subsystem":
  Nur wenn isdn4linux benötigt wird:
  ISDN support: Yes
  Support synchronous PPP: Yes
  Use VJ compression with synchronous PPP: Yes
  Support audio via ISDN: Yes
  Support generic MP (RFC 1717): Yes
  Verwendete Karte eintragen.

Wenn später der Kernel ohne Probleme läuft, kann man daran denken, einige dieser Bausteine auch als Module statt als feste Kernelbestandteile zu definieren.

Die Treibersoftware für ISDN-Karten

Wer lediglich ein Modem benutzen will (egal, ob analog oder ISDN), kann diesen Abschnitt getrost überspringen.

Wer eine ISDN-Karte einsetzt, muß aber zusätzlich Arbeit investieren und sich die aktuelle Version von Fritz Elferts "isdn4kernel-Utilities" holen. Wer eine ältere Version von isdnctrl besitzt, muß updaten: der Befehl "isdnctrl pppbind" muß laufen! Das bekommt man heraus, indem man isdnctrl eingibt und sich die möglichen Optionen ansieht. Hier gibt es die neue Version:

  ftp.franken.de/pub/isdn4linux/v2.0/isdn4k-utils-2.0.tar.gz

Man setzt sich diese ins Verzeichnis /usr/src und entpackt sie per "tar zxfv isdn4k-utils-2.0.tar.gz". Im Verzeichnis

  /usr/src/isdn4k-utils-2.0

findet man jetzt alle zum Betrieb notwendigen Dateien. Bei einigen Linux-Distributionen fehlen einige wichtige Links, weshalb man an einigen Makefiles drehen muß. Diese Makefiles befinden sich alle im Unterverzeichnis tools

/usr/src/isdn4k-utils-2.0/tools/Makefile
  In der folgenden Zeile "isdnbutton-1.1" entfernen,
  falls Sie kein Motif besitzen - sonst Compilierfehler.
  SUBDIRS=imon imontty-0.3 isdnlog-2.41 isdnbutton-1.1 tcltk
  [...]

/usr/src/isdn4k-utils-2.0/tools/imontty-0.3/Makefile
  [...]
  LDFLAGS=-lncurses -lm
  [...]

/usr/src/isdn4k-utils-2.0/tools/isdnlog-2.41/Makefile
  [...]
  LIB         = -lgdbm
  [...]

Zunächst müssen die Programme erzeugt werden. Dazu begibt man sich in's Verzeichnis /usr/src/isdn4k-utils-2.0, übersetzt alles mit "make", erzeugt anschließend die neuen ISDN-Gerätedateien mit "make devices" und installiert zum Schluß die ausführbaren Programme mit "make install" im Verzeichnis /sbin sowie die man-Seiten dort, wo sie hingehören.

Die Kartenparameter müssen auch noch eingestellt werden - hierzu ist die ISDN4Linux-Anleitung

  /usr/src/linux/Documentation/isdn/README

zu Rate zu ziehen. Die Parameter werden beim Booten als Kernelparameter oder beim Laden des entprechenden Modules übergeben.

Die Konfiguration

Tip:
Jetzt kommen etliche große Scriptdateien. Sie liegen diesem Anleitungspaket bei - am Script ist nur die Überschrift anzuklicken!
Hinweis für treue Leser:
Die Scripten haben sich sehr stark verändert. Es gibt keinen Befehl isdn mehr, alles wird jetzt über ein neues Scriptpaket namens connect abgearbeitet. Dieses kann jetzt auch Modems ansteuern!

Konfigurationsdateien

Zwei zentrale Dateien steuern den Setup und den Verbindungsaufbau. Die eine nennt sich rc.connect, liegt im Bootverzeichnis und wird beim Rechnerstart abgearbeitet. Das andere heißt connect und regelt den Verbindungsauf- und -abbau sowie einiges mehr.

Eine Reihe weiterer Dateien müssen angelegt werden. So ist für jeden Provider je eine Datei pro Einwahl-Telefonnummer herzustellen, in der alle wichtigen Daten enthalten sind. Die PPP-Dämonen benötigen überdies ein paar weitere Dateien. Das werden wir nun der Reihe nach besprechen.

Leute, die sich diese WWW-Seiten als Paket "leafsite.tar.gz" geladen haben, finden die Scripte im Unterverzeichnis "scripts".

Vorarbeiten

Wenn Sie vorher bereits das alte "isdn"-Paket dieses Tutorials benutzt haben, so müssen sie zuallererst ein paar Sachen ändern:
root:# <startup_path>/i4l stop (oder "rc.isdn stop" oder wasimmer) root:# _
(<startup_path> ist das Verzeichnis, in dem alle System-Bootdateien enthalten sind).
Dann löscht man (oder sichert sie woanders) einige alte Dateien:
root:# rm <startup_path>/i4l (falls eine neuere SuSE benutzt wird) root:# rm <startup_path>/rc.isdn root:# rm /sbin/isdn root:# rm /etc/i4l.provider (/etc/i4l.config bei alten "isdn"-Versionen) root:# rm /etc/i4l.secrets (/etc/i4l.param bei alten "isdn"-Versionen) root:# _

Zu Beginn müssen einige Verzeichnisse eingerichtet werden:

  root:# mkdir /usr/lib/connect
  root:# mkdir /usr/lib/connect/providers
  root:# mkdir /var/lib/connect
  root:# _

Die Daten des Providers

In /usr/lib/connect/providers ist für jeden Provider und jede Einwahlnummer jeweils eine Datei zu erstellen. Je nachdem, ob die Einwahlnummer per Modem oder über isdn4linux angewählt werden soll, sehen die Dateien leicht unterschiedlich aus. Hier gekürzte Beispiele, man kann sich aber entsprechende Vorlagen herunterladen, in denen auch weitere Erklärungen enthalten sind. Sie können diese Dateien benennen, wie Sie möchten - aber benutzen Sie keines der connect-Schlüsselwörter (on, off, status, help, maxtries, route, device, all).

Beispiel für eine isdn4linux-Datei

  #!/bin/bash
  MODE=i4l
  PHONE=0891234567
  IP_ADDRESS=123.234.210.109
  OPTIONS_FILE=/etc/ppp/options.ipppd

Beispiel für eine Modem-Datei

  #!/bin/bash
  MODE=modem
  IP_ADDRESS=234.123.134.56
  DEVICE=ttyS1
  OPTIONS_FILE=/etc/ppp/options.pppd
  CHAT_SCRIPT="ABORT BUSY ABORT 'NO CARRIER' '' ATZ0 OK ATD0,08912345 CONNECT"

Diese Dateien definieren etliche Umgebungsvariable, die in den hier verwendeten Scripten teilweise eingebunden werden. MODE sagt connect, ob es isdn4linux aufrufen oder ein Modem ansteuern soll. IP_ADDRESS ist die IP-Adresse des Remotes, bei dem Sie sich einwählen möchten. OPTIONS_FILE ist die Optionendatei des (i)pppd für diesen Remote. isdn4linux benötigt die Telefonnummer des Remotes (PHONE), und der pppd braucht den Namen der seriellen Schnittstelle (DEVICE) sowie ein CHAT-Script (CHAT_SCRIPT), an welcher das Modem angeschlossen ist.

Eine Datenbank mit Daten einiger Unis und anderer Provider kann man sich herunterladen.

Ich wäre übrigens nicht undankbar, wenn man mir funktionierende Dateien mailen würde (eventuelle Privatdaten wie Paßwörter entfernen!).

Defaultwerte

Einige Daten werden beim Start des Systemes gesetzt. Dazu baut man sich eine eigene Datei. Hier die meine:

/usr/lib/connect/base
#!/bin/bash
# (c) 1997 Bernhard Hailer (GNU GPL V.2)

# Edit this file for your needs

# local settings
# ==============

# Fully qualified host name
read MY_HOSTNAME </etc/HOSTNAME                          # read host's name
# MY_HOSTNAME=foo.bar.com

# Host phone number and MSN (EAZ) - replace by your numbers!
MY_PHONE=817890032                                          # no leading zero!
MY_EAZ=90032

# Email address for fetching mail - replace by your address!
MY_EMAIL_ADDRESS=dl4mhk@lrz.uni-muenchen.de


# extra start commands for rc.connect (e.g. module loading)
# ---------------------------------------------------------
function Con_Start()
{
  insmod /lib/modules/`/bin/uname -r`/misc/isdn.o
  insmod /lib/modules/`/bin/uname -r`/misc/hisax.o io=3,2,12,0xd80 HiSax_id=Teles0
  #insmod /lib/modules/`/bin/uname -r`/misc/teles.o io=0,12,0xd80,2 teles_id=Teles0
  #rmmod teles.o
  #insmod /lib/modules/`/bin/uname -r`/misc/teles.o io=0,12,0xd80,2 teles_id=Teles0
  return
}

# extra stop commands for rc.connect (e.g. module unloading)
# ----------------------------------------------------------
function Con_Stop()
{
  rmmod hisax.o  
  #rmmod teles.o
  sleep 1
  rmmod isdn.o
  return
}

# Default remote providers for regular connects
DEFAULT_REMOTES="lrz-d1 lrz-d2"

# default device where your modem is connected - no leading "/dev/"!
DEFAULT_DEVICE="ttyS1"

# Maximum number of dialin attempts
declare -i DEFAULT_MAX_TRIES
DEFAULT_MAX_TRIES=4

# Maximum idle time before hangup (you should use a time of about 300 secs
# here, because it is more expensive to dial often than to hold a line!)
# This only works for isdn4linux connections.
declare -i HUPTIMEOUT
HUPTIMEOUT=300             # 5 min

Die Shell-Funktionen Con_Start() und Con_Stop() werden vom Script rc.connect aufgerufen und verdienen besondere Beachtung: Wenn man das ISDN-Subsystem als Module laden und entladen will, so kann man die dazugehörigen Befehle hier eintragen. Beispiele für den Teles- und den HiSax-Treiber sind aufgeführt (ich benutze inzwischen HiSax 1.4 an meiner Teles 16.3).

Desweiteren werden noch ein paar Defaultwerte vereinbart. DEFAULT_REMOTES enthält die Dateinamen der Remotes, die normalerweise angerufen werden sollen (wenn man mehrere angibt, dann wird einer nach dem anderen ausprobiert, bis eine Verbindung zustandekommt). DEFAULT_MAX_TRIES sagt aus, wie oft das passieren soll. HUPTIMEOUT wirkt nur bei der Benutzung von isdn4linux. Man trägt hier ein, nach wieviel Zeit ohne Datenübertragung aufgelegt werden soll (bei Modems das Handbuch zu Rate ziehen). Und DEFAULT_DEVICE ist der Name der normalerweise vom Modem benutzten seriellen Schnittstelle.

Das Bootscript rc.connect wollen wir als nächstes behandeln.

Vorgänge beim Booten

Linux kann nach zwei Möglichkeiten gestartet werden. Die eine ist simpleinit (z.B. Slackware), die andere, etwas kompliziertere, aber auch viel flexiblere ist sysvinit (S.u.S.E. ab 4.0, Debian, Caldera, Red Hat...). Diese beiden Varianten erfordern eine voneinander verschiedene Einbindung des ISDN-Startups.

simpleinit

Bei simpleinit sind die Startdateien in /etc/rc.d/ untergebracht; man findet etliche Einzelscripte, von denen die Dateien rc.M (Aufruf etlicher Startscripte) und rc.6 (Reboot-Script) für uns von Bedeutung sind. In's selbe Verzeichnis setzen wir eine neue Datei rc.isdn, die das ISDN-System starten soll.

Diese Datei muß neu angelegt werden. Damit sie beim Booten als Startdatei erkannt wird, muß man vorher folgenden Eintrag in die Datei /etc/rc.d/rc.M vornehmen:

/etc/rc.d/rc.M; Sektion "# Initialize the NET subsystem."
  . /etc/rc.d/rc.inet1
  . /etc/rc.d/rc.connect    # <-- diese Zeile einfügen!
  . /etc/rc.d/rc.inet2

sysvinit

Bei sysvinit funktioniert der Start ganz anders. Hier werden die Initialisierungsscripten beispielsweise unter /sbin/init.d/, /etc/init.d oder /etc/rc.d/ abgelegt. Hier haben die Scripten Doppelfunktion: werden sie mit dem Argument "start" aufgerufen, wird etwas gestartet, mit dem Argument "stop" wird das System auf den Shutdown vorbereitet. Das Ganze funktioniert mit sogenannten "run levels": Level 0 bedeutet "Systemhalt", Level 1 "single user mode", Level 2 in der Regel "multiuser mode mit Netzwerk" und Level 3 "mit xdm", und schließlich Level 6 "rebooting". Level 1-3 werden nacheinander beim Rechnerstart aufgerufen, und in deren Verlauf werden etliche der Scripten mit dem Argument "start" aufgerufen. Im Runlevel 6 werden diese Scripten in umgekehrter Reihenfolge mit dem Argument "stop" gerufen.

Das mit der Reihenfolge ist "tricky": ein "Masterscript" sieht in den Runleveln zugeordneten Verzeichnissen (./rc0.d, ./rc1.d, ./rc2.d) nach, was zu tun ist. Darin befinden sich eine Reihe von Soft-Links auf die gerade beschriebenen Scripten. Alle Links heißen entweder

  SnnScriptname

oder

  KnnScriptname

mit einer Zahl nn, die bestimmt, wann diese Datei aufgerufen wird. Wenn also eine neue Datei - nennen wir sie auch hier wieder rc.connect, unterzubringen im Scriptenverzeichnis - eingebunden werden soll, die das ISDN-System integriert, dann ist das zugehörige Runlevelverzeichnis ./rc2.d, und man muß dort zwei Softlinks unterbringen:

  root:# cd /sbin/init.d/rc2.d  # (Pfad anpassen!!)
  root:# ln -s ../rc.connect K20rc.connect
  root:# ln -s ../rc.connect S20rc.connect
  root:# _

Hinweis für Benutzer der S.u.S.E.-Distribution ab Version 4: Hier heißt diese Datei i4l, ferner gibt es eventuell eine Datei i4l_hardware. Diese Dateien müssen beseitigt werden, entsprechend auch ihre Aufrufdateien in /sbin/init.d/rc2.d. Damit werden selbstverständlich auch die Einträge I4L_* in der S.u.S.E.-Konfigurationsdatei /etc/rc.config belanglos.
Diese Änderungen sind leider notwendig, weil nur so ein distributionsunabhängiges Paket geschaffen werden kann.

System-Start und -Stop

Die Datei(en), die man sowohl bei simpleinit als auch bei sysvinit braucht, kann man sich wie gehabt laden. Hier beschränke ich mich darauf, die Startpassage für isdn4linux zu beschreiben - Modems benötigen praktisch keinerlei Startup. Man lade diese Datei und installiere sie wie beschrieben.

/sbin/init.d/rc.connect (Ausschnitt)
  /sbin/isdnctrl verbose 0  # For debugging set to 2 (max. 4)
  # ISDN device drivers     ippp0 (PPP)
  /sbin/isdnctrl addif      ippp0
  /sbin/isdnctrl pppbind    ippp0 0
  /sbin/isdnctrl addphone   ippp0 out $PHONE      # dial-out number
  /sbin/isdnctrl addphone   ippp0 in $MY_PHONE    # my telephone no
  /sbin/isdnctrl eaz        ippp0 $MY_EAZ         # my MSN / EAZ
  /sbin/isdnctrl huptimeout ippp0 $HUPTIMEOUT     # defined in $BASE
  /sbin/isdnctrl secure     ippp0 on              # nobody may enter
  /sbin/isdnctrl l2_prot    ippp0 hdlc
  /sbin/isdnctrl l3_prot    ippp0 trans
  /sbin/isdnctrl encap      ippp0 syncppp
  /sbin/ifconfig ippp0 $MY_HOSTNAME pointopoint $IP_ADDRESS metric 1
  /sbin/route add default ippp0                   # interface definitions 
  /sbin/ipppd /dev/ippp0 file $OPTIONS_FILE &
  /sbin/route del default
  ifconfig ippp0 down

Unter Umständen muß der Pfad PATH in diesem Script angepaßt werden!

Vor Aufruf muß rc.connect mit chmod 744 rc.connect ausführbar gemacht werden.

Man sieht: hier werden etliche der oben definierten Umgebungsvariable benutzt! Einige der Kommandos sind bemerkenswert: das "pppbind"-Kommando wird gegen Seiteneffekte eingesetzt, die entstehen, wenn mehr als ein ipppd gestartet werden. Ohne dieses Kommando benutzen alle ipppd's beispielsweise die Paßwörter, die für den ersten definiert wurden. Auch die letzten beiden Kommandos sind essentiell: nur wenn kein ipppd "up" ist, kann man daneben problemlos einen herkömmlichen pppd für Modems starten.

Hier wird übrigens nicht der Standard-PPP-Dämon pppd 2.2.0f aufgerufen, sondern eine speziell gepatchte Version namens "ipppd". Diese liegt dem ISDN4Linux-Paket bei und wurde beim Installieren nach /sbin befördert. Trotzdem gelten die man-Seite zum pppd sowie das "PPP-HOWTO".

Weitere wichtige Dateien

Damit PPP funktioniert, muß man als root noch etliche Dateien editieren. Sowohl der pppd als auch der ipppd benutzen die Datei /etc/ppp/options, um zentrale Konfigurationsparameter zu laden. Außerdem kann man beiden Dämonen noch mit dem Kommandozeilenargument file weitere zu ladende Dateien angeben - diese Dateien haben wir oben bei der Erstellung der Remote-Dateien bereits definiert (OPTIONS_FILE). Hier aber erst einmal /etc/ppp/options, die immer geladen wird:

/etc/ppp/options
# comment out the following three lines if you don't need 
# dynamic IP negotiation.
ipcp-accept-local
ipcp-accept-remote
noipdefault
# more pppd/ipppd options
lock
mru 1500
mtu 1500
debug
-detach

Falls man nicht dynamisch von seinem Provider eine IP zugewiesen bekommt, muß man die ersten drei Befehle auskommentieren. Der Rest wird praktisch immer benötigt.

Nun zu den Extra-Optionsdateien. Sie sind erforderlich, weil

der ipppd andere Optionen benötigt als der pppd,
die Optionen von Provider zu Provider variieren.

Beispieldatei für den pppd
# /etc/ppp/options
crtscts
user hailer

Beispieldatei für den ipppd
# /etc/ppp/options for ipppd
useifip
-vjccomp
-ac
-pc
-detach
-bsdcomp
-vj
user hailer

Anmerkung zur Option "-vj": Wird dieser Parameter nicht gesetzt, so kann das System sehr ungehalten reagieren. Während es bei einer laufenden X-Sitzung schlicht und einfach hängenbleiben kann, so kommt es bei einer einfachen Sitzung zur Anzeige von "Kernel-Oopses". Speziell die Zeile "Aiee, killing interrupt handler" deutet auf eine eingeschaltete VJ-Kompression hin. Die Option useifip verhindert Seiteneffekte bei mehreren gleichzeitig laufenden ipppd's.

/etc/resolv.conf: (siehe /etc/i4l.provider-Datenbank!)
search <what_you_need>
nameserver <IP 1st nameserver> 
nameserver <IP 2nd nameserver> 
nameserver <IP 3rd nameserver>

Es können maximal drei Nameserver angegeben werden. Bei "search" trägt man ein, wo verkuerzte Hostnamen gesucht werden sollen. Beispiel: bei einem Eintrag von search lrz-muenchen.de kann beim Befehl ping sun3 der Rechner sun3.lrz-muenchen.de gefunden werden.

/etc/host.conf:
  order hosts bind
  multi on

/etc/hosts: (ein Beispiel!)
  # For loopbacking.
  127.0.0.1       localhost
  # My own IP address
  192.168.1.1     maschinen.name              alias    # oder eigene IP-Adresse
  # (192.168.x.x ist frei verfügbar und kann immer verwendet werden.) 
  # example entries
  129.187.10.22   sun3.lrz-muenchen.de        sun3     # (Beispiel-Remote)
  129.187.13.48   sunmailhost.lrz-muenchen.de getmail  # (Beispiel, für Mail)
  129.187.13.48   news.lrz-muenchen.de        getnews  # (Beispiel, für News)

Authentifizierung

Unter PPP muß man sich beim Provider ausweisen. Dazu gibt es zwei Methoden, die je nach Provider verwendet werden: PAP (Password Authentification Protocol) und CHAP (Challenge Authentification Protocol). PAP ist weit verbreitet, aber CHAP bietet dem Provider mehr Sicherheit. Je nachdem, welches Verfahren verwendet wird, ist die Datei /etc/ppp/pap-secrets oder /etc/ppp/chap-secrets zu editieren (nur eine der beiden sollte vorhanden sein). Achtung! Diese Dateien enthalten Paßwörter und müssen unter allen Umständen vor unbefugtem Zugriff geschützt werden!

  root:# chmod 600 /etc/ppp/pap-secrets (bzw. /etc/ppp/chap-secrets)
  root:# _

PAP

/etc/ppp/pap-secrets
  # Secrets for authentification using PAP
  # client          server          secret          IP addresses
  <provider_login>  <1. Provider>   '<password>'    -
  <provider_login>  <2. Provider>   '<password>'    -

Anmerkungen:

Es empfiehlt sich, das Paßwort in Hochkommas einschließen. Dann kommt es nicht zu Fehlern, wenn ein "#" darin vorkommt. (Vielen Dank an Michael Matschilles <mat@pascal.bmw.de> für den Tip!)
In vielen Fällen ist es einfacher, in der "server"-Spalte statt dem Namen des Providers einfach ein Sternchen "*" anzugeben.

Das Schützen mit chmod 600 /etc/ppp/pap-secrets nicht vergessen!

CHAP

Die Provider kennen im allgemeinen nicht den "fully qualified hostname" des Kundenrechners - die IP im Zweifel auch nicht. Daher wird stattdessen als Kundenrechnername einfach dessen Login-Name benutzt. Das hat zur Folge, daß man seinen Rechner auf den Login-Namen (ohne Domain!) beim Provider umbenennen müßte - was man aber durch die Angabe von "name <provider_login>" als Option beim Aufruf vom ipppd (bzw. in der Datei /etc/ppp/options) umgehen kann. Statt der Datei /etc/ppp/pap-secrets schreibt man nun eine Datei /etc/ppp/chap-secrets, die folgendermaßen aussehen muß (man beachte: es sind zwei Zeilen pro Eintrag erforderlich!):

/etc/ppp/chap-secrets
  # Secrets for authentification using CHAP
  # client          server             secret       IP addresses
  <provider_login>  <1. Provider>      <password>
  <1. Provider>     <provider_login>   ""
  <provider_login>  <2. Provider>      <password>
  <2. Provider>     <provider_login>   ""

Das Schützen mit chmod 600 /etc/ppp/chap-secrets nicht vergessen!

Ein wenig Schliff

Nun sollte man noch das PPP-Log auf eine Extra-Datei umlenken, damit man leichter eventuelle Fehler suchen kann. Dazu editiert man die Datei /etc/syslog.conf und fügt folgende Zeile an (Anmerkung: KEINE Leerzeichen, nur Tabulatoren benutzen!):

  daemon.*                      /var/log/ppp-log

Damit wird alles, was der PPP-Dämon an Informationen abgibt, in der Datei /var/log/ppp-log abgelegt.

Damit hat man alle erforderlichen Dateien angepaßt, und das System sollte laufen.

Der Betrieb

Leider neigt das Linux-System nun dazu, mehr oder weniger unmotiviert Verbindungen zum Provider aufzubauen. Dies liegt in der Natur des Systems: wann immer ein IP-Paket anliegt, will das System es auch loswerden (z.B. Zugriff auf Nameserver etc.). Da das Kosten verursacht, muß man es abstellen. Das macht man, indem man die Default-Route zum Interface ippp0 löscht - das Linux-System kennt dann den Weg nach draußen nicht mehr.

Die neuen Kernels ab 1.3.100 haben eine etwas unangenehme Eigenschaft: sie greifen intensiv in die Routenlegung ein. Damit es keine Kollisionen gibt, muß man erst wählen, dann warten, bis die Verbindung steht und darf erst dann die Defaultroute legen. Das folgende Script erledigt das "An-" und das "Abschalten" der Route. Es ist so abgefaßt, daß es auch mehrmal aufgerufen werden kann, so daß die erste Anwendung (beispielsweise Post holen) die Verbindung herstellt, und weitere Verbindungen nicht neue Leitungen aufmachen müssen. Die letzte Anwendung räumt auf: es wird aufgelegt und die Defaultroute wieder gelöscht. Aufruf: /sbin/connect on und /sbin/connect off. Eine ausgeklügelte Datei kann geladen werden (auf die Überschrift klicken!), hier nur eine ganz kurze Beispieldatei.

Das Script setzt man in das Verzeichnis /sbin und macht es ausführbar (der route-Befehl ist nur für "root" ausführbar!):

  root:# chmod 744 /sbin/connect
  root:# _

/sbin/connect
  #! /bin/bash

  PATH=/sbin:/usr/sbin:/bin:/usr/bin

  #  ISDN4Linux:

  case $1 in
    on)
      isdnctrl dial ippp0       #  Verbindung herstellen
      sleep 5                   #  warten, bis Leitung offen
      route add default ippp0   #  Route setzen
      ;;
    off)
      isdnctrl hangup ippp0     #  Verbindung abbrechen
      route del default         #  und Route wieder löschen
      ;;
  esac

  # Modem:

  IF_FILE=/var/lib/connect/interface
  case $1 in
    on)
      pppd connect "chat $CHAT_SCRIPT" file $OPTIONS_FILE /dev/$DEVICE &
      # the interface name was saved now by /etc/ppp/ip-up in IF_FILE.
      sleep 1
      echo "Sleeping 40 seconds for establishing connection..."
      sleep 40
      read INTERFACE <$IF_FILE
      route add default $INTERFACE
      ;;
    off)
      kill -HUP `cat /var/lock/LCK..$DEVICE`
      route del default
      ;;
  esac

Unter Umständen muß der Pfad PATH in diesem Script angepaßt werden!

Beim Modem wird das INTERFACE auf raffinierte Art und Weise bestimmt: beim Hochfahren des pppd wird das Script /etc/ppp/ip-up mit folgenden Argumenten aufgerufen:

  ip-up interface device speed local_address remote_address

Und das macht man sich zunutze. Man schreibt eine Datei ip-up:

/etc/ppp/ip-up
#!/bin/bash
# This script is called by (i)pppd while starting up.
# It is called this way:
#   ip-up interface device speed local_address remote_address.
#   So you can get the used interface by fetching $1
echo $1 >/tmp/connect_interface.tmp

und schon hat man den Namen des Interfaces gespeichert!

Hinweise für eigene Experimente:

Mit dem "isdnctrl dial ippp0" wird die Verbindung aufgebaut (von da ab kostet es Geld!). So werden Fehlverbindungseffekte vermieden, die entstehen, wenn man eine Verbindung per "telnet" zu einem anderen Rechner aufbauen will, ohne zu wählen. In diesem Falle gibt es nämlich "Hänger", weil es zu Timingproblemen nach dem Verbindungsaufbau kommt.
Wichtig ist auch, daß die Defaultroute erst nach dem vollständigen Aufbau der Verbindung gesetzt wird. Sonst entfernt der Kernel die Route vorzeitig und meldet dann beim Zugriff auf andere Rechner "network not reachable".

Test:

  root:# connect
  Calling ippp0
  Dialing of ippp0 triggered
  Sleeping 8 sec for PPP handshaking...
  Line open - checking...
  :-) Line is ok - have fun!
  root:# telnet foo.bar.com
  [...]

(nun wie gewohnt einloggen; später zum Abschluß "exit" eingeben)

  root:# connect off
  Last application stopped - closing line.
  prov0 hung up
  prov1 already closed! To force closing use "connect off all"
  root:# _

Was kann "connect"?

Die ersten beiden Varianten haben Sie gerade kennengelernt:

"connect" (oder "connect on")      Verbindung mit Defaultremote herstellen
"connect off"                      Verbindung abbrechen

Wichtiger Befehl:

"connect off all"                  bricht alle Verbindungen ab

Weitere Remotes lassen sich ganz einfach anwählen:

"connect remote1 (on)"             Verbindung mit remote1 herstellen
"connect remote1 off"              und wieder abbrechen

Wenn man mehrere Remotes angibt, wird einer nach dem anderen probiert, bis eine Verbindung zustandekommt. Das "on" ist immer optional.

"connect remote1 remote2 remote3 ..."

Man kann auch mehrere Verbindungen gleichzeitig aufbauen. Natürlich macht es dann keinen Sinn mehr, lauter Defaultroutes zu legen: sie darf nur einmal existieren. Bei mehreren offenen Leitungen muß man einzeln Routen legen:

"connect remote1 route Netz-IP"    Verbindung mit Route
"connect remote2 route default"    Verbindung mit Default-Route

Die Route muß zum Remote passen! Das "route default" ist nicht wirklich nötig.

Wenn die Einwahlports des Providers stark belastet sind, kann man eine Maximalanzahl von Einwahlversuchen angeben:

"connect remote1 maxtries versuche"

Wenn man kein "maxtries" angibt, wird der Defaultwert aus /usr/lib/connect/base verwendet.

Ähnlich ist das hiermit:

"connect remote1 device ttySn"

So gibt man bei Verwendung eines Modems die serielle Schnittstelle an, an der das Modem hängt. Ohne diese Angabe gilt das Defaultgerät, das in /usr/lib/connect/base definiert ist.

Weitere Utilities

Dem ISDN4Linux-Paket liegen noch etliche sehr brauchbare Werkzeuge bei. Eines ist zum Beispiel der unter X laufende "isdnmon" von Andreas Kool, mit dem der momentane Zustand des S0-Busses angezeigt wird (frei oder bestehende Verbindung). Das gleiche in einem Terminal macht "imon" von Michael Knigge. Sehr interessant ist auch "isdnlog" von Andreas Kool. "isdnlog" kann den Verkehrsablauf auf dem S₀-Bus mitprotokollieren. Mit "imontty" von Volker Goetz kann man auf die Schnelle feststellen, welche Kanäle der IDN-Karte gerade aktiv sind - dies ist beispielsweise in Scripten sehr brauchbar.

Man sehe sich dazu das README von Fritz Elfert an.