HopGlass - Development Thread


#101

Ist gefixed 20202020


#102

Es wäre praktisch, wenn (mindestens) auf den mobilen Clients die “grauen” Clienticons eingespart würden, das verbraucht einfach nur Platz. Der numerische Wert reicht da.

Wenn da dann mal 600 clients in der lokalen Wolke sind wird es auf kleinen Displays unübersichtlich.
https://map.freifunk-iserlohn.de/#!v:m;n:14cc20a92732


#103

Die Uplinks werden auch nicht mehr farblich hervorgehoben, wäre cool wenn die wieder sofort Farblich auffallen würden


#104

Hi,

wir haben gestern unsere Hopglass Installation geupdatet.
Es fehlen die Icons für die Clients in der Wolke

http://srv11.ffnw.de/hood-os/

Wo muss das Image hin? Selbst mit Firebug finde ich nichts… :frowning:


#105

Die Clients werden durch eine Font gebastelt. Und irgendwie fehlt in eurer CSS Datei der dazugehörige Eintrag:

.infobox .clientsMesh {
    font-family: "ionicons";
    color: #dbdbdb;
    word-spacing: -0.2em;
    white-space: normal;

#106

Huch, okay.
Ich habe ein ganz normales git pull ausgeführt. Warum der Eintrag wohl fehlt. Jemand eine Idee?


#107

Auch grunt ausgeführt sodass das scss neu compiliert wird?


#108

Nach einem pull?
Was muss genau ausgeführt werden?


#109

Im entprechenden Ordner als entsprechendet Nutzer (nicht root)

  1. “npm install” (dependencies installieren)
  2. “npm install grunt-cli” (grunt lokal installieren),
  3. “node_modules/.bin/grunt” (minifizieren, compilieren)…

Die minifizierte Version liegt dann im Unterverzeichnis “build” und dort sollte ebenfalls eine config.json liegen.
Bei Updates reicht meistens der letzte Befehl.
Steht aber auch alles in der README


#110

Man könnte die Setup Anleitung auch einfach um einen Eintrag im passenden Git Hook erweitern, sodass man nie in dieses Problem läuft.


#111

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?

#112

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.


#113
          "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


#114

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)

#115

Sogar sehr wahrscheinlich
Du musst die respondd-Module anpassen


#116

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”. )


#117

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


#118

Kann ich am Mac mit dem Safari nicht nachstellen …
Daher wäre der browser und das os interessant.

Gruß
Daniel


#119

ich jetzt auch nicht mehr, fragt mich nicht warum… Gehen Sie weiter, es gibt hier nichts zu sehen :wink:


#120

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.