# multicast address to destination of respondd
# (optional - without definition used batman default ff02::2:1001)
-#multicast_address = "ff05::2:1001"
+multicast_address = "ff05::2:1001"
Hier war glaube ich wirklich nur einkommentieren nötig.
Das ganze wird nicht einfacher in Map-Setups, die auf mehreren Batman-Interfaces in unterschiedlichen L2-Domains hängen.
Ich gehe davon aus, dass man nun um getrennte Routingtabellen (plus tagging der Pakete) nicht mehr herumkommen wird.
Ist vermutlich trivial, es muss nur jemand tun.
Ich verstehe gerade das Problem nicht, wir haben yanic mit 12 batman Interfaces und ff05::2:1001 am Laufen von Anfang an seitdem wir die neuen Gateways haben.
Unser Config für ein Interface sieht zum Beispiel so aus:
[[respondd.interfaces]]
ifname = "br-muc_cty"
port = 45124
[[respondd.interfaces]]
ifname = "br-muc_nord"
port = 45124
Diesen Config Eintrag kann man beliebig oft und für jedes Interface wiederholen.
Auch auf unseren Gateways ist der respondd entsprechend eingestellt.
In Gluon gab es eine Änderung der Adresse, und die neue Adresse ist keine link-local multicast-Adresse, wodurch die Adresse nicht mehr so verwendet werden kann wie die alte(n). Was genau nötig ist weiss ich nicht.
Also mit yanic funktioniert das mit gluon 2019.1 super einfach die zweite Adresse konfigurieren und alles klappt. Mit hopglass server allerdings habe ich auch noch meine Probleme. Wir beitreiben beides, um Redundanz zu haben.
auf und alles ist gut.
Ich wäre trotzdem sehr an einer Lösung für hopglass interessiert, da ich zumindest bis zum switch auf batman 15 noch gerne mit hopglass arbeiten würde. Wenn das Netz komplett geswitcht ist wäre mir dass dann egal
Die Autoren in diesen Tickets zu Informieren ist vielleicht sinnvoller als hier im Forum schlechte Workarounds zu basteln. Denn mit einer sinnvollen Loesung in den Softwarepaketen, kann man vielen Leuten helfen ohne mit der Zeit in seinen eigenen Hacks zu ersticken.
der patch müsste doch einfach die datei /etc/init.d/gluon-respondd ändern, bovor sie in die router images kopiert wird, oder? dann müsste das doch auch im router funktionieren im nachhinein.
vielleicht gehts ja auch, bloss in kiel haben wir ein anderes Problem als in Nord
@anon68922371, womit werden in nord nochmal die kartendaten generiert?