Opennet Firmware für Fortgeschrittene: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Hinweis auf http-Abruf von ondataservice-Daten)
 
(7 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt)
Zeile 7: Zeile 7:
 
== Einrichtung auf dem AP ==
 
== Einrichtung auf dem AP ==
 
{{hinweis|Seit der Firmware v0.5.2 genügt die Aktivierung des Opennet-Moduls "on-monitoring" für die Sammlung diverser Zustandsdaten.<br/>Die untenstehenden Anleitungen sind also nur für ältere Firmware-Versionen relevant.}}
 
{{hinweis|Seit der Firmware v0.5.2 genügt die Aktivierung des Opennet-Moduls "on-monitoring" für die Sammlung diverser Zustandsdaten.<br/>Die untenstehenden Anleitungen sind also nur für ältere Firmware-Versionen relevant.}}
 
  
 
=== Grundlegendes Monitoring (alle Firmware-Versionen) ===
 
=== Grundlegendes Monitoring (alle Firmware-Versionen) ===
Zeile 55: Zeile 54:
 
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.
 
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 =
+
== 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 [[Ondataservice#Alternativer_HTTP-Abruf|Abruf via HTTP]] ist seit Firmware 0.5.5 möglich und kann in älteren Firmware-Versionen mit folgender Anpassung aktiviert werden:
 
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 [[Ondataservice#Alternativer_HTTP-Abruf|Abruf via HTTP]] ist seit Firmware 0.5.5 möglich und kann in älteren Firmware-Versionen mit folgender Anpassung aktiviert werden:
 
<pre>
 
<pre>
 
ln -s ../tmp/database.json /www/opennet-ondataservice-export.json
 
ln -s ../tmp/database.json /www/opennet-ondataservice-export.json
 +
</pre>
 +
 +
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:
 +
<pre>
 +
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
 +
</pre>
 +
 +
= 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.
 +
 +
<pre>
 +
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
 
</pre>
 
</pre>
  
Zeile 172: Zeile 194:
 
  uci commit system
 
  uci commit system
 
  reload_config
 
  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 ==
 +
<gallery>
 +
olsrd_hna_fuer_non_olsr_nachbar.png|HNA für olsrd konfigurieren
 +
route_fuer_nicht_olsr_nachbar.png|statische Route setzen
 +
firewall_snat_fuer_nicht_olsr_nachbar.png|SNAT für weitergeleitete Pakete konfigurieren
 +
</gallery>
 +
 +
== Konfiguration via Kommandozeile ==
 +
<pre>
 +
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
 +
</pre>
  
 
[[Kategorie:Firmware]]
 
[[Kategorie:Firmware]]

Aktuelle Version vom 17. Mai 2019, 05:35 Uhr

Inhaltsverzeichnis

[Bearbeiten] Ü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.

[Bearbeiten] Monitoring eines AP

Monitoring-Daten von APs mit aktiviertem munin-Dienst sind unter https://monitor.opennet-initiative.de/ erreichbar.

[Bearbeiten] Einrichtung auf dem AP


[Bearbeiten] Grundlegendes Monitoring (alle Firmware-Versionen)

Das weitverbreitete Monitoring-System munin ist leicht auf den APs einzurichten:

opkg update
opkg install muninlite
/etc/init.d/xinetd enable
/etc/init.d/xinetd start

Nun lauscht fortan auf Port 4949 der inet-Daemon, welcher bei Bedarf das lokale muninlite startet, um entfernte Anfragen zu beantworten.

[Bearbeiten] Erweitertes Monitoring

Im Vergleich zum grundlegenden Monitoring (siehe oben) 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

[Bearbeiten] Firmware v0.5.2 oder später

Web-Interface: installiere im Menü Opennet -> Basis -> Module das Paket on-monitoring.

Konsole: on-function install_from_opennet_repository on-monitoring

[Bearbeiten] Firmware v0.4.5 bis v0.5.1

In den openwrt-Basisversionen der älteren Firmware-Versionen ist leider nicht das Paket micropython enthalten, das für die Monitoring-Plugins erforderlich ist.

opkg update
opkg install \
  http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/packages/libffi_3.0.13-1_ar71xx.ipk \
  http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/packages/micropython_1.4.5-20150827-936e25b164d837fc91e4bafd76580e747b235dff-1_ar71xx.ipk \
  http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/packages/packages/micropython-lib_0.5-20150827-bfbbf85a181d84e2494ea6f15be311734666bf67-1_ar71xx.ipk \
  http://downloads.on/openwrt/stable/0.5.2/ar71xx/packages/opennet/on-monitoring_0.5.2-1697_ar71xx.ipk

Die Fehlermeldungen (postinstall-Skripte) sind akzeptabel, erfordern jedoch ein wenig Nachbehandlung:

(. /usr/lib/opennet/on-monitoring.sh; enable_suggested_munin_plugin_names wireless_channel_occupation_)
sed -i '/^PLUGINS=".*irqstats"$/s/irqstats/irqstats plugindir_/' /usr/sbin/munin-node
/etc/init.d/xinetd enable
/etc/init.d/xinetd start

[Bearbeiten] 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.

[Bearbeiten] 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.

[Bearbeiten] 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

[Bearbeiten] 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

[Bearbeiten] 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

[Bearbeiten] 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

[Bearbeiten] 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

[Bearbeiten] 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 beispielweise auch nach einem Neustart des AP seine Fehlermeldungen nachvollziehbar.

[Bearbeiten] Empfänger / Server

Auf Server/howmei läuft ein syslog-Server, der empfänglich für fremde Nachrichten ist.

Die Ergebnisse für jeden Host liegen unter /var/log/opennet-hosts/....

Die einzige notwendige Konfigurationsänderung ist in der neu zu erstellenden Datei /etc/rsyslog.d/opennet-hosts.conf zu finden:

$ModLoad imtcp
$InputTCPServerBindRuleset remote
$InputTCPServerRun 514

$ModLoad imudp
$InputUDPServerBindRuleset remote
$UDPServerRun 514

$template RemoteHost,"/var/log/opennet-hosts/%HOSTNAME%/syslog.log"

$RuleSet remote
*.* ?RemoteHost

$DefaultRuleset local
$RuleSet local

Hinzu kommt noch eine logrotate-Konfiguration (/etc/logrotate.d/opennet-remote-syslog) für tägliche Kompression und Löschung nach einem Quartal:

/var/log/opennet-hosts/*/*.log {
        daily
        rotate 91
        compress
        delaycompress
        missingok
        sharedscripts
        postrotate
                service rsyslog rotate >/dev/null
        endscript
}

[Bearbeiten] Sender / Client

Ein auf OpenWrt basierender Client benötigt folgende Einstellungen:

uci set "system.@system[0].log_ip=192.168.10.13"
uci commit system
reload_config

Alternativ ist auch im Web-Interface das Logging aktivierbar: Administration -> System -> Logging</pre> (die Host-IP 192.168.10.13 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 192.168.10.13 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

[Bearbeiten] 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

[Bearbeiten] Konfiguration via Web-Interface

[Bearbeiten] 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
Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge