Firmware/Dokumentation

Ziele

• Autokonfiguration
  • Internet am WAN-Port wird automatisch erkannt und geteilt
  • Wolke ohne Internetzugang teilt diesen bedauerlichen Zustand den Teilnehmern mit
• Keine persistenten Schreibzugriffe beim Alltagsgebrauch (z.B. uci commit für Dinge wie Internet up/down)
• Splash-Status der Benutzer wird verteilt
• etc …

Netzwerke

• 10.##.?.0/16 - privat, IPv4
  • Jedes Gateway (GW) und jeder Client bekommen eine IP-Adresse in diesem Bereich
  • routet ins IPv4 Internet
  • Gateway-Adressen werden durch eine P2P-Tabelle verwaltet
• mesh-weites IPv6 (ULA e.g. "Privat")
  • jeder Node und Client
  • Standard für alle Node-zu-Node-Kommunikation (außer HBBP)
  • automatische Adresse für Meshknoten, SLAAC für Clients
• mesh-weites link-local IPv6

benutzt für UDP broadcasts (HBBP)

• Robinson-Netzwerke (s.u.)

Router-Ports

WAN: Internet-Uplink

Ports 1+2: LAN Segment des Routers

Ports 3+4: zum verbinden von Nodes und zum anschließen von Geräten an das Mesh.

Zustandsautomaten (FSMs)

Zustandsautomaten sind im /sbin/fsm Skript implementiert

inetable

Verwaltet die verschiedenen Netzwerkzustände, die aus der Existenz eines lokalen Internetzugang und dem Zustand der Wolke resultieren. Datei:FSM inetable.png

Boot

Der Node wurde erst vor Kurzem gestartet und sucht noch nach seiner Mama.

• gw_mode=0

Queen

Der Node hat eine funktionierende direkte Internetverbindung.

• gw_mode=1, bandwidth >> 0
• DHCP-Bereich: abgeleitet von der Router-ID

TODO Ghost

Der Node war vor Kurzem eine Queen (innerhalb der letzten 3600 Sekunden), aber hat seinen direkten Internetzugang verloren. Es gibt immer noch eine funktionierende Verbindung zur Wolke.

• gw_mode=0
• gesamter Netzverkehr wird zu einem anderen GW umgeleitet
• keine neuen DHCP-Vergaben

Drone

Der Node hat keinen direkten Internetzugang, aber befindet sich in einer Wolke mit funktionierendem Internetzugang.

• gw_mode=0
• kein DHCP

TODO Robinson

Der Node ist in einer Wolke ohne funktionierende Internetverbindung.

• gw_mode=0
• zufällige IP-Adresse im Bereich 21.x.x.1
• DHCP-Bereich: 21.x.x.2 - 21.x.x.254
• Pseudo-DNS, löst alle A-Querys in ein Robinson-Netz auf; Host-Teil der Adresse wird von einem Hash des Namen, der aufgelöst werden soll, abgeleitet.
• Der gesamte Internet-Verkehr wird auf einen lokalen httpd umgeleitet, welcher den Netzwerkstatus angibt und das Freifunkprinzip erläutert

update

Implementiert ein "Alles-Oder-Nichts"-Update der Nodes (z.B. wenn das Netzwerkprotokoll inkompativel geändert wird). Synchronisiert durch p2ptable firmware-versions mit den Attributen:

• machine_id
• current firmware (ein menschenlesbarer Versionsstring)
• SHA256 der target firmware; leer, wenn kein Update durchgeführt werden soll
• time target: vom Admin gesetzt; Zeit an der das Update stattfinden soll
• acknowledge time: Wird vom Gerät auf den Wert von time target gesetzt sobald es bereit für das Update ist.

Das Sicherheitsmodell verlangt, dass das Update auf einer sicheren Stelle im Node abgelegt wird. Das soll per SSH geschehen. Datei:FSM update.png

Idle

Die aktuelle Firmware ist installiert und kein Update ist nötig oder möglich.

Ready

Die Zielfirmware ist in "/tmp/firmware-update" abgelegt und verifiziert worden.

Scheduled

Der Node hat die target time erhalten und diesen Wert in die acknowledge time kopiert. Dieser Zeitpunkt ist außerdem noch nicht vergangen.

Applying

Für alle Knoten in der 'firmware-versions' Tabelle gilt eine der folgenden Bedingungen:

1. target firmware, time target und acknowledge time sind leer
2. time target = acknowledge time und target firmware zeigt auf eine neue Version die lokal gespeichert und verifiziert wurde.

Sobald dieser Zustand erreicht wurde, wird das Update durchgeführt.

Komponenten

Firmware-ID

"/etc/firmware" speichert einen String, welcher die aktuelle Firmware identifiziert. Er besteht aus:

1. dem Datum des git-Commits der Freifunk-Rheinland-Config
2. dem Hash des git-Commits der Freifunk-Rheinland-Config
3. der OpenWRT-Major-Version
4. der OpenWRT-Revision

Beispiel:

2011-12-06_a4fa439-modified_backfire-29460

Router-IDs

• unique ID: Alle Router nutzen eine MD5SUM des eth0 Interfaces als einzigartige ID
• node ID: /etc/nodeid wird benutzt, um den Router zwischen Reboots und Firmware-Updates eindeutig zu identifizieren; es wird mit der unique ID des ersten Boots intialisiert.
• gateway ID: 0..254, wird nur an Queens und Ghosts vergeben, verwaltet durch p2ptbl "gwid"

Verbindungstests

• /usr/sbin/test_connectivity <internet|vpn>
• pingt einige test-Hosts über das angegebene Interface an: Wenn mindestens einer antwortet, sind wir online.
• gibt Verbindungsstatus zurück
• TODO: führe mehrere Pings an verschiedene Hosts parallel durch

Zustandsautomaten

FSMs werden implementiert durch

• /sbin/fsm: ein Skript, welches den Zustand überwacht und ändert:
  • fsm watch <name>: Überprüft, ob eine Änderung nötig ist
  • fsm change <name> <new-state>: Erzwingt eine Zustandsänderung
• /etc/fsm/<name>/initial_state: Der Zustand, der beim Start gesetzt wurde
• /etc/fsm/<name>/watch/<state>: Überprüfe Skripte, die den nächsten Status ausgeben. Wenn diese Datei nicht existiert, wird /etc/fsm/<name>/watch/default ausprobiert. Das Skript darf annehmen, dass:
  • the state they denote is the current state reached via non-failing transition functions
  • das aktuelle Verzeichnis ist /etc/fsm/<name>/watch
  • Kommandozeilenparameter $1 ist auf den aktuellen Zustand gesetzt
• /etc/fsm/<name>/trans/<transition>: scripts implementing the transition between states, probed in the following order:

1. If a transition name <oldstate>-<newstate>.trans exists it is executed
2. Otherwise first <oldstate>.leave and then <newstate>.enter are executed if they exist.
3. If one of them does not exist default.enter and default.leave is tried.
4. If none exists, the state transition happens, but has no effect.

• The script may assume that:
  • the CWD is /etc/fsm/<name>/trans
  • cmd line param $1 is set to the old state and $2 is set to the new state
  • it is called exactly once for a state change
• /var/fsm/<name>: a tmpfs-based storage of the current state

TODO:

• ordentliche Fehlerbehandlung, falls ein Fehler in einem der vielen Scripts geschieht (z.B. Übergang in einen Fehlerzustand oder Reboot des Geräts)
• behandle ungültige Zustände

HBBP: Home-Based Broadcast Protocol

• UDP “broadcast” und “listener”
• übertrage einen nulltermineirten Schlüssel und eine optionale beliebig lange Binärpayload: Der Key ist vergleichbar mit einer HTTP URI, die Payload zu HTTP POST Daten.
• IPv6-only
• begrenzt auf ein einzelndes Netzwerk durch link-local Broadcast und lauschen an nur einem Interface

Wire format

Eins von:

• <key>
• <key> \0 <payload>

gekapselt in IPv6 UDP. <key> darf keine \0 enthalten.

P2P-Tabellen

P2P-Tables sind ein leichtgewichtiger verteilter Schlüssel-Wert-Speicher mit eingebauter Kollisionsvermeidung. Endgültige Konsistenz wird durch das HBBP-basierte Gossip-Protokoll gewährleistet.

Usage

• p2ptbl init <table>: Erstelle eine neue Tabelle namens <table>
• p2ptbl update <table> <key> <value> [iface]: Setzt den Wert von <key> auf <value> in <table> egal ob <key> vorher existierte oder nich; falls vorhanden, verkünde die Änderung über [iface]
• p2ptbl get <table> <key>: Lies den Wert von <key> in <table> oder gib keinen Output wenn <key> nicht in <table> existiert
• p2ptbl gossip <table> <size> <iface>: Verteile <table> über <iface>; Sende maximal <size> bytes komprimierter Tabellendaten: wenn die Tabelle größer ist, wird eine zufällige Teilmenge verschickt.

Alle Tabellen werden in /tmp/p2ptbl/table gespeichert. Die obigen Werkzeuge verlangen den absoluten Pfad zur Tabelle. Um durch das Gossip-Protokoll synchronisiert zu werden, müssen Updates an der Tabelle durch einen Symlink von /hbbp/p2ptbl/<table> zu /sbin/p2ptbl-recv ermöglicht werden..

P2P table format

• Tab-separiert
• Felder:
  • key: Ein pro Tabelle einzigartiges Token
  • version: integer
  • value(s): beliebig, tab-separiert
• wenn zwei Tabellen vereinigt werden, wird für jeden Key die Variante mit der größten Versionsnummer gewählt.
• beim Update wird die Versionsnummer um einen genügend großen Wert erhöht (z.B. 2^32) um Kollisionen zu vermeiden

Gossip-Protocol

HBBP mit Schlüssel p2ptbl/<table-name> und gzip-komprimierten zufälligen vermischten Untermengen einer Tabelle als Nutzlast.

Bevorzugtes Gateway

• Jeder Knoten hat ein bevorzugtes Gateway, welches dem Zugriff zum Internet dient, falls keine lokale Verbindung verfügbar ist.
• Wie soll dieses bestimmt werden? Aus batman?

Robinson-Netz

• geklautes .mil-Netzwerk (/16)
• wenn kein Internet verfügbar ist, werden DNS-Antworten gefaket, welche auf eine stabile Adresse in diesem Bereich zeigen (durch den Hash des Namens)
• sobald das Internet verfügbar wird und die Namen aufgelöst werden können, werden Umleitungen durch iptables eingerichtet.
• nach einer gewissen Zeit wird diese Umleitung vergessen.

Multiple web servers

Zwei uhttpd Dienste mit www root /www/<servicename> für die folgende Zwecke:

• service: self-service / debugging / status.xml
  • listening on port 80 of link-local IPv6 pf br-mesh and br-lan; public IPv6 of br-mesh; and gateway IPv4 (if existing)
• redirection: use for splash/robinson redirection
  • redirects all traffic to the URL given by /tmp/redirection_target
  • listening on port 81 gw/robinson IPv4

Thoughts, Fragments, Questions

• VPN node takes part in batman mesh?
  • no (memory intensive) NAT on mesh nodes
  • roaming without sticking to the old gateway
• continuous bandwidth tests for internet uplinks to update advertised batman gw capabilities?
  • occasional flooding to/from VPN node (with idle QoS class)
• IPv6: use multiple routers for roaming w/o breaking existing connections?
• how to support uplinks that do not use the WAN port (e.g. 3G modems)?