Zwei Fragen zur config:
Das ist in der Tat komisch.
http://gadow.freifunk.net:4000/nodes.json sieht so aus, als ob man damit die wireless und die cable unterscheiden können sollte.
Der Fehler liegt in
http://gadow.freifunk.net:4000/graph.json
Da stehen alle auf Type „other“.
Warum? Was für eine Firmware läuft auf Euren Knoten?
Da sollten eigentlich zumindest ein paar mit type:wireless stehen.
dafür kannst Du eine alias.json hinterlegen im Server.
"interfaces": {
"tunnel": [
"6a:25:4f:0c:e8:17"
],
"other": [
"6a:25:4f:0c:e8:12",
"6a:25:4f:0c:e8:13"
]
}
aus http://gadow.freifunk.net:4000/raw.json
Alle Wifi-Interfaces werden vom Knoten als other markiert => Das Problem liegt auf den Knoten
Dieser kleine Teil des Netzes verwendet gluon. Die site config dafür liegt hier.
Hast du eine Idee, wie ich das gelöst bekomme? Könnte es mit der Benennung des interfaces in „ibss0.61“ zu tun haben?
ifconfig
bat0 Link encap:Ethernet HWaddr C8:D3:A3:5C:71:B6
inet6 addr: fe80::cad3:a3ff:fe5c:71b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81448939 errors:0 dropped:0 overruns:0 frame:0
TX packets:2221469 errors:0 dropped:5141 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1656642877 (1.5 GiB) TX bytes:434438396 (414.3 MiB)
br-client Link encap:Ethernet HWaddr C8:D3:A3:5C:71:B6
inet6 addr: fdef:ffc0:7030:0:cad3:a3ff:fe5c:71b6/64 Scope:Global
inet6 addr: fe80::cad3:a3ff:fe5c:71b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81927081 errors:0 dropped:50713 overruns:0 frame:0
TX packets:3080870 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4874023150 (4.5 GiB) TX bytes:483387156 (460.9 MiB)
br-wan Link encap:Ethernet HWaddr CA:D4:A3:5C:71:B6
inet addr:192.168.10.59 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::c8d4:a3ff:fe5c:71b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:247462461 errors:0 dropped:21229 overruns:0 frame:0
TX packets:150295676 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:50279495317 (46.8 GiB) TX bytes:45050275468 (41.9 GiB)
client0 Link encap:Ethernet HWaddr CA:D5:A4:5C:71:B6
inet6 addr: fe80::c8d5:a4ff:fe5c:71b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:469957 errors:0 dropped:0 overruns:0 frame:0
TX packets:81741235 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:69087059 (65.8 MiB) TX bytes:7481557585 (6.9 GiB)
eth1 Link encap:Ethernet HWaddr C8:D3:A3:5C:71:B7
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:248553646 errors:0 dropped:1033019 overruns:0 frame:0
TX packets:150295675 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2495763778 (2.3 GiB) TX bytes:2100602466 (1.9 GiB)
Interrupt:4
ibss0 Link encap:Ethernet HWaddr CA:D6:A4:5C:71:B6
inet6 addr: fe80::c8d6:a4ff:fe5c:71b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1536 Metric:1
RX packets:209127780 errors:0 dropped:0 overruns:0 frame:0
TX packets:208533888 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:41724202095 (38.8 GiB) TX bytes:42316810639 (39.4 GiB)
ibss0.61 Link encap:Ethernet HWaddr CA:D6:A4:5C:71:B6
inet6 addr: fe80::c8d6:a4ff:fe5c:71b6/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1532 Metric:1
RX packets:209127732 errors:0 dropped:0 overruns:0 frame:0
TX packets:208533904 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:37959896000 (35.3 GiB) TX bytes:37679372797 (35.0 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:5044068 errors:0 dropped:0 overruns:0 frame:0
TX packets:5044068 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1075772122 (1.0 GiB) TX bytes:1075772122 (1.0 GiB)
local-node Link encap:Ethernet HWaddr 16:41:95:40:F7:DC
inet addr:10.61.3.3 Bcast:10.61.3.255 Mask:255.255.255.0
inet6 addr: fe80::1441:95ff:fe40:f7dc/64 Scope:Link
inet6 addr: fdef:ffc0:3dd7::1/128 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:38557995 errors:0 dropped:50638 overruns:0 frame:0
TX packets:1211409 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1946799193 (1.8 GiB) TX bytes:104181422 (99.3 MiB)
Sogar sehr wahrscheinlich
Du musst die respondd-Module anpassen
Das respondd im Gluon ist nicht vlan-aware…
ibss = {
ssid = '02:ca:ff:ee:ba:be',
bssid = '02:ca:ff:ee:ba:be',
mcast_rate = 12000,
mtu = 1532,
vlan = 61,
Das ist dann leider ein klassisches „muss upstream gefixt werden“.
(Denn die Knoten liefern die notwendigen Daten so leider nicht mehr „zum Mapserver“. )
habe leider noch einen Bug gefunden hinsichtlich der „clients in der Wolke“:
Wenn man nach dem leeren des Browser-Cache eine „Wolke“ das erste Mal besucht, wird die Anzahl der Clients in der Wolke noch zusätzlich einmal um die Anzahl der Clients des angeklickten Knotens addiert - sobald man dann einmal einen anderen Knoten angeklickt hat stimmt der Wert bei allen, bis man wieder die Seite „hart“ neulädt, sprich den Cache löscht.
Nachtrag:
Dieser Fehler besteht in der Kartenansicht, nicht in der Graphenansicht
Kann ich am Mac mit dem Safari nicht nachstellen …
Daher wäre der browser und das os interessant.
Gruß
Daniel
ich jetzt auch nicht mehr, fragt mich nicht warum… Gehen Sie weiter, es gibt hier nichts zu sehen
HopGlass zeigt nun im Knotengraph die Richtungen der Links seperat an.
Demo: https://map.ffdus.de/#!v:g
Als nächstes werde ich damit anfangen, dass die Gateways und NextHops mit Namen angezeigt werden und anklickbar sind. Der Aufbau vom Meshviewer steht mir hier leider ziemlich im Weg.
Zum Verständnis:
„von einem Node aus die Linie“ bezeichnet die Qualität wie der Nachbarkonoten (in dieser Richtung) genau eben jeden Node „hört“.
ein „stummer Node“ (ohne Respondd/Alfred) wird also sichtbar als Node mit „halben bunten Strahlen“, die nach der Hälfte alle grau werden, eben weil er selbst ja nicht reported, wie er seine Nachbarn hört.
Im Beispiel: Der Speiseraum sendet gut zum Umsonstladen, der Umsonstladen ist aber im Speiseraum schlechte rzu hören.
Oekoma-Laden hört den Oekoma, umbekehrt ist aber keine Verbindung vorhanden.
Nexthop und Gateways werden jetzt mit Namen angezeigt und sind klickbar.
In den Statistiken werden die Gateways ebenfalls nach Namen aufgelöst. Das funktioniert aber nur, wenn kein Filter ausgewählt wird, das muss ich noch fixen.
Beispiele (einfach mal durch die nexthops klicken):
https://bgl.map.ffgl.eu/#!v:g;n:60e327366f46
https://bgl.map.ffgl.eu/#!v:g;n:10feed3b4c70
https://bgl.map.ffgl.eu/#!v:g;n:60e327e764a2
Sieht gut aus.
Nur muss ich jetzt wohl doch mal neue Firmware bauen, damit ich den Nextnode vom respondd mit gemeldet bekomme.
Richtig, und du musst mal deine MAC-Adresse von Flingern-2-fastd so anpassen, dass sie der aus der aliases.json entspricht (ba:b1:e… statt ca:b1:e…).
Das ist ein anderes Problem, der hat mehrere Batman-Interfaces (mit unterschiedlichen MACs) und es ist mehr oder minder Zufall, welches davon das ist was als Gateway gemeldet wird.
Solange die erste Hälfte der MAC konsistent ist, funktioniert es.
mit der neuesten Version erhalte ich nur noch eine Fehlermeldung:
TypeError: e.substr is not a function
Wie kann ich beim debuggen helfen?
Link? 2020202020202020
wenn wir live debuggen wollen, komm ins IRC.
ansonsten lasse ich eine nicht funktionierende Map nicht online
Als Feature Request:
Besteht die Möglichkeit, anhand der vom Knoten übermittelten Daten die WiFi-Clients farblich (und in der Tabelle in Zahlen) anders auszuzeichnen als die Wire-Clients am LANport?