14.1. | Ich bekomme ppp(8) nicht zum Laufen. Was mache ich falsch? |
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
!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. | |
14.2. | Warum hängt sich ppp auf, wenn ich es benutze? |
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 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 | |
14.3. | Warum wählt ppp(8) im
|
Überprüfen Sie zunächst, ob Sie einen
Standard-Gateway eingestellt haben. Wenn Sie
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
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 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 Ihrer Datei
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
delete ALL
add 0 0 HISADDR
Weitere Details 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(8) beträgt
drei Minuten. Er kann durch die folgende Zeile eingestellt werden,
wobei set timeout NNN Falls | |
14.6. | Wieso bricht meine Verbindung bei hoher Auslastung ab? |
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 | |
14.7. | Warum brechen meine Verbindungen nach unbestimmter Zeit zusammen? |
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. | |
14.8. | Warum hängen meine Verbindung nach einer unbestimmten Zeit? |
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
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 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 | |
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 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 Schicken Sie zum Schluss das Log der
gdb-Sitzung an Brian Somers | |
14.11. | Warum passiert nach der Nachricht „Login OK!“ nichts? |
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 Anmerkung:Für gewöhnlich schadet es nicht, wenn beide Seiten versuchen, Verhandlungen einzuleiten. Deshalb ist openmode nun standardmäßig aktiv. Im nächsten Abschnitt wird allerdings erklärt, in welchen Fällen es doch schadet. | |
14.12. | 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 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
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.13. | Die LCP-Verhandlungen dauern an, bis die Verbindung geschlossen wird. Was mache ich falsch? |
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 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 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
set openmode active N Weitere Details finden Sie in den Manualpages. | |
14.14. | 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.15. | Warum wird ppp(8) niemals beendet, wenn ich es über ein Nullmodem-Kabel benutze? |
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.16. | Warum wählt ppp(8) im Modus |
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 define(`confDELIVERY_MODE', `d')dnl Das veranlasst sendmail dazu, alles
in eine Warteschlange einzureihen, bis die Warteschlange
verarbeitet wird (normalerweise wird sendmail mit
| |
14.17. | 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 Predictor1 auch lokal ausschalten: disable pred1 | |
14.18. | Warum loggt ppp die Geschwindigkeit meiner Verbindung nicht? |
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 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.19. | Warum ignoriert ppp(8) das Zeichen
|
Das Programm ppp analysiert jede
Zeile in Ihrer 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"
Was folgende Zeichen ergibt:
ATZ
OK
ATDT1234567
| |
14.20. | Warum gibt es die Datei |
Weder ppp noch andere Programme
sollten Core-Dumps erzeugen. Da ppp(8) mit der effektiven
Benutzerkennung #
#
#
#
Nun ist die installierte Version von ppp(8) mit
einem Debugger ausführbar. Sie können
ppp(8) nun nur noch als Wenn nun wieder eine Speicherverletzung auftreten
sollte, wird ppp(8) einen Speicherauszug erzeugen,
den Sie in der Datei % 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. | |
14.21. | Warum bekommt das Programm, das eine Anwahl im Modus
|
Dies war ein bekanntes Problem bei
ppp(8)-Konfigurationen, bei denen im Modus
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
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
Noch eine andere Möglichkeit wäre die, das
Aktivieren von Schnittstellen ohne IP-Adresse zu erlauben.
Ausgehende Paketen würde die IP-Adresse
| |
14.22. | Warum laufen die meisten Spiele mit dem |
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
( 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 nat port proto internalmachine :port port wobei für 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:
| |
14.23. | Hat jemand eine Liste mit nützlichen Portnummern erstellt? |
Noch nicht, aber hieraus könnte eine solche
entstehen (falls Interesse besteht). In jedem Beispiel
sollte
| |
14.24. | Was sind FCS-Fehler? |
FCS steht für 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
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 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. | |
14.25. | Wieso hängen die Verbindungen meiner Mac OS®- und Windows® 98-Maschinen (und eventuell auch andere Microsoft® Betriebssysteme), wenn auf meinem Gateway PPPoE läuft? |
Vielen Dank an Michael Wozniak
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 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 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
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 ppp(8) kennt seit Version 2.3 den Befehl
| |
14.26. | 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 des Befehls |
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>.