Gluon 2019.1.x Knoten erscheinen nicht in der Map (respondd)

Wie oben erwähnt Yanic, nachdem es da hieß dass es auch nicht geht von @Tarnatos.

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.

Für Yanic führt man einfach zwmail die config

[[respondd.interfaces]]
ifname = „bridge interface“
multicast_address = „ff02::2:1001“

[[respondd.interfaces]]
ifname = „bridge interface“
multicast_address = „ff05::2:1001“

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

Habe den patch mal von Hand auf einem Router ausgeführt:

sed -i '/procd_set_param command $DAEMON -d \/usr\/lib\/respondd -p 1001 -g ff02::2:1001 $meshdevs -g ff05::2:1001 $clientdevs/c\        procd_set_param command $DAEMON -d \/usr\/lib\/respondd -p 1001 -g ff02::2:1001 $meshdevs $clientdevs -g ff05::2:1001 $clientdevs' /etc/init.d/gluon-respondd
reboot

aber hat nichts gebracht

1 Like

Sowohl yanic als auch gluon respondd scheinen noch Probleme zu haben. Fehlerberichte dazu finden sich unter

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.

1 Like

Hab den Patch vor dem build ausgeführt und funktioniert einwandfrei.

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 :wink:

@tarnatos, womit werden in nord nochmal die kartendaten generiert?

yanic

Und auf dem Mapserver wurde KEINE explizite Route für ff05-prefix gesetzt?

nein.

Dann bleibt die Frage, wie man das hinbekommt, ohne eine solche route (für den yannic) zu setzen und damit den Einsatz in einem Multi-Domain/Multi-Hood-Environment ohne x verschiedene Routingtabellen zu ermöglichen.

Bei uns geht das alles einfach ohne Probleme, auch München meldet keinerlei Probleme zurück. Es scheint also nicht an Gluon zu liegen.

Nutzt ihr separate Patches auf Gluon oben drauf? Wenn ja welche?

Ist euer bat0 Interface in einer Bridge? Ist der bat0 Bridgeport dann als Multicast-Router konfiguriert?

Was sind sonstige Gemeinsamkeiten die eure Setups haben?

hast Du mal einen oneliner mit tcpdump, um auf einem Knoten festzustellen, ob er auf die respondd-requests (und wenn ja auf welche Adresse) er antwortet?

Ich sehe da so Dinge wie:

05:11:49.773694 IP6 fe80::d832:3ff:fe7b:aa05 > ff02::2:1001: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff02::2:1001, length 24
05:11:50.939035 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
05:11:50.939075 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
05:11:52.253741 IP6 fe80::d832:3ff:fe7b:aa05 > ff05::2:1001: HBH ICMP6, multicast listener reportmax resp delay: 0 addr: ff05::2:1001, length 24
root@64283-cccda-n:~# tcpdump -ni br-client udp and port 1001
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-client, link-type EN10MB (Ethernet), capture size 262144 bytes
11:12:30.038791 IP6 fe80::d8ff:1ff:fe00:1504.10001 > ff05::2:1001.1001: UDP, length 34
11:12:34.027297 IP6 fe80::c6e9:84ff:feb0:c6b8.1001 > fe80::d8ff:1ff:fe00:1504.10001: UDP, length 1049

wir benutzen hopglass-server in Kiel und das sieht so aus:

listening on br-client, link-type EN10MB (Ethernet), capture size 262144 bytes
11:59:50.466193 IP6 fe80::5054:ff:fe4a:f13e.45123 > ff02::1.1001: UDP, length 14
11:59:51.024971 IP6 fe80::5054:ff:fe4a:f13e.45123 > ff02::1.1001: UDP, length 14
12:00:00.779114 IP6 fe80::1659:c0ff:feca:b902.43261 > fe80::dcad:beff:feef:ff00.1001: UDP, length 7
12:00:00.849260 IP6 fe80::dcad:beff:feef:ff00.1001 > fe80::1659:c0ff:feca:b902.43261: UDP, length 67
12:00:20.460520 IP6 fe80::5054:ff:fe4a:f13e.45123 > ff02::1.1001: UDP, length 14
12:00:21.020779 IP6 fe80::5054:ff:fe4a:f13e.45123 > ff02::1.1001: UDP, length 14
12:00:50.513940 IP6 fe80::5054:ff:fe4a:f13e.45123 > ff02::1.1001: UDP, length 14
12:00:51.056610 IP6 fe80::5054:ff:fe4a:f13e.45123 > ff02::1.1001: UDP, length 14
12:01:00.629106 IP6 fe80::1659:c0ff:feca:b902.40822 > fe80::dcad:beff:feef:ff00.1001: UDP, length 7
12:01:00.673766 IP6 fe80::dcad:beff:feef:ff00.1001 > fe80::1659:c0ff:feca:b902.40822: UDP, length 67

Ich habe herausgefunden, dass man in yanic die link-local Adresse des Interfaces setzen muss (sonst nimmt er fuer ff05::2:1001 eine global routbare Adresse auf dem Interface um es zu senden. Sonst geht folgendes nicht:

„mit respondd auf der br-client“:
Requests kommen an,
Irgendwelche Antworten sehe ich.
Erwarten würde aber, dass respondd dann von fe80::d832:3ff:fe7b:aa05%br-client antwortet.
Mit welcher SourceIP sollte der respondd denn antworten?

Vor allem: was passiert denn, wenn in yanic und hopGlass das Problem gelöst wird? Laufen dann die Knoten mit dem workaround patch nicht mehr korrekt?

Negativ. Mit dem Patch sollten d ie Knoten so wie ein 2018er Gluon verhalten, d.h. auf beide Adressen antworten.
(dass das funktioniert, dafür fehlt mir bislang noch eine Bestätigung in Verbindung mit einem Hopglass-Multidomain-Setup)

Das mit dem Multidomain-Setup lässt sich ja auch durch Network Namespaces lösen, wenn also alle anderen Hürden gelöst sind und das die verbleibende ist ping mich mal an dann bastele ich es so dass auf der eulenmap jeder hopglass-server in einem network namespace läuft

2 Likes

Was für Andere Hürden?
Der Patch, dass die 2019er-Knoten auch auf die alte ff02-Adresse lauschen? der ist systematisch hier drin.