Ne sehe jetzt auf anhieb keine Regeln. Aber ich bau mal die Firmware von Grundauf neu und probiere es nochmal vielleicht ist irgendwas beim bauen schiefgelaufen bin die ganze Zeit am basteln 
Hallo @PetaByteBoy
also neue Firmware gebaut hat aber auch nix geholfen. Allerdings sehe ich in einem tcpdump das Pakete am Node ankomme aber sehe nirgends eine Antwort.
18:50:46.432378 IP6 fe80::6429:24ff:feb6:5de6 > ff02::2: ICMP6, echo request, seq 71, length 64
18:50:46.444256 IP6 fe80::6429:24ff:feb6:5de6 > ff02::2: ICMP6, echo request, seq 663, length 64Probier mal wieder mit ff02::1
Antwortet auch nur der Server selbst.
Das ist ungünstig… Hast du es schonmal auf deinem PC im WAN-Netz mit deinem Router versucht? Dort sollte zumindest der eine Router erkannt werden.
Das sieht schon anders aus:
ping6 -c2 ff02::1%enp0s25
PING ff02::1%enp0s25(ff02::1) 56 data bytes
64 bytes from fe80::f2de:f1ff:fec5:7a38: icmp_seq=1 ttl=64 time=0.065 ms
64 bytes from fe80::30b6:c2ff:feb0:6d9a: icmp_seq=1 ttl=64 time=0.931 ms (DUP!)
64 bytes from fe80::f2de:f1ff:fec5:7a38: icmp_seq=2 ttl=64 time=0.098 ms
— ff02::1%enp0s25 ping statistics —
2 packets transmitted, 2 received, +1 duplicates, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.065/0.364/0.931/0.401 ms
Und was passiert, wenn du den Hopglass Server auf diesem PC installierst? landen Daten in der raw.json? (nach ca. 1 min) Und ähnelt die 30b6:c2ff:feb0:6d9a der MAC-Adresse deines Routers?
Klappt wenn ich den Server lokal installiere.
Dann wirst Du wohl an den entsprechenden Routern „dazwischen“ an die ebtables-Regeln müssen.
An welche Router dazwischen? Im Moment hängt nur ein Knoten per VPN direkt am Supernode.
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
Mir ist unklar, auf welchem Rechner es nicht funktioniert wenn dort das Hopglass-Server läuft.
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
Dann solltest Du Dich an denjenigen wenden, der Dir das Gateway aufgesetzt hat.
Der bin ich 
Bin mich da grad am einarbeiten.
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
Keine neuen als die, die oben schon im Thread stehen.
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.
*Bridge des Batman 2020
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.)