Hopglass Server Installation (keine Antworten der Router am Server)

Technik
21

Noch irgendwelche Ideen @PetaByteBoy? Also lokal auch wenn ich nicht am WAN hänge wird mir einer bzw. 2 Router (habe noch testweise einen 2.Router reingehangen:

ping6 -c2 ff02::1%wlp3s0
PING ff02::1%wlp3s0(ff02::1) 56 data bytes
64 bytes from fe80::120b:a9ff:fea1:22c0: icmp_seq=1 ttl=64 time=0.032 ms
64 bytes from fe80::32b5:c2ff:fed9:eae6: icmp_seq=1 ttl=64 time=3.31 ms (DUP!)
64 bytes from fe80::fcfe:feff:fefe:fefe: icmp_seq=1 ttl=64 time=3.56 ms (DUP!)
64 bytes from fe80::120b:a9ff:fea1:22c0: icmp_seq=2 ttl=64 time=0.111 ms

— ff02::1%wlp3s0 ping statistics —
2 packets transmitted, 2 received, +2 duplicates, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.032/1.754/3.561/1.685 ms

22

Mir ist unklar, auf welchem Rechner es nicht funktioniert wenn dort das Hopglass-Server läuft.

23

Wenn ich auf einem Client im Netz den Hopglass Server laufen lässt sammelt er fleißig Daten.

Von einem Gateway aus allerdings nicht.

Gruß
Fabian

24

Dann solltest Du Dich an denjenigen wenden, der Dir das Gateway aufgesetzt hat.

25

Der bin ich :slight_smile: Bin mich da grad am einarbeiten.

26

Moin zusammen,

erster Erfolg… naja oder auch nicht.
Wenn ich Hopglass auf dem fastd Interface laufen lasse findet er zumindestens schonmal alle die eine direkt Verbindung haben. Meshrouter werden allerdings nicht angezeigt ist ja auch verständlich weil die ja eigentlich über bat0 sprechen.

Irgendwelche Ideen warum es auf bat0 nicht funktioniert.

Gruß
Fabian

27

Keine neuen als die, die oben schon im Thread stehen.

28

Danke nochma an @adorfer und @PetaByteBoy für den Support heute im Mumble.

Falls jemand ein ähnliches Problem hat, hier noch kurz unsere Lösung.
Warum auch immer laufen lassen sich die Multicast Antworten nicht am Bat0 Interface abgreifen. An der Bridge des Fastd schon.
Das Mesh-Knoten hier nicht auftauchen, liegt an dem Mesh-Router, mit einem anderen funktioniert es. Das werden wir uns nochmal anschaun.

Vielen Dank an alle.

29

*Bridge des Batman 2020

30

Da möchte ich noch mal einhaken: wieso wird über das Batman-Interface kommuniziert? Weder bei unserem aktuellen Netz (compat v14; fastd in GWs, L2TP-Tunnel zwischen den GW; FW-Basis: Gluon v2016.2.7) noch einem neuen Netz (compat v15; fastd in GWs, fastd zw. GWs; FW-Basis: Gluon v2017.1) antworten andere Geräte auf dem bat-Interface:

root@gw10:~# ping6 -c5 ff02::1%bat-ffgt
PING ff02::1%bat-ffgt(ff02::1) 56 data bytes
64 bytes from fe80::dcad:beff:feef:210: icmp_seq=1 ttl=64 time=0.069 ms
64 bytes from fe80::dcad:beff:feef:210: icmp_seq=2 ttl=64 time=0.037 ms
64 bytes from fe80::dcad:beff:feef:210: icmp_seq=3 ttl=64 time=0.076 ms
64 bytes from fe80::dcad:beff:feef:210: icmp_seq=4 ttl=64 time=0.049 ms
64 bytes from fe80::dcad:beff:feef:210: icmp_seq=5 ttl=64 time=0.040 ms

--- ff02::1%bat-ffgt ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 3998ms
rtt min/avg/max/mdev = 0.037/0.054/0.076/0.016 ms
root@gw10:~# batctl -m bat-ffgt if 
Ehopglass: active
Egw00: active
Egw02: active
Egw04: active
ffgt-mesh-vpn: active

vs.

root@gw10:~# ping6 -c5 ff02::1%br-ffgt
[…]
--- ff02::1%br-ffgt ping statistics ---
5 packets transmitted, 5 received, +2155 duplicates, 0% packet loss, time 4001ms
root@gw10:~# brctl show br-ffgt
bridge name     bridge id               STP enabled     interfaces
br-ffgt         8000.deadbeef0210       no              bat-ffgt

Kurzum: ich habe Hopglass-Server funktional laufend (aus meiner Sicht) auf dem br-ffgt-interface, auf bat-ffgt tat sich nix. Die Daten im darauf aufsetzenden Hopglass decken sich mit denen des alten Meshviewers, der seine Daten aus dem alten ffmap-backend & Alfred bezieht.

Was mache ich also ›falsch‹, daß Multicast auf dem Batman-Interface nicht tut und inwiefern ist das ein Problem, da im Mesh-Netz ja korrekt funktioniert? (Hopglass-Sample-Config stellt explizit auf bat0 ab.)