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.
Scheinbar aber nichts, was nicht vorher bei uns auch schon so war.
Das Node taucht sauber auf der Karte auf mit unserem Setup.
https://map.ffmuc.net/#!/en/map/18e829c0aaae
Und was ist das für ein Backend?
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
- respondd: No reply when receiving for ff05::2:1001 from yanic server · Issue #1841 · freifunk-gluon/gluon · GitHub
- https://github.com/FreifunkBremen/yanic/issues/167
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 
@anon68922371, 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 24root@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 67Ich 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:
- yanic sendet es nicht auf dem gesetzten Interface heraus: https://github.com/FreifunkBremen/yanic/issues/167
- gluon respondd antwortet nicht auf die Anfrage: respondd: No reply when receiving for ff05::2:1001 from yanic server · Issue #1841 · freifunk-gluon/gluon · GitHub
„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?