PPP LCP Echo-Requests verändern/abstellen?

[robert_s]

Hat sich schon mal jemand damit beschäftigt, ob und wie man die ständigen PPP LCP Echo-Requests der Fritz!Box verändern oder abstellen kann?

Bei mir setzt die Fritz!Box alle 10 Sekunden einen Echo-Request ab, selbst wenn die Verbindung ganz offensichtlich noch funktioniert, weil ständig Daten reinkommen.

Ich würde gerne zumindest das Intervall deutlich raufsetzen, oder besser noch die Fritz!Box dazu bewegen, dass sie nur Echo-Requests schickt, wenn x Sekunden lang "Funkstille" auf der Verbindung war. Alternativ vielleicht auch ganz die Echo-Requests abstellen.

Zum Hintergrund: PPP LCP Echo-Requests waren sinnvoll zu Zeiten, als es nur externe DSL-Modems gab und der Router nicht feststellen konnte, wenn die DSL-Synchronisation verlorenging (allerdings war auch damals schon die elegantere Lösung, die Echo-Requests nur bei "Funkstille" einzusetzen, wie z.B. RASPPPOE es tut). Inzwischen "weiss" der Router Dank integriertem DSL-Modem aber, ob die DSL-Verbindung noch steht, sodass dieser Fehlerfall wegfällt. Und der Fall, dass im Leitungsnetz des Anbieters die Verbindung verschütt geht, tritt bei mir so selten auf, dass ich eigentlich keine Echo-Requests mehr brauche. Zumal ich sowieso meine Fritz!Box auf on-demand Verbindung gestellt habe, sodass wenn da nichts mehr rübergeht die Verbindung eh abgebaut und bei Bedarf neu aufgebaut wird - und dann wird eben auf diesem Umweg erkannt, dass die PPP(oE)-Gegenstelle nicht mehr erreichbar ist...

 

[frank_m24]

Hallo,

und was willst du damit erreichen?

Du machst übrigens einen katastrophalen Denkfehler: Es gibt einen Unterschied zwischen PPPOE Fehler und DSL Syncverlust, allein schon weil beides auf unterschiedlichen Schichten des OSI Modells abläuft. Und sowas wie Cross-Layer-Signalisierung sieht die DSL-PPP Spezifikation noch nicht vor. Durch deinen Eingriff würdest du also die PPP Statemachine durcheinander bringen.
Übrigens kann auch die Gegenseite einen LCP Timeout diagnostizieren und damit die PPP Verbindung kappen. Das war auch immer schon ein Problem beim RASPPPOE. Ganz abgesehen davon wäre eine Spezifikationsverletzung und die Box könnte damit die Zulassung als Endgerät verlieren.

Aber wie gesagt: Vorne dran steht bei mir die Frage nach der Sinnhaftigkeit dieses Ansinnens. Ich kann absolut keinen Grund erkennen, warum man alle 10 Sekunden (das sind immerhin Ewigkeiten) ein Paket von ein paar Byte unterbinden sollte. :noidea: Hast du mal ausgerechnet, wieviel Overhead das erzeugt im Gegensatz zu ATM Headern, IP Headern und MTU Fehlanpassungen? Vor allem letzterer ist dramatisch. Anders ausgedrückt: Du hast massiv Optimierungspotential an deiner Verbindung, bevor du dich an die LCP Pakete begeben musst.

 

[robert_s]

Du machst übrigens einen katastrophalen Denkfehler: Es gibt einen Unterschied zwischen PPPOE Fehler und DSL Syncverlust, allein schon weil beides auf unterschiedlichen Schichten des OSI Modells abläuft. Und sowas wie Cross-Layer-Signalisierung sieht die DSL-PPP Spezifikation noch nicht vor. Durch deinen Eingriff würdest du also die PPP Statemachine durcheinander bringen.

Kann ich nicht nachvollziehen. Wenn es bei mir einen DSL-Syncverlust gibt, erkennt die Fritz!Box auch den Verlust der PPP-Verbindung.

Übrigens kann auch die Gegenseite einen LCP Timeout diagnostizieren und damit die PPP Verbindung kappen. Das war auch immer schon ein Problem beim RASPPPOE.

Sowas ist mir nie zu Ohren gekommen, und ich hab das Teil schliesslich programmiert... Bisher haben die Telekom-Gegenseiten auch von sich aus Echo-Requests geschickt, aber wohl nur wenn da zu lange Funkstille war - und mit dieser "geschwätzigen" Fritz!Box passiert das ja nie. Ich glaube die Telekom schickt erst nach 120 Sekunden einen Echo-Request, aber das kann ich ja so nicht ausprobieren. Hmm, oder ich nehm mal RASPPPOE und entferne vorher die Echo-Requests daraus...

Ganz abgesehen davon wäre eine Spezifikationsverletzung und die Box könnte damit die Zulassung als Endgerät verlieren.

Also in 1TR112 Version 9.2 finde ich keinerlei Erwähnung von LCP Echo Requests. Wo soll das spezifiziert sein?

Aber wie gesagt: Vorne dran steht bei mir die Frage nach der Sinnhaftigkeit dieses Ansinnens. Ich kann absolut keinen Grund erkennen, warum man alle 10 Sekunden (das sind immerhin Ewigkeiten) ein Paket von ein paar Byte unterbinden sollte. :noidea: Hast du mal ausgerechnet, wieviel Overhead das erzeugt im Gegensatz zu ATM Headern, IP Headern und MTU Fehlanpassungen? Vor allem letzterer ist dramatisch. Anders ausgedrückt: Du hast massiv Optimierungspotential an deiner Verbindung, bevor du dich an die LCP Pakete begeben musst.

Ich habe einen VDSL2-Anschluss, die ATM-Header gibt's da nicht mehr. Das mit der MTU ist sowieso kein Problem.

Aber zur Sinnhaftigkeit: Zum einen stört das beim Paketmitschnitt, wenn da ständig diese Echo-Requests drin sind wenn man etwas analysieren möchte (kann man rausfiltern, aber wenn die gar nicht erst drin wären...). Ausserdem möchte ich mal eine exakte Messung meiner Bandbreite und Paketverluste durchführen können, und wenn da ständig diese Pakete reingesetzt werden, verpfuscht mir das die Messung. Ich will einfach mal eine "saubere" Leitung haben, auf der kein unangeforderter oder unnützer Datenverkehr auftaucht. Neben den LCP Echo-Requests sind da natürlich noch die IGMP-Queries von BRAS und DHCP-Server, aber erstere sollte die Telekom irgendwann beseitigen und zweitere sollten sich durch eine Deaktivierung von VLAN8 unterdrücken lassen.

Abgesehen davon sollte es an sich ja auch keine "Riesenoperation" sein, die Echo-Request ein- oder abzustellen. Hoffe ich jedenfalls. Ich wäre allerdings auch bereit, ein Binary (kdsldmod oder dsld?) im Hexeditor zu bearbeiten, um das hinzukriegen...

 

[Silent-Tears]

Ausserdem möchte ich mal eine exakte Messung meiner Bandbreite und Paketverluste durchführen können, und wenn da ständig diese Pakete reingesetzt werden, verpfuscht mir das die Messung.

Diese paar Byte verpfuschen dir die Messung bei einer vdsl2-Leitung? Ziemlich übertreibene Aussage, findest du nicht? Vor allem, weil diese Pakete dazugehören, und somit auch bei der Gesamtbandbreite mit Berücksichtigt werden sollten.

Aber nun gut, jeder nach seiner Fasson, mir wären ein paar "Ich habe die dickere Leitung"-Bytes 0 aufwand wert. Wenn du mir allerdigns nachweislich belegen könntest, dass das >1MBit/s ausmacht, dann würd ich das sogar noch einsehen....

 

[stinkstiefel]

Hast du schon überprüft ob die Änderung der Optionen in ar7 etwas bewirkt?

redial_delay_after_low_error = 10s;
redial_delay_after_ppp_timeout = 10s;

 

[robert_s]

Hast du schon überprüft ob die Änderung der Optionen in ar7 etwas bewirkt?

Danke für den Hinweis. Ich habe mal alle Vorkommnisse der Zahl 10 in den Konfigurationsdatei auf andere Werte gesetzt, auch die genannten beiden Werte, aber die LCP Echo-Requests blieben davon völlig unbeeindruckt bei ihrem 10s Intervall. Möglicherweise sind die überhaupt nicht per Konfigurationsdatei einstellbar und schlimmstenfalls hardcodiert...

 

[RalfFriedl]

Wenn es bei mir einen DSL-Syncverlust gibt, erkennt die Fritz!Box auch den Verlust der PPP-Verbindung.

Wenn die untere Eben nicht mehr geht, geht auch die darüber liegende nicht mehr? So eine Überraschung.
Aber es kann passieren, daß die obere Eben (PPP) nicht mehr geht, obwohl auf der unteren Eben (DSL) die Verbindung noch steht.

Aber zur Sinnhaftigkeit...

Dann verwende doch die Box nur als Modem und laß den Rechner die PPP-Verbindung übernehmen. Wenn Du selbst RASPPPOE geschrieben hast, solltest Du wissen, wie man das macht. Dann kannst Du messen und mitschneiden ganz nach Wunsch.
IGMP und DHCP hat übrigens normalerweise auf der PPP-Verbindung nichts verloren und ist mir auch noch nicht untergekommen.

Abgesehen davon sollte es an sich ja auch keine "Riesenoperation" sein, die Echo-Request ein- oder abzustellen. Ich wäre allerdings auch bereit, ein Binary (kdsldmod oder dsld?) im Hexeditor zu bearbeiten, um das hinzukriegen

Das Bearbeiten eines Programms mit dem Hexeditor ist tatsächlich keine "Riesenoperation". Das einzige Problem ist, die richtige Stelle zu finden.

 

[frank_m24]

Hallo,

Also in 1TR112 Version 9.2 finde ich keinerlei Erwähnung von LCP Echo Requests. Wo soll das spezifiziert sein?

Zitat der 1TR112 Version 9.2:

PPP shall conform to [23], [24], [26], [27] and [28]

Die zitierten Literaturverweise:

[23]        IETF RFC 1144: Compressing TCP/IP Headers 
[24]        IETF RFC 1332: The PPP Internet Protocol Control Protocol (IPCP) 
[26]        IETF RFC 1570: PPP LCP Extensions 
[27]        IETF RFC 1661: The Point-to-Point Protocol (PPP) 
[28]        IETF RFC 1994: PPP Challenge Handshake Authentication Protocol (CHAP)

"Shall" ist laut Nomenklatur ein hartes Requirement.

Dort vor allem interessant die RFC 1661. Ich zitiere:

Upon reception of an Echo-Request in the LCP Opened state, an Echo-Reply MUST be transmitted.

Echo-Request and Echo-Reply packets MUST only be sent in the LCP Opened state. Echo-Request and Echo-Reply packets received in any state other than the LCP Opened state SHOULD be silently discarded.

Hier ist "MUST" ein hartes Requirement.

Der Opened State ist - wie zu erwarten ist - nach der erfolgreichen Konfiguration der Zustand der etablierten Verbindung.

Opened
In the Opened state, a Configure-Ack has been both sent and received. The Restart timer is not running.
When entering the Opened state, the implementation SHOULD signal the upper layers that it is now Up. Conversely, when leaving the Opened state, the implementation SHOULD signal the upper layers that it is now Down.

"Should" ist ein weiches Requirement.

Wie man es dreht und wendet: LCP Echos sind hart gefordert. Weglassen ist eine Spezifikationsverletzung und kann zu unvorhergesehenem Verhalten führen.

 

[robert_s]

Dort vor allem interessant die RFC 1661. Ich zitiere:

Echo-Request and Echo-Reply packets MUST only be sent in the LCP Opened state.

Hier ist "MUST" ein hartes Requirement.

Wie man es dreht und wendet: LCP Echos sind hart gefordert. Weglassen ist eine Spezifikationsverletzung und kann zu unvorhergesehenem Verhalten führen.

Da hast Du Dich aber verlesen, ich habe das entscheidende Wörtchen mal oben rot markiert. Zur Verdeutlichung eine Übersetzung:

Echo-Request und Echo-Reply Pakete dürfen nur im LCP Opened Zustand gesendet werden.

Die Verwendung von Echo-Requests und Echo-Replies ist also keineswegs hart gefordert. Würde mich auch sehr überraschen. Falls Du einst noch nicht dabei gewesen sein solltest: Zu Analogmodem- und ISDN-Zeiten wurde auch PPP verwendet, und da wurden nie Echo-Requests/Replies gesendet, weil die magere Bandbreite dafür auch viel zu kostbar war.

Von der Verwendung von LCP Echo-Requests ist tatsächlich erst im PPPoE-RFC die Rede, und dort steht dann:

http://www.ietf.org/rfc/rfc2516.txt

It is RECOMMENDED that the Access Concentrator ocassionally send Echo-Request packets to the Host to determine the state of the session.

Also ist es sogar nicht nur lediglich empfohlen - die Empfehlung gilt auch einzig für die Serverseite! Dass der PPPoE-Client LCP Echo-Requests verwenden soll ist tatsächlich weder gefordert, noch empfohlen, noch überhaupt erwähnt!

 

[RalfFriedl]

Es ist trotzdem sinnvoll, wenn auch 10 Sekunden etwas häufig ist.

Von der praktischen Seite her sieht es aber nicht so aus, als könntest Du das den AVM-Boxen abgewöhnen.

 

[frank_m24]

Hallo,

das interpretiere ich ein wenig anders.

Echo-Request und Echo-Reply Pakete dürfen nur im LCP Opened Zustand gesendet werden.

Damit sind wir bei dem Problem der Interpretation von Standards. Bedeutet es, dass in keinem anderen Status LCP Opened Zustand gesendet werden dürfen, oder bedeutet es, dass es nur im LCP Opened Zustand ein MUST ist? Der englische Satz lässt beide Interpretationen zu.
Der nachstehende Satz, dass die Pakete in anderen Zuständen schweigend discarded werden sollten (SHOULD = weich!), deutet darauf hin, dass sie in anderen Zuständen vorkommen können. Das ist alles andere als ein "MUST not". Folglich trifft hier dann die Interpretation zu, dass es nur im Opened Zustand Pflicht ist, sonst wäre der zweite Zusatz widersprüchlich und würde eine Verhaltensweise für einen verbotenen Zustand beschreiben. Das ist in einem ausgereiften Standard aber nicht der Fall.

Falls Du einst noch nicht dabei gewesen sein solltest: Zu Analogmodem- und ISDN-Zeiten wurde auch PPP verwendet, und da wurden nie Echo-Requests/Replies gesendet, weil die magere Bandbreite dafür auch viel zu kostbar war.

Sogar über 9.6 kBit/s CSD Verbindungen im Mobilfunk werden LCP Pakete verschickt. Und da ist Bandbreite kostbar, wie du sicher bestätigen wirst. (Aus der Ecke komme ich nämlich, aus der Mobilfunkentwicklung.)
Noch krasser ist es für das Szenario, wenn man sein Handy an den Laptop stöpselt (z.B. per USB oder serieller Verbindung). Nutzt man den CSD "Nachfolger" der paketvermittelten Verbindung (GPRS, EDGE, UMTS), so terminiert die PPP Verbindung schon im Endgerät, existiert also nur zwischen Handy und Rechner (über die Luftschnittstelle wird bei GPRS nur die Payload geschickt). Und doch gibt es - auf dem kurzen und im Vergleich zur Mobilfunkverbindung um Größenordnung stabileren Kabel-Verbindung, LCP Echo Requests und Replies - eingeführt mit der Begründung der RFC Spezifikation. Wären sie optional, hätte man sich den Aufwand sparen können, und es ist in den ETSI und den nachfolgenden 3GPP Arbeitsgruppen auch sehr kontrovers diskutiert worden. Die Entscheidung war am Ende aber eindeutig.

Von der Verwendung von LCP Echo-Requests ist tatsächlich erst im PPPoE-RFC die Rede, und dort steht dann:

http://www.ietf.org/rfc/rfc2516.txt


Also ist es sogar nicht nur lediglich empfohlen - die Empfehlung gilt auch einzig für die Serverseite! Dass der PPPoE-Client LCP Echo-Requests verwenden soll ist tatsächlich weder gefordert, noch empfohlen, noch überhaupt erwähnt!

Es wird empfohlen für die Serverseite. Was das für die Client-Seite bedeutet, geht daraus nicht hervor. Es kann durchaus für die Client Seite verpflichtend sein, gefordert durch die anderen Standards, auf die verwiesen wird.

Ich bleibe dabei: Die Spezifikation muss man so interpretieren, dass LCP Echos eine harte Anforderung sind. Alle darauf aufbauenden Standards und Implementierungen, mit denen ich in den letzten 15 Jahren konfrontiert wurde, haben sie auch umgesetzt, obwohl man besonders im GPRS Fall wirklich darüber streiten kann.

 

[linuxkasten]

"must only" = "darf nur"

 

[robert_s]

Damit sind wir bei dem Problem der Interpretation von Standards. Bedeutet es, dass in keinem anderen Status LCP Opened Zustand gesendet werden dürfen, oder bedeutet es, dass es nur im LCP Opened Zustand ein MUST ist? Der englische Satz lässt beide Interpretationen zu.

Sehe ich nicht, die Sprache ist klar und es bedeutet erstere Interpretation. Letztere Interpretation hätte man schlichtweg ohne das "only" ausgedrückt.

Der nachstehende Satz, dass die Pakete in anderen Zuständen schweigend discarded werden sollten (SHOULD = weich!), deutet darauf hin, dass sie in anderen Zuständen vorkommen können. Das ist alles andere als ein "MUST not". Folglich trifft hier dann die Interpretation zu, dass es nur im Opened Zustand Pflicht ist, sonst wäre der zweite Zusatz widersprüchlich und würde eine Verhaltensweise für einen verbotenen Zustand beschreiben.

Keineswegs, das kann auch bei völlig standardkonformem Verhalten beider Seiten vorkommen, nämlich wenn eine Seite die Verbindung beendet, weiss die andere das schliesslich nicht "sofort". So schickt eine ein Echo-Request, die andere terminiert gerade. Die terminierende Seite SOLLTE an dieser Stelle den Request still verwerfen. Antworten darf sie sowieso nicht, aber jemand könnte ja auf die Idee kommen, eine Fehlermeldung auszuwerfen - ist aber nicht empfohlen, weil das auch bei einem völlig standardkonformen Verbindungsabbau nur unnötig Verwirrung stiftende Fehlermeldungen erzeugen würde.

Sogar über 9.6 kBit/s CSD Verbindungen im Mobilfunk werden LCP Pakete verschickt. Und da ist Bandbreite kostbar, wie du sicher bestätigen wirst. (Aus der Ecke komme ich nämlich, aus der Mobilfunkentwicklung.)

Hoffentlich nicht erst seit Du RFC 1661 fehlinterpretiert hast...

Ich bleibe dabei: Die Spezifikation muss man so interpretieren, dass LCP Echos eine harte Anforderung sind. Alle darauf aufbauenden Standards und Implementierungen, mit denen ich in den letzten 15 Jahren konfrontiert wurde, haben sie auch umgesetzt,

Dann ist Dir das Betriebssystem Microsoft Windows offenbar unbekannt. Dessen PPP-Stack in Windows 95/98/SE/ME/NT/2000 dachte nämlich gar nicht daran, LCP Echo-Requests zu verschicken. Und das weiss ich definitiv, denn ich musste die in RASPPPOE selbst implementieren (und entsprechend den LCP-Datenverkehr des PPP-Stacks "mitsniffen" um an die Magic Number zu kommen).

Wenn Du's nicht glaubst, kannst Du ja mal ein Windows 2000 mit RASPPPOE 0.94 ausprobieren...

Alternativ kannst Du auch mal den Verfasser von RFC 1661 anschreiben und ihn um Klärung bitten, ob LCP Echo-Requests im LCP Opened State "mandatory" sind. Kontaktinformationen findest Du ganz am Ende von RFC 1661.

 

[gg7]

Hat sich schon mal jemand damit beschäftigt, ob und wie man die ständigen PPP LCP Echo-Requests der Fritz!Box verändern oder abstellen kann?

Bei mir setzt die Fritz!Box alle 10 Sekunden einen Echo-Request ab, selbst wenn die Verbindung ganz offensichtlich noch funktioniert, weil ständig Daten reinkommen....

Hallo,
Ich wär auch daran interessiert... dabei geht's mir nicht um irgendwelche Vorschriften sondern nur darum, daß ich eine lausige Anbindung habe. Meine Fritzbox (7170) hängt hinter einem DSL-Modem. Leider unterbricht die Fritzbox die Verbindung immer wieder wegen fehlender Antworten auf die sehr häufigen LCP Echo Requests.
Grüße,
gg7

 

[frank_m24]

Da sind die LCP Echos aber nur ein Symptom des Problems und nicht die Ursache. Wenn man die LCP Echos abschaltet, gehen die Pakete auf der physikalischen Strecke trotzdem verloren, was auch dann zwangsläufig zum Verbindungsabbruch führt.

 

[gg7]

Dem stimm ich zu. In meinen Logs wurde der Abbruch immer von der Fritzbox ausgelöst - das hätte ich gern mal so geändert, daß erst getrennt wird wenn die Gegenstelle das macht.
Gibt es einen anderen Wert als lcpecho_auto, der in ar7.cfg verwendet werden kann, bei "lcpecho_disconnect_mode = lcpecho_auto;"?

 

[RalfFriedl]

Wenn keine Antwort auf die Echos kommt, dann liegt es meistens daran, dass überhaupt nichts mehr von der Gegenseite ankommt.
Woher soll also die Box wissen, dass die Gegenseite die Verbindung aufgegeben hat?

 

[gg7]

In meinen Logs kommen noch jede Menge Pakete von der Gegenseite an. Die Gegenseite selbst schickt auch Echo Requests, aber eben nur alle 30 Sekunden. Wenn irgendwer sagen könnte, was außer "lcpecho_auto" noch akzeptiert wird, würde ich das einfach mal ausprobieren.

Mir ist es schon einmal passiert, dass der zuständige Anbieter die Leitungsqualität nicht hingebracht hat und mir dann von heute auf morgen die Leitungslänge nachgerechnet hat - dabei hat er einige zusätzliche Meter gefunden und schwupps war der Anschluß nicht mehr DSL-fähig!
Mein DSL-Modem hat zwar noch synchronisiert und ich habe damit bis zu meinem Umzug gearbeitet und auch dafür bezahlt - durfte aber nicht mehr beim Anbieter nach technischer Unterstützung fragen. Damals hatte ich noch keine Fritzbox im Einsatz, sonst wär's wohl schnell zu Ende gewesen. Wenn sich das in der Fritzbox gar nicht einstellen lässt, probiere ich es halt mit meinem alten Router dazwischen, der dann die PPPOE Verbindung übernimmt. Vielleicht gönne ich mir auch ein neues DSL-Modem.

 

[MaxMuster]

Hilft dir das vielleicht?

root@Speedport:/var/mod/root# strings /lib/libar7cfg.so | grep  lcp
PPPCFG_lcpechodisconnectmode_enumdef
PPPCFG_lcpechodisconnectmode_enum
lcpecho_disconnect_mode
lcpechodisconnectmode
[B]lcpecho_auto
lcpecho_always
lcpecho_never[/B]
root@Speedport:/var/mod/root#

 

[gg7]

Danke. Damit kann ich schon mal testen.