PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,303
- Punkte für Reaktionen
- 1,764
- Punkte
- 113
Die FRITZ!Box meldet bei allen möglichen Gelegenheiten "DSL antwortet nicht." - bei diesem Log waren es dann (nach der Support-Datei zu urteilen) aber doch Abstürze und Neustarts des "dsld":
Es ist für die Software auch gar nicht so einfach, diesen Umstand mit einer anderen Meldung zu kommentieren, denn die Zahl der Nachrichten, die ein "DSL" in ihrem (deutschen) Text haben, ist schon arg begrenzt (wenn hier auch aus der 07.11 und damit schon älter, für die 07.21 habe ich noch keine Liste erstellt):
Zwar kann die Message mit der Nummer 10 durchaus noch mit einer genaueren Erklärung erweitert werden (wie man am %s1 im Text sieht), aber das scheint nur sehr selten auch genutzt zu werden. Auch wäre es natürlich denkbar, daß man eine Nachricht ohne "DSL" dafür verwendet ... das erscheint mir aber auch nicht ganz logisch, weil es dem Benutzer die "Einordnung" des Problems ja wieder erschwert.
Auch muß das wohl der "dsld" gar nicht selbst schreiben ... AVM hat mittlerweile ein ziemlich komplexes "Event-System" entwickelt, bei dem die Komponenten nur noch über entsprechende Nachrichten miteinander kommunizieren und daher kann dieser Eintrag im Event-Log tatsächlich von jeder anderen Komponente erzeugt werden, die auf ein entsprechendes Event so reagieren soll.
Leider kann man nicht ohne weiteres erkennen, welche Komponente letzten Endes dann den Eintrag ins Event-Log erzeugt - aber man kann durchaus erkunden, daß es für DSL-Events mind. die Optionen:
Und auch in Anbetracht der Überlegung, wieviele andere Komponenten der Firmware da noch ein Interesse daran haben sollten zu erfahren, daß die DSL-Verbindung nicht mehr besteht, würde ich doch eher davon ausgehen, daß das über irgendein "avm_event_id_dsl_status"-Ereignis "verkündet" wird und dann eine andere Komponente daraufhin die Message mit der Nummer 10 in das Event-Log protokolliert - das wäre jedenfalls eine sinnvolle Aufgabenverteilung, weil es auch gleichzeitig (über die serielle Be-/Abarbeitung von solchen Events - das ist ja ein Vorteil einer Message- bzw. Event-basierten Architektur) konkurrierende Zugriffe auf das Event-Log - quasi automatisch - aus dem Spiel nimmt und man sich darum nicht weiter kümmern muß (mit allem, was da ggf. hinsichtlich Locking/Waiting noch dran hängt), wenn nur ein einzelner Prozess dieses Event-Log verwaltet.
Aber das führt jetzt sicherlich auch zu weit vom Problem des TO weg ... aber ein "So etwas kann's doch gar nicht geben, das ist doch klar." würde ich hier (so, wie es weiter oben jeweils begründet wurde bei den von mir aufgegriffenen Aussagen) definitiv nicht unterschreiben.
Es ist für die Software auch gar nicht so einfach, diesen Umstand mit einer anderen Meldung zu kommentieren, denn die Zahl der Nachrichten, die ein "DSL" in ihrem (deutschen) Text haben, ist schon arg begrenzt (wenn hier auch aus der 07.11 und damit schon älter, für die 07.21 habe ich noch keine Liste erstellt):
Code:
# grep "DSL" /var/media/ftp/YourFritz/eventlog_messages_07.11.txt
10=DSL antwortet nicht (Keine DSL-Synchronisierung%s1).
11=DSL ist verf��gbar (DSL-Synchronisierung besteht mit %s1/%s2 kbit/s).
12=DSL-Synchronisierung beginnt (Training).
126=DSL-Fallback auf Mobilfunk aktiv, Mobilfunknetz: %s
230=DSL Data E-Mail wurde an AVM versandt.
231=DSL Data E-Mail konnte nicht an AVM gesendet werden.
240=Die DSL-Einstellungen zur St�rsicherheit wurden ge��ndert.
241=Die DSL-Diagnose wurde gestartet.
242=Die DSL-Diagnose wurde beendet.
243=Die Kalibrierung f��r den DSL-Leitungstest wurde gestartet.
244=Der DSL-Leitungstest wurde gestartet.
7500=Die Internetverbindung (DSL) wurde getrennt. Die St�rung wurde m�glicherweise durch Powerline verursacht.
7501=Fehler bei der DSL-�.bertragung (CRC-Fehler). Der Fehler wurde m�glicherweise durch Powerline verursacht.
7502=Die DSL-�.bertragungsrate wurde eingeschr��nkt. Die St�rung wurde m�glicherweise durch Powerline verursacht.
7503=Das DSL-Signal wird m�glicherweise durch Powerline gest�rt.
#
Auch muß das wohl der "dsld" gar nicht selbst schreiben ... AVM hat mittlerweile ein ziemlich komplexes "Event-System" entwickelt, bei dem die Komponenten nur noch über entsprechende Nachrichten miteinander kommunizieren und daher kann dieser Eintrag im Event-Log tatsächlich von jeder anderen Komponente erzeugt werden, die auf ein entsprechendes Event so reagieren soll.
Leider kann man nicht ohne weiteres erkennen, welche Komponente letzten Endes dann den Eintrag ins Event-Log erzeugt - aber man kann durchaus erkunden, daß es für DSL-Events mind. die Optionen:
- avm_event_id_dsl_get
- avm_event_id_dsl_set
- avm_event_id_dsl_status
- avm_event_id_dsl_getarch
- avm_event_id_dsl_setarch
- avm_event_id_dsl_connect_status
Und auch in Anbetracht der Überlegung, wieviele andere Komponenten der Firmware da noch ein Interesse daran haben sollten zu erfahren, daß die DSL-Verbindung nicht mehr besteht, würde ich doch eher davon ausgehen, daß das über irgendein "avm_event_id_dsl_status"-Ereignis "verkündet" wird und dann eine andere Komponente daraufhin die Message mit der Nummer 10 in das Event-Log protokolliert - das wäre jedenfalls eine sinnvolle Aufgabenverteilung, weil es auch gleichzeitig (über die serielle Be-/Abarbeitung von solchen Events - das ist ja ein Vorteil einer Message- bzw. Event-basierten Architektur) konkurrierende Zugriffe auf das Event-Log - quasi automatisch - aus dem Spiel nimmt und man sich darum nicht weiter kümmern muß (mit allem, was da ggf. hinsichtlich Locking/Waiting noch dran hängt), wenn nur ein einzelner Prozess dieses Event-Log verwaltet.
Aber das führt jetzt sicherlich auch zu weit vom Problem des TO weg ... aber ein "So etwas kann's doch gar nicht geben, das ist doch klar." würde ich hier (so, wie es weiter oben jeweils begründet wurde bei den von mir aufgegriffenen Aussagen) definitiv nicht unterschreiben.