Statusseite: Kein Knotenname der Nachbarknoten bei respondd Patch

Community Eulenfunk
1

Fortsetzung der Diskussion von Tipps für 2020.1.3 Firmware:

Damit Knoten von HopGlass bei auf der Eulenfunk-Karte angezeigt werden, braucht es ab Gluon 2019.1.x diesen Patch:

Bei Knoten mit so gepatchter Firmware wird jetzt aber kein Knotenname auf der Statusseite der Nachbarknoten angezeigt. Dort erscheint nur die MAC Adresse. Lasse ich den Patch weg, wird auf der Statusseite korrekt der Knotenname als anklickbarer Link zur entsprechenden IPv6 adresse angeziegt.

Gibt es da wirklich einen Zusammenhang, oder liegt dieses Verhalten an etwas anderem, dem ich in meinem Setup noch nicht auf die Spur gekommen bin? Hier meine Site, mit der ich die Firmware erstellt habe:

Und ich bin natürlich für Hinweise und Tipps dankbar, wie ich hier weiterkomme.

2

Neue Erkenntnis: Gleiches Verhalten zeigen auch die FFdus Knoten auf ihrer Statusseite. Ich vermute daher, dass es alle mit diesem Patch betrifft. Vielleicht können das andere Eulenfunker noch bestätigen?

3

Ich teste gerade mal einen modifizierten Patch:

1 „Gefällt mir“
4

Ich experimentiere gerade mit Gluon v2020.1.3, und verwende dabei diesen Patch:

Ich finde, dass unsere Skripte und Patches generell zu sparsam an Informationen sind. Daher habe ich versucht alles, was ich zu diesem Thema gelernt habe, im Patch selbst zu dokumentieren.

Mein Patch fügt nur Adresse ff02::1 in die Liste hinzu, und entfernt dabei keine Alte. Alleine das könnte das Problem bei den Nachbarknoten lösen.

Es kann aber sein, dass bei der neuen Adresse ff02::1 nicht nur $clientdevs, sondern auch $meshdevs stehen sollte, wie im modifizierten Patch oben. Wenn das nicht erforderlich ist, wäre es besser, es bei $clientdevs zu lassen.

Leider kenne ich mich mit der Firmware noch nicht gut genug aus und habe keine gute Test-Möglichkeiten bei mir. Daher würde ich mich über etwaige Rückmeldungen freuen.

5

Du bist ein Fuchs :slight_smile: Keine Ahnung was die Zahlen und der Code bedeuten, aber es funktioniert.Konten ist auf der Karte und Statusseite passt auch.

1 „Gefällt mir“
6

Leider habe ich keinen Plan von diesen Adressen und ihre Bedeutung. Aber @adorfer hat schon mal in einem anderen Zusammenhang geschriebenen, dass eine bestimmte Variante für die Eulenfunk Karte nicht funktioniert

Bei Gelegenheit teste ich aber auch gerne deine Version, falls die Speziallisten das in der Theorie nicht abschließend beurteilen können.

7

Es wäre lieb, wenn du es testen könntest.

Die neue Multicast-Adresse ff02::1, die wir mit dem Patch eingefügt haben, bedeutet „alle IPv6 im Netzwerk“. Da ist eigentlich zu viel, und es könnte ein Sicherheitsrisiko darstellen. Es ist wahrscheinlich der Grund, warum Gluon diese Adressen geändert hat.

Wenn wir bei dieser Adresse eine Schnittstelle weniger haben können, dann sollten wir es auch tun.

Irgendwann sollten wir die Server auf die neuen Adressen anpassen. Gluon hat bei dieser Änderung ja vor „Lecks“ gewarnt.

8

PRs welcome.
(Hint: es ist nicht so einfach wie es erscheint, ist halt kein Linklocal mehr)

FUD. Gerade das spricht dafür, die alte Adresse zu behalten, damit solche Szenarien nicht nur bei den „Leuten im Backend“ auffallen, sondern sofort auf der Map sichtbar werden, wenn sie mal auftreten.
Je länger ich drüber nachdenke, desto weniger halte ich es eigentlich für sinnvoll, die Map anzupassen, zumindest nicht vor einem Wechsel zu Babel.

9

Der Begriff „FUD“ hat einen abfälligen Beigeschmack, den hier nicht zu rechtfertigen ist. Nach meiner Erfahrung arbeite ich, und die Gluon Entwickler auch, freiwillig, großzügig und mit guten Absichten.

Das Freifunk-Netzwerk wächst immer mehr, und irgendwann wird es für Angreifer interessant. Eine gängige Art Angriff ist ein „Denial of Service“, und dafür sind Dienste wie respondd erstmals auffällig.

Man will nicht unbedingt jedem sofort Informationen zur Verfügung stellen, welche Nodes veraltete Firmwares mit bekannten Sicherheitslücken gerade da sind. Es gibt zum Beispiel in /etc/ssh/sshd_config die Einstellung „DebianBanner“, um diese Art Informationen zu minimieren. Ich möchte darauf hinweisen, dass Gluon 2018 das Lebensende bereits erreicht hat. Alles auf dieser Basis ist wohl nicht mehr wirklich sicher zu betreiben.

respondd hat keinerlei Authentifizierung. Normalerweise würde man denken, dass nur der Map-Server diese Informationen sammeln würde, und manche Details vielleicht nur an Admins weitergibt. Normalerweise wäre nicht jeder in der Lage, das Netzwerk mit Broadcasts an alle zu fluten. Generell versucht man auch, dass Services nicht auf Broadcasts an alle horchen und unbedacht antworten.

Gibt es irgendwo Dokumentation darüber, wie das Netzwerk organisiert ist, wo man sehen kann, welche Anforderungen an welche Nodes geroutet werden sollen, und welche nicht erlaubt sind? Wo ich zum Beispiel lernen könnte, warum manche Firewall Rules da sind oder nicht. Oder welche Multicast-Adressen wofür überall eingesetzt werden? Gab es bislang keine Bedenken zum respondd?

Zum Thema Map-Server, das es ist nicht so einfach ist, glaube ich dir gern. Sonst wäre es bereits gemacht. Ich möchte gern dazu lernen: was meinst du mit „kein Linklocal mehr“?

Warum denkst du, dass der Wechsel der Multicast-Adressen in Gluon keinen großen Sinn macht? Es stimmt ja auch, dass die Formulierung dazu in den Gluon-Release-Notes etwas schwammig ist. Ich denke aber, dass „Leck“ eher als „Informationsleck“ gemeint ist, und nicht als „Speicherleck“. Solche Sicherheitsrisiken wären nicht „sofort auf der Map sichtbar“.

Ich habe halt das Gefühl, dass es viel Halbwissen gibt, und ich möchte gerne Genaueres wissen und möglichst aufschreiben.

2 „Gefällt mir“
10

Ich halte die geplante Elektroverschrottung von >80% der heute eingesetzten Router für mindestens unschön.

Und was die breaking-Changes bei den Respond-Adressen anbelangt: Sie waren ungenügend diskutiert (in meinen Augen), die die Rechtfertigung („wegen Babel“, was 99% der Leute weder heute, noch binnen dieses Kalenderjahres nutzen werden) und dann die Umschreibung in den Releasnotes „prevents leaks“ war Nebelkerzenwerferei.
Ob das für Deine Definition für „böse Absichten“ ausreicht, das vermag ich nicht zu urteilen.

Aber wenn es Dir gefällt, dann ziehe ich mein „FUD“ zurück und nenne es eben „Nebelkerzenwerferei“.

11

zur Respondd Adresse fragte @rdiez heute auf der Mailingliste nach und bekam von @blocktrron folgende Antwort:

There are two addresses nodes answer respondd queries on. ff02::2:1001 (Link-Local)
and ff05::2:1001 (Site-Local).

Up until 2017, only the Link-Local address existed but with the addition of Babel
the link-local address became deprecated for mesh-wide queries (nd was removed a year ago).

The leakage is described in #1701 [0]. In the past, the nodes respondd also ran for the
link-local address on the client bridge (LAN ports). This way, attaching a WAN port of a node
from a different site (which does not interconnect sites) would leak to respondd-information
leaking between domains / communities.

[0] How to prevent a respondd connection between different sites · Issue #1701 · freifunk-gluon/gluon · GitHub

Wer auch immer deiner Meinung nach eine Verschrottung plant oder irgendetwas böswillig oder zumindest mutwillig dergleichen tut, möge bitte mit Belegen benannt werden.

Was Gluon angeht wurde eben erst ein Patch von @anon75826926 gemerged für das kommende v2020.2, der 64KB im Flash-Speicher auf tiny devices spart: build: target_config_lib: do not build unused packages for targets without opkg by neocturne · Pull Request #2051 · freifunk-gluon/gluon · GitHub
… aber alles geplante Verschrottung…

4 „Gefällt mir“
12

Ich habe gerade einmal versucht, den Bug in unserem Testsetup nachzustellen - leider erfolglos.

Die Supernodes von Rhein-Sieg (siegburg1+2/lohmar1-3) binden durch den Multidomain-Betrieb die yanics nicht an die Multicast-Adresse, sondern an die fe80 vom bat-Interface. So müssen wir die jsons eines yanics für verschiedene Maps nicht aufdröseln, sondern bekommen für jede Hood/Domain eigene json files.

Map Testnode

20200616_respondd_nameresolv
20200616_respondd_nameresolv1366×598 30.5 KB

gluon branch 2020.1.3

  • gl-mifi patch
  • respondd-backpatch

sonst nix drin

Test-Firmware liegt hier

13

Der bisherige Patch war „auf die alte Broadcast-Adresse zurück“.

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

Da aber die Knoten Untereinander für die Namensauflösung (natürlich) die neue Adresse nutzen und somit „leer ausgegangen“ sind nach dem Patch
ist der neue Patch nun „die alte Broadcastadresse zusätzlich“.
Dass der „funktioniert“ hat ja @steneu als erster erfolgreich testen können und ich konnte es gestern spät mit Plaste zusammen bei unserer Firmware auch nachvollziehen.

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
14

Hab’ bei der Testfirmware gerade auf den 2020.2 branch gewechselt - da wollte er nicht patchen.
Neuer diff und hiermit gepatcht

15

Ist der identisch mit dem obigen von adorfer? Konnte keinen Unterschied finden. :thinking:

16

den anderen wollte der buildserver nicht - Inhalt ist 1:1 identisch.

Warte jetzt, was aus dem Ofen rauskommt.

17

Festgstellt, dass ich beim Patch von @adorfer beim supernode yanic auf fe80:: keine Daten kriege.

es braucht dazu:

-g ff02::2:1001 $meshdevs $clientdevs

sonst läuft hier nix.

18

Was fehlt/geht nicht, wenn „$clientdevs“ fehlt an

-g ff02::2:1001 $meshdevs
19

Erst wenn $clientdevs dazu kommt, bekomme ich auf dem yanic der supernode Daten.
Da auf der Supernode je Hood/Domain ein yanic an das jeweilige bat-Interface gebunden ist, werden separierte .jsons erzeugt.

root@lohmar1 /home/yanic # more yanic_config_validator.sh
#!/bin/bash
for bat in ifconfig | grep bat | cut -d ' ' -f 1; do
echo „config file for $bat is: "
ls /etc/yanic/yanic_$bat.conf
address=ifconfig $bat | grep fe80 | awk '{print $2}' | cut -d '/' -f 1
echo „configured ip_adress is: $address“
echo „writing $address to config file…“
sed -i 's/^(ip_address\s*=\s*).*$/\1“‚$address‘"/’ /etc/yanic/yanic_$bat.conf
echo „restarting yanic_$bat service“
systemctl restart yanic_$bat
done

root@lohmar1 /home/yanic # ifconfig bat01
bat01 Link encap:Ethernet Hardware Adresse ae:b4:d5:9f:fd:55
inet Adresse:10.6.8.2 Bcast:10.6.15.255 Maske:255.255.248.0
inet6-Adresse: 2a03:2260:123:100::2/64 Gültigkeitsbereich:Global
inet6-Adresse: fe80::acb4:d5ff:fe9f:fd55/64 Gültigkeitsbereich:Verbindung

[[respondd.interfaces]]
ifname = "bat01"
port = 10001
ip_address = "fe80::acb4:d5ff:fe9f:fd55"
# default
multicast_address = "ff02::2:1001"
# or
#multicast_address = "ff05::2:1001"
#send_no_request = true

damit läuft die parallele Sammlung mit yanic stabil durch.

20

Danke, ich hab’s mal auch bei mir dazugeschrieben.