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 !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 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 | |
14.3. | Warum wählt ppp(8) im |
Ü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 Ein weiterer Grund dafür, dass die Zeile für die Standardroute fehlt, könnte der sein, dass Sie eine Standardroute in 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 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
| |
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 Wenn Sie festgestellt haben, ob es sich um ein lokales oder um ein externes Problem handelt, haben Sie zwei Möglichkeiten: | |
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 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:
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:
An der Eingabeaufforderung von gdb können Sie die Befehle | |
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 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 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 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 Alternativ kann der folgende Befehl (wobei set openmode active 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 Falls Sie solche Befehle verwenden möchten, benutzen Sie stattdessen den Befehl | |
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 |
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 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 | |
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 |
Das Programm ppp analysiert jede Zeile seiner Konfigurationsdatei, damit es Zeichenketten wie z.B. Wenn der Chat-Interpreter jedes Argument analysiert, reinterpretiert er die Argumente, um irgendwelche speziellen Escape-Sequenzen wie z.B. Falls Sie tatsächlich das Zeichen 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 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 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 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 |
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>.