prtg-freifunk Monitoring

Auf dieser Seite beschreibe ich, wie ich die Funktion meines Freifunk-Routers überwachen. Seit einiger Zeit betreibe ich bei mir einen Freifunk AccessPoint. Damit sollte ich zum einen dem Problem der Störerhaftung komplett aus dem Weg gehen und zudem muss ich mich um Kennworte für Gäste-Zugänge kümmern. Nebenbei kann ich so die Bandbreite für Gäste drosseln so dass "ein "bisschen was" geht ohne dass meine Leitung überlastet wird. Natürlich kann auch ich mit Freifunk einen alternativen Internet-Ausgang nutzen, was für VoIP Tests und Traceroute etc. ganz nützlich ist.

Überwachung eingebaut

Es ist schwer einen Überblick über Freifunk zu erhalten. Die meisten Communitites pflegen eine Liste der Hosts und Standorte. Die Daten sind öffentliche zugänglich und meine Statusseite sieht dann so aus.

Sie sehen schön, dass der Router aktiv eine Verbindung zum Gateway aufrecht erhält (VPN-Tunnel) und das Gateway damit den Status des Zugangspunktes auch kennt. Auf Rückfrage wurde mit leider gesagt, dass ich bei der Einrichtung des Zugangs zwar eine Kontaktadresse angeben kann aber das System selbst keine Mail dorthin sendet, wenn ein Knoten mal nicht erreichbar ist. Was liegt hier also näher als diese Informationen per PRTG oder anderen Tools abzufragen.

Zusätzlich kann man die Daten noch im Grafana, (z.B. https://grafana.ffho.net/dashboard/db/nodes?orgId=1&var-hostname=FC&var-nodeid=704f5727b9f6) betrachten. Vielleicht gibt es ja sogar hier noch eine einfachere URL um den Status des Knoten zu erkennen. Ich habe hier aber erst mal nicht weiter gesucht und mit die Statusseite auf https://map.hochstift.freifunk.net/#/en/map/704f5727b9f6 genauer angeschaut.

Auch die Münchner Community betreibt Grafana und stellt einige Daten bereit

Wer eine jede Minute aktualisierte Anzeige z.B. auf einem Tableau anzeigen will, kann an die URL ein "&refresh=1m" anhängen.

Analyse des Verkehrs

Die Webseite ist natürlich nun nicht grade eine "alte HTML"-Seite sondern nutzt intensiv JavaScript und sammelt die Daten per JSON vom dahinterliegenden Webserver. Das kann man recht einfach sehen, wenn ich die URL eingeben und mit Fiddler die Pakete betrachte. Am Anfang zieht er ein relativ großes JavaScript, welches dann die Nutzdaten als JSON Daten nachlädt

Ich habe dann einfach nach meinen Koordinaten gesucht und genau eine Zeile gefunden, in der ein Treffer war:

Ich habe nun natürlich nicht den kompletten Handshake analysiert und genau genommen müsste ich wohl auch erst den Root-Node lesen und dann alle weiteren Teildokument um meinen Knoten zu finden Es könnte ja sein, dass ich später mal von "pb-west" zu einem anderen Knoten verlagert werden. Vielleicht gibt es ja auch eine URL, die genau nur meinen Knoten anhand der node_id zurückliefert

Proof of Concept

Was liegt da näher als diese URL einfach abzugreifen und die Rückgabe als JSON-Datei zu parsen und an mein Monitoring zu übergeben? Etwas gebremst wurde ich erst mal nun durch eine TLS-Besonderheit, bei der ein einfacher Invoke-WebRequest mit einem Fehler beendet wurde

Invoke-WebRequest : Die zugrunde liegende Verbindung wurde geschlossen: Unerwarteter Fehler beim Senden..

Der gleiche Aufruf per Internet Explorer lieferte aber Daten zurück. Relativ schnell konnte ich per Wireshark war sehen, das die PowerShell TLS 1.0 mit 7 Cipher Suiten anbietet und die Gegenseite darauf mit einem TCP-RESET antwortet. Sie mag meine TLS-Angebote nicht.

Im Internet Explorer kommen die Daten an. Der IE bietet dabei TLS 1.2 an.

Also muss ich auch TLS 1.2 freischalten (Siehe TLS 1.2 Enforcement)). Ich erwarte aber, dass zukünftig die PowerShell diese auch als Default aktivieren wird. Für die aktuelle PowerShell kann ich das wie folgt einstellen.

[System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12
$jsondata = invoke-webrequest https://map.hochstift.freifunk.net/data/pb-west/meshviewer.json 
$psdata= $jsondata | ConvertFrom-Json
$psdata.nodes| ?{$_.node_id -eq"704f5727b9f6"}

firstseen       : 2017-12-31T19:35:30+0100
lastseen        : 2018-04-02T11:18:30+0200
is_online       : True
is_gateway      : False
clients         : 0
clients_wifi24  : 0
clients_wifi5   : 0
clients_other   : 0
rootfs_usage    : 0,5446
loadavg         : 0
memory_usage    : 0,512533635462399
uptime          : 2018-03-31T17:56:18+0200
gateway_nexthop : f200260700e0
gateway         : f20026070000
node_id         : 704f5727b9f6
mac             : 70:4f:57:27:b9:f6
addresses       : {2a03:2260:2342:700:724f:57ff:fe27:b9f6, fe80::724f:57ff:fe27:b9f6}
site_code       : ffho_hvf
hostname        : FC
location        : @{longitude=8,642098; latitude=51,818854}
firmware        : @{base=gluon-v2016.2.7-1-g69246031; release=1.0.6}
autoupdater     : @{enabled=True; branch=stable}
nproc           : 1
model           : TP-Link TL-WR940N v4
vpn             : False

Mit den Daten kann ich dann sehr einfach PRTG füttern und einen Sensor bauen, der mir auch einen Alarm sendet, wenn "is_online" eben nicht auf "true" steht

PRTG-Custom Sensor

Der Rest war dann wieder einfach. Eigentlich wollte ich nur den Status erhalten um passend darauf mit eine Alarmierung zu generieren. Wenn aber durch de JSON-Datei sowieso auch noch die Anzahl der Clients etc. zurück kommt, habe ich mir wieder einen PRTG - Custom Sensor gebaut, den PRTG gerne einmal alle 5 Minuten aufrufen kann. Die Parametrisierung habe ich im Code hinterlegt. Den folgenden Code muss ich einfach in das Verzeichnis EXEXML einer Probe ablegen, die auch ins Internet darf und schon kann ich meinen Knoten in PRTG einbinden und eine Alarmierung aktivieren. Ich denke, dass der Code natürlich auch für Nagios, icinga und andere Tools angepasst werden kann.

prtg-freifunk.ps1.txt

Sie müssen auf jeden Fall den Parameter der "NodeID" anpassen und auch die URL funktioniert nur für einen Teil der Knoten, die auch in diesem Bereich enthalten sind.

Die Ausführung dauert auf meinem Notebook (i5 3320M) von 2013 unter Windows 10 gerade mal 250ms. Das sollte den PRTG Server nicht sonderlich belasten. Die Ergebnisse im Überblick:

Die Grafik über eine kurze Zeit ist natürlich nicht sehr aussagekräftig:

Wichtiger ist aber sowieso die Funktion der Alarmierung:

Wenn der Sensor für mehr als 30 Sekunden den Status "Down" hat, bekomme ich als Admin eine Mail und zudem einen Push-Meldung an meine App.

Weitere Links