#

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