HopGlass - Development Thread

Zwei Fragen zur config:

  1. Wie kann HopGlass zwischen Kabelmesh und WLAN-Mesh unterscheiden? Hier z.B. steht nämlich bei beiden „Kabel“.
  2. Kann man das Gateway irgenwie benennen?

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 :wink:

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.

7 „Gefällt mir“

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.

3 „Gefällt mir“

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

4 „Gefällt mir“

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 :wink:

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?