PRTG Fritz!Box

Die anhaltende Instabilität meiner DSL-Verbindung nach einem Update von Firmware 6.20 auf 6.23 hat mich bewogen, diesen Sensor zu entwickeln, der die Fehlerdaten der Fritz!Box in PRTG verfügbar macht. Zudem hat Paessler den bislang mitgelieferten PRTG-Sensor für die Fritz!Box mit der Version 16.x.23 eingestellt.

AVM TR-064 – First Steps
https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/AVM_TR-064_first_steps.pdf

Paessler Fritz!Box-Sensor - entfallen

Hinweis: Dieser Sensor ist nicht mehr verfügbar
Which sensor types will you remove from PRTG and what are the alternatives?
https://kb.paessler.com/en/topic/68227-which-sensor-types-will-you-remove-from-prtg-and-what-are-the-alternatives
Sensor Types Deprecated as of PRTG 16.x.23: "AVM FRITZ!Box WAN Interface v2

PRTG enthält schon einen "WAN-Monitor" für die Fritz!Box, aber der erfasst nur den Traffic In/Out, Calls und die "Connection Time", aber keine weitergehende DSL-Parameter oder WiFi-Daten. Nachdem ich aber mal einen Tag fast nicht arbeiten konnte, weil die DSL-Verbindung immer wieder weggebrochen ist, habe ich mir gewünscht, dass PRTG doch etwas besser ermittelt, wenn die Abbrüche sich häufen. Hier mal ein Bild des eingebauten Sensors. Nette Werte und Bilder zu dem Verkehr und eine Connection Time von "1s/1s" sieht schon mal gut aus.

Das ist zwar ein Anfang, aber bei dem folgenden Problem noch keine Hilfe.

Ich könnte mir durchaus vorstellen, dass Paessler z.B. aufgrund meiner Vorarbeit auf dieser Seite ihren eigenen Sensor etwas erweitert. Eigentlich würde ich mir es sogar wünschen, dass der PRTG-Sensor für die Fritz!Box auch andere wichtige Daten abgreift und so einer Vielzahl von Personen verfügbar macht.

Daten aus dem Log

Schau ich dann aber in das Log der Fritz!Box, dann sieht das schon gar nicht mehr so schön aus. Alle 3 Minuten bricht die Verbindung ab und braucht natürlich wieder einige Zeit um neu hergestellt zu werden.

Sehr viele Trennungen an einem Tag sind auch in Verbindung mit Outlook im Cached Mode und OneDrive und OneDrive Business als Cache zu viel. Da wäre es ja schon mal interessant, wann solche Häufungen auftreten, die weit mehr sind als die Zwangstrennung nach 24h. Genau genommen in ich richtig froh, dass ich in so einem Fall immer noch einen "richtigen ISDN-Anschluss" habe und noch nicht auf "VoIP by Telekom" umgestellt wurde. Auch wenn ich ansonsten eigentlich eher ein VoIP-Freund bin. Dazu müssen aber die Verbindungswege stabil funktionieren. Leider sendet die Fritz!Box keine Alarme oder SYSLOG oder SNMP-Traps.

DSL Information

Auf der Fritz!Box gibt es aber noch einen sehr viel detaillierteren Bericht über die Verbindung und da sind durchaus einige interessante Optionen sichtbar.

Hier sind z.B.: die Fehlerzähler ein sehr wichtiger Indikator für die Qualität. Diese Zahlen wollte ich gerne in PRTG haben. Also habe ich geschaut, wie ich diese anzapfen kann.

Die Wahl der API

Nachdem ich meine Fritz!Box etwas analysiert habe, musste ich feststellen, dass eine einfache Abfrage per SNMP und eine Protokollierung per Syslog nicht zur Verfügung stehen. Also bleiben nur zwei Optionen

  • HTML-Parsing
    Da viele Informationen der Fritz!Box auch über einen Browser erreichbar sind, ist dieser Weg fast immer möglich. Ein Skript gibt sich als Browser aus, meldet sich an und lädt die HTML-Seite um darin die Texte zu extrahieren. Das habe ich z.B.: bei meinem Wechselrichter (Siehe PRTG Kostal) auch schon so gemacht. Bei der Fritz!Box ist die Anmeldung etwas besonders, da als Schutz gegen DoS-Attacken mit SessionIDs gearbeitet wird. Aber es ist machbar.
    Weitere Einschränkungen sind aber, dass eine Änderung der Webseite wieder eine Anpassung des Parsers erforderlich macht und die Anmeldedaten irgendwo hinterlegt werden müssen.
  • UPnP / TR64
    Der zweite Weg ist die Nutzung der TR64 Schnittstelle, die AVM auch sehr gut auf "Schnittstellen für Entwickler (https://avm.de/service/schnittstellen/) dokumentiert hat

Ich habe mich für den TR64-Weg entschieden, da er nach Aktivierung der Funktion auf der Fritz!Box ohne Anmeldedaten erreichbar ist. Leider sind aber nicht alle Bereiche anonym über UPnP erreichbar. Für einige Daten ist weiterhin eine Anmeldung erforderlich.

PRTG-Fritz!Box V2

Die Version 2 baut auf den Arbeiten der Seite Fritz!Box Monitoring auf und ermittelt per UPnP und TR64 über drei SOAP-Aufrufe umfangreiche Daten der Fritz!Box. Allerdings verzichte ich auf Daten des NAS oder der Telefonie. als PRTG:Custom Sensor wird er durch PRTG z.B. alle 60 Sekunden einmal gestartet und braucht meist nur eine Sekunde, um Daten zu liefern. Hier ein Bild der ermittelten Daten:

Neu gegenüber V1 ist an diesem Sensor, dass ich erstmals eine CSV-Datei zur Steuerung nutze. In der Datei wird über Spalten zu jedem Wert folgendes festgelegt.

  • channel
    Das ist der Name des Kanals in der Quelle, der zugleich auch Kanalname in PRTG wird
  • float
    Hier sind die Werte 0 oder 1 möglich, um PRTG mitzuteilen, ob es ein Integer oder Fließkommazahlen sind
  • mode
    "Absolute" sagt PRTG, dass der Wert ein absoluter Wert ist. Über "Difference" können Sie PRTG anweisen, den Wert vom vorherigen abzuziehen und so Differenzielle Werte zu erhalten
  • customunit
    Hier kann ich die Einheit des Kanals beschreiben
  • calc
    Das ist das stärkste Feld, da es mir erlaubt, den Wert über PowerShell-Formeln umzuschreiben, die über "Invoke-Expression" ausgeführt werden. Achten Sie aber bitte darauf, dass der Code hier "safe" ist, da er natürlich auch ein Einfallstor für Angriffe sein könnte

Da ein Teil der Werte der Fritz!Box anonym aber andere Werte nicht anonym ermittelt werden können, benötigt das Skript das Kennwort der Fritz!Box. Am besten hinterlegen Sie es in der Konfiguration:

Alternativ können Sie es natürlich auch im Skript hinterlegen oder einbinden. Das dürfte dann die sicherere Version sein.

Wenn Sie kein Kennwort mitliefern, dann überspringt das Skript die Aufrufe, die nicht anonym möglich sind. Über einen Tag lassen sich dann einfach Werte ermitteln:

Am unteren Rand sehen sie erste mal die aktuelle Übertragungsraten In/Out. Der obere Strich, der Links bei 650.000 steht, ist die aufsummierte Übertragungsmenge, die aber bei der Trennung wieder zurück gesetzt wird. Der Wert ist also nur bedingt hilfreich. die beiden Linien in der Mitte zeigen den Signalabstand beim Senden/Empfangen. Der Wert kann über mehrere Wochen interessant werden, um z.B. eine Verschlechterung der Leitung abhängig von Nachbarn, Umbauten, Wetter o.ä. zu belegen. Schon beim Blick über 48 Stunden sehen Sie auch mal Spitzen beim Download und wieder den

Download PRTG-Fritz!Box Version 2

Die Lösung besteht aus einem PowerShell-Script, welches aus einer CSV-Datei die gewünschten Parameter ausliest. Sie können in der CSV-Datei die Zeilen entfernen, die sich nicht erfassen wollen. Die volle CSV liefert 36 Werte in den Sensor.

prtg-fritzbox2.20221004.ps1.txt
prtg-fritzbox2.definition.csv.txt

Legen Sie das Skript und die CSV-Datei direkt im EXEXML-Verzeichnis der PRTG Installation ab.

Das Skript nutzt noch nicht "Invoke-WebRequest" sondern die alten HTTP-Clients. TLS 1.2 Zwang ist aktiv und Zertifikatsprüfung abgeschaltet. Eine sehr alte Fritz!Box, die kein TLS 1.2 unterstützt, erfordert Skript-Anpassungen. Auch der Benutzername wurde von "dslf-config" auf "fritzdefault" geändert und als Parameter addiert.

Wenn Sie das Skript mit dem User "fritzdefault" ohne Kennwort starten, dann bekommen Sie nur eine Teilmenge der Daten. Sie sollten in der Fritz!Box einen eigenen User mit Kennwort anlegen und dem Skript entweder als Parameter übergeben oder direkt ins Skript schreiben oder von eine anderen "sicheren Quelle" holen. Siehe dazu auch PS Passwort / Kennwort und PowerShell Keyvault.

PRTG-Fritz!Box V1 (alt)

Dieser Absatz ist noch hier, weil es eine Version 1 des Sensors gegeben hat. Ich nutze ihn aber nicht mehr.

Mit den Grundlagen, wie man per HTTP(S), PowerShell und TR-064 an die Daten kommt ist nun klar. Auf der Seite PRTG:Custom Sensor habe ich beschrieben, wie man per PowerShell Daten ermitteln und an PRTG übergibt. Aufgrund meiner "Probleme" mit der Fritz!Box durch das Updates von Firmware 6.20 auf 6.23 haben mich natürlich die Counter rund um die Fehlerraten interessiert. Und so habe ich mir einen Custom Sensor hierfür gebaut, der erst mal sehr viele Wert erfasst und in einem Sensor hinterlegt. Ich hole mir dazu zwei Daten ab.

  • urn:dslforum-org:service:WANDSLInterfaceConfig:1#GetInfo
    Dies sind absolute Daten, wie z.B. die Bandbreite etc.
  • urn:dslforum-org:service:WANDSLInterfaceConfig:1#GetStatisticsTotal
    Dieser Bereich enthält numerische Werte, die sich aufaddieren. Daher werden diese als "Difference" in PRTG eingespeist, d.h. PRTG bildet die Differenz vom aktuellen Messwert und dem vorherigen Wert

In der ersten Version habe ich einfach mal ALLE Werte, die beide Bereiche liefern, in einem Sensor zusammen gefasst.

Über die Filter-Funktionen in der GUI bzw. der Konfiguration kann ich später in den Grafiken einzelne Linien Ausblenden und die Einheiten vergeben. Das bedeutet zwar bei der Ersteinrichtung etwas mehr Arbeit, aber ich spare mit die einzelne Parametrisierung jedes Messwerts in der XML-Datei, die sowieso dann nur beim ersten Anlegen genutzt wird. Nach einem Tag habe ich schon folgende Daten:

Ich habe hier alle Kanäle deaktiviert, die quasi auf "0" stehen, so dass nur die interessanten Kanäle übrig bleiben. Leider ist die Farbauswahl bei so vielen Kanälen nicht optimal. Vielleicht werde ich daher das Skript doch noch erweitern, um die Kanäle auswählbar zu machen. Dem spricht aber entgegen, dass man dann nicht mehr so einfach Werte gegenüberstellen kann. Hier sieht man, dass die maximale vom DSL-Modem gemeldete Upstream-Rate zweimal eingebrochen ist. Die FEC-Errors sind mit 1-3 Stück pro Sekunde durchaus vorhanden. Ohne Vergleichswerte mit anderen DSL Anschlüssen kann ich das aber noch nicht bewerten. Die Downstream-Rate war in der Zeit aber unverändert hoch. Wenn ich die hier aber mit den 12 Megabit zusätzliche einblende, dann sind die anderen Werte durch die Skalierung zu gering um noch sichtbar zu sein.

Der Custom Sensor ist wie viele andere Sensoren und Skripte der MSXFAQ natürlich kostenfrei erhältlich. Über den Parameter "-fritzip:" können Sie eine abweichende IP-Adresse oder einen DNS-Namen angeben. Der Default "fritz.box" sollte aber in den meisten Umgebungen funktionieren.

Interessant:
Im Skript gibt es auch den Parameter "-Fritzpass:Kennwort" zur Angabe eines Kennworts.

Sie können und sollten das Skript einfach mal so in einer PowerShell starten und neben den Diagnoseausgaben am Anfang auch die XML-Daten auf dem Bildschirm erkennen können.

prtg-Fritz!BoxV1.ps1

Laden Sie sich das Skript einfach herunter und kopieren Sie es in das Verzeichnis "C:\Program Files (x86)\PRTG Network Monitor\Custom Sensors\EXEXML" als PowerShell-Skript. Sie können es dann in PRTG als "Custom Sensor EXE/XML" einfach addieren.

Beispiele des eigenen Fritz Sensors

Dass ich vielleicht nicht den besten DSL-Anschluss habe, sieht man schon an der lausigen Geschwindigkeit von 10 Megabit am DSL16000 ohne aktuell Aussicht auf mehr. Es werden also immer noch Neubaugebiete mit schwachen Anbindungen erschlossen und obwohl es im Kernbereich von Hövelhof sogar TV-Kabel mit Internet gibt, wurde auch hier ein neue Baugebiet wieder mal "Ohne" erschlossen. Ziemlich kurzfristig gedacht. Interessant ist aber die Überwachung der Fehlerrate an diesem Anschluss. Sie ist wieder mal beim Update der Fritz-Firmware von 6.23 auf 6.30 deutlich angestiegen.

Mit der aktuellen Firmware hat die CRC-Fehlerrate zugenommen. Ob das noch "tolerierbar" ist, wenn jede Sekunde ein Frame so unbrauchbar wird? Zum Glück kann man in der Konfiguration auch die "alte DSL-Firmware" aktivieren. Und schon die die Fehlerrate dann wieder unten. Hier eine kleine Tabelle

DSL Firmware DSLAM-FW Down Up Statistik  

1.68.24.29

Infineon 7.27.8

10.935kBit

984kbit




 

1.68.26.07

Infineon 7.27.8

11192kBit

991kBit


 

 

 

 

 

 

 

Schaut man sich die Zahlen an, dann sind sie eigentlich an vielen Stellen gleich. Die "neue" Firmware versucht aber wohl etwas mehr rauszuholen und das geht wohl auf die Qualität.

Der geheimnisvolle Schalter, der in meinem Fall aber Wunder wirkt befindet sich in der Karteikarte "Störsicherheit" der DSL-Information.

Hier kann ich die "vorherige DSL-Version" ausgewählt werden, womit die Verbindung geführt stabiler ist. Alternativ gibt es auch noch eine 5-stufige Einstellmöglichkeit, um der Stabilität gegenüber der Leistung den Vorzug zu geben.

Zukunft

Die erste Version gab es schon 2015 und Ende 2018 habe ich Version 2 erstellt, bei der ich per CSV-Datei eine Flexible Parametrisierung addiert habe. Aber es ist immer noch Potential für mehr Optionen, z.B. dass Werte wie NewTotalBytesSent umgerechnet werden in Differenzwerte. Auch überlege ich die Werte mit Formeln zu verbinden.

Weitere Links