Kapitel 14. PPP

Sie sollten zuerst ppp(8) (die Manualpage zu ppp) und den Abschnitt zu PPP im Handbuch lesen. Aktivieren Sie das Logging mit folgendem Befehl:

set log Phase Chat Connect Carrier lcp ipcp ccp command

Dieser Befehl kann an der Eingabeaufforderung von ppp(8) eingegeben oder in die Konfigurationsdatei /etc/ppp/ppp.conf eingetragen werden (der beste Ort hierfür ist der Anfang des Abschnitts default. Stellen Sie sicher, dass die Datei /etc/syslog.conf die folgenden Zeilen enthält und die Datei /var/log/ppp.log existiert:

!ppp
*.*              /var/log/ppp.log
         

Sie können nun über die Logfiles eine Menge darüber herausfinden, was geschieht. Es macht nichts, wenn die Einträge in den Logfiles Ihnen gar nichts sagen. Wenn Sie jemandem um Hilfe bitten müssen, könnten sie für ihn von Nutzen sein.

Das liegt meistens daran, dass Ihr Rechnername nicht aufgelöst werden kann. Um dieses Problem zu lösen, müssen Sie sicherstellen, dass die Datei /etc/hosts von Ihrem Resolver zuerst genutzt wird. Dazu muss in der Datei /etc/host.conf der Eintrag hosts an die erste Stelle gesetzt werden. Erstellen Sie dann einfach für Ihren lokalen Rechner einen Eintrag in der Datei /etc/hosts. Falls Sie kein lokales Netzwerk besitzen, ändern Sie die localhost-Zeile:

127.0.0.1    foo.example.com foo localhost

Andernfalls fügen Sie einfach einen weiteren Eintrag für Ihren lokalen Rechner hinzu. Weitere Details finden Sie in den betreffenden Manualpages.

Wenn Sie fertig sind sollten Sie ping -c1 `hostname` erfolgreich ausführen können.

Überprüfen Sie zunächst, ob Sie einen Standard-Gateway eingestellt haben. Wenn Sie netstat -rn ausführen, sollten Sie zwei Einträge ähnlich den folgenden sehen:

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0
         

Hier wird angenommen, dass Sie die Adressen aus dem Handbuch, der Manualpage oder aus der Datei ppp.conf.sample benutzt haben. Falls Sie keine Standardroute haben, kann es daran liegen, dass Sie vergessen haben, die Zeile HISADDR in der Datei ppp.conf hinzuzufügen.

Ein weiterer Grund dafür, dass die Zeile für die Standardroute fehlt, könnte der sein, dass Sie fälschlicherweise eine Standardroute in der Datei /etc/rc.conf eingetragen und die folgende Zeile in ppp.conf ausgelassen haben:

delete ALL

Lesen Sie in diesem Fall den Abschnitt Abschließende Systemkonfiguration des Handbuchs.

Dieser Fehler beruht für gewöhnlich auf einem fehlenden Abschnitt in Ihrer Datei /etc/ppp/ppp.linkup:

MYADDR:
  delete ALL
  add 0 0 HISADDR
         

Er ist nur notwendig, wenn Sie eine dynamische IP-Adresse besitzen oder die Adresse Ihres Gateways nicht kennen. Wenn Sie den interaktiven Modus benutzen, können Sie folgendes eingeben, nachdem Sie in den packet mode gelangt sind (den Paket Modus erkennen Sie an PPP im Prompt):

delete ALL
add 0 0 HISADDR
         

Weitere Details finden Sie im Abschnitt PPP und Dynamische IP-Adressen des Handbuchs.

Der Standardtimeout für ppp(8) beträgt drei Minuten. Er kann durch die folgende Zeile eingestellt werden, wobei NNN die Inaktivität in Sekunden angibt, bevor die Verbindung geschlossen wird:

set timeout NNN

Falls NNN Null ist, wird die Verbindung niemals aufgrund eines Timeouts geschlossen. Es ist möglich, diesen Befehl in die Datei ppp.conf einzubinden, oder ihn an der Eingabeaufforderung im interaktiven Modus einzugeben. Durch eine Verbindung zum Server-Socket von ppp über telnet(1) oder pppctl(8) ist es auch möglich, den Timeout bei aktiver Verbindung anzupassen. Weitere Details finden Sie in der Manualpage ppp(8).

Falls Sie Link-Quality-Reporting (LQR) konfiguriert haben, ist es möglich, dass zu viele LQR-Pakete zwischen Ihrer Maschine und dem verbundenen Rechner verloren gehen. Das ppp(8)-Programm folgert daraus, dass die Verbindung nicht in Ordnung ist und schließt sie. Vor FreeBSD Version 2.2.5 war LQR standardmäßig aktiviert; nun ist es standardmäßig deaktiviert. Es kann durch die folgende Zeile deaktiviert werden:

disable lqr

Wenn die Qualität Ihrer Telefonleitung zu schlecht oder bei Ihrem Anschluss die Option (Telekomdeutsch: das Leistungsmerkmal) Anklopfen aktiviert ist, kann es manchmal vorkommen, dass Ihr Modem auflegt, weil es (fälschlicherweise) annimmt, dass es das Trägersignal verloren hat.

Bei den meisten Modems gibt es eine Einstellmöglichkeit, um anzugeben, wie tolerant es gegenüber vorübergehenden Verlusten des Trägersignals sein soll. Bei einem U.S. Robotics® Sportster® wird dies zum Beispiel im Register S10 in Zehntelsekunden angegeben. Um Ihr Modem toleranter zu machen, können Sie zu Ihrem Wählbefehl die folgende Sende-Empfangs-Sequenz hinzufügen:

set dial "...... ATS10=10 OK ......"

Weitere Information sollten Sie dem Handbuch Ihres Modems entnehmen können.

Viele Leute machen Erfahrungen mit hängenden Verbindungen ohne erkennbaren Grund. Als erstes muss festgestellt werden, welche Seite der Verbindung hängt.

Wenn Sie ein externes Modem benutzen, können Sie einfach versuchen, ping(8) zu benutzen, um zu sehen, ob die TD-Anzeige aufleuchtet, wenn Sie Daten übertragen. Falls sie aufleuchtet (und die RD-Anzeige nicht), liegt das Problem am anderen Ende. Falls TD nicht aufleuchtet, handelt es sich um ein lokales Problem. Bei einem internen Modem müssen Sie den Befehl set server in Ihrer Datei ppp.conf benutzen. Stellen Sie über pppctl(8) eine Verbindung zu ppp(8) her, wenn die Verbindung hängt. Falls Ihre Netzwerkverbindung plötzlich wieder funktioniert (ppp wurde durch die Aktivität auf dem Diagnose-Socket wiederbelebt) oder Sie keine Verbindung bekommen (vorausgesetzt, der Befehl set socket wurde beim Start erfolgreich ausgeführt), handelt es sich um ein lokales Problem. Falls Sie eine Verbindung bekommen und die externe Verbindung weiterhin hängt, aktivieren Sie lokales asynchrones Logging mit set log local async und benutzen Sie ping(8) von einem anderen Fenster oder Bildschirm aus, um die externe Verbindung zu benutzen. Das asynchrone Logging zeigt Ihnen, welche Daten über die Verbindung gesendet und empfangen werden. Falls Daten hinausgehen, aber nicht zurückkommen, handelt es sich um ein externes Problem.

Wenn Sie festgestellt haben, ob es sich um ein lokales oder um ein externes Problem handelt, haben Sie zwei Möglichkeiten:

• Wenn es ein externes Problem ist, lesen Sie bitte bei F: 14.9. weiter.

• Handelt es sich um ein lokales Problem, lesen Sie bitte F: 14.10..

Hier können Sie wenig tun. Die meisten ISPs werden ablehnen, Ihnen zu helfen, wenn Sie kein Betriebssystem von Microsoft® benutzen. Sie können enable lqr in Ihrer Datei ppp.conf angeben, wodurch ppp(8) ermöglicht wird, ein externes Versagen zu erkennen und aufzulegen, aber diese Erkennung ist relativ langsam und deshalb nicht besonders nützlich. Evtl. sagen Sie Ihrem ISP nicht, dass Sie user-PPP benutzen.

Versuchen Sie zunächst, jegliche Datenkompression auszuschalten, indem Sie folgendes zu Ihrer Konfiguration hinzufügen:

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
         

Stellen Sie nun wieder eine Verbindung her, um festzustellen, ob sich etwas geändert hat. Falls es nun besser läuft oder falls das Problem vollständig behoben ist, versuchen Sie durch schrittweises Ändern der Einstellungen festzustellen, welche Einstellung den Unterschied bewirkt. Hierdurch erhalten Sie schlüssige Fakten für ein Gespräch mit Ihrem ISP (andererseits wird hierdurch offensichtlich, dass Sie kein Microsoft-Produkt benutzen).

Aktivieren Sie asynchrones Logging und warten Sie, bis die Verbindung wieder hängt, bevor Sie sich an Ihren ISP wenden. Hierzu kann einiges an Plattenplatz nötig sein. Die Daten, die als letztes von dem Port gelesen wurden, könnten von Interesse sein. Für gewöhnlich handelt es sich um ASCII-Text, der sogar den Fehler beschreiben kann (“Memory fault, Core dumped”).

Falls Ihr ISP hilfsbereit ist, sollte er in der Lage sein, an seinem Ende das Logging zu aktivieren und wenn das nächste Mal die Verbindung abbricht, könnte er Ihnen mitteilen, worin das Problem auf seiner Seite besteht. Gerne können Sie Details auch an Brian Somers <brian@FreeBSD.org> schicken, oder Ihren ISP bitten, sich direkt an ihn zu wenden.

In diesem Fall erstellen Sie am besten ppp(8) mit Debugging-Informationen neu und benutzen dann gdb(1), um von dem hängenden ppp Prozess eine Aufzeichnung des Stacks zu erstellen. Um die ppp Anwendung mit Debugging-Informationen zu übersetzen, geben Sie folgendes ein:

# cd /usr/src/usr.sbin/ppp# env DEBUG_FLAGS='-g' make clean
 	# env DEBUG_FLAGS='-g' make install

Anschliessend sollten Sie ppp neu starten und darauf warten, dass es wieder hängt. Wenn die Debug-Version von ppp hängt, starten Sie gdb für den steckengebliebenen Prozess, indem Sie folgendes eingeben:

# gdb ppp `pgrep ppp`

An der Eingabeaufforderung von gdb können Sie die Befehle bt oder where benutzen, um eine Aufzeichnung des Stacks zu erhalten. Speichern Sie die Ausgabe der gdb-Sitzung und “trennen” Sie den laufenden Prozess über den quit Befehl von gdb.

Schicken Sie zum Schluss das Log der gdb-Sitzung an Brian Somers <brian@FreeBSD.org>.

Bei FreeBSD-Versionen vor 2.2.5 wartete ppp(8) darauf, dass der Partner das Line Control Protocol (LCP) initiiert. Viele ISPs starten nicht mit der Initiierung, sondern erwarten dies vom Client. Benutzen Sie die folgende Zeile, um ppp(8) zu veranlassen, LCP zu initiieren:

set openmode active

Nach dem Aufbau einer Verbindung kann es sein, dass Sie in der Logdatei gelegentlich Meldungen mit dem Hinweis “magic is the same” sehen. Manchmal sind diese Meldungen harmlos und manchmal bricht die eine oder andere Seite die Verbindung ab. Die meisten Implementationen von PPP können dieses Problem nicht handhaben und Sie werden wiederholte Konfigurationsanforderungen und -bestätigungen in der Logdatei finden, bis ppp(8) schließlich aufgibt und die Verbindung beendet.

Dies geschieht normalerweise auf Servern mit langsamen Festplatten, bei denen ein getty auf dem Port ausgeführt und ppp(8) nach dem Einloggen von einem Login-Skript oder einem Programm aus gestartet wird. Es wurde auch schon berichtet, dass dies bei der Benutzung von slirp regelmäßig auftritt. Der Grund hierfür ist, dass das ppp(8) auf der Client-Seite in der Zeit, die benötigt wird, getty(8) zu beenden und ppp(8) zu starten, bereits beginnt, Line Control Protocol (LCP) Pakete zu senden. Da ECHO auf dem Serverport weiterhin eingeschaltet ist, werden diese Pakete zum ppp(8) auf der Client-Seite “reflektiert”.

Ein Teil der LCP-Verhandlungen ist die Einrichtung einer “Magic Number” für jede Seite der Verbindung, damit “Echos” erkannt werden können. Das Protokoll besagt, dass, wenn der Partner versucht, die gleiche “Magic Number” auszuhandeln, ein NAK zurückgesendet und eine neue "Magic Number" gewählt werden soll. Während der Server das ECHO eingeschaltet hat, sendet der Client LCP Pakete, sieht die gleiche “Magic Number” im reflektierten Paket und erzeugt ein NAK. Er sieht auch das reflektierte NAK (was bedeutet, dass ppp(8) seine "Magic Number" ändern muss). Hierdurch wird eine Vielzahl von Änderungen der “Magic Number” hervorgerufen, die sich allesamt im tty-Puffer des Servers ansammeln. Sobald ppp(8) auf dem Server startet, wird es mit Änderungen der “Magic Number” überflutet und entscheidet, dass es sich zur Genüge mit den LCP-Verhandlungen beschäftigt hat und gibt auf. Und während sich der Client noch darüber freut, dass er keine weiteren Reflexionen sieht, wird ihm gemeldet, dass der Server auflegt.

Dies kann verhindert werden, indem dem Partner durch die folgende Zeile in der Datei ppp.conf erlaubt wird, mit der Verhandlung zu beginnen:

set openmode passive

Hierdurch wird ppp(8) mitgeteilt, darauf zu warten, dass der Server mit den LCP-Verhandlungen beginnt. Einige Server starten jedoch nie mit der Verhandlungen; falls dies der Fall ist, können Sie folgendes tun:

set openmode active 3

Hierdurch bleibt ppp(8) für drei Sekunden passiv und fängt dann erst an, LCP-Anforderungen zu senden. Falls der Partner während dieser Zeit beginnt, Anforderungen zu senden, wird ppp(8) direkt antworten und nicht erst, nachdem die drei Sekunden abgelaufen sind.

Es gibt eine Fehlfunktion in der Implementierung von ppp(8), die darin besteht, dass LCP-, CCP- & IPCP-Antworten nicht mit den ursprünglichen Anforderungen assoziiert werden. Für den Fall, dass eine Implementation von PPP mehr als sechs Sekunden langsamer ist, als die andere Seite, resultiert das darin, dass die andere Seite zwei weitere LCP-Konfigurationsanforderungen sendet, was fatale Auswirkungen hat.

Stellen Sie sich vor, wir hätten es mit zwei Implementierungen A und B zu tun. A beginnt unmittelbar nach der Verbindung, LCP-Anforderungen zu senden und B benötigt sieben Sekunden, zu starten. Wenn B startet, hat A bereits drei LCP-Anforderungen gesendet. Wir nehmen an, dass ECHO ausgeschaltet ist; andernfalls würden wir Probleme mit der "Magic Number" beobachten, wie bereits im vorherigen Abschnitt beschrieben. B sendet eine Anforderung und anschließend eine Bestätigung der ersten Anforderung von A. Dies führt dazu, dass A in den Zustand OPENED übergeht und eine Bestätigung (die erste) zurück an B sendet. In der Zwischenzeit sendet B zwei weitere Bestätigungen als Antwort auf die zusätzlichen Anforderungen, die von A gesendet worden sind, bevor B gestartet ist. B empfängt dann die erste Bestätigung von A und geht in den Zustand OPENED über. A empfängt die zweite Bestätigung von B, geht zurück in den Zustand REQ-SENT und sendet eine weitere (vierte) Anforderung entsprechend dem RFC. A empfängt dann die dritte Bestätigung und geht in den Zustand OPENED über. In der Zwischenzeit empfängt B die vierte Anforderung von A, wechselt in den Zustand ACK-SENT und sendet eine weitere (zweite) Anforderung und (vierte) Bestätigung entsprechend dem RFC. A erhält die Anforderung, geht in den Zustand REQ-SENT über, sendet eine weitere Anforderung, erhält unverzüglich die nächste Bestätigung und geht in OPENED über.

Das geht so weiter, bis eine Seite erkennt, dass man zu keinem Ergebnis gelangt und aufgibt.

Am besten verhindert man solche Situationen, indem man eine Seite als passiv konfiguriert, also dafür sorgt, dass eine Seite darauf wartet, dass die andere mit den Verhandlungen beginnt. Das kann durch den folgenden Befehl geschehen:

set openmode passive

Diese Option sollten Sie mit Vorsicht genießen. Folgenden Befehl sollten Sie benutzen, um die Wartezeit auf den Beginn der Verhandlungen des Partners von ppp(8) zu begrenzen:

set stopped N

Alternativ kann der folgende Befehl (wobei N die Wartezeit in Sekunden vor Beginn der Verhandlungen angibt) benutzt werden:

set openmode active N

Weitere Details finden Sie in den Manualpages.

Wenn Sie den Befehl shell oder ! benutzen, führt ppp(8) eine Shell aus (falls Sie Argumente übergeben haben, führt ppp(8) diese Argumente aus). Das Programm ppp wartet auf die Beendigung des Befehls, bevor es seine Arbeit fortsetzt. Falls Sie versuchen, die PPP-Verbindung während der Programmausführung zu benutzen, wird es so aussehen, als wäre die Verbindung eingefroren. Das liegt daran, dass ppp(8) auf die Beendigung des Befehls wartet.

Falls Sie solche Befehle verwenden möchten, benutzen Sie stattdessen den Befehl !bg. Hierdurch wird der angegebene Befehl im Hintergrund ausgeführt und ppp(8) kann fortfahren, die Verbindung zu bedienen.

Es gibt keine Möglichkeit für ppp(8), automatisch festzustellen, ob eine direkte Verbindung beendet worden ist. Das liegt an den Leitungen, die bei einem seriellen Nullmodem-Kabel benutzt werden. Wenn Sie diese Art der Verbindung verwenden, sollte LQR immer mit der folgenden Zeile aktiviert werden:

enable lqr

LQR wird standardmäßig akzeptiert, wenn es vom Partner ausgehandelt wird.

Falls ppp(8) unerwarteterweise wählt, müssen Sie den Grund herausfinden und Wählfilter (dfilters) einsetzen, um dies zu verhindern.

Benutzen Sie die folgende Zeile, um den Grund herauszufinden:

set log +tcp/ip

Dadurch wird jeglicher Verkehr über die Verbindung geloggt. Wenn das nächste mal unerwartet eine Verbindung hergestellt wird, werden Sie den Grund zusammen mit einer hilfreichen Zeitangabe in der Logdatei finden.

Sie können nun das Wählen aufgrund dieser Bedingungen verhindern. Normalerweise wird diese Art von Problemen durch Anfragen an den DNS verursacht. Um zu verhindern, dass DNS-Anfragen den Aufbau der Verbindung hervorrufen (das verhindert nicht, dass Pakete über eine bestehende Verbindung gesendet werden), benutzen Sie die folgenden Zeilen:

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0
         

Dies ist nicht immer brauchbar, weil es effektiv Ihre Fähigkeit, auf Anforderung wählen zu können einschränkt - die meisten Programme müssen eine DNS-Anfrage durchführen, bevor Sie andere, das Netzwerk betreffenden Dinge tun können.

Im Fall von DNS sollten Sie versuchen, herauszufinden, welches Programm tatsächlich versucht, einen Hostnamen aufzulösen. Sehr oft handelt es sich hier um sendmail(8). Sie sollten sicherstellen, dass Sie sendmail in der Konfigurationsdatei sagen, dass keine DNS-Anfragen durchführen soll. Weitere Details enthält der Abschnitt E-Mail über Einwahl-Verbindungen des Handbuchs. Sie könnten z.B. die folgende Zeile in Ihre .mc-Datei einfügen:

define(`confDELIVERY_MODE', `d')dnl

Das veranlasst sendmail dazu, alles in eine Warteschlange einzureihen, bis die Warteschlange verarbeitet wird (normalerweise wird sendmail mit -bd -q30m aufgerufen, was besagt, dass die Warteschlange alle 30 Minuten abgearbeitet wird) oder, bis ein sendmail -q ausgeführt wird (z.B. aus Ihrer Datei ppp.linkup heraus).

Ich sehe ständig folgende Fehler in meiner Logdatei:

CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
         

Das liegt daran, dass ppp(8) versucht, die Komprimierung Predictor1 auszuhandeln und der Partner über keinerlei Komprimierung verhandeln will. Die Meldungen sind harmlos, aber wenn Sie sie beseitigen möchten, können Sie die Komprimierung Predictor1 auch lokal ausschalten:

disable pred1

Um alle Zeilen Ihrer “Modemkonversation” mitzuloggen, müssen Sie folgendes einstellen:

set log +connect

Dies veranlasst ppp(8) dazu, alles bis zur letzten angeforderten “expect”-Zeile mitzuloggen.

Falls Sie die Geschwindigkeit Ihrer Verbindung erfahren möchten und PAP oder CHAP (und deshalb nach dem CONNECT im Wählskript nichts mehr zu “chatten” haben - kein set login-Skript), müssen Sie sicherstellen, dass Sie ppp(8) anweisen, die gesamte CONNECT-Zeile zu “erwarten”, etwa so:

set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"

Hier bekommen wir unser CONNECT, senden nichts, erwarten dann einen Line-Feed, der ppp(8) zwingt, die gesamte CONNECT-Antwort zu lesen.

Das Programm ppp analysiert jede Zeile in Ihrer Konfigurationsdatei, damit es Zeichenketten wie z.B. set phone "123 456 789" korrekt interpretieren kann (und erkennen, dass es sich bei der Nummer tatsächlich nur um ein Argument handelt). Um das Zeichen " anzugeben, müssen Sie ihm einen Backslash (\) voranstellen.

Wenn der Chat-Interpreter jedes Argument analysiert, reinterpretiert er die Argumente, um irgendwelche speziellen Escape-Sequenzen wie z.B. \P oder \T (sehen Sie in die Manualpage) zu finden. Das Ergebnis dieser Doppelanalyse ist, dass Sie daran denken müssen, die richtige Anzahl an Escape-Zeichen zu verwenden.

Falls Sie tatsächlich das Zeichen \ z.B. zu Ihrem Modem senden möchten, brauchen Sie etwas ähnliches, wie:

set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"

Woraus sich folgende Zeichen ergeben:

ATZ
OK
AT\X
OK
         

Oder:

set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
         

Was folgende Zeichen ergibt:

ATZ
OK
ATDT1234567
         

Weder ppp noch andere Programme sollten Core-Dumps erzeugen. Da ppp(8) mit der effektiven Benutzerkennung 0 ausgeführt wird, wird das Betriebssystem das Coreimage von ppp(8) nicht auf die Festplatte schreiben, bevor es ppp(8) beendet hat. Falls ppp(8) jedoch tatsächlich aufgrund einer Speicherverletzung abbricht und Sie die aktuellste Version (siehe Anfang dieses Kapitels) benutzen, dann sollten Sie die Systemquellen installieren und folgendes tun:

# cd /usr/src/usr.sbin/ppp
# echo STRIP= >> /etc/make.conf
# echo CFLAGS+=-g >> /etc/make.conf
# make install clean

Nun ist die installierte Version von ppp(8) mit einem Debugger ausführbar. Sie können ppp(8) nun nur noch als root ausführen, da alle vorherigen Zugriffsrechte aufgehoben worden sind. Achten Sie darauf, in welchem Verzeichnis Sie sich gerade befinden, wenn Sie ppp(8) starten.

Wenn nun wieder eine Speicherverletzung auftreten sollte, wird ppp(8) einen Speicherauszug erzeugen, den Sie in der Datei ppp.core finden. Sie sollten dann folgendes tun:

% su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
....
(gdb) i args
....
(gdb) l
.....

Mit Hilfe all dieser Informationen sollte es möglich sein, das Problem zu diagnostizieren.

Falls Sie mit gdb(1) vertraut sind, könnten Sie weitere Einzelheiten herausfinden, z.B. wodurch der Fehler tatsächlich hervorgerufen wurde oder die Adressen und Werte der betreffenden Variablen.

Dies war ein bekanntes Problem bei ppp(8)-Konfigurationen, bei denen im Modus -auto dynamische, lokale IP-Adressen mit dem Partner ausgehandelt werden. Das Problem ist bereits seit einiger Zeit behoben - suchen Sie in den Manualpages nach iface.

Das Problem bestand darin, dass, wenn das erste Programm connect(2) aufruft, die IP-Adresse der tun(4)-Schnittstelle dem Socketendpunkt zugeordnet wird. Der Kernel erstellt das erste ausgehende Paket und schreibt es in das tun(4)-Gerät. ppp(8) liest dann das Paket und baut eine Verbindung auf. Falls die Schnittstellenadresse sich nun aufgrund ppp(8)s dynamischer Adresszuordnung ändert, wird der originale Socketendpunkt ungültig. Alle weiteren Pakete, die zum Partner gesendet werden, werden für gewöhnlich verworfen. Selbst wenn sie nicht verworfen werden würden, würden alle Antworten nicht an den betreffenden Rechner gelangen, weil die IP-Adresse nicht mehr zu diesem Rechner gehört.

Theoretisch gibt es mehrere Möglichkeiten, dieses Problem anzugehen. Am schönsten wäre es, wenn der Partner die gleiche IP-Adresse wieder zuordnen würde, wenn möglich. Die derzeitige Version von ppp(8) tut das, aber die meisten anderen Implementierungen nicht.

Die einfachste Maßnahme von unserer Seite wäre die, niemals die IP-Adresse der tun(4)-Schnittstelle zu ändern, sondern stattdessen alle ausgehenden Pakete so zu ändern, dass als Absender-IP-Adresse anstelle der IP-Adresse der Schnittstelle die ausgehandelte IP-Adresse gesetzt wird. Das ist im wesentlichen das, was durch die Option iface-alias in der aktuellsten Version von ppp(8) bewirkt wird (mit Unterstützung von libalias(3) und ppp(8)'s -nat Schalter) - alle Schnittstellenadressen werden beibehalten und auf die letzte ausgehandelte Adresse umgesetzt.

Eine andere Alternative (und wahrscheinlich die zuverlässigste) wäre die, einen Systemaufruf zu implementieren der die IP-Adressen aller verbundenen Sockets von einer Adresse in eine andere ändert. ppp(8) würde diesen Aufruf benutzen, um die Sockets aller laufenden Programme zu ändern, nachdem eine neue IP-Adresse ausgehandelt worden ist. Der gleiche Systemaufruf könnte von DHCP-Clients benutzt werden, wenn sie gezwungen werden, die bind()-Funktion auf ihren Sockets auszuführen.

Noch eine andere Möglichkeit wäre die, das Aktivieren von Schnittstellen ohne IP-Adresse zu erlauben. Ausgehende Paketen würde die IP-Adresse 255.255.255.255 gegeben, bis der erste ioctl(2) mit SIOCAIFADDR erfolgt. Dies würde in der vollständigen Verbindung des Sockets resultieren. Es wäre die Aufgabe von ppp(8), die Absender-IP-Adresse zu ändern, allerdings nur dann, wenn sie 255.255.255.255 lautet und nur die IP-Adresse und IP-Prüfsumme müssten geändert werden. Dies wäre allerdings keine besonders elegante Lösung, da der Kernel fehlerhafte Pakete an eine unzureichend konfigurierte Schnittstelle senden würde, in der Annahme, dass andere Mechanismen in der Lage sind, diese Dinge rückwirkend zu beheben.

Der Grund dafür, dass Spiele und andere Programme nicht funktionieren, wenn libalias(3) benutzt wird, ist der, dass der Rechner außerhalb des lokalen Netzes versucht, eine Verbindung aufzubauen und (unaufgefordert) UDP-Pakete an den Rechner innerhalb des lokalen Netzes zu senden. Die Software, die für die NAT zuständig ist, weiß nicht, dass sie diese Pakete an den internen Rechner weiterleiten soll.

Um dies zu beheben, stellen Sie zunächst sicher, dass die Software, mit der Sie Probleme haben, die einzige ist, die gerade läuft. Benutzen Sie dann entweder tcpdump(1) auf der tun(4)-Schnittstelle des Gateways oder aktivieren Sie auf dem Gateway das Logging von TCP/IP (set log +tcp/ip) unter ppp(8).

Wenn Sie nun das betreffende Programm starten, sollten Sie sehen, wie Pakete den Gateway-Rechner passieren. Wenn von außen etwas zurückkommt, wird es ignoriert (das ist das Problem). Merken Sie sich die Portnummer dieser Pakete und beenden Sie das betreffende Programm. Wiederholen Sie diesen Schritt einige Male, um festzustellen, ob die Portnummern konsistent sind. Falls dem so ist, wird die folgende Zeile im entsprechenden Abschnitt von /etc/ppp/ppp.conf dafür sorgen, dass das Programm funktioniert:

nat port proto internalmachine:port port

wobei für proto entweder tcp oder udp zu setzen ist, internalmachine den Rechner bezeichnet, an den die Pakete geschickt werden sollen und port die betreffende Portnummer.

Sie können das Programm nicht auf einem anderen Rechner benutzen, ohne die obige Zeile abzuändern und die Benutzung des Programms auf zwei internen Rechnern steht außer Frage - schließlich sieht die Außenwelt Ihr gesamtes internes Netz so, als wäre es ein einzelner Rechner.

Falls die Portnummern nicht konsistent sind, gibt es drei weitere Optionen:

1. Ermöglichen Sie die Unterstützung durch libalias(3). Beispiele für “spezielle Fälle” finden Sie in /usr/src/sys/netinet/libalias/alias_*.c (alias_ftp.c ist ein schöner Prototyp). Hierzu gehört für gewöhnlich das Lesen bestimmter, erkannter, ausgehender Pakete, die Identifizierung der Instruktion, die den entfernten Rechner dazu veranlasst, auf einem bestimmten (wahlfreien) Port eine Verbindung zurück zum lokalen Rechner herzustellen, sowie das Erstellen einer “Route” in der Aliastabelle, so dass nachfolgende Pakete wissen, wohin sie gehören.

   Dieses ist zwar die komplizierteste Lösung, aber die beste, die auch dafür sorgt, dass die Software auf mehreren Rechnern funktioniert.

2. Benutzen Sie einen Proxy. Die Anwendung könnte z.B. socks5 unterstützen, oder (wie im Fall von cvsup) eine Option “passiv” besitzen, die stets verhindert, dass verlangt wird, dass der Partner eine Verbindung zurück zur lokalen Maschine aufbaut.

3. Leiten Sie mit nat addr alles zur lokalen Maschine um. Dieses Vorgehen ähnelt dem mit einem Vorschlaghammer.

Noch nicht, aber hieraus könnte eine solche entstehen (falls Interesse besteht). In jedem Beispiel sollte internal durch die IP-Adresse der Maschine ersetzt werden, auf der das Spiel laufen soll.

• Asheron's Call

  nat port udp internal:65000 65000

  Konfigurieren Sie das Spiel manuell auf Port 65000 um. Wenn Sie von mehreren Rechner aus spielen wollen, weisen Sie jedem eine eindeutige Portnummer zu (also 65001, 65002, u.s.w.) und fügen Sie für jede Maschine eine eigene nat port Zeile ein.

• Half Life

  nat port udp internal:27005 27015

• PCAnywhere 8.0

  nat port udp internal:5632 5632

  nat port tcp internal:5631 5631

• Quake

  nat port udp internal:6112 6112

• Quake 2

  nat port udp internal:27901 27910

  nat port udp internal:60021 60021

  nat port udp internal:60040 60040

• Red Alert

  nat port udp internal:8675 8675

  nat port udp internal:5009 5009

FCS steht für Frame Check Sequence. Jedes PPP-Paket besitzt eine Checksumme, um sicherzustellen, dass die empfangenen Daten dieselben sind, wie die versendeten. Falls die FCS eines ankommenden Paketes fehlerhaft ist, wird das Paket verworfen und der Zähler HDLC FCS wird erhöht. Der HDLC-Fehlerwert kann durch den Befehl show hdlc angezeigt werden.

Falls Ihre Leitung schlecht ist (oder falls Ihr serieller Treiber Pakete verwirft), werden sie gelegentliche FCS-Fehler sehen. Normalerweise lohnt es sich nicht, sich hierüber Gedanken zu machen, obwohl das Kompressionsprotokoll hierdurch wesentlich langsamer wird. Wenn Sie ein externes Modem besitzen, stellen Sie sicher, dass Ihr Kabel ausreichend gegen Interferenzen abgeschirmt ist - das könnte das Problem beseitigen.

Falls Ihre Leitung einfriert, sobald die Verbindung steht, und viele FCS-Fehler auftreten, könnte das daran liegen, dass Ihre Leitung nicht 8-Bit-rein ist. Stellen Sie sicher, dass Ihr Modem keinen Software-Flow-Control (XON/XOFF) verwendet. Falls Ihre Datenschnittstelle Software-Flow-Control verwenden muss, benutzen Sie den Befehl set accmap 0x000a0000, um ppp(8) zu sagen, dass es die Zeichen ^Q und ^S maskieren soll.

Ein weiterer Grund dafür, dass zu viele FCS-Fehler auftreten, könnte der sein, dass das andere Ende aufgehört hat, ppp zu sprechen. Aktivieren Sie async Logging, um festzustellen, ob es sich bei den eingehenden Daten tatsächlich um einen login- oder Shell-Prompt handelt. Wenn Sie am anderen Ende einen Shell-Prompt haben, ist es möglich, durch den Befehl close lcp ppp(8) zu beenden, ohne die Verbindung zu beenden (ein folgender term-Befehl wird Sie wieder mit der Shell auf dem entfernten Rechner verbinden.

Falls nichts in Ihrer Logdatei darauf hindeutet, warum die Verbindung beendet wurde, sollten Sie den Administrator des externen Rechners (Ihren ISP?) fragen, warum die Sitzung beendet worden ist.

Vielen Dank an Michael Wozniak <mwozniak@netcom.ca> für die Erklärung und an Dan Flemming <danflemming@mac.com> für die Lösung für Mac OS.

Die Ursache des Problems ist ein so genannter “Black Hole Router”. Mac OS und Windows 98 (und wahrscheinlich auch die anderen Betriebssysteme von Microsoft) senden TCP Pakete, bei denen zum einen die angeforderte Segmentgröße zu groß für einen PPPoE-Rahmen ist (die Default-MTU für Ethernet beträgt 1500 Byte) und bei denen das “don't fragment” Bit gesetzt ist (das ist bei TCP allerdings Standard). Außerdem sendet der Router beim Provider nicht die eigentlich notwendigen “must fragment”-Meldungen zu dem Webserver, von dem Sie gerade eine Seite laden wollen. Es ist auch möglich, dass diese Meldung zwar erzeugt, aber danach von einem Firewall vor dem Webserver abgefangen wird. Wenn Ihnen dieser Webserver nun ein Paket schickt, das nicht in einen PPPoE-Rahmen passt, dann verwirft der Router dieses Paket und die Seite wird nicht geladen (einige Seiten/Grafiken werden geladen, weil ihre Größe kleiner ist als die MSS). Dies scheint leider der Normalfall zu sein.

Eine der möglichen Lösungen für dieses Problem ist die Erzeugung des folgenden Schlüssels in der Registry des Windows-Clients mit regedit:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU

Der Schlüssels sollte vom Typ String sein und den Wert 1436 haben, da einige ADSL-Router nicht mit größeren Paketen umgehen können. Wenn Sie Windows 2000 verwenden, müssen Sie hingegen den Schlüssel Tcpip\Parameters\Interfaces\ID der Netzwerkkarte\MTU benutzen, außerdem müssen Sie als Typ DWORD verwenden.

Die Knowledge Base von Microsoft enthält weitere Informationen darüber, wie sie die MTU einer Windows-Maschine ändern, damit diese mit einem NAT-Router korrekt zusammenarbeitet. Vom besonderen Interesse sind die Artikel Q158474 - Windows TCPIP Registry Entries und Q120642 - TCPIP & NBT Configuration Parameters for Windows NT®.

Bei Windows 2000 können Sie alternativ auch, wie im Artikel 120642 beschrieben, mit regedit das DWORD Tcpip\Parameters\Interfaces\ID der Netzwerkkarte\EnablePMTUBHDetect auf 1 setzen.

Mit den Bordmitteln von Mac OS ist es leider nicht möglich, die TCP/IP-Einstellungen zu verändern. Es gibt jedoch kommerzielle Lösungen, mit denen man die TCP/IP-Einstellungen bearbeiten kann. Wenn Sie als Mac OS-Anwender NAT benutzen, suchen Sie ihre MTU-Einstellungen und geben Sie dort 1450 statt 1500 ein.

ppp(8) kennt seit Version 2.3 den Befehl enable tcpmssfixup, mit dem die MSS automatisch korrigiert wird. Wenn Sie einen ältere Version von ppp(8) benutzen müssen, könnte der Port net/tcpmssd für Sie interessant sein.

Falls alles andere fehlschlägt, senden Sie möglichst umfangreiche Informationen, einschließlich Ihrer Konfigurationsdateien, wie Sie ppp(8) starten, die relevanten Teile Ihrer Logdateien und die Ausgabe des Befehls netstat -rn (vor und nach Aufbau der Verbindung) an die Mailingliste 'Fragen und Antworten zu FreeBSD' <de-bsd-questions@de.FreeBSD.org> oder die Newsgroup de.comp.os.unix.bsd. Irgend jemand sollte Ihnen dann weiterhelfen.