Hallo DSL-Freunde,
ich möchte nochmals die Diskussion aufwerfen, woran es liegt,
daß bei "falscher" Konfiguration des pppd die mru-Verhandlung
scheitert in dem Sinne, daß danach gewisse Server nicht mehr
erreichbar sind.
Andreas Könnecke hat geäußert, daß dies ein Problem der Gegenstelle
sein müßte, zumal es scheint, daß das Problem mit Siemens-Gegenstellen
auftritt, mit Ciscos aber nicht. Diese Vermutung erscheint mir
aber nicht gesichert, daher möchte ich das folgende Protokoll
nochmal zur Diskussion stellen:
----------------------------------------------------------------
Nov 8 16:43:23 server pppd[11972]: sent [LCP ConfReq id=0x1 ]
Nov 8 16:43:24 server pppd[11972]: rcvd [LCP ConfReq id=0x47 <auth pap> ] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
pppd schickt einen Request für die mru 1490. Eine Sekunde später
schickt die Gegenstelle einen Request für die mru 1492.
Nov 8 16:43:24 server pppd[11972]: sent [LCP ConfAck id=0x47 <auth pap> ]
pppd bestätigt die 1492, aber ...
Nov 8 16:43:25 server pppd[11972]: sent [LCP ConfReq id=0x1 ]
schickt nochmals einen Request für die 1490 !
Nov 8 16:43:26 server pppd[11972]: rcvd [LCP ConfAck id=0x1 ] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00
und der wird auch bestätigt!!!
---------------------------------------------------------------
Nach dieser Verhandlung weist pppd eine mtu von 1492 aus. Über
die mru gibt ifconfig keine Auskunft, wie kann ich mir diese
anschauen? Wir gingen bislang stillschweigend davon aus, daß
mru=mtu. Die mtu stand auf 1492, also müsse hier auch mru=1490
sein.
Ich sehe aber 2 Möglichkeiten:
1. Die mru steht tatsächlich auf 1492, dann muß man sich fragen,
warum pppd ein ACK für 1490 schickt, aber 1492 (für das er selbst
ein ACK erhalten hat) einstellt. Der Fehler würde hier beim pppd
liegen
2. Die mru steht in Wahrheit auf 1490. 1490 sollte im Prinzip
funktionieren, aber es könnten weiterhin Fehler auftreten, wenn
die Gegenstelle von 1492 ausgeht (für das sie ebenfalls ein
ACK geschickt hat). Bei der Gegenstelle würde dann "First wins"
gelten, gleich welche ACK's danach noch verschickt werden. Das
kann pppd nicht wissen, somit liegt hier der Fehler auf der
Seite der Gegenstelle.
Ich hätte hier die Möglichkeit, das Problem auf "verkürztem
Dienstweg" an einige Telekom-Techniker weiterzuleiten. Nicht
daß ich dort beschäftigt wäre... Bevor ich das tue würde ich
mir daher gerne ein klareres Bild verschaffen.
Erbitte Diskussionsbeiträge, ggf. auch weitere Protokolle.
- Matthias
