Fyi: meshviewer inkl Anzahl Clients per Gateway

wir haben unseren meshviewer erweitert sodass der nun auch die Anzahl der Clients per Gateway neben der Anzahl der Knoten per Gateway anzeigt.
Damit wird der Meshviewer noch besser zur recherche

https://openfreiburg.de/freifunk/meshviewer

https://cccfr.de/git/viisauksena/meshviewer2/commit/a31cdbbc4a5aeff5ef0bbc126bd00958eb42007a

3 Likes

Das passt doch gut zu den Ă„nderungen die @tcatm in der Richtung vor hat. +1

Könntet Ihr bitte bei der Gelgenheit noch die Lizenz fixen?
Danke.
(ist ja AGPL)

1 Like

Wie zählt ihr denn die Clients an den Gateways?

@tcatm … zum client/gw zählen wird auf die daten der nodes.json zurück gegriffen, da die eh ausgelesen wird.

wir haben analog zu den gw count ein online gw count genommen (in dem falle gleich) und eine count2 funktion die .statistics.clients addiert statt simpel 1 wie die anderen counter.
kann man sehr gut sehen am link oben (auf den commit)

Ah. Das zählt dann aber nicht die Clients je Gateway sondern die Clients der Knoten, die dem nächsten Client diesen Gateway empfehlen würden, oder?

1 Like

Ja, das ist zwar nicht 100% genau, aber auf eine Hand voll Clients mehr oder weniger (z.B. wegen Roaming) kommt es ja auch nicht an. „Empfehlen“ - naja, die werden halt per DHCP zugewiesen und die Lease time ist extrem niedrig bei uns (Wupper)…

Wir machen das ähnlich für diese Statistik für Traffic und Clients am Gateway:
https://map.eulenfunk.de/stats/dashboard/db/gateway

Ein Client kann sehr viel länger seinen Gateway beibehalten (auch über Reboots hinweg). Gerade das Verlängern der Leases geschieht per Unicast und wird nicht von batman umgeleitet.

@tcatm genau, aber es ist so das die clients an das gw vermittelt werden, ich kenn keine comunity die clients von knoten ĂĽber 3. gw routen, das bedeutet doch sonst quertraffic

oder das router initial das dhcp machen und damit extra tunnel zu gw

nicht das das nicht ginge, dann wäre die Einschränkung das dies first hop gw sind. wo ja initial alle gezählte clients drüber gehen
unabhängig vom weiteren routing foo

Den wievielten Thread haben wir denn hier jetzt zum Thema
„BatmanGW != DHCP-Server=IPv4-Gateway != FastD-Server“

So gesehen können wir eigentlich gar keine sinnvollen Statistiken (zumindest keine präzisen) machen.
Und in dem Moment wo wir den Quertraffic wirklich visualisieren könnten, würdn wir vermutich ständige Schmerzen leiden beim Zuschauen.

@adorfer , naja, unabhängig davon monitoren wir mit munin die dhcp leases …
http://pluto.freiburg.freifunk.net/munin/freiburg.freifunk.net/Total/sum_dhcp2.html
nicht so schön und vor allem auch nicht mit der Karte zusammen (und den doch recht mächtigen filtern)

das ist wiederum schwer in die Karte zu bringen, fĂĽr einen groben ĂĽberblick was initial an demjeweiligen ersten GW ankommt ist das glaub ganz brauchbar (und definiert damit schonmal einen guten Teil der Last)
das von dort auch quer geht, u.o. die clients aktiver/schläfrig sind wird damit nicht abgebildet.

btw.: den hieb in richtung xter Thread zu batman != dhcp lease hätteste durchaus konstruktiver fassen können. (zumal es hier nichtmal darum geht, quasi Thema verfehlt)

Ich könnte mir durchaus vorstellen, dass die Gateways selber (per alfred oder respondd) bekanntgeben, wieviele Clients sie derzeit zu bedienen glauben.

1 Like

Wo könnte man die Information aus einem isc-dhcp-server auslesen? Das wäre nämlich durchaus schöner.

Dafür könnte man die Leasedatenbank (eine Textdatei) regelmäßig parsen.

Faktisch geht der Traffic in Richtung Internet ĂĽber einen ganzen Haufen Gateways.
Wobei der Batman-Gateway dahingehend ein guter Indikator fĂĽr die Performance des ganzen Systems (Latenz als Summe ĂĽber CPU/Last/Anbindung) ist.