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.

Eingebauter Fritz!Box-Sensor

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.

Abruf per HTTP

Wenn ein Browser die Daten abfragen und anzeigen kann, dann könnte ich ja auch per Skript mich als Browser ausgehen und die Daten quasi "abfischen". Das habe ich z.B.: bei meinem Wechselrichter (Siehe PRTG Kostal) auch schon so gemacht. Bei der Fritz-Box ist die Anmeldung allerdings etwas kniffliger, da man sich zuerst durch eine Anmeldung eine SessionID (SID) besorgen muss, die dann bei jedem Aufruf anzuhängen ist.

Als Skript ruft man die URL "http://fritz.box/login_sid.lua" auf, und bekommt folgende XML mit einer leeren SID

<?xml version="1.0" encoding="UTF-8"?>
<SessionInfo>
   <SID>0000000000000000</SID>
   <Challenge>c2e0278d</Challenge>
   <BlockTime>0</BlockTime>
   <Rights/>
</SessionInfo>

Dann codiert man das Kennwort mit dem Challenge per MD5 und sendet es erneut an die Loginseite. Hier ein Code-Sement aus einem anderen Skript

response = $Challenge."-".md5(mb_convert_encoding($Challenge."-".$this->Password
http://fritz.box/login_sid.lua ?response=".$response

So bekommt man dann eine SID, die in der Folge anzuhängen ist. Die Statusseite würde man dann unter "http://fritz.box/internet/dsl_stats_tab.lua?sid=ab82982a23d80370" bekommen. (wenn das die SID wäre). Der HTML-Output wäre dann zu parsen und an PRTG zu übergeben.

Das ist alles möglich aber nicht "dauerhaft". schon das nächste Firmwareupdate mit einer kleinen Änderungen der Ausgaben würde den Sensor äußer Kraft setzen und eine Änderung erforderlich machen

Abruf per UPNP und TR064

Aber die Fritz!Box hat noch einen Zugang. Über den Port 49000(http) bzw. 49443 (https) gibt es einen Zugang zu einer TR-064 Schnittstelle, bei der per HTTP-POST auch Daten ausgelesen und sogar gesetzt werden können. Auf der Seite PS SOAP habe ich als Beispiel für SOAP-Request mit PowerPoint schon ein paar Fritz!Box-URLs aufgeführt.

Über die URL "http://fritz.box:49000/igddesc.xml" und einer For-Schleife gibt es ganz schnell eine Liste der Parameter, die eine Fritz!Box liefert:

[xml]$igddesc =(invoke-webrequest -uri "http://fritz.box:49000/igddesc.xml").content

Analog gibt es dazu noch zwei weitere URL zum Abruf von Beschreibungen.

http://192.168.179.1:49000/tr64desc.xml
https://192.168.179.1:49443/tr64desc.xml

Sie können gerne die XML-Datei durchlaufen aber es ist im wesentlichen eine Dokumentation aber enthält keine Messwerte. Interessant ist darin z.B. ein Eintrag:

Dazu muss man dann doch einen SOAP-Request absetzen. Hier z.B. ein Basischeck mit dem Default Port 49443 und der Ausgaben von GetInfoResponse:

$w=New-Object System.Net.WebClient
$w.Encoding=[System.Text.Encoding]::UTF8
$w.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$w.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:WANDSLInterfaceConfig:1#GetInfo')

$query='<?xml version="1.0"?>
        <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <s:Body> ' +
        '<u:GetInfo xmlns:u="urn:dslforum-org:service:WANDSLInterfaceConfig:1">
        </u:GetInfo>' +
        '</s:Body>
        </s:Envelope>'

$w.Credentials=New-Object System.Net.NetworkCredential("dslf-config", "kennwort hier eingeben")
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$r = [xml]$w.UploadString("https://fritz.box:49443/upnp/control/wandslifconfig1",$query)
$r.Envelope.Body.GetInfoResponse u                        : urn:dslforum-org:service:WANDSLInterfaceConfig:1
NewEnable                : 1
NewStatus                : up
NewDataPath              : Fast
NewUpstreamCurrRate      : 1035
NewDownstreamCurrRate    : 11896
NewUpstreamMaxRate       : 1036
NewDownstreamMaxRate     : 11896
NewUpstreamNoiseMargin   : 60
NewDownstreamNoiseMargin : 50
NewUpstreamAttenuation   : 130
NewDownstreamAttenuation : 310
NewATURVendor            : 41564d00
NewATURCountry           : 0400
NewUpstreamPower         : 628
NewDownstreamPower       : 597

Sollten keine Daten kommen, dann könnte das Kennwort falsch oder TR-064 in der Fritz!Box deaktiviert worden sein.

Wenn man das Kennwort mit sendet, dann sollten Sie unbedingt auch HTTPS nutzen, damit das Kennwort nicht im Klartext übertragen wird. Damit HTTPS aber funktioniert, muss die Fritz!Box ein Zertifikat anbieten. Meine Box nutzt dazu anscheinend ein "selbstsigniertes" Zertifikat, welches mit jeder neuen IP-Adresse auf dem WAN-Interface auch neu ausgestellt wird.

Da wird doch hoffentlich diese URL nicht aus dem Internet erreichbar sein ?

PRTG und Fritz!Box

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.

Das Skript

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-fritzbox.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-stsufige EinstellMöglichkeit, um der Stabilität gegenüber der Leistung den Vorzug zu geben.

Weitere Links