Wie sauberen DSL disconnect auslösen ?

[maik005]

@_jan_
danke.
Es ist dort ja wirklich einfach beschrieben.
Schon traurig das AVM es wohl seit Jahren/schon immer in der Hilfe falsch erklärt.
Dann ist es natürlich auch logisch, dass selbst bei korrigierbaren DTU die Geschwindigkeit sinkt, wenn die Anzahl der DTU/Zeiteinheit sehr groß ist.

Das heißt dann also, dass es vom Modem keine Fehlerkorrektur gibt?
Es wird nur geprüft, ob die DTU unbeschädigt ist und wenn die Prüfung fehlschlägt wird die DTU erneut vom DSLAM angefordert?

 

[chrisulin]

Wer kann denn hier garantieren, das all das theoretisch im Text verfasste, auch in der Praxis so umgesetzt wird?!

 

[BeeHaa]

@chrisulin
Warum sollte man auch immer alles was geregelt ist, negieren und hinterfragen?

Das funktionierte als ich es vor einiger Zeit mal ausprobiert hatte zuverlässig mit Fritzboxen (7530 und 7412) sowie einem Speedport Smart 2 (Gegenstelle für den Test war ein Allnet ALL126AM2). Bei Geräten von anderen Herstellern sollte man aber eher nicht damit rechnen, dass es klappt (mit einem Asus DSL-N17U und einem Draytek Vigor 130 ging es nämlich nicht).

An der Stelle ist das tatsächlich interessant. Wenn man den Stecker zieht, gehen für einen Mensche die Power-LEDs quasi augenblicklich aus. Was speichert da die Energie und für wie lange, damit das Modem noch ein Signal senden kann?
Kaka als ich eine Fritte das letzte Mal offen hatte, hab ich nicht dran gedacht nach Tantalkondensatoren zu suchen (?)

Bei einem Neustart wird kein Dying gasp gesendet, der ist nur für unvorhergesehene Ausfälle der Spannungsversorgung vorgesehen.

Das hängt alles IMHO auch nicht vom dying gasp ab. Bei einem Neustart gibt es wohl einen Zeitpunkt wo der Router ein "auf wiedersehen" sendet.
Bei einer harten Stromunterbrechung, ein "lebt wohl" (dying gasp). Aber wenn du dir das am 126AM2 anschauen konntest, dann kannst du auch dazu bestimmt was handfestes sagen
Es heißt eben, es gibt den log-in und den log-out.

Das passt jetzt auch zu meinem Kontext, also warum ich hier noch vorbeischaute, weil ich eigentlich fragen wollte wie man für sauberste Trennung den Zeitpunkt an einer Fritzbox erwischen kann. Die LEDs gehen da zwar in einem moment komplett aus, es gibt aber schon während dessen imho ein Geblinke und damit ist das irgendwie nicht so einfach zu erfassen (?)

Halte ich in DE aber eher für theoretisch und allgemeinbildend -> Was betreut in DE an Kupfer nicht die Telekom? Eben. Und die behauptet ja seit einer halben Ewigkeit bei allen solchen Anfragen, wenn die Verbindung auch mit einer harten Trennung länger als 1200 Sekunden getrennt ist (20min.) ist, wird beim neuen Aufbau der Verbindung das DLM nicht angewendet.
Allerdings scheint es mir, die haben dying gasp gelegentlich auch im Hinterkopf, denn wenn das mal einer von denen in 1-2 Sätzen mehr erklärt, meist die Rede davon ist erst das Netzteil ziehen und DANN ggf. aus der TAE

 

[chrisulin]

Warum sollte man auch immer alles was geregelt ist, negieren und hinterfragen?

Um mal wieder zum eigentlichen Threadtitel zu kommen:
Mir wird hier einfach zum Thema zuviel theoretisiert und ins mythologisch lächerliche geschrieben.
Solange hier keiner belastbare Daten über die Funktionsweise oder tatsächliches Insiderwissen besitzt und der Allgemeinheit mitteilt, würde ich es doch dabei belassen wie einige mit ASSIA/DLM oder wie man es immer nennen möchte, umgeht!
Wer noch keine negativen Erfahrungen damit gesammelt hat soll sich doch freuen und weiterhin fröhlich triggern. Lasst doch den anderen Betroffenen Ihre funktionierende Lösung zum Thema.

 

[_jan_]

Das heißt dann also, dass es vom Modem keine Fehlerkorrektur gibt?
Es wird nur geprüft, ob die DTU unbeschädigt ist und wenn die Prüfung fehlschlägt wird die DTU erneut vom DSLAM angefordert?

Wie schon erwähnt, gibt es zusätzlich auch noch die Vorwärtsfehlerkorrektur, die eine Ebene tiefer stattfindet. Sie wird also auf Empfängerseite zuerst angewendet.

Was speichert da die Energie und für wie lange, damit das Modem noch ein Signal senden kann?

Bei der Fritzbox 7530 hatte der Dying gasp im Test nur funktioniert, wenn man das Netzteil aus der Steckdose gezogen hat (beim Ziehen des Kabels an der Fritzbox ging es nicht).

---

Ansonsten habe ich mir jetzt mal den L3-Request näher angeschaut und ausprobiert.

Das ALL126AM2 bekommt leider keine DSL-Verbindung mehr zustabde, deshalb habe ich stattdessen ein Netsys NV-202 genommen. Das hat aber keine Management-Funktionen. Für die Auswertung verwende ich deshalb die Upstream-Fehlerzähler des verbundenden Modems (die werden ja von der Gegenstelle abgerufen). Als Modem habe ich eine Fritzbox 7530 mit OpenWrt benutzt.

Die üblichen Befehle zur Trennung/Wiederaufbau der DSL-Verbindung sind da /etc/init.d/dsl_control stop und /etc/init.d/dsl_control start. Auffällig ist dabei gleich, dass die Verbindungs-LED am Netsys nach einer Trennung noch einige Sekunden weiter leuchtet. Nach einem erneuten Verbindungaufbau ist dann der LOSS-Fehlerzähler (Loss of Signal Seconds) der Gegenstelle um 10 höher als vorher. Es ist also ziemlich eindeutig, dass so keine saubere Trennung stattfindet, und aus Sicht des Netsys ein plötzlicher Signalverlust auftritt.

Es gibt aber einen Befehl, mit dem sich ein L3-Request auslösen lässt, und zwar dsl_cpe_pipe.sh g997pmsft 3. Das steht für "G997_PowerManagementStateForcedTrigger", der Parameter 3 ist der gewünschte Zustand L3 (eine 0 stattdessen würde L0 entsprechen und die Verbindung wieder aufbauen). Bei einer Trennung mit diesem Befehl erlischt die Verbindungs-LED am Netsys sofort, und nach einer neuen Verbindung ist der LOSS-Zähler unverändert. Die saubere Trennung scheint also tatsächlich zu funktionieren.

---

Als nächstes habe ich versucht zu testen, wie sich die AVM-Firmware bei einem Neustart verhält.

Für den Test starte ich OpenWrt über den Bootloader aus dem RAM, sodass ein einfacher Wechsel zwischen der Originalfirmware und OpenWrt möglich ist. Alternativ hätte man aber natürlich auch zwei separate Geräte nehmen können.

Der Ablauf ist dann wie folgt:

1. Ich fange an unter OpenWrt, notiere mir den Stand des LOSS-Zählers, und lasse die DSL-Verbindung sauber über einen L3-Request trennen.
2. Danach wird die Box mit der AVM-Firmware neu gestartet (im Test die Version 7.90-114234). Nach dem Aufbau der DSL-Verbindung löse ich über das Webinterface einen Neustart aus. Sobald alle LEDs an der Fritzbox aufleuchten, trenne ich die Stromversorgung (die DSL-Verbindung ist zu dem Zeitpunkt auf jeden Fall getrennt, denn die LED am Netsys geht kurz vorher aus).
3. Nun starte ich die Box wieder mit OpenWrt. Nach Aufbau der DSL-Verbindung rufe ich nochmal den LOSS-Zähler ab, und vergleiche ihn mit dem vorherigen Wert.

Das ganze habe ich mehrmals ausprobiert, jedes Mal mit dem gleichen Ergebnis: Der LOSS-Zähler ist um 10 höher ist als vorher. Es gibt also beim Neustart der Fritzbox keine saubere Trennung.

 

[Grisu_]

Deine wertvollen Erfahrungswerte könnte man mal bei AVM als Verbesserungsvorschlag einbringen. ;-)

 

[_jan_]

Ich habe es mittlerweile auch mal ausprobiert, meinen richtigen DSL-Anschluss mit einem L3-Request zu trennen (Nokia MSAN, Broadcom 208.134 / 13.1.6).

Es funktioniert leider nicht. Hier ist das Ergebnis, das sich auch bei mehrmaligem Versuch nicht geändert hat:

root@Modem:~# dsl_cpe_pipe.sh g997pmsft 3
nReturn=-26

(Der Fehlercode -26 steht für einen Timeout.)

 

[arghmage]

Und wie man hier gut erkennen kann, gab es keine Anpassung mehr nach oben. Erst nachdem der Service eingegriffen hat, war die Leitungskapazität im UL wieder ausgelastet.
Im Übrigen waren das keine 3 Monate, sondern 4 Monate, wo an meinem Anschluss nichts passiert ist.

Die Anpassung nach oben hat bei mir bislang immer zuverlässig funktioniert. Es dauert immer etwas aber bei mir war dann z.B. alle paar Tage nachts ein Disconnect und der Upload wurde stückchenweise hochgefahren. Nun bin ich von ca. ISDN-Speed wieder auf 32,0 Mbit/s (von 40), mehr gibt die Leitung hier wohl nicht her.

 

[stoney]

@arghmage Ob die Leitung mehr her gibt, sollest Du an der "Leitungskapazität" auslesen können.

@_jan_ verstehe ich Dich richtig, dass zwar das passende Signal zwar gesendet wird, aber vom DSLAM ignoriert bzw. falsch behandelt wird?

 

[_jan_]

@stoney: Ja, so würde ich das Ergebnis auch interpretieren.

Dass der L3-Request tatsächlich gesendet wird ist anzunehmen, weil es ja mit dem NV-202 als Gegenstelle funktioniert.

Eigentlich müsste die Gegenstelle (also der DSLAM/MSAN) darauf antworten, und damit den Request entweder annehmen oder ablehnen. Wenn er angenommen wird, sollte zuerst das Modem aufhören zu senden, und danach auch die Gegenstelle sobald sie kein Signal mehr empfängt.

Aber diese Antwort scheint es hier aus irgendeinem Grund nicht zu geben.

Der VRX518-DSL-Treiber hat einen Timeout von 2 Sekunden. Wenn es bis dahin keine Antwort gibt, wird der Request wiederholt. Nach insgesamt 3 Versuchen bricht der Treiber ab, und gibt den Timeout-Fehler zurück.

Falls es jemand selber ausprobieren will: Einfach eine Fritzbox 7520/7530 mit OpenWrt nehmen, und bei aktiver DSL-Verbindung den Befehl aus dem vorherigen Post ausführen.

 

[stoney]

Sehr interessant, danke für Deine Test und Input, was zwar für weitere Diskussionen sorgen wird, aber zumindest sind wir hier einenem passenden Thread, wo es auch hingehört, daher "lasst die Spiele beginnen"