Für Rhein-Sieg Domains, die über die Siegburger Supernodes anbinden, ist ein respondd-reverse-Patch eingepflegt:
, damit von den yanics auf den fe80-Adressen der Bat-Interfaces auch Multicast-Requests ihre Antworten erhalten.
Der gl-mifi support kommt ebenfalls per patch - wird durch openwrt voll supported.
Testbetrieb, wie gehabt, in Lohmar Innenstadt auf den Haupstraßen-Nodes.
Die Archer C50v4 im Testfeld bauen jetzt im 2.4Ghz Bereich Meshverbindungen auf, die es vorher nicht gab. Der 5Ghz Bereich scheint dagegen unverändert.
warum habt ihr den eingebaut? was passiert ohne den?
Wir haben in Kiel im Moment mit der 2019-nightly probleme, könnt edas damit zusammenhängen?
wir haben auf den Siegburger SuperNodes mehrere Domains mit batman Interfaces parallel laufen und entsprechend hocken die yanics auf den fe80-Adressen:
root@fgw03 ~ # ps ax | grep yanic 14888 ? Ssl 0:03 /opt/go/bin/yanic serve --config /etc/yanic/yanic_bat04.conf 14901 ? Ssl 0:06 /opt/go/bin/yanic serve --config /etc/yanic/yanic_bat05.conf 14915 ? Ssl 0:01 /opt/go/bin/yanic serve --config /etc/yanic/yanic_bat11.conf 14929 ? Ssl 0:04 /opt/go/bin/yanic serve --config /etc/yanic/yanic_bat14.conf
und schicken Multicasts auf port 1001 raus für die Anforderung der Stats. Siehe Ansible Role yanics Rhein-Sieg.
Die fe80-Adressen wechseln bei reboot, deswegen auch die zusätzlichen cronjobs zum Nachsteuern:
yanic_config_validator.sh
Ich habe ganz vergessen hier zu erwähnen, dass für die Siegburger Map selbst noch ein Hopglass-Server auf die Daten wartet - da wäre also auch jede Menge im ansible rumzubasteln was ich mir vor dem geplanten Umzug auf neue VMs besser spare.
Gerade nachkontrolliert - auf der Siegburger Map ist jetzt rot die vorherrschende Farbe - dem Hopglass hat der Patch wohl nicht geholfen.
Mit v2019.1 wurde die ff02::2::1001 standardmäßig deaktiviert, weil es Probleme im Multidomain-Betrieb mache und nur noch die ff05::2:1001 an das ClientInterface gebunden. Das hat dazu geführt, dass die nodes von den Gateways den Request nicht mehr mitbekommen haben. Statt jetzt alle yanics auf den batman Interfaces der 4 Supernodes umzukonfigurieren, wurde das clientInterface wieder and die f002::2:1001 gebunden.
So kommen die Requests auf Port 1001 der Node wieder an und sie antwortet, wie gewohnt, zurück.
Ohne den Patch gab es keine Meldungen an den yanic mehr und die Node ging in der Map offline.
Vorher getestet mit v2019.1 Original FW-Image und dann manuell in /etc/init.d/gluon-respondd das im Bild rot markierte ‚$clientdevs‘ wieder eingefügt, Service restart und schon kamen die Stats wieder im jeweiligen yanic auf dem bat-Interface der supernode an.
Auch wenn ich nun auf einem 2019.1 einen respondd habe, der gestartet wurde wie auf einem 2018er: Auf der Karte traucht er trotzdem nicht auf.
/usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i mesh0 -i mesh-vpn -i br-client -t 10 -g ff05::2:1001 -i br-client -t 10
Gibt es noch irgendeine ebtables-Rule, die ebenfalls angepasst gehört?
Könnte es sein, dass die Datenstruktur sich geändert hat? (oder das was als request-Packets erwartet wird?)
„oben“ geht, „unten“ kommt nicht an.
Gerade noch die restlichen Rhein-Sieg Domains für den Rollout signiert.
Die einzige Änderung, die der Patch auf dem Router selbst macht ist der rot markierte in /etc/init.d/gluon-respondd:
#!/bin/sh /etc/rc.common
USE_PROCD=1
START=50
DAEMON=/usr/bin/respondd
MAXDELAY=10
start_service() {
local ifdump="$(ubus call network.interface dump)"
local meshdevs=$(for dev in $(echo "$ifdump" | jsonfilter -e "@.interface[@.proto='gluon_mesh' && @.up=true].device"); do echo " -i $dev";done;)
local clientdevs=$(for dev in $(echo "$ifdump" | jsonfilter -e "@.interface[@.interface='$(cat /lib/gluon/respondd/client.dev 2>/dev/null)' && @.
up=true].device"); do echo " -i $dev -t $MAXDELAY";done;)
procd_open_instance
procd_set_param command $DAEMON -d /usr/lib/respondd -p 1001 -g ff02::2:1001 $meshdevs $clientdevs -g ff05::2:1001 $clientdevs
procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout:-5} ${respawn_retry:-5}
procd_set_param stderr 1
procd_close_instance
}
service_triggers() {
local script=$(readlink "$initscript")
local name=$(basename ${script:-$initscript})
procd_open_trigger
procd_add_raw_trigger "interface.*" 0 "/etc/init.d/$name" reload
procd_close_trigger
}
Also per ssh in den Testrouter mit der ungepatchten v2019.1 einloggen und nachschauen, was im script steht - vermutlich fehlt das $clientdevs.
Das hat für den Rhein-Sieg Meshviewer mit den yanic-Datenquellen gereicht - ich habe gerade gesehen, dass der Hopglass-Server für die Siegburger Map damit immer noch Probleme hat.
nach meiner Vermutung(!) antwortet das Gluon jetzt schlicht auf einem anderen Interface, so dass der Hopglas auf der Netzmaske (außerhalb von fe80 evtl.) nicht mit Antworten rechnet?
Wir hatten für die Kompatibilität zu Hopglass den alfred noch im image drin. Die Siegburger Map arbeitet noch mit dediziertem Hopglass-Server, auf dem alfred und batvis laufen.
Ich habe gerade einen ar150 mit dem alten stable-3.0.8 geflasht - der liefert sauber ab beim hopglass.
Jetzt nach den Unterschieden suchen…
Ich wundere mich ehrichgesagt, wieso das bei uns in Troisdorf einfach läuft.
Ich habe nur den yanic auf die Aktuellste Version geholt und alles andere läuft (jetzt halt über die fd05)
Hab ich da was übersehen was mir auf die Füße fällt?
Damit hast Du halt die Anpassung für den Hopglass nicht gemacht. (Hint: Darum geht es hier in den letzten x postings)
Ok. Das war mir nicht ganz klar.
Mit den yanics habe ich alle Daten auf den Siegburger Supernodes - such gerade, ob ich die nicht direkt an den hopglass durchpusten kann, dass der die Nodes in Ruhe lassen kann.
P.S.: @Stefan - mir fehlen immer noch die Troisdorfer Gate-Daten auf dem yanic, der dafür auf dem Grafana Server zum Einsammeln läuft?
Daran dachte ich auch schon: Den Hopglass-Server gegen yannic zu ersetzen und nur den Hopglass selbst zu behalten.
Aber da ich jetzt schon so viel Zeit in die „Fehlersuche“ gesteckt habe ohne greifbares Ergebnis würde ich die Lösung trotzdem gern auf dem bisherigen Weg finden.
Nur mal so zur Sicherheit: Hast Du auch mal einen neuen Knoten (also den der Mapserver noch nicht kannte) mit 2019.x ins Netz (und auf die Karte) gebracht?
@adorfer: nö - smart03 fährt zum Vergleich die alte stable-3.0.8 - die liefert alfred/batvis beim hopglass ab - siehe Siegurger Map und mit respondd zu den yanics auf den gateways: Rhein-Sieg Map
Als Vergleich muss mein rettesichwerkann herhalten mit stable-3.1.0/v2019.1 - der taucht nur in der Rhein-Sieg Map auf:
auf beiden bin ich per ssh drin und suche und weiss nicht genau, nach was. alfred und batvis laufen -
diff -uNr rettesichwerkann smart03 >alfred.patch
will nicht 
„Nö“ zu was?
Neue (vorher unbekannte) Knoten tauchen auch in der Yannic-Map nicht auf, nur die „von 2018 bekannten“ werden von Yannic gefunden?
nö, ich habe einen neuen Knoten mit alter Firmware zum Vergleich online gebracht.
der rettesichwerkann fährt zum Vergleich die neue Version. Alt geht in beide Richtungen (yanic/hopglass), neu nur Richtung yanic Bai yanic werden neue wie alte Knoten gefunden - bei hopglass ist alles in der map offline, was neue Firmware fährt.
Wenn also 2019er-Knoten („fabrikneu geflashte“), die nicht vorher auf 2018er-gluon dem Yannic bekannt geworden sind, auf dem yannic jetzt auch fehlen, dann haben wir evtl. einen Gluon-Bug.
Dann würden die Knoten nur noch auf Unicast aber nicht mehr auf Multicast ihre respondd-Daten geben.
zum dritten Mal: mit yanic und gluon v2019.1 ist alles cool - alle Knoten da.
Hopglass mit alfred und batvis bekommt nur Daten von Nodes mit alter Firmware.
Dann hatte ich Dein „Nö“ falsch verstanden.
Darum geht’s mir nicht.
Frage war: Was passiert mit neuen Knoten, die erstmalig mit Gluon2019 überhaupt ins Netz kommen. Aber auch die tauchen auf im yannic, korrekt?