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

PetaByteBoy · 13. Oktober 2019 um 03:42

Das heisst wenn das jetzt kein Multi-Domain setup wäre, würde es funktionieren?

adorfer · 13. Oktober 2019 um 03:44

Davon wäre ich ausgegangen. die Knoten haben die Requests auf die ff02-Adresse bekommen und irgendwie drauf geantwortet. Aber wohl nicht so wie der hopglass es verstanden/ausgewertet/bekommen hätte.

PetaByteBoy · 13. Oktober 2019 um 03:59

Ich kann nicht ganz folgen, was ist jetzt das Problem? An den Antworten hat sich doch nichts geändert, die sind immernoch unicast an die IP, die angefragt hat, oder hab ich was verpasst?

adorfer · 13. Oktober 2019 um 04:05

Das weiss ich auch nicht, aber die Requests kommen an bei den 2019.x-Knoten und werden -sofern gepatched- auch beantwortet.
Nur der hopglass-Server gibt sie nicht in seinen Output. Warum das so ist, das entzieht sich meiner Kenntnis.

Ich kann nur auf obigen Screenshot verweisen, das ist tcpdump auf einem solchen Knoten.
Gern kann ich ich auch pcap-files liefern. Dann aber bitte spezifizieren, was gebraucht wird.

adorfer · 13. Oktober 2019 um 23:50

Jetzt ist da wieder ein Knoten in ffdus.

firmware: ‚2019101310-exp‘ - ‚v2019.1-5-g9600749f+‘

Ich werfe da auch gern Deinen Key drauf.

root@x64-updatetest:/etc/opkg# ps |grep respondd|grep -v grep
3540 root     34176 S    /usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i eth0 -i mesh-vpn -i br-client -t 10 -g ff05::2:1001 -i br-client -t 10 
root@x64-updatetest:/etc/opkg# 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
01:46:04.733903 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:46:04.733942 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:46:04.734787 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:46:04.734808 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:46:06.526611 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
01:46:06.527606 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
01:46:12.836093 IP6 fe80::d832:3ff:fe7b:aa05.1001 > fe80::6400:ecff:fe4f:6c70.20026: UDP, length 220
01:46:12.876206 IP6 fe80::d832:3ff:fe7b:aa05.1001 > fe80::6400:ecff:fe4f:6c70.20026: UDP, length 443
01:46:34.741764 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:46:34.741783 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:46:34.741791 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:46:34.742740 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:47:04.758454 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:47:04.758487 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:47:04.759373 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:47:04.759819 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:47:06.550974 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
01:47:06.550999 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
01:47:10.676302 IP6 fe80::d832:3ff:fe7b:aa05.1001 > fe80::6400:ecff:fe4f:6c70.20026: UDP, length 443
01:47:15.316234 IP6 fe80::d832:3ff:fe7b:aa05.1001 > fe80::6400:ecff:fe4f:6c70.20026: UDP, length 219
01:47:34.766129 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:47:34.767007 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:47:34.767481 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:47:34.767506 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:48:04.790976 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:48:04.792114 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:48:04.792140 IP6 fe80::8c7b:98ff:fe7b:9d11.38080 > ff02::1.1001: UDP, length 14
01:48:04.793213 IP6 fe80::8c7b:98ff:fe7b:9d11.42544 > ff02::1.1001: UDP, length 14
01:48:06.612221 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
01:48:06.612263 IP6 fe80::6400:ecff:fe4f:6c70.20026 > ff02::2:1001.1001: UDP, length 14
01:48:08.276012 IP6 fe80::d832:3ff:fe7b:aa05.1001 > fe80::6400:ecff:fe4f:6c70.20026: UDP, length 219
01:48:11.316644 IP6 fe80::d832:3ff:fe7b:aa05.1001 > fe80::6400:ecff:fe4f:6c70.20026: UDP, length 449

adorfer · 16. Oktober 2019 um 00:12

Mein Fehler: Ich hatte den Patch von
https://raw.githubusercontent.com/Freifunk-Rhein-Sieg/ffrsk-site/tools/patches/package/101-add-respondd-clientdev.patch
genutzt, der aber nicht die Broadcast-Adresse ändert, sondern nur das client-Interface

nach

github.com

eulenfunk/firmware/blob/v2019.1.x/patches/fix-respondd-rsk.patch

--- a/package/gluon-respondd/files/etc/init.d/gluon-respondd
+++ b/package/gluon-respondd/files/etc/init.d/gluon-respondd
@@ -13,7 +13,7 @@ start_service() {
        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 -g ff05::2:1001 $clientdevs
+       procd_set_param command $DAEMON -d /usr/lib/respondd -p 1001 -g ff02::1 $clientdevs $meshdevs -g ff02::2:1001 $meshdevs -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

funktioniert es auch mit dem bisherigen Hopglas (ohne Änderungen)

https://map.ffdus.de/#!v:m;n:da32037baa05

rubo77 · 6. November 2019 um 00:58

Also, wenn ich das richtig sehe, macht der patch von Freifunk-Sieg mehr als nur den gluon commit zu reverten. Hier ist das Problem doch eingeführt worden, oder?

https://github.com/rubo77/gluon/commit/59a442

also müsste man in /etc/init.d/gluon-respondd nur clientdevs wieder ergänzen und es sollte so laufen wie vorher, oder?

wenn ich das von hand im Router änder scheint es nicht zu klappen, außerdem: wenn ich den reboote, dann ist die manuelle Änderung wieder weg in der datei ;( ???

adorfer · 11. November 2019 um 14:39

Keina Ahnung was Du dort tust. Ich vermag zu sagen, dass es mit dem von mir im Vorposting verlinkten Patch funktioniert.

github.com

eulenfunk/firmware/blob/v2019.1.x/patches/fix-respondd-rsk.patch

--- a/package/gluon-respondd/files/etc/init.d/gluon-respondd
+++ b/package/gluon-respondd/files/etc/init.d/gluon-respondd
@@ -13,7 +13,7 @@ start_service() {
        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 -g ff05::2:1001 $clientdevs
+       procd_set_param command $DAEMON -d /usr/lib/respondd -p 1001 -g ff02::1 $clientdevs $meshdevs -g ff02::2:1001 $meshdevs -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

rubo77 · 12. November 2019 um 05:51

Ich versuche deinen Patch von Hand per SSH auf dem Router anzuwenden ohne die Firmware zu bauen.

ich würde gerne den Zustand von Gluon 2018 wiederherstellen, um zu testen ob es bei uns in Kiel das das Problem löst, oder ob vielleicht noch etwas anderes zu tun ist.

Ist hier denn noch jemand, bei dem der Patch auch nicht hilft?

In Kiel benutzen wir ja leider nicht yanic.

adorfer · 12. November 2019 um 16:38

Zu yanic kann ich Dir nichts sagen, da musst Du andere befragen, wie man das zum Laufen bekommt.

ddreamer · 17. November 2019 um 11:29

Fast.
Schau dir die IP-Adressänderung an „ff02::2:1001“ ersetzen gegen „ff02::1“ !
Das hast sicherlich vergessen. Zusatzich $clientdevs dazu

… Man überliest das mit der IP schnell.
Kannst aber auch auf laufenden Knoten anwenden. Ging hier bei mir (Freifunk Kassel) wunderbar

Vogelbecker · 20. November 2019 um 09:35

Moin zusammen,

irgendwie tun meine gluon-v2019.1-1-gcdbfdf7 Test Knoten nicht das was sie sollen.

Yanic hatte ich angepasst:

[...]
# interface that has an IP in your mesh network
[[respondd.interfaces]]
# name of interface on which this collector is running
ifname = "bat0"
[...]
# multicast address to destination of respondd
# (optional - without definition used batman default ff02::2:1001)
#multicast_address = "ff02::2:1001"
[...]
# interface that has an IP in your mesh network
[[respondd.interfaces]]
# name of interface on which this collector is running
ifname = "bat0"
[...]
# multicast address to destination of respondd
# (optional - without definition used batman default ff02::2:1001)
multicast_address = "ff05::2:1001"
[...]

Das Ganze hat auch schonmal funktioniert. Nur nach einem Reboot der Nodes sind diese laut der Map offline. Der Knoten ist aber funktional. Via SSH komme ich auch drauf:

root@ffein-vogelbeck-dorfplatz:~# ps
[...]
 2201 root      2124 S    /usr/bin/respondd -d /usr/lib/respondd -p 1001 -g ff02::2:1001 -i mesh0 -i vx_mesh_wan -g ff05::2:1001 -i br-client -t 10
[...]

Übersehe ich hier irgendwas?

Viele Grüße

rubo77 · 21. November 2019 um 23:41

Ich habe jetzt den patch aus Rhein-Sieg auch in Kiel eingebaut und mit der neuesten hopglass-server version werden die jetzt auch angezeigt:

die entscheindende Zeile ist

-	procd_set_param command $DAEMON -d /usr/lib/respondd -p 1001 -g ff02::2:1001 $meshdevs -g ff05::2:1001 $clientdevs
+	procd_set_param command $DAEMON -d /usr/lib/respondd -p 1001 -g ff02::2:1001 $meshdevs $clientdevs -g ff05::2:1001 $clientdevs

adorfer · 22. November 2019 um 02:49

Es kommt halt darauf an, wie die lokale hopglass-Server-Installation ist, also welche Adresse dort konfiguriert wurde.

rubo77 · 5. Januar 2020 um 03:04

Ich habe herausgefunden, wie man feststellen kann ob in dem json Knoten sind, die wegen dem bug noch nicht in hopglass angezeigt werden:

Man muss in der aliases.json für den hopglass-server einen block ohne node_id ergänzen, z.B.

  "ffffffffaaaa": {
      "nodeinfo": {
        "hostname": "Unbekannter Knoten mit respondd bug",
        "owner": {
          "contact": "Unbekannt"
        }
      },
  },

dann erscheinen die unter der id undefinded, z.b. hier:

https://mesh.freifunk.in-kiel.de/#!v:m;n:undefined

steneu · 9. Juni 2020 um 08:53

Ist der Patch aktuell für die Eulenfunk Karte noch notwendig? Mein Testknoten mit 2019.1.x taucht dort jedenfalls leider auch nicht auf. Wie müsste ich das in die Firmware oder den Build Prozess einbauen?

adorfer · 9. Juni 2020 um 10:45

Ja.

Das ist ein Problem der Selbstdiagnose von unvollständig provisionierten Supernodes, die dann ihre Tunneldigger abschalten sollten.
Will sagen: Dein Knoten hängt vermutlich an einen Supernode, der keine Verbindung zum Restnetz hat. Ist halt die Test-Firmware für das derzeitige Testnetz.

steneu · 9. Juni 2020 um 12:19

Ich Baue im Moment Firmware für Rade und da geht es auf die bestehenden Supernodes. Das hat auf der Statusseite des Knoten auch schon gut ausgesehen. Der Knoten war per mesh-vpn online und hatte auch angemessenen Durchsatz. Nur auf der Eulenfunk Karte für Rade taucht er nicht auf. Die bisherige Firmware in Rade ist auch „schon“ auf Gluon 2018.1.3

Jetzt bräuchte ich vermutlich nur eine Anleitung, wie ich diesen Patch in die Firmware bekomme.

adorfer · 9. Juni 2020 um 12:27

ein .patch-file und ein .sh-script

https://raw.githubusercontent.com/eulenfunk/firmware/2675e54dee30bc6df54e9b435b63c706093749aa/patches/fix-respondd-rsk.patch

github.com

eulenfunk/firmware/blob/2675e54dee30bc6df54e9b435b63c706093749aa/patches/fix-respondd-rsk.sh

#!/bin/bash
echo $PWD 
patchfile="../patches/fix-respondd-rsk.patch"
if ! patch -R -p1 -s -f --ignore-whitespace --dry-run <$patchfile; then
  patch -p1 --ignore-whitespace <$patchfile
fi
grep 'ff02:'  package/gluon-respondd/files/etc/init.d/gluon-respondd

github.com

eulenfunk/firmware/blob/2675e54dee30bc6df54e9b435b63c706093749aa/patches/fix-respondd-rsk.patch

--- a/package/gluon-respondd/files/etc/init.d/gluon-respondd
+++ b/package/gluon-respondd/files/etc/init.d/gluon-respondd
@@ -13,7 +13,7 @@ start_service() {
        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 -g ff05::2:1001 $clientdevs
+       procd_set_param command $DAEMON -d /usr/lib/respondd -p 1001 -g ff02::1 $clientdevs $meshdevs -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

steneu · 9. Juni 2020 um 12:47

Die habe ich gefunden. Aber ich kapier nicht, wie ich das in meinen Firmware Bau Prozess einbinden kann. Habe mir das Eulenfunk Repro jetzt schon länger angeschaut, aber es nicht geblickt. Es scheint ja nicht wie ein Paket eingebunden zu werden.