OpenWRT und Dortmund

Community Dortmund
1

Hallo,
gerade versuche ich einen Knoten mit OpenWRT aufzubauen der zumindest einen fastd Tunnel auf machen kann und dann per batman-adv am Netz teilhaben kann. Die WLAN config soll dann folgen.

Leider antwortet mir fastd immer mit einem Fehler:

mesh_vpn: startup failed

Ich habe einfach die komplette Konfiguration aus einer Node (/etc/config/*) kopiert. Da die Node fehlerfrei funktioniert sehe ich dort kein Problem.

Weiter habe ich in /etc/config/fastd erst „secret“ geloescht und dann per /etc/init.d/fastd generate_key mesh_vpn neu erzeugt.

Was fehlt mir denn noch?

Pakete:
DEPENDS:=+kmod-batman-adv +batctl +vis +fastd

2

Hi Hermann,

was willste damit bezwecken? In der Art wie das Netz momentan aufgebaut its hat es nur Nachteile sowohl für den Node als auch für das Netz wenn du nicht Gluon benutzt, insbesondere wenn du dich nicht sehr sehr gut mit der Funktionsweise von Gluon auskennst. Zusätzlich werden wir den Knoten nicht auf der Karte sehen können wenn du nicht auch respondd korrekt einrichtest und du musst ständig hinter den Parametern herrennen die mit aktualisierter Gluon-Firmware ausgeliefert werden.

Da wir in der letzten Woche einige Umstellungen im Dortmunder Netz hatten bin ich hinter diversen Knoten - auch in Geflüchteteneinrichtungen - her gerannt, die ohne Autoupdate oder mit sonstigen Sonderlocken eingerichtet wurden und dann nicht mehr gepflegt wurden. Sehr sehr frustrierend.

2 „Gefällt mir“
3

Hi,
nun es geht bei Freifunk ja um ein freies Netz. Sich damit zu beschäftigen kann nicht falsch sein. Im Bezug auf die Pflege ist das halt Arbeit. Es wird ja auch mal wieder ruhiger.

Die Sichtbarkeit ist ja genauso wenig gegeben wie bei Knoten die nicht sich das nicht wünschen.

Zum Thema:
Gibt es offensichtliche Dinge die anders sind im Bezug auf OpenWRT vs gluon?
Was ist mit anderen Stolpersteinen?
Ist ein Fehler erkennbar?

4

Ja die Diskussion was Freifunk ist und zu was es geworden ist wurde und wird ständig geführt. Gluon ist leider ziemlich auf eine Monokultur und den Use Case eines Hotspot-Netzes optimiert. Wir denken durchaus drüber nach wie wir das ändern können, da standen aber bisher andere Prioritäten im Weg.

Eigentlich ist dein Ansatz korrekt. Fastd kennt zwei Schlüssel, den eigenen und den public key der Supernodes (je ein Key pro Supernode). Die Supernode-Keys müssen stimmen sonst gibt es keine Verbindung. Die Supernodes akzeptieren beliebige keys, müssen also den Key von deinem Router nicht kennen.

1 „Gefällt mir“
5

Vielen Dank.

Da ich das kopiert habe vermute ich da kein Problem.

Ist das Gluon von Dortmund im Prinzip ein OpenWRT oder sind da patches, spezielle Versionen oder soetwas im Einsatz?
Im besonderen batman?

6

Wir nutzen bisher Gluon ohne jegliche externe Pakete oder Patches. Unser Buildsystem und die Konfiguration sind offen und liegen auf Github: GitHub - ffdo/site-ffdo: FF Dortmund (FFDO) specific Gluon configuration

Alle genutzten Einstellungen und Pakete sind in den Dateien site.conf und site.mk angegeben. Die Einstellungen und der Build-Vorgang sind gut dokumentiert: http://gluon.readthedocs.io/

1 „Gefällt mir“
7

Hint: aus /etc/config/fastd wird in Gluon eine fastd.conf zur Laufzeit zusammengebaut und damit der fastd gestartet:

root@17139-FW-Test-5f9a:~# ps w | grep fastd
 1136 root      3304 S    /usr/bin/fastd --config - --daemon --pid-file /var/run/fastd.mesh_vpn.pid

/etc/fastd, wo fastd eigentlich drin lebt, ist leer:

root@17139-FW-Test-5f9a:~# ls -la /etc/fastd/
drwxr-xr-x    2 root     root             3 Jun  9 17:55 .
drwxrwxr-x    1 root     root             0 Jun 11 01:21 ..

D. h. es fehlen Dir wohl die Skripte, die die Konfiguration umsetzen.