Opennet Firmware für Fortgeschrittene
Überblick
Die folgenden Hinweise zu erweiterten Anwendungsfällen der Opennet (bzw. Openwrt) Firmware sind meist nicht für Einsteiger geeignet. Komm vielleicht einfach zu unseren regelmäßigen Treffen, falls du Fragen dazu haben solltest.
WLAN Einstellungen
Entfernung
Wenn der 'distance' Wert falsch gesetzt ist, dann kann der Client entweder sich gar nicht verbinden (Wert zu klein) oder die erreichte Übertragungsgeschwindigkeit ist geringen (Wert zu groß).
manuell
Die Erfahrung zeigt, dass man die dreifache Entfernung der Clients eintragen sollte. Angenommen die Client sollten max. 2km entfernt sein, dann muss 'distance 6000' gesetzt werden.
Wird der Wert zu hoch gesetzt, kann für nahe gelegene Client nur ein geringer Durchsatz erzielt werden.
automatisch
Für ath9k gibt es einen Automatismus, welcher manuell aktiviert werden muss: https://github.com/openwrt/openwrt/commit/8b42a260ed8ff6809cd0ade20a5c1fa003feb6d0
Für ath10k gibt es leider keine automatische Lösung
Kanäle
Bei 802.11ac kann zwischen Kanalbreite von 20 MHz und 40 MHz gewählt werden. Prinzipiell gilt, je breiter desto mehr Durchsatz. Bei Standorten mit vielen WLAN Sendern macht es aber auch Sinn 20 MHz zu nutzen weil es weniger Interferenzen gibt.
Wir müssen sicherstellen, dass wir auf keinen Fall den Kanal Radarssysteme wie das Warnmünder Wetterradars (Kanal 128) stören. Eigentlich sollte die DFS Funktion des WLAN Treibers dies sicherstellen aber sicherheitshalber sollten wir den Kanal 128 und benachbarte Kanäle 124+132 von unserer Konfiguration ausnehmen.
Hierfür muss folgendes Konfiguriert werden in /etc/config/wireless:
option htmode 'HT20' option chanlist '44 100-120 136-140'
option htmode 'HT40' option chanlist '44 100-116 136'
Eine Kanalbreite von 80 MHz ist zwar schön für den Durchsatz aber leider mit DFS Erkennung und dem Warnemünder Wetterradar nicht vereinbar.
Problem: Wenn man VHT80 konfiguriert, dass muss Kanal 128 enthalten sein. Sobald auf Kanal 128 per DFS Radar erkannt wird muss der gesamte 80 Mhz Bereich gemieden werden. Ein zweites in Deutschland zulässiges 80 Mhz Band gibt es nicht. WLAN ist dann abgeschaltet.
Monitoring eines AP
Monitoring-Daten von APs mit aktiviertem munin-Dienst sind unter https://monitor.opennet-initiative.de/ erreichbar.
Einrichtung auf dem AP
Seit der Firmware v0.5.2 genügt die Aktivierung des Opennet-Moduls "on-monitoring" für die Sammlung diverser Zustandsdaten.
Das Modul kann über das Web-Interface (Opennet -> Basis -> Module) oder über die Kommandozeile (opkg-oni install on-monitoring) aktiviert werden.
Opennet-Anpassungen
Im Vergleich zum grundlegenden Monitoring (via muninlite) werden folgende zusätzlichen Daten erfasst:
- ath9k: Übertragungsgeschwindigkeiten und Ereignisse
- olsrd: Verbindungsqualität und Ping-Zeiten zu Nachbarn; Routing-Umgebung
- WLAN: Kanalbelegung
- WLAN: Signal/Noise
- WLAN: aktuell aktiver Kanal
- Ping-Zeit zum aktiven Gateway (via Tunnel)
- Anzahl der DHCP-Leases auf dem LAN-Interface
Datensammlung
Ist das Monitoring installiert befragt howmei deinen AP im Fünf-Minuten-Takt nach seinem aktuellen Zustand (z.B. Netzwerkaktivität, Uptime, Load, ...).
Du kannst natürlich auch auf einem eigenen Server einen munin-Sammler konfigurieren, der deinen AP abfragt.
Bedenke bitte vor der Einrichtung von munin auf einem AP, dass dadurch private Daten (z.B. Verkehrsaufkommen im Tagesverlauf) sichtbar werden können. Überwache also keinesfalls fremde APs ohne explizites Einverständnis der Nutzer.
API-Daten via HTTP für Firmware vor 0.5.5
Bis zur Firmware 0.5.4 waren die Ondataservice-Daten nur mittels eines olsr-Transports verfügbar, der jedoch nicht in allen Fällen die Daten im gesamten Mesh verteilt. Der zusätzliche Abruf via HTTP ist seit Firmware 0.5.5 möglich und kann in älteren Firmware-Versionen mit folgender Anpassung aktiviert werden:
ln -s ../tmp/database.json /www/opennet-ondataservice-export.json
Die Quelle (database.json) wird einmal täglich erzeugt. Ggf. muss also bis zum Folgetag gewartet werden.
Umstellung der IPv6-Adresse für Firmware v0.5.3
In der Firmware 0.5.3 verwendeten wir ein IPv6-Präfix, das wir später änderten.
Folgende Kommandos setzen diese Änderung um:
sed -i 's/^IP6_PREFIX=2001:67c:1400:2432$/IP6_PREFIX=fd32:d8d3:87da:0/' /usr/lib/opennet/olsr2.sh uci set "network.on_loopback.ip6addr=$(uci get network.on_loopback.ip6addr | sed 's/^2001:67c:1400:2432:/fd32:d8d3:87da::/')" uci commit network; reload_config
Announcierung der Main-IPv6-Adresse via ondataservice für Firmware vor v0.5.5
Ab der Firmware-Version 0.5.5 ist das Attribut "on_ipv6_mainip" Teil des ondataservice-Datensatz. Dieses Attribut ist für die IPv6-DNS-Auflösung (relevant für OLSR2) notwendig.
Auf älteren APs lässt sich dies durch folgenden Aufruf nachbessern.
if [ -e /etc/banner ] && [ -e /usr/sbin/status_values.sh ] && ! grep -q "on_ugw_presetnames.*cut" /usr/sbin/status_values.sh; then \ wget -O /tmp/status_values.sh "http://dev.opennet-initiative.de/browser/on_firmware/opennet/packages/on-core/files/usr/sbin/on-update-status-dump?format=raw" \ && chmod +x /tmp/status_values.sh && /tmp/status_values.sh && mv /tmp/status_values.sh /usr/sbin/status_values.sh; fi
Patch aus dem Repository anwenden
Falls ein Problem einer Release-Version mit einem Patch/Commit aus dem Repository zu beheben ist, dann kann folgender Aufruf verwendet werden, um einen oder mehrere Commits auf die aktuelle Firmware auf einem AP anzuwenden:
on-function apply_repository_patch GIT_COMMIT_HASH [..]
Ein Patch kann auch wieder entfernt werden:
ON_PATCH_ARGS=--reverse on-function apply_repository_patch GIT_COMMIT_HASH [..]
Die Funktion apply_repository_patch ist erst nach dem Firmware Release v0.5.2 verfügbar. Um die obige Funktion bereits in Version 0.5.2 einzusetzen, ist folgender Ablauf auszuführen (dabei wird der Commit für dieses Feature angewandt):
opkg update && opkg install patch wget -q -O - http://dev.on-i.de/changeset/4eb43e138606da459fcf9048c3cde5aa7634e23d/on_firmware?format=diff | patch -p4 --directory / on-function clear_caches
Pakete aus dem Opennet-Repository installieren / explizite Kernel-Abhängigkeiten
Wir bauen die Opennet-Firmware zwar aus den openwrt-Quellen ohne Kernel-Anpassungen, nichtsdestotrotz hat jedoch der von uns erzeugte Kernel eine andere Build-ID, als der Kernel aus dem dazugehörigen Openwrt-Release. Daher resultiert der Versuch, ein Paket mit Abhängigkeiten vom Kernel aus dem openwrt-Repository zu installieren, etwa in folgender Fehlermeldung:
root@AP:~# opkg install tinc Installing tinc (1.0.26-1) to root... Downloading http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/packages/tinc_1.0.26-1_ar71xx.ipk. Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for tinc: * kernel (= 3.18.20-1-7bed08fa9c06eb8089e82c200340ec66) * * opkg_install_cmd: Cannot install package tinc.
Sofern das gewünschte Paket Teil des opennet-Builds ist, lässt es sich folgendermaßen installieren:
on-function install_from_opennet_repository tinc
Im Unterschied zum üblichen Aufruf von opkg gibt es dabei keine Meldungen auf der Standardausgabe, sofern der Installationprozess fehlerfrei ablief.
In Firmware-Versionen seit v0.5.3 ist auch das Skript okg-oni verfügbar: es verwendet die Opennet-Quellen anstelle der OpenWrt-Quellen. Die Installation eines Pakets funktioniert also folgendermaßen:
opkg-oni install kmod-ath10k
Workarounds für bekannte Probleme anwenden
Für sehr spezifische Umstände/Geräte/Situationen sind Workarounds erforderlich, um die gewünschte Funktionalität herzustellen. Diese Workarounds sind nicht Teil der Firmware, da sie:
- nur unter eng begrenzten Umständen hilfreich bzw. unschädlich sind,
- eine schlechte Lösung darstellen,
- oder nicht ohne technisches Detailwissen verwendet werden sollten.
Damit diese Workarounds nicht auf individuellen Datenträgern herumliegen, werden sie im Firmware-Repository zentral gelagert. Wer einen der Workarounds anwenden möchte, möge sich das jeweilige Skript anschauen und dann selbständig entscheiden, ob dieses Skript sein Problem löst.
Liste der Workarounds im Firmware-Repository: https://dev.opennet-initiative.de/browser/on_firmware/opennet/workarounds
Das Auflisten, Installieren und Entfernen der obigen Workarounds ist seit v0.5.3 über die Kommandzeile möglich, z.B.:
on-workarounds install on_workaround_wifi_master_hangs minutely
Remote Syslog
Remote Logging kann sinnvoll sein, um problematische Zustände auf APs zu analysieren. Die APs senden dabei ihre Log-Meldungen nicht nur an den lokalen Buffer (verfügbar via logread), sondern auch an den konfigurierten syslog-Server. So sind beispielsweise auch nach einem Neustart des AP seine Fehlermeldungen nachvollziehbar.
Ein auf OpenWrt basierender Client benötigt folgende Einstellungen:
uci set "system.@system[0].log_ip=<syslog-server-ip>" uci commit system reload_config
Alternativ ist auch im Web-Interface das Logging aktivierbar: Administration -> System -> Logging</pre> (die Host-IP <syslog-server-ip> eintragen). Anschließend muss reload_config per Hand ausgeführt werden.
Anschließend ist ungefähr folgender Prozess sichtbar:
/sbin/logread -f -h AP-X-Y -r <syslog-server-ip> 514 -p /var/run/logread.2.pid -u
Falls die Änderung der Konfiguration via uci irgendwie nicht erkannt wurde, dann hilft in jedem Fall folgendes:
/etc/init.d/log restart
Probeweiser Meldungsversand:
echo foo | logger
Das Logging lässt sich folgendermaßen wieder abschalten:
uci delete "system.@system[0].log_ip" uci commit system reload_config
HNA/NAT Konfigurieren für Nicht-OLSR-Nachbarn
Wir haben im Opennet Mesh Geräte ohne eigenen OLSR Dienst. Damit diese im Opennet erreichbar sind, muss ein benachbarter Opennet Knoten die IP des PoE Switches im Mesh bekannt machen (per HNA) und den Traffic weiterleiten.
Es sind drei Dinge auf dem Opennet Knoten zu konfigurieren:
- in OLSR HNA konfigurieren
- Route zu Geräte anlegen
- Source-NAT konfigurieren
Konfiguration via Web-Interface
Konfiguration via Kommandozeile
connected_interface="on_eth_0"; target_ip=192.168.5.x connected_local_ip=$(ubus call "network.interface.$connected_interface" status | jsonfilter -e '@["ipv4-address"][0].address') prefix=olsrd.$(uci add olsrd Hna4) && uci set "$prefix.netmask=255.255.255.255" && uci set "$prefix.netaddr=$target_ip" && uci commit olsrd prefix=firewall.$(uci add firewall redirect) && for assignment in "target=SNAT" "src=on_mesh" "dest=on_mesh" "proto=all" "src_dip=$connected_local_ip" "dest_ip=$target_ip" ; do uci set "$prefix.$assignment"; done && uci commit firewall prefix=network.$(uci add network route) && uci set "$prefix.interface=$connected_interface" && uci set "$prefix.target=$target_ip" && uci commit network reload_config /etc/init.d/olsrd restart
Nutzung ohne Weboberfläche
Für alle die lieber via ssh agieren...
Opennet Module installieren
verfügbare Module auflisten und installieren:
on-function get_on_modules on-function enable_on_module <name> opkg-oni install <name>
https://downloads.opennet-initiative.de/openwrt/stable/latest/doc/group__modules.html
Firmware aktualisieren
- Firmware-Image ("sysupgrade") herunterladen, beispielsweise:
wget -O /tmp/sysupgrade.bin https://downloads.opennet-initiative.de/openwrt/stable/0.5.5/targets/ath79/generic/openwrt-0.5.5-2750-ath79-generic-ubnt_nanostation-m-xw-squashfs-sysupgrade.bin
- Firmware-Upgrade durchführen:
sysupgrade /tmp/sysupgrade.bin
- nach dem Reboot dauert es noch ein paar Minuten, bis die Opennet-Firmware eventuell zuvor installierte Pakete erneut nachinstalliert
- nach einer Viertelstunde sollte der AP wieder wie zuvor funktionieren
Einstellungen zurücksetzen
- alle Einstellungen des APs (inklusive persönliche Zertifikate) können auf der Kommandozeile gelöscht werden (siehe OpenWrt-Wiki):
firstboot && reboot now
- anschließend ist der AP in dem Zustand, wie er nach der ersten Installation der Opennet-Firmware war (keine ID, keine Zertifikate, keine WLAN-Einstellungen)
OpenWrt Pakete vollständig aktualisieren
Es ist möglich alle OpenWrt Pakete gleichzeitig zu aktualisieren. Nur für Fortgeschrittene, ggf. Paket- und Versionsabhängigkeiten beachten:
opkg update && opkg list-upgradable| awk '{print $1}'| tr '\n' ' '| xargs -r opkg upgrade
Opennet Firmware virtualisiert betreiben
Für Testzwecke oder mehr Performance kann die Opennet Firmware auch auf einem Virtualisierungs Host laufen.
Virtualisierung mit Proxmox
Ein schnell gangbarer Weg, um z.B. ältere NUC Hardware als Virtualisierer zu nutzen wird auf der Proxmox Seite beschrieben.
Openwrt Links
Da die Opennet Firmware auf OpenWRT basiert, lässt sie sich auch ebenso leicht virtualisieren.
- https://openwrt.org/docs/guide-user/virtualization/qemu
- https://openwrt.org/docs/guide-user/virtualization/virtualbox-vm
- https://openwrt.org/docs/guide-user/virtualization/vmware
Hab mich bislang nur mit der Virtualisierung des x86 images auf x86 Hardware beschäftigt. Andere Plattformen (z.B. arm) wären auch mal spannend. Zum besseren Verständnis wird hier beschrieben, wie sich das auf native Hardware (ohne Virtualisierung) bringen lässt:
Für die User IPv6 zur Verfügung stellen (on-openvpn-v6)
Wir habe eine erste Version einer IPv6 Unterstützung im LAN Netz. Diese Unterstützung ist noch nicht in der Weboberfläche integriert. Daher müssen Kommandos über die Konsole eingegeben werden.
Eine detailierte Beschreibung des on-openvpn-v6 Paketes findet ihr auch unter IPv6/on-openvpn-v6.
Szenario 1: Der AP ist kein UGW gleichzeitig
Es wird vorausgesetzt, dass das Paket on-openvpn installiert ist. Es muss dort auch ein Zertifikat hinterlegt sein.
Als erstes sollten wir prüfen, ob wir den Server gai per interner IPv6 erreichen können. Hierzu auf den AP einloggen und mit ping die Erreichbarkeit testen:
ping fd32:d8d3:87da::245
Wenn dies erfolgreich ist, dann können wir fortfahren. Wir müssen nun das neue on-openvpn-v6 Paket installieren. In der Kommandozeile folgendes eingeben:
opkg-oni install on-openvpn-v6
Nun müssen wir ggf. mehrere Minuten warten bis der AP den neuen VPN Tunnel aufgebaut hat. Dann sollte wir auf dem AP ein neues Interface on_tap_user6 sehen. Das kann man wie folgt prüfen:
root@AP-2-50:/tmp# ip a | grep user6 11: on_tap_user6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
Nun sollten alle Geräte im LAN auch IPv6 Adressen bekommen.
Wenn du https://www.test-ipv6.com aufrufst, solltest du 10/10 Punkten erhalten.
Szenario 2: Der AP ist auch ein UGW gleichzeitig
Es wird vorausgesetzt, dass das Paket on-openvpn installiert ist. Es muss dort auch ein Zertifikat hinterlegt sein.
Nun on-openvpn-v6 installieren:
opkg-oni install on-openvpn-v6
Optional kann man auch on-openvpn jetzt deaktivieren. In diesem Fall würde nur IPv6 über Opennet zur Verfügung gestellt werden. IPv4 würde dann über das WAN Interface bedient werden.
Server gai zur UGW Liste hinzufügen:
- gai.opennet-initiative.de
- port 1602
- protocol udp
Nun muss dieser neue UGW Server präferiert werden. Dies kann man bspw. dadurch erreichen, dass er über die Weboberfläche nach "oben" bewegt wird (über die entsprechenden Schaltfläche). (Optional kann man auch die anderen UGW Server deaktivieren.)
Anschließend Hintergrundprozesse zur Aktualisierung starten.
on-function update_on_usergw_status
Nach einigen Minuten sollte wir ein Verbindung zum UGW gai haben. Dies kann man bspw. prüfen mit:
root@AP-2-50:/etc# ps | grep vpn 7581 root 3908 S /usr/sbin/openvpn --syslog openvpn(mesh_openvpn_gai_opennet_initiative_de_1602_udp) --status /var/run/openvpn.mesh
Nun kommt eine Besonderheit, welche euch i.d.R. nicht betreffen sollte. Wenn du in deinem WAN6 bereits DHCPv6-PD IPv6 hast, dann wird automatisch ein Subnet im LAN propagiert. Nun funktioniert das Routing zu fd32:: nicht. Um dies zu korrigieren, musst du das Interface WAN6 deaktivieren und den Punkt "Während des Bootvorgangs starten" für das Interface deaktivieren. Jetzt den AP sicherheitshalber neustarten.
Ihr solltet mit dem UGW Tunnel nun in der Lage sein, die interne IP von gai vom AP aus zu erreichen:
ping fd32:d8d3:87da::245 # ping from AP
Nach einiger Zeit sollte auch der User-v6 Tunnel aufgebaut sein und ein Interface on_tap_user6 auf dem AP erscheinen.
Jetzt sollten auch alle Geräte im LAN eine IPv6 Adresse (2a0a:4580:1010:...) erhalten.
Wenn du https://www.test-ipv6.com aufrufst, solltest du 10/10 Punkten erhalten.