Monitoring
Map
Die Monitoring-Map zeigt alle Knoten in Bereich von Freifunk Franken und ihre Verbindungen untereinander:
Knoten | Verbindung | |
---|---|---|
|
|
V1 und V2 bezieht sich auf Router der jeweiligen KeyXchange-Version. Dezentrale Hoods werden immer als V2 behandelt.
Mit dem Mausrad oder mit "+" und "-" kann man rein- und rauszoomen.
Oben rechts kann über das kleine Symbol ein Layer eingeblendet werden, der die Hoodgrenzen anzeigt. Diesen Layer gibt es ebenfalls für V1 und V2.
Zusätzlich existiert ein Layer "Position-Popup". Wird dieser aktiviert, kann durch Klicken auf einen leeren Bereich der Karte ein Popup mit den Koordinaten angezeigt werden.
Unten links ist ein Maßstab, mit dem man Entfernungen schätzen kann.
Die Karte stammt von OpenStreetMap, der Knoten-Layer von Freifunk-Franken.
Popup
Mit einem Klick auf einen roten, grünen oder grauen Knoten-Punkt wird in einem Popup-Fenster der Knotenname angezeigt, und darunter mit dem Knoten verbundene weitere Knoten und die Verbindungsqualität. Gut funktionierende Verbindungen werden grün, schlecht funktionierende rot angezeigt. Blaue Felder sind Layer-3 Verbindungen.
Parameter | Bedeutung | ||||
---|---|---|---|---|---|
Router | Name des angezeigten Knotens Link zum Monitoring des angezeigten Knotens | ||||
Link | Name des verbundenen Knotens Link zum Monitoring des verbundenen Knotens | ||||
Quality | Qualität der Verbindung (1 = schlecht, 255 = gut) die Qualität wird auch in verschiednenen Stufen der Ampelfarben angezeigt für Babel wurde eine blaue Farbe eingeführt. | ||||
Interface |
|
Monitoring eines Knotens
Mit einem Klick auf den Knotennamen öffnet sich die "Monitoringseite des Knotens".
--> zur Hilfeseite über die Monitoringseite eines Knotens
Diese Seite befindet sich noch im Entwurfsstadium.
Hilf mit sie zu verbessern!
Interfaces
Beachtet das nicht jeder Router alle Interfaces hat. Dies ist von Modell zu Modell leicht unterschiedlich. Das Monitoring zeigt manche Interfaces auch erst an, wenn damit etwas verbunden wurde (z.b. die ethX.Y).
Seit einiger Zeit besitzt das Monitoring eine Logik, die für die Interfaces die jeweilige Funktion direkt anzeigt.
br-mesh
Bridge in der das bat0 sowie alle Clientinterfaces die mit Batman kommunizieren sollen (z.b. w2ap, w5ap und eth0.1 falls vorhanden) hängen
bat0
Hier sieht man den Traffic der ins Batman (=der große Switch) geschickt wird oder der aus dem Batman herauskommt. Das wäre z.b. wenn ein Client auf w2ap connectet ist und Traffic über das Batman-VPN zu einen Gateway transferiert (Traffic kommt über w2ap rein und wird dann ins bat0 reingesteckt, somit wird er hier angezeigt). Traffic der im Batman bleibt, ist hier nicht zu sehen (z.b. wenn Traffic von w2mesh (=Batman WLAN) oder eth0.3 (Batman Kabel) ankommt und per fffVPN (=Batman-VPN) weiter zu einen Gateway geht)
ethX.Y
Dies ist je nach Routermodell ein wenig unterschiedlich grundsätzlich gilt aber (falls vorhanden):
ethX.1
Dies ist das VLAN an welches die Kabel-Clientports angebunden sind, dort ist der komplette Traffic aller Clients die per Kabel angebunden sind zu sehen
ethX.2
Dies ist bei manchen Routern das VLAN des WAN Ports. Hier sieht man den kompletten Traffic der über das WAN in das Internet geht. Bei manchen Routern ist WAN auch eth0 und eth1.1 und eth1.3 Client und Batman
ethX.3
Dies ist das VLAN in welches die Kabelgebunden Batmangeräte hängen. Hier sieht man den Traffic der über Batman-Kabel hereinkommt oder herausgeht
Router mit nur einem Ethernetport
Bei Routern mit nur einen Etherntport ist meist eth0 das, als was der Port konfiguriert wurde. Dort gibt es meist keine VLANs
fffVPN oder fffauxVPN
Dies ist das Interface für das VPN. Dort ist der komplette Traffic der innerhalb des VPN verschickt wird zu sehen
l2tpX
Dies ist das l2tp Interface zu den Gateways
w2ap / w5ap
Dies ist das WLAN-Interface auf welches Clients per WLAN zugreifen. Dort ist der komplette WLAN Traffic für Clients zu sehen. w2ap ist das 2,4GHz Band, w5ap ist das 5GHz Band
w2mesh / w5mesh
Dies ist das WLAN-AdHoc-Interface über welches die Router anschließend mit Batman verbunden werden. Hier ist der komplette Traffic zu sehen welcher per Batman über WLAN verschickt wird. w2mesh ist das 2,4GHz Batman, w5mesh ist das 5GHz Batman.
Neighbours Anzeige
Wichtig ist hier zu wissen, das nur Nachbarn angezeigt werden, die Batman auch nutzt. Es kommt immer wieder vor, das Verbindungen hier nicht angezeigt werden obwohl sie möglich wären, da sie keinen Sinn machen und Batman sie daher nicht nutzt.
Hood
Prinzipiell sind zwei Fälle zu unterschieden:
1. Der Router übermittelt eine Hood. In diesem Fall wird die Hood vom Monitoring ohne weitere Prüfung übernommen.
2. Der Router liefert KEINE Hood. Das Monitoring berechnet die Hood selbst aus den Koordinaten. In ungünstigen Fällen kann diese Anzeige fehlerhaft sein z.B.:
- ein Meshrouter steht in einer anderen Hood als der Uplinkrouter dazu, dies ist möglich solang am Meshrouter kein Uplinkrouter aus der Hood wo er steht dran mesht. Der Meshrouter ist aber tatsächlich in der Hood des jeweiligen Uplinks.
- Sind keine Koordinaten gesetzt und der Router hat Uplink kommt er in die Default-Hood.
- Sind keine Koordinaten gesetzt und der Router hat keinen Uplink wird er in die Hood NoCoordinates einsortiert, obwohl er eigentlich in der Hood des Uplink-Routers ist.
Blaue Linien zeigen Layer 3 Verbindungen an, sie verbinden somit Hoods untereinander.
Eigene Daten mit an das Monitoring schicken
Andere Hood
uci set "system.@system[0].hood=meinehood" uci commit system
Blaue Linien zeichnen
Bitte diesen Teil überprüfen, ob noch aktuell
Nach dem Blöcken mit "DATA=$DATA..." (ca. Zeile 296) muss folgendes mitgeschickt werden:
BABELS=$(echo dump | nc ::1 33123 | awk '/^add neighbour/ {print "<neighbour><ip>"$5"</ip><outgoing_interface>"$7"</outgoing_interface></neighbour>"}') DATA=$DATA"<babel_neighbours>$BABELS</babel_neighbours>"
Achtung: geht erst ab Babel 1.8 und nur, wenn in Babel die Option 'local-port 33123' aktiviert ist (Entweder in /etc/config/babeld (lede) oder /etc/babeld.conf (Debian) ).
Das Standard netcat unter Debian 9 kann kein IPv6, es muss netcat-openbsd installiert sein. Bei diesem ist für korrekte Funktion noch die Option '-N' notwendig.
Andernfalls können die Babel-Nachbarn auch so mitgeschickt werden:
DATA=$DATA"<babel_neighbours>" DATA=$DATA"<neighbour><ip>fe80::6666:b3ff:fede:f5cd</ip><outgoing_interface>eth0.4</outgoing_interface></neighbour>" DATA=$DATA"</babel_neighbours>"
bzw. automatisch generiert kann sie z.b. so werden (Syntax ist so richtig und funktioniert so, wenn auch unschön):
DATA=$DATA"<babel_neighbours>" numhops=`traceroute 10.50.130.1 2>/dev/null | tail -1 | cut -d' ' -f2` if [ "$numhops" = "1" ]; then DATA=$DATA"<neighbour><ip>fe80::6666:b3ff:fede:f5cd</ip><outgoing_interface>eth0.4</outgoing_interface></neighbour>" fi DATA=$DATA"</babel_neighbours>"
Weiterhin existiert eine Variante, die die Link-Kosten mit einschließt und ähnlich der Nachbar-Verbindungsqualität im Monitoring als History anzeigt (so implementiert in Adrians GW-Firmware):
BABELS="$(echo dump | nc ::1 33123 | grep '^add neighbour' | awk -v RS='\n' \ '{r = gensub(/.*add neighbour.*address ([0-9a-fA-F:]*) +if +([^ ]+).* cost +([0-9.]+).*/, \ "<neighbour><ip>\\1</ip><outgoing_interface>\\2</outgoing_interface><link_cost>\\3</link_cost></neighbour>", "g"); print r;}')" DATA=$DATA"<babel_neighbours>$BABELS</babel_neighbours>"