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.
Die neue version der karte ist toll 
endlich sieht man nicht nur alle Namen, sonder bei den Nodes die Stats Dnake und hoffentlich bleibt es so
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 
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
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 
) 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 
.
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.
@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.
Jap das klappt 1A, teilweise haben Nodes mit schwachem Uplink noch Probleme, aber das können wir nicht wirklich damit fixen
Wir nutzen die folgene Config in interfaces:
auto br0
iface br0 inet manual
bridge-ports none
bridge_fd 0
bridge_stp off
bridge_waitport 0
post-up ifup alfred0
pre-down ifdown alfred0
iface alfred0 inet manual
pre-up ip link add alfred0 link br0 type macvlan ; ip link set dev alfred0 mtu 1280
up ip link set dev alfred0 up
down ip link set dev alfred0 down
post-down ip link del alfred0 link br0
Hat jemand eine Idee,
wieso Rheinufer in den Stats wieder nicht ganz zu funktionieren scheint?
Ich habe die Vermutung, dass es mit der Umstellung auf die neue Karte passiert ist aufgrund der zeitlichen Korrelation.
Danke und viele Grüße
Lukas
In welchen Stats? Und welche Abweichung meinst Du zu sehen?
(Ich hätte auch „-vv“ schreiben können, aber dann hätte es wieder was mit „20 Zeichen“ geheißen.)
In den Stats, die in dem Beitrag vorkommen, auf den ich geantwortet hab 
http://map.freifunk-ruhrgebiet.de/counts/
Wobei da sich scheinbar wirklich irgendwas geändert hat. Die Karte auf www.freifunk-neuss.de läuft seitdem auch nicht mehr. @Florian wollte sich eh mal anschauen.
Hi Lukas
Die Stats zählen wohl noch die Nodes im alten Format, daher stimmt das natürlich nicht. Aber du kannst natürlich immer die Zahlen aus dem Meshviewer nehmen.
Was die Karte auf Freifunk-Neuss.de angeht so gibt es die einzelnen Seiten nicht mehr als individuelle HTML Files. Wenn du direkt auf die Haupturl verlinkst sollte es kein Problem sein.
Die Karte funktioniert so, dass die nodes.json vom Mapserver geholt wird und die entsprechenden Nodes herausgefiltert und gezählt werden.
Hat sich da an der nodes.json grundlegend was geändert oder liegt die nur an ner anderen Stelle?
Vielen Dank übrigens, dass die „neue Karte“ (der meshviewer) nun auch wieder einen client-graph hat (vermutlich noch aus einer alten ffmap-Installation.
Das ist sehr praktisch. Danke!
