Natürlich wollte ich auch Statistiken von der FRITZ!Box in meiner MRTG/Routers2-basierten Monitoring Umgebung haben. Glücklicherweise habe ich ein Tool namens upnp2mrtg gefunden, welches exakt das macht, nämlich die Interface-Statistik des WAN Ports der FRITZ!Box über UPnP abzufragen und für MRTG aufzubereiten. Sehr einfach zu benutzen. Hier also eine Anleitung mit einigen zusätzlichen Hinweisen.

UPnP auf der FRITZ!Box zulassen

Der erste Schritt ist die Kontrolle, ob Universal Plug and Play (UPnP) auf der FRITZ!Box erlaubt ist. Man findet die Einstellung unter Heimnetz -> Netzwerk -> Programme. Das Häkchen bei “Statusinformationen über UPnP übertragen (empfohlen)” muss drin sein, während das Häkchen bei “Änderungen der Sicherheitseinstellungen über UPnP gestatten” draußen bleiben sollte:

Eine potentielle Frage kann ich noch mit “ja” beantworten: Die Abfrage über UPnP funktioniert auch aus anderen IP-Bereichen und über einen aufgebauten VPN-Tunnel hinweg. Beides war für mich wichtig, da ich mehrere FRITZ!Boxen von meinem zentralen Monitoring Server aus überwache und somit alle Boxen über die VPN-Tunnel abfrage.

upnp2mrtg

Zunächst muss man sich das Tool hier herunterladen. Auf meinem Ubuntu Server hat es sofort ohne Probleme funktioniert. (Natürlich darf man nicht vergessen, es ausführbar zu machen: chmod u+x upnp2mrtg ). Wichtig ist dann nur der -a <IP-Adresse> Switch, der die Ziel IP-Adresse der FRITZ!Box bestimmt. Ein kurzer Test sah so aus:

Wie gewohnt habe ich das Tool nach “/usr/local/bin/” verschoben. (Infos zur Verzeichnisstruktur hier.)

Schieße dich selber ab …

… bevor du alles blockierst. Nach ein paar Wochen im Test mit MRTG (Konfig kommt weiter unten) musste ich feststellen, dass das Tool immer wieder den kompletten MRTG Prozess blockiert hat, sobald eine einzelne FRITZ!Box nicht auf die Anfragen geantwortet hat. Sprich: Bei allen Graphen von MRTG waren diese grauen Balken zu sehen. Hier ein Screenshot davon und die Ausgabe von htop auf dem Monitoring-Server welches zeigt, dass cron alle 5 Minuten MRTG neu startet, aber die alten Prozesse noch gar nicht fertig sind:

Deswegen habe ich ein kleines Skript geschrieben, welches das eigentliche upnp2mrtg Skript aufruft und aber nach 3 Sekunden schaut, ob es noch am Laufen ist. Wenn ja, dann wird das upnp2mrtg Skript abgeschossen, damit MRTG alle anderen Geräte zeitnah abfragen und sich dann beenden kann.

Mein “upnp2mrtgwithkill” Skript sieht folgendermaßen aus:

Ich habe es auch wieder nach “/usr/local/bin” verschoben und ausführbar gemacht. Als einzigen Parameter braucht es die IP Adresse der abzufragenden FRITZ!Box:

Wieder in htop sieht man schön, wie sich die Prozesse gegenseitig aufrufen. Bei einem kill von upnp2mrtg ist außerdem anzumerken, dass ein paar Zombies weiterhin existieren. Diese verschwinden aber auf meinem Ubuntu immer nach ein paar Augenblicken (macht Ubuntu das?). Hier zwei htop Screenshots davon:

MRTG/Routers2 Konfiguration

Jetzt also endlich zur MRTG/Routers2 Konfiguration. Diese sieht relativ einfach aus und erinnert stark an die eines normalen Interfaces welches per SNMP abgefragt wird. Hier wird stattdessen halt mein Skript verwendet:

Hier ein Beispiel für einen solchen Graphen. Ab 22:15 Uhr wurde ein Live-Stream übers Internet geschaut – zunächst in normaler Qualitätsstufe. Gegen 23:15 Uhr wurde dann auf HQ umgeschaltet, was die Downloadrate direkt verdoppelt hat:

Cool ist natürlich auch, dass Routers2 nicht nur die durchschnittlichen Down-/Uploadwerte, sondern auch die absoluten Werte für den Traffic anzeigt. Das sieht bei mir beispielsweise so aus (im letzten Monat 29,6 GB Download und 4,21 GB Upload):

Meine komplette FRITZ!Box Konfig

Als Template biete ich hier noch meine komplette FRITZ!Box Konfiguration für MRTG/Routers2 an. Sie beinhält neben dem hier erwähnten Skript noch drei weitere Graphen, nämlich den Traceroute Hop Count (siehe hier) sowie die Ping Zeiten (siehe hier) vom externen und dem internen Interface. Dieses Template macht natürlich nur da Sinn, wo auch über einen VPN-Tunnel die FRITZ!Box abgefragt wird. Hat man den Monitoring-Server im eigenen Netz direkt hinter der FRITZ!Box kann man sich das Traceroute Hop Count und die Pings sparen. Summa summarum ist überdies interessant, dass bei keinem der vier Graphen SNMP zum Einsatz kommt, sondern nur externe Skripte. :)

Man muss lediglich drei Variablen per Suchen-und-Ersetzen anpassen, damit die Konfig fertig ist. Beschrieben ist es am Anfang der Datei.

Hier noch eine Slideshow von den vier Graphen in meinem Montoring-System. Man sieht zum Beispiel, dass der Ping zum outside Interface im Vergleich zum inside Interface stets etwas kürzer ist, da er nicht durch den VPN-Tunnel muss. Interessant sind auch die unterschiedlichen Hop-Counts, die sich immer nach der DSL-Zwangstrennung in der Nacht ergeben:

Das war’s. ;) Viel Spaß damit.

Featured image “Blitzer / Geschwindigkeitsmessung durch die Polizei” by Dirk Vorderstraße is licensed under CC BY-NC 2.0.