Kapitel 14. PPP

14.1. Ich bekomme ppp(8) nicht zum Laufen. Was mache ich falsch?
14.2. Warum hängt sich ppp(8) auf, wenn ich es benutze?
14.3. Warum wählt ppp(8) im -auto-Modus nicht?
14.4. Was bedeutet No route to host?
14.5. Wieso werden meine Verbindungen nach ca. drei Minuten beendet?
14.6. Wieso bricht meine Verbindung bei hoher Auslastung ab?
14.7. Warum bricht die Verbindung nach unbestimmter Zeit zusammen?
14.8. Warum hängt meine Verbindung nach einer unbestimmten Zeit?
14.9. Was kann ich machen, wenn die Gegenstelle nicht antwortet?
14.10. Was kann ich tun, wenn sich ppp(8) aufhängt?
14.11. Ich sehe ständig Fehlermeldungen über gleiche „Magic Numbers“ Was heißt das?
14.12. Die LCP-Verhandlungen dauern an, bis die Verbindung geschlossen wird. Was mache ich falsch?
14.13. Warum reagiert ppp(8) nicht mehr, wenn ich es mit shell verlassen habe?
14.14. Warum wird ppp(8) niemals beendet, wenn es über ein Nullmodem-Kabel benutzt wird?
14.15. Warum wählt ppp(8) im Modus -auto ohne Grund?
14.16. Was bedeuten diese CCP-Fehler?
14.17. Warum protokolliert ppp(8) die Geschwindigkeit meiner Verbindung nicht?
14.18. Warum ignoriert ppp(8) das Zeichen \ in meinem Chat-Skript?
14.19. Was sind FCS-Fehler?
14.20. Nichts von alledem hilft - ich bin verzweifelt! Was soll ich machen?

14.1.

Ich bekomme ppp(8) nicht zum Laufen. Was mache ich falsch?

Lesen Sie zuerst ppp(8) und den Abschnitt zu PPP im Handbuch. Aktivieren Sie zur Fehlersuche die Protokollierung 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 den Abschnitt default der Konfigurationsdatei /etc/ppp/ppp.conf eingetragen werden. 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 in der Protokolldatei eine Menge darüber herausfinden, was geschieht. Es macht nichts, wenn die Einträge Ihnen gar nichts sagen. Wenn Sie jemandem um Hilfe bitten müssen, könnten sie für ihn von Nutzen sein.

14.2.

Warum hängt sich ppp(8) auf, wenn ich es benutze?

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

127.0.0.1        foo.example.com foo localhost

Andernfalls fügen Sie einfach einen weiteren Eintrag für den lokalen Rechner hinzu. Weitere Informationen finden Sie in den entsprechenden Manualpages.

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

14.3.

Warum wählt ppp(8) im -auto-Modus nicht?

Überprüfen Sie zunächst, ob eine Standardroute existiert. Das folgende Kommando sollte zwei Einträge anzeigen:

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

Wenn die Standardroute nicht erscheint, stellen Sie sicher, dass die Zeile HISADDR in /etc/ppp/ppp.conf hinzugefügt wurde.

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

delete ALL

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

14.4.

Was bedeutet No route to host?

Dieser Fehler beruht für gewöhnlich auf einem fehlenden Abschnitt in /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 des Gateways nicht bekannt ist. 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 Informationen finden Sie im Abschnitt PPP und Dynamische IP-Adressen des Handbuchs.

14.5.

Wieso werden meine Verbindungen nach ca. drei Minuten beendet?

Der Standardtimeout für PPP beträgt drei Minuten. Er kann durch die folgende Zeile eingestellt werden:

set timeout NNN

NNN gibt die Inaktivität in Sekunden an, bevor die Verbindung geschlossen wird. Falls NNN Null ist, wird die Verbindung niemals aufgrund eines Timeouts geschlossen. Es ist möglich, diesen Befehl in 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 Informationen finden Sie in der Manualpage ppp(8).

14.6.

Wieso bricht meine Verbindung bei hoher Auslastung ab?

Falls Link-Quality-Reporting (LQR) konfiguriert wurde, ist es möglich, dass zu viele LQR-Pakete zwischen dem FreeBSD-System und dem verbundenen Rechner verloren gehen. ppp(8) folgert daraus, dass die Verbindung nicht in Ordnung ist und schließt sie. LQR ist standardmäßig deaktiviert und kann mit der folgenden Zeile aktiviert werden:

enable lqr

14.7.

Warum bricht die Verbindung nach unbestimmter Zeit zusammen?

Wenn die Qualität der Telefonleitung zu schlecht oder beim Anschluss die Option Anklopfen aktiviert ist, kann es manchmal vorkommen, dass das 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. Lesen Sie die Dokumentation des Modems für weitere Informationen.

14.8.

Warum hängt meine Verbindung nach einer unbestimmten Zeit?

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

Wenn Sie ein externes Modem benutzen, können Sie versuchen, ping(8) zu benutzen, um zu sehen, ob die TD-Anzeige aufleuchtet, wenn Daten übertragen werden. 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 ppp.conf benutzen. Stellen Sie über pppctl(8) eine Verbindung zu ppp(8) her, wenn die Verbindung hängt. Falls die 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, 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 bei F: 14.9 weiter.

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

14.9.

Was kann ich machen, wenn die Gegenstelle nicht antwortet?

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 /etc/ppp/ppp.conf angeben, wodurch ppp(8) ermöglicht wird, ein externes Versagen zu erkennen und aufzulegen. Jedoch ist diese Erkennung relativ langsam und deshalb nicht besonders nützlich.

Versuchen Sie zunächst, jegliche Datenkompression auszuschalten, indem Sie folgendes zur 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 dem ISP. Andererseits wird hierdurch offensichtlich, dass Sie kein Microsoft®-System benutzen.

Aktivieren Sie asynchrones Logging und warten Sie, bis die Verbindung wieder hängt, bevor Sie sich an den 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 der 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.

14.10.

Was kann ich tun, wenn sich ppp(8) aufhängt?

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

Anschließend starten Sie ppp neu und warten darauf, 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 mit quit.

14.11.

Ich sehe ständig Fehlermeldungen über gleiche Magic Numbers Was heißt das?

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 Implementierungen 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(8) 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 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.

14.12.

Die LCP-Verhandlungen dauern an, bis die Verbindung geschlossen wird. Was mache ich falsch?

Es gibt derzeit eine Fehlfunktion in der Implementierung von ppp(8), die darin besteht, dass LCP-, CCP- und 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 zwei Implementierungen A und B vor. 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 lange 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 Informationen finden Sie in der Manualpage.

14.13.

Warum reagiert ppp(8) nicht mehr, wenn ich es mit shell verlassen habe?

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.

14.14.

Warum wird ppp(8) niemals beendet, wenn es über ein Nullmodem-Kabel benutzt wird?

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.

14.15.

Warum wählt ppp(8) im Modus -auto ohne Grund?

Falls ppp(8) unerwartet 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 protokolliert. Wenn das nächste mal unerwartet eine Verbindung hergestellt wird, wird der Grund zusammen mit einer hilfreichen Zeitangabe in der Logdatei gespeichert.

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 die 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. Sie sollten sicherstellen, dass Sie Sendmail in der Konfigurationsdatei sagen, dass es 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 die .mc-Datei einfügen:

define(`confDELIVERY_MODE', `d')dnl

Das veranlasst Sendmail dazu, alles in eine Warteschlange einzureihen, bis die Warteschlange verarbeitet wird (normalerweise alle 30 Minuten) oder wenn sendmail -q ausgeführt wird (z.B. aus /etc/ppp/ppp.linkup heraus).

14.16.

Was bedeuten diese CCP-Fehler?

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 auch lokal ausschalten:

disable pred1

14.17.

Warum protokolliert ppp(8) die Geschwindigkeit meiner Verbindung nicht?

Um alle Zeilen der Modemkonversation zu protokollieren, müssen Sie folgendes einstellen:

set log +connect

Dies veranlasst ppp(8) dazu, alles bis zur letzten angeforderten expect-Zeile zu protokollieren.

Falls Sie die Geschwindigkeit der Verbindung erfahren möchten und PAP oder CHAP nutzen, müssen Sie sicherstellen, dass Sie ppp(8) so konfigurieren, 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.

14.18.

Warum ignoriert ppp(8) das Zeichen \ in meinem Chat-Skript?

Das Programm ppp analysiert jede Zeile seiner Konfigurationsdatei, damit es Zeichenketten wie z.B. set phone "123 456 789" korrekt interpretieren und zudem erkennen kann, 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 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 \ senden möchten, benutzen Sie etwas 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"

Woraus sich folgende Zeichen ergeben:

ATZ
OK
ATDT1234567

14.19.

Was sind FCS-Fehler?

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 die Leitung schlecht ist, oder falls der serielle Treiber Pakete verwirft, werden gelegentliche FCS-Fehler generiert. Normalerweise lohnt es sich nicht, sich hierüber Gedanken zu machen, obwohl das Kompressionsprotokoll hierdurch wesentlich langsamer wird.

Falls die Leitung einfriert, sobald die Verbindung steht, und viele FCS-Fehler auftreten, müssen Sie sicherstellen, dass das Modem keinen Software-Flow-Control (XON/XOFF) verwendet. Falls die 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 gefolgt von term zu benutzen, um ppp(8) zu beenden, ohne die Verbindung zu beenden und Sie wieder mit der Shell auf dem entfernten Rechner verbinden.

Falls nichts in der Logdatei darauf hindeutet, warum die Verbindung beendet wurde, sollten Sie den Administrator oder ISP des externen Rechners fragen, warum die Sitzung beendet worden ist.

14.20.

Nichts von alledem hilft - ich bin verzweifelt! Was soll ich machen?

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 von netstat -rn (vor und nach Aufbau der Verbindung) an die FreeBSD general questions mailing list.

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.

Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.