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