Opennet Firmware/Firmware-Paket technische Dokumentation
Aus Opennet
Die Opennet-Firmware ist mit der Zeit immer komplexer geworden, so dass es nötig ist, die technischen Details genauer zu dokumentieren.
automatische Gatewaywahl
Optimierung der Sendeleistung
theoretische Erläuterung
Motivation
Eine besondere Eigenart des Rostocker Netzes ist die hohe Konzentration vieler AccessPoints auf sehr engem Raum. Viele der über hundert Accesspoints befinden sich innerhalb eines Bereiches von weniger als einem Quadratkilometer, der Bereich lässt sich faktisch mit einer 8dBi-Antenne und 10mW Sendeleistung bei freier Sicht komplett übertreichen. Darum musste ein Weg gesucht werden, die Sendeleistung der einzelnen AccessPoints zu drosseln, anstatt wie in veilen anderen Netzen (oder auch in der Anfangsphase des Opennet) das beste aus dem APs herauszuholen.
Lösung
Die Opennet-Firmware enthält ein script, welches die Sendeleistung optimiert. Dabei wird die Verbindung zum nächsten AccessPoint, der auf dem Weg zum lokal genutzten Opennet-Internet-Gateway liegt, so lange geprüft, bis der Paketverlust bei kleinster Sendeleistung akzeptabel ist. Ergänzend wird geprüft, ob die Verbindung zu umliegenden Accesspoints, die ihrerseits den zu optimierenden AP auf ihrem Weg zum Gateway brauchen, noch akzeptabel ist, notfalls wird die Sendeleistung wieder schrittweise erhöht.
technische Realisierung
Firmware-Details
Kern der automatischen Sendeleistungsanpassung ist das Script /usr/sbin/adapt_txpower.sh. Das script ist recht gut kommentiert, hier lohnt sich ein Blick in den Code ;). Wird das script mit dem parameter -h aufgerufen, werden mögliche Kommandozeilenoptionen angegeben. Werdem dem script IP-Adressen übergeben, wird die Sendeleistung zu diesen Adressen optimiert (lines 168-162), anderenfalls wird die folgende, automatisierte Optimierungsstrategie genutzt (lines 164 bis 229). Zur Optimierung selbst wird jeweils die Funktion check_transmission() aufgerufen, die die aktuelle Sendeleistung zwischen $MaximalPower und $min_pwr auf den kleinsten Wert, bei dem eine akzeptable Verbindung zu $address erreicht wird, verringert.
Optimierungsstrategie
Werden durch Aufruf des scripts /usr/sbin/working_gateways.sh keine aktuellen Gateways gefunden, wird die automatische Optimierung abgebrochen (lines 164-168), wohin sollte auch optimiert werden? Nun wird die Sendeleistung auf den maximal zulässigen Wert ($MaximalPower) erhöht, danach wird etwas gewartet, damit sich die benachbarten APs an die veränderten Bedingungen anpassen können (lines 171-183). Anschliessend wird eine Liste der direkten Nachbar-APs erstellt und mit dem script /usr/sbin/get_gateway.sh wird geprüft, ob die Nachbar-APs auf ihrem Weg zum Gateway eine Verbindung zum lokalen, zu optimierenden Ap benötigen. Ist dies der Fall, werden sie in eine Liste ($interested_neighbors) aufgenommen (lines 186 bis 204). Nun wird noch ermittelt, welchen Nachbar-AP der eigene, zu optimierende AP auf dem Weg zum eigenen Gateway benötigt (lines 209 bis 221) um anschliessend die Sendeleistung für die Verbindung zu diesem AP (lines 215 bis 221) und zu den interessierten Nachbarn ($interested_neighbors, lines 224 bis 229) optimiert.
automatisierte Optimierung
In der Diskussion nach der ersten Veröffentlichung zeigten sich Zweifel an der Tragfähigkeit des gewählten Optimierungsansatzes (vgl. Opennet-Forum). Besonders die Idee, mit dem script regelmässig (täglich?) die Sendeleistung zu verändern, schien im Ergebnis wenig geeignet, um ein konsistentes Netz zu etablieren. Daher wird dieses Script aktuell nur zur einmaligen, initialen Sendeleistungs-Limitierung nach einer Neuinstallation der firmware genutzt (/usr/sbin/cron-hourly, lines 12-24). Im Webfrontend (/www/cgi-bin/on_txpwr.html) kann diese Anpassung deaktiviert werden, auch kann dort das script bei Bedarf per Hand gestartet werden.
weitere Hinweise
Status-Indikatoren
Die folgenden Dateien werden bei einer automatischen Optimierung der Sendeleistung (/usr/sbin/cron-hourly) oder bei Aufruf durch das Webfrontend (/www/cgi-bin/on_txpwr.html) benutzt:
| Dateiname | Bemerkungen |
| /tmp/adapt_txpwr.log | logfile des letzten Durchlaufes von adapt_txpwr.sh |
| /tmp/adapt_txpwr_running.log | logfile des aktuellen Durchlaufes, solange noch nicht beendet |
| /tmp/adapt_txpwr.failed | Indikator, dass der letzte Durchlauf nicht erfolgreich war. |
relevante nvram-variablen
| Name | Typ | Werte | Bemerkungen |
| on_autoadapttxpwr | bool | "on" !"on" | Automatische einmalige Optimierung der Sendeleistung |
OLSR synchronisation der Konfiguration
Internet Freigabe (User-Gateways)
theoretische Erläuterung
Motivation
Wir nutzen im Opennet für die Verbindung der Nutzer-APs mit dem Internet VPN-Tunnel zu den Opennet-Gateways (im folgenden user-tunnel). Bei 'klassischen' Opennet-Gateways hiess dass, das jeweils ein eigener Rechner am Internetzugang nötig ist, der die komplette Verwaltung der VPN-Verbindungen übernimmt (bspw. titan.on-i.de, izumi.on-i.de). Natürlich reicht die Rechenleistung der üblichen AccessPoints nicht aus, um bei Nutzern, die ihren Breitbandanschluss zur Verfügung stellen wollen, die komplette OpenVPN-Verschlüsselung und die zugehörige Nutzerverwaltung auf dem AP selbst zu erledigen. Die Alternative, dass solche Nutzer einen eigenen Gateway-Rechner bei sich einrichten und rund um die Uhr laufen lassen, ist auch nicht praktikabel.
Lösung
Der Verein hat im Internet zwei gut erreichbare Rechner platziert (nagare.on-i.de und erina.on-i.de), welche die Nutzer-Verwaltung und die OpenVPN-Verschlüsselung übernehmen. Die AccessPoints derjenigen Nutzer, die ihren Breitbandanschluss teilen wollen, bauen zwei weitere OpenVPN-Tunnel zu nagare und erina auf (usergateway-tunnel). Über diese Tunnel werden die Opennet-IPs von nagare (192.168.0.251) und erina (192.168.0.247) per olsr ins WLAN-Opennet eingebunden, andere Nutzer können nun wiederum einen user-tunnel zu diesen Gateways aufbauen und nutzen dann den freigegebenen Breitbandanschluss.
VPN-Tunnel Details
Ursprünglich war geplant, Daten, welche bereits verschlüsselt durch einen user-tunnel zu nagare/erina gehen, am Usergateway-AccessPoint nicht nochmals durch den usergateway-tunnel zu schicken (und damit unnötig doppelt zu verschlüsseln). Allerdings ist so ein Wechsel des Usergateways, ueber den der Traffic zu nagare/erina geht, im laufenden Betireb nicht moeglich. Die OpenVPN-Sevrer auf den Gateways erkennen die unterschiedlichen Quelle-Adressen der Pakete und weigern sich (trotz float-Option) diese anzunehmen. Darum wird seit release 0.11ipkg-12 auf die Aufspaltung des Traffics verzichtet und Nutzerdaten werden doppelt getunnelt.
weitere Effekte
Da die user-tunnel direkt an nagare/erina enden, gehen die Nutzerdaten eines Opennet-APs verschlüsselt über den Usergateway-AccessPoint. Eine Modifikation der übertragenen Daten ist daher an dieser Stelle nicht möglich. Weiterhin erhöht dies die 'gefühlte' Sicherheit derjenigen Nutzer, die ihren Breitbandanschluss freigeben, weil eine möglicherweise missbräuchliche Nutzung des Internetanschlusses nicht auf den Usergateway-Anbieter zurückverfolgt werden kann, sondern nur zu nagare/erina. Ansprechpartner bei dahingehenden Problemen ist somit der Verein, Nutzer, die lediglich ihren Breitbandanschluss freigeben, haben nichts zu befürchten.
technische Realisierung
Firmware-Details
Die Firmware ist so angepasst wurden, dass sie einen zu teilenden Breitbandanschluss immer am WAN-Port des AccessPoints erwartet. Basis fuer eine erfolgreiche Teilung des Internet-Anschlusses ist eine default-route ueber das WAN-device, welche vom script /usr/sbin/check_WAN.sh erkannt und durch policy-routing ersetzt wurde. In diesem Script wird gleichfalls minütlich geprüft, ob das Ziel einer über den WAN-Anschluss erreichbaren default-route erreichbar ist. Die weitere Prüfung, ob die zentralen Gateways zu erreichen sind erfolgt ebenso regelmässig mit dem script /usr/sbin/check_usergateway.sh.
weitere Hinweise
Status-Indikatoren
root@OpenWrt:~# ip route show table 4 throw 212.202.37.254 throw 10.2.0.0/16 throw 192.168.0.0/16 throw 172.16.0.0/12 default via 213.148.128.50 dev ppp0 root@OpenWrt:~# ip route show table 5 139.30.241.8 via 213.148.128.50 dev ppp0 212.227.37.142 via 213.148.128.50 dev ppp0 root@OpenWrt:~#
Wird ein Breitbandanschluss am WAN-device gefunden, wird per routing-table 4 aller traffic, der nicht ins Opennet oder ins LAN geht, unabhängig von den olsr-routen über das WAN-device geschickt. Die routing-table 5 kann als Indikator angesehen werden, dass es möglich ist, nagare/erina extern zu erreichen und die Internetverbindung daher geteilt werden kann.
root@OpenWrt:~# more /tmp/opennet_ugw1_tap1.txt nagare.on-i.de root@OpenWrt:~# more /tmp/opennet_ugw2_tap0.txt erina.on-i.de root@OpenWrt:~#
Bei aufgebauten Tunneln kann in den Dateien /tmp/opennet_ugw* erkannt werden, welche devices und welche Ziele diesen Tunnel zugeordnet sind.
root@OpenWrt:~# ls /tmp/ugw_reachable_* /tmp/ugw_reachable_erina.on-i.de /tmp/ugw_reachable_nagare.on-i.de root@OpenWrt:~#
Die Erreichbarkeit der Tunnel wird auch in durch die Dateien /tmp/ugw_reachable_* angezeigt.
andere relevante Änderungen
Das start-script von openvpn (/etc/init.d/S80openvpn) wurde so angepasst, dass der usergateway-tunnel nur gestartet wird, wenn dies vom Nutzer aktiviert wurde.
relevante nvram-variablen
| Name | Typ | Werte | Bemerkungen |
| on_ugws | char* | "nagare.on-i.de erina.on-i.de" | zu benutzende zentrale Gateways |
| on_share_internet | bool | "on" !"on" | Freigabe des Internet-Anschlusses |
| on_share_internet_blocked | integer | Sperrzeit in Minuten | vorübergehende Sperrung der Internet-Freigabe |
