Fragen zur Map Rheinufer

Wir haben jetzt batadv-vis noch mal getestet, scheint besser zu klappen.
Beim ersten versuch schien es nicht zu funktionieren. Jetzt zeigt der Graph auch mehr als 500 Nodes an.

An dem Gateway Problem arbeite ich noch :wink:

1 „Gefällt mir“

Hast Du denn die Gateways/Supernodes per Alias-File mit an ffmap-backend übergeben?
Wichtig ist, dass das Flag „vpn: true“ gesetzt ist, und das das Flag im Alias-File steht.
In Alfred-Daten wurde das Flag bei mir zumindest ignoriert.

1 „Gefällt mir“

Wobei das einer der Punkte ist bei denen ich mich frage, warum das nicht upstream gefixt,
oder zumindest klarer dokumentiert wird.

Ja habe ich :slight_smile: An der Datei hab ich gar nichts verändert, die werden einfach nur nicht angezeigt. Ich schau später mal was das Probelm sein könnte.
Bis jetzt sieht man zumindest mal mehr Nodes im Graph :wink:

Dann sollten sie aber im nodes.json drin stehen.
Bekommst Du denn Fehlermeldungen wie „Unknown gateway …“ beim Erzeugen der nodes.json?
Aber ich will nicht stressen :smile:, schau einfach später in Ruhe mal nach.

Das Problem gibt es in der Domäne Möhne schon länger, allerdings steht „mit Uplink“ nicht mal mehr in der Legende :smiley:

Vielleicht ist da der Fehler schon bekannt.

Die neue Version der Karte zeigt jetzt wieder VPN-Uplinks und sogar die diversen Nodes mit 08:/10:/12:er-Macs im Niemandsland haben jetzt endlich in der Karte Namen bekommen.

1 „Gefällt mir“

Die Map Version hatte nichts damit zu tun, die haben ich nur aufgespielt um neue Features zu haben.
Die Graphen Ansicht hat jetzt auch Stats beim anklicken einer Node.

Gelöst habe ich das Problem indem ich ein Macvlan Interface auf der Bridge der Supernodes erstellt haben welches eine MTU von 1280 hat und nun für Alfred verwendet wird.
Das Problem mit nicht angezeigten Nodes, Namen oder Gateways liegt daran das die Pakete zu teils fragmentiert werden was Merging-Fehler zur Folge hat.

3 „Gefällt mir“

Die neue version der karte ist toll :wink: endlich sieht man nicht nur alle Namen, sonder bei den Nodes die Stats :wink: Dnake und hoffentlich bleibt es so :wink:

2 „Gefällt mir“

Wo liegen denn die Sourcen der aktuellen Map? Ich weiß, dass @johnyb gerade an einer komplett neuen Map arbeitet, aber welches Repo spiegelt den aktuellen Stand?

Bei https://github.com/ffrl/ffmap-d3 hatte ich schon mal versucht eine Kleinigkeit per Pull Request abzuliefern, das ist aber offenbar ein veralteter Stand :slight_smile:

1 „Gefällt mir“

Die Probleme mit nicht angezeigten Namen einiger Router sind in der aktuellen ffmap gelöst worden, durch Änderung der nodesdb.py, die nicht mehr diese seltsame fuzzy mac identification nutzt…reines Frontend-Thema…

Im Ruhrgebiet warten wir dennoch das Release von Julians Map-Server ab, soviel Zeit muss sein :wink:

1 „Gefällt mir“

Für mich ist „upstream“ GitHub - ffnord/ffmap-d3: Deprecated and superseded by http://draic.info/meshviewer - dort gibt es einen „single_page_application“ branch, auf dem hab ich vor einiger Zeit mal aufgesetzt und angefangen mit einer Middleware zu experimentieren. Den aktuellen Stand dazu hab ich in meinem clone liegen, weil das wirklich proof-of-concept Code ist. Den Stand gibts hier. Der Middleware-Code liegt auch bei mir rum: GitHub - johnyb/ffmap-rethinkdb: A middleware to store ffmap-backend data into a rethinkdb and serve it via a socket.io based API. - wie gesagt, sehr experimentell. Läuft aber schon ganz vielversprechend.

Es wäre sehr schön, wenn die y-Skala nicht stumpf „immer auf 100%“ gehen würde, sondern in in festen Schritten wie z.B. 5/10/30/100. Und dazu auch passende Hintergrund-Skalen. (farblich?)
So muss man jedes mal schauen, was es jetzt war.

Darüber hinaus würde ich mir für „unter 5“ wünschen, dass es schlicht „quantelt“; also Treppenstufen.
So eine Skalierung wirkt doch etwas merkwürdig mit den „Nachkommastellen“ bei den UserInnen.

Da bin ich durchaus bei Dir, wobei das auch gute Themen sind, um diese und weitere Änderungswünsche in einem Workshop (z.B. auf dem Freifunk-Tag :smile:) direkt mal umzusetzen.
Vorher schaffe ich das aus Zeitgründen leider nicht.

Zu Beachten ist zudem noch, dass die Graphen höchst experimentell sind, und ich mich erstmalig in den letzten zwei Wochen damit befasst habe. Ich bin auch positiv überrascht, dass sie so schnell schon im „Produktiv-Betrieb“ im Rheinufer zu sehen sind :smiley:.

1 „Gefällt mir“

Das liegt einfach daran, dass Graphite die Werte aggregiert, um weniger Daten speichern zu müssen, und darüber dann standardmäßig den Durchschnittswert bildet.
Ist aber in meiner Entwicklungsversion auf die Erfassung des Maximalwertes geändert, so dass man dann immer die maximale Anzahl an Clients in dem zusammengefassten Zeitraum sieht.

Schreibe das mal hier unten ran, weil es tatsächlich Fragen zur Map, genauer zu den Statistiken sind:

Was bedeutet die Statistik „WLAN-Verbindungen“ genau?

Bei meinen Knoten sieht das so aus:

Im Aachener Graphen wird die gleiche Statistik „Mesh“ genannt:

Wenn es die Anzahl der Mesh-Partner ist, verstehe ich das schon eher. Dann sollte der Name vielleicht in der Rheinufer-Map entsprechend angepasst werden.

Aber eigentlich sollten die beiden Knoten nur über LAN vermesht sein. Warum also „2“ und nicht jeweils „1“?

Wo ich gerade dabei bin: Ich finde, @adorfer hat hier sehr recht. Die Client-Anzahl sollte nicht geglättet oder gedurchschnittet werden. Haben die Aachener für die Knoten, die schon in ihrer Domäne sind, ganz schön umgesetzt:

(Da übrigens nur 1 Mesh-Partner. Seltsam, das.)

Edit: Ach so, das ist einfach schon die Entwicklungs-Version? Sorry, beim ersten Mal überlesen.

Die Knoten haben sowohl eine Mesh Verbindung per LAN als auch eine WLAN. In aller Regel werden sie nur die Mesh Verbindung per Kabel Nutzen, die anderen kennen sie aber trotzdem. Daher ist 2 korrekt.

Angenommen es wären dual Band Router wären es sogar 3.

Hmmm, wegen dieser Diskussion hatte ich das Mesh-WLAN am TP-Link (dem …-01) eigentlich ausgeschaltet, damit nur das Kabel verwendet wird.

Kann natürlich sein, dass das autoupdate auf die transfer-Firmware diese Einstellung rückgängig gemacht hat. Das würde bedeuten, dass Mesh-on-LAN updatefest (zumindest für dieses Update) ist (sonst wäre ja die Kabel-Verbindung weg), Deaktivieren des Mesh-WLANs aber nicht. Interessant!

Das wird wohl passiert sein, das ist aber meiner Meinung nach auch gut so. So ist die Chance für die Umgebung größer einen Mesh Partner zu finden und die Menge an Traffic einer nicht aktiv genutzten Mesh Verbindung ist überschaubar.

Außerdem funktioniert das Netz zwischen den Knoten weiterhin falls mit dem Kabel mal etwas schief geht.

1 „Gefällt mir“

@CyrusFox: Hat der Workaround das Problem gelöst? Oder gibt es immer noch Paket-Verluste in Bezug auf Alfred? Sonst würden wir das bei uns auch mal einbauen.