[RFC PATCH 0/1] Konzept zum Erreichen des Webinterfaces

Di Jan 5 14:22:24 CET 2016

Moin

Gestern hab mit ChristianDr das ganze noch mal in Ruhe bei na Cola
durchgesprochen.

Wir sind zu dem Schluss gekommen, dass es erstmal ausreichen sein wird
in jedem Subnetz das selbe Prefix über die Router zu announcen. Damit
kommt man erstmal auf die Kisten drauf. Dabei wird der keyXchange
erweitert, die Geo-Daten vom Knoten zu bekommen und der Nodewatcher
sendet die Geo-Daten dann auch direkt an das Monitoring.

In einem Schritt danach wird der keyXchange dann so umgebaut, dass die
Auswahl der Hood auf den Knoten erfolgt. Dazu soll der keyXchange dann
einfach die Hood Informationen als json ausgeben. Am besten können wir
in diesem Schritt einfach einen neuen keyXchange bauen, den wir dann auf
mehreren Servern hinterlegen können. Diese Server könnten sich z.B. per
Syncthing synchronieren.

Eine Authentifikation der json Files kann man danach dann natürlich auch
noch einbauen. Und mit der Zeit können wir dann auch die bssid/essid/etc
Daten pro Hood definieren.

Ein passender Patch für den ersten Schritt wird heut Abend oder im Laufe
des morgigen Tages kommen. Mir fehlen da nur noch n paar Kleinigkeiten.

Tim

Am Montag, den 04.01.2016, 17:04 +0100 schrieb Tim Niemeyer:
> Hallo
> 
> Der Patch ist wirklich nur RFC (bitte nicht applien). Ich weiß nichtmal,
> ob der letzte Stand jetzt so compiled. Der Patch dient nur grob der
> Orientierung. Mich interessiert vor allem, ob ihr allgemein Einwände
> habt, ob ich irgendwelche wichtigen Punkte übersehen oder vergessen
> habe, oder ob es eine bessere Lösung gibt.
> 
> Eigentlich wollte ich aktuell nur daran arbeiten, dass man das
> Webinterface besser erreichen kann. Dabei war die Idee recht einfach:
> Die Knoten verteilen mit niedriger Priorität ein IPv6 Prefix an die
> lokalen Clients, ohne dabei ein Gateway zu setzen (wir wissen ja nicht,
> ob der Knoten online ist oder nicht). Der Client kann sich dann sein
> eigenes Prefix angucken und braucht nur noch die MAC des Knotens dran zu
> schreiben, um die IPv6 Adresse vom Knoten zu bekommen. Das Prefix ist
> allerdings in jeder Hood anders, weshalb der Knoten wissen muss in
> welcher Hood er gerade ist.
> 
> Das schöne dabei ist, dass wir diese Prefixe auf den L3 Gateways auch
> irgendwann mal announcen könnten. Dabei würden wir dann allerdings ein
> Gateway mitsenden. Wenn sich dann der Knoten und der Client dieses
> Gateway setzen, könnte man auch Hood-Übergreifend auf den Knoten
> zugreifen.
> 
> Da in jeder Hood ein anderes Subnetz gilt, ist der Patch schon etwas
> länger geworden. Denn der Knoten muss wissen, welche Subnetze es gibt
> und in welches er rein gehört. Das soll ja nach wie vor anhand der
> Geo-Location passieren. Diese Zuordnung geschieht zur Zeit noch immer im
> zentralen keyXchange. Mit diesem Patch wird das anders. Der Knoten
> bekommt die Information über alle Hoods und sucht sich dann selber die
> richtige Hood aus.
> 
> Aktuell ungelöste Probleme:
> * Die announcten Prefixe haben eine unlimited valid time. Leider kann
>   odhcpd das aktuell nicht anders. Ich tendiere dazu einen simplen radvd
>   selber zu implementieren, bzw den uradvd von fluon zu forken und an
>   unseren Zweck anzupassen.
> * Das VPN wird noch nicht konfiguriert. Hier stelle ich mir eine
>   Erweitung des hoodconfigure Scripts vor, welches in /etc/hoods/ die
>   *.gw Dateien ausließt und dann das normale openwrt fastd config File
>   einstellt. Parallel dazu müssten wir auf den Gateways einstellen, dass
>   sich auch unbekannte Clients verbinden können.
> * Noch keine Auswahl der Hood über das Webinterface. Hier geht es
>   lediglich nach Entfernung anhand der Geo-Position. Wenn keine Position
>   angegeben ist, wird die Trainstation gewählt.
> * Die *.hood Dateien sind aktuell hart-kodiert. Hier stelle ich mir eine
>   Synchronisation vor. Allerdings sollten wir vorher die
>   Authentifizierung sicherstellen, sonst kann jeder unser komplettes
>   Netz zerstören. Hier wäre ein Web-of-Trust angebracht, was wir
>   dynamisch erweitern können. Ich könnte mir *.sign Dateien vorstellen,
>   welche neue Public Keys zum signieren einführen können. Diese müssen
>   natürlich selbst erst einmal signiert werden.
> * Das ganze Script wird aktuell noch gar nicht gestartet. Ziel wäre es,
>   ab Boot die Trainstation konfiguriert zu haben. Erst nach Auswahl der
>   Geo-Position wird dann umkonfiguriert.
> * Ein Knoten, der weder Uplink, noch aktuelle Hood-Daten hat, kann nicht
>   zum vorhanden Freifunk verbinden. Hier braucht es noch ein
>   "Such-Script".
> * Nicht alle Hoods sind im Patch enthalten.
> * configurehoods sollte modularisiert werden.
> 
> Weitere Lektüre:
> * https://wiki.freifunk-franken.de/w/Portal:Netz/Konzept:HoodAnnouncement
> * https://wiki.nordwest.freifunk.net/Entwicklung/hoodsystem/ideen
> 
> Tim
> 
> 
> Tim Niemeyer (1):
>   fff-hoods: add initial hood configuration package
> 
>  bsp/default/root_file_system/etc/firewall.user     |   9 ++
>  src/packages/fff/fff-hoods/Makefile                |  39 ++++++
>  .../fff/fff-hoods/files/etc/hoods/fuerth.hood      |  18 +++
>  .../fff/fff-hoods/files/etc/hoods/nuernberg.hood   |  18 +++
>  .../fff/fff-hoods/files/etc/hoods/test.hood        |  18 +++
>  .../fff-hoods/files/etc/hoods/trainstation.hood    |  17 +++
>  .../fff/fff-hoods/files/etc/uci-defaults/hood-dhcp |  18 +++
>  .../fff/fff-hoods/files/usr/sbin/configurehood     | 144 +++++++++++++++++++++
>  src/packages/fff/fff/Makefile                      |   4 +-
>  9 files changed, 283 insertions(+), 2 deletions(-)
>  create mode 100644 src/packages/fff/fff-hoods/Makefile
>  create mode 100644 src/packages/fff/fff-hoods/files/etc/hoods/fuerth.hood
>  create mode 100644 src/packages/fff/fff-hoods/files/etc/hoods/nuernberg.hood
>  create mode 100644 src/packages/fff/fff-hoods/files/etc/hoods/test.hood
>  create mode 100644 src/packages/fff/fff-hoods/files/etc/hoods/trainstation.hood
>  create mode 100644 src/packages/fff/fff-hoods/files/etc/uci-defaults/hood-dhcp
>  create mode 100755 src/packages/fff/fff-hoods/files/usr/sbin/configurehood
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20160105/1e6710a0/attachment-0002.sig>