Dies ist eine alte Version des Dokuments!


Administration eines Freifunk-Knotens via SSH

Bild: Freifunk München Logo Zur Administration unseres bzw. unserer Freifunk-Knoten verwenden wir die SSH1), da uns hier der volle Zugriff auf den Router gestattet, Konfigurationen im laufenden Betrieb vorzunehmen, Parameter abzufragen oder auch zusätzlich Programm zu starten. Viele hilfreiche Informationen rund um die SSH finden sich unter anderem in Djangos WIKI im Kapitel Secure Shell zu finden.

Für den Zugriff benötigen wir natürlich ein entsprechendes SSH-Schlüsselpaar, welches wir uns zunächst erstellen.

 ssh-keygen -b 4096 -t rsa -C [email protected] -f ~/.ssh/id_rsa4096_ff
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/django/.ssh/id_rsa4096_ff.
Your public key has been saved in /home/django/.ssh/id_rsa4096_ff.pub.
The key fingerprint is:
44:8b:1a:de:ad:be:ef:23:af:65:b7:e6:1a:bf:98:3d [email protected]
The key's randomart image is:
+--[ RSA 4096]----+
|      ...        |
|     o.o .       |
|    +.o o        |
|  ..+= .         |
|   ooo  S        |
|    + .+oF       |
|   +.. .         |
|  .  *E          |
|    ++=o         |
+-----------------+

Um nun nicht jedes mal beim Aufruf einer SSH-Verbindung zu einem unserer Knoten, Parameter wie user und die doch sehr langen IPv6-Adressen angeben zu müssen, hinterlegen dwir die entsprechenden Daten in der Konfigurationsdatei unseres lokalen SSH-Clients auf unserem Admin-Rechners. Dies hat darüber hinaus auch noch zusätzlich den Vorteil, dass z.B. von einem Netz aus, bei dem es „nur“ IPv4-Adressen Verwendung finden wir keinen zusätzlichen Sprunghost angeben müssen. Dies erleichtert die Arbeit doch ungemein, vor allem dann wenn Dateien von und zum Router kopiert werden müssen. Hintergrundinformationen zur Clientkonfiguration sind im Kapitel Client Konfiguration bei der Secure Shell zu finden.

So ist z.B. in nachfolgendem Konfigurationsbeispiel der Router ff_pliening_gbw_od direkt erreichbar und der Router ff_pliening_gbw_od-e nur über den Sprunghost mit Namen jumphost, der natürlich auch eine entsprechende Konfiguration aufweist.

 vim ~/.ssh/config
~/.ssh/config
Host jumphost
     Hostname 217.92.13.131
     Port 22
     User adminuser
     ForwardAgent yes
     Protocol 2
     IdentityFile ~/.ssh/id_ed25519
 
Host ff_pliening_gbw_od
     Hostname [2001:608:a01:106:822a:a8ff:feea:fae3]
     Port 22
     User root
     Protocol 2
     IdentityFile ~/.ssh/id_rsa4096_ff
 
Host ff_pliening_gbw_od-e
     Hostname [2001:608:a01:106:822a:a8ff:feea:fae3]
     Port 22
     User root
     Protocol 2
     IdentityFile ~/.ssh/id_rsa4096_ff
     ProxyJump jumphost

Wir können somit, wenn wir uns z.B. in einem IPv4-only Netzwerk aufhalten, ganz einfach durch den nachfolgenden Aufruf den Knoten ff_pliening_gbw_od erreichen.

 ssh ff_pliening_gbw_od-e

Ebenso können wir so direkt Dateien auf den Knoten in das /tmp-Verzeichnis kopieren, da sich der SCP-Aufruf entsprechend vereinfacht, Bsp.:

 scp firmware ff_pliening_gbw_od-e:/tmp

Hier wird nun ohne manuelle Umwege Datei firmware in das /tmp-Verzeichnis des Routers ff_pliening_gbw_od.

Zur Abfrage von Konfigurationsparametern bemühen wir den Befehl uci des gleichnamigen Unified Configuration Interface, welches intern von OpenWrt verwendet wird, um dessen Konfiguration verwalten zu können. Auf der offiziellen GitHub Projektseite finden sich Informationen zu aktuellen Änderungen mit entsprechenden Beispielen. Ohne Eingabe von zusätzlichen Parametern, werden die zur Verfügung stehenden Optionen ausgegeben.

 uci
Usage: uci [<options>] <command> [<arguments>]

Commands:
	batch
	export     [<config>]
	import     [<config>]
	changes    [<config>]
	commit     [<config>]
	add        <config> <section-type>
	add_list   <config>.<section>.<option>=<string>
	del_list   <config>.<section>.<option>=<string>
	show       [<config>[.<section>[.<option>]]]
	get        <config>.<section>[.<option>]
	set        <config>.<section>[.<option>]=<value>
	delete     <config>[.<section>[[.<option>][=<id>]]]
	rename     <config>.<section>[.<option>]=<name>
	revert     <config>[.<section>[.<option>]]
	reorder    <config>.<section>=<position>

Options:
	-c <path>  set the search path for config files (default: /etc/config)
	-d <str>   set the delimiter for list values in uci show
	-f <file>  use <file> as input instead of stdin
	-m         when importing, merge data into an existing package
	-n         name unnamed sections on export (default)
	-N         don't name unnamed sections
	-p <path>  add a search path for config change files
	-P <path>  add a search path for config change files and use as default
	-q         quiet mode (don't print error messages)
	-s         force strict mode (stop on parser errors, default)
	-S         disable strict mode
	-X         do not use extended syntax on 'show'

Die Ausgabe aller Konfigurationsparameter kann mitunter doch sehr umfänglich werden. Bsp.:

 uci show |wc -l
674

In aller Regel wird man gezielt nach einzelnen Parametern suchen, wie z.B. hier nach den hinterlegten Kontaktdaten.

 uci show | grep contact
gluon-node-info.@owner[0].contact='[email protected]'

Alle Parameter einer Section kann man durch Angabe der Section anwählen.

 uci show gluon-node-info
gluon-node-info.@location[0]=location
gluon-node-info.@location[0].share_location='1'
gluon-node-info.@location[0].altitude='504'
gluon-node-info.@location[0].latitude='48.198680689'
gluon-node-info.@location[0].longitude='11.798007488'
gluon-node-info.@owner[0]=owner
gluon-node-info.@owner[0].contact='[email protected]'
gluon-node-info.@system[0]=system

Alle Werte sind hierbei im Verzeichnis /etc/config/ abgelegt. So kann man auch z.B. die gluon-node-info sich auch direkt in der zugehörigen Konfigurationsdatei ansehen.

 less /etc/config/gluon-node-info
config location
	option share_location '1'
	option altitude '504'
	option latitude '48.198680689'
	option longitude '11.798007488'

config owner
	option contact '[email protected]'

config system

Zur Ausgabe der Anzahl der aktuell verbiundenen Clients verwendet man folgenden Aufruf:

 grep -cEo "\[.*W.*\]+" /sys/kernel/debug/batman_adv/bat0/transtable_local
3
 cat /lib/gluon/release
v2019.0.3
 cat /lib/gluon/gluon-version
v2018.2.1+

Zur Anzeige des verwendeten Router-Modells benutzt man den Befehl lua.

 lua -e 'print(require("platform_info").get_model())'
TP-Link TL-WR940N v6

Wollen wir wissen welche SSID2) (WLAN-Kennung) unser Freifunkknoten ausstrahlt, bedienen wir uns folgendem Aufruf.

 uci show | grep -i ssid
wireless.mesh_radio0.ssid='ffmuc-uml_ost'

Die SSID des Mesh-Netzes ermitteln wir mit folgendem Befehl:

 uci show | grep -i mesh_id
wireless.mesh_radio0.mesh_id='ffmuc-muc_ost-mesh'

Da es sich hier um einen Router der nur ein 2,4 GHz WLAN ausstrahlt, wird jeweils auch nur eine Zeile ausgegeben. Im nachfolgenden Beispiel handelt es sich um ein Routermodell der sowohl ein 2,4 GHz wie auch ein 5 GHz WLAN verwendet - wir sehen dies an der Ausgabe von zwei Konfigurationswerten.

 uci show wireless | grep -i id
wireless.mesh_radio0.mesh_id='ffmuc-muc_ost-mesh'
wireless.mesh_radio1.mesh_id='ffmuc-muc_ost-mesh'
wireless.client_radio0.ssid='muenchen.freifunk.net/muc_ost'
wireless.client_radio1.ssid='muenchen.freifunk.net/muc_ost

WICHTIG: Das Abändern der zum Segment passenden SSID ist gemäß der Nutzungsbedingungen nicht gestattet!

  • 5. Lokale Zusätze für Freifunk München
    Das Betreiben von Routern in Verbindung mit der Freifunk-München Netzwerkinfrastruktur ist nur gestattet, solange die folgenden zwei Bedingungen erfüllt sind:
    • die SSID des Client-Netzes auf “muenchen.freifunk.net/(Segmentname)” lautet
    • die Mesh-BSSID/SSID denen, der in den offiziellen Firmware-Images veröffentlichten, entspricht

Bei der Fehlersuche ist es mit unter sehr hilfreich, wenn aussagekräftige Logmeldung in Echtzeit zur Verfügung stehen. Mit Hilfe des Befehls logread können diese zur Ansicht gebracht werden. Durch Angabe eines nicht verwendeten Parameters -h werden alle Optionen ausgegeben, die der Befehl unterstützt

 logread -h
Usage: logread [options]
Options:
    -s <path>		Path to ubus socket
    -l	<count>		Got only the last 'count' messages
    -e	<pattern>	Filter messages with a regexp
    -r	<server> <port>	Stream message to a server
    -F	<file>		Log file
    -S	<bytes>		Log size
    -p	<file>		PID file
    -h	<hostname>	Add hostname to the message
    -P	<prefix>	Prefix custom text to streamed messages
    -f			Follow log messages
    -u			Use UDP as the protocol
    -t			Add an extra timestamp
    -0			Use \0 instead of \n as trailer when using TCP

So lassen sich z.B. mit der Option -l 4 die letzten 4 Logmeldungen ausgeben.

 logread -l 4
Mon Jun  3 20:32:06 2019 daemon.info fastd[2316]: resolving host `gw02.ext.ffmuc.net' for peer <mesh_vpn_backbone_peer_gw02>...
Mon Jun  3 20:32:11 2019 daemon.info fastd[2316]: resolving host `gw02.ext.ffmuc.net' failed: Try again
Mon Jun  3 20:32:19 2019 daemon.info fastd[2316]: resolving host `gw01.ext.ffmuc.net' for peer <mesh_vpn_backbone_peer_gw01>...
Mon Jun  3 20:32:24 2019 daemon.info fastd[2316]: resolving host `gw01.ext.ffmuc.net' failed: Try again

Mit der Option -f wird das log fortlaufend angezeigt.

 logread -f
Mon Jun  3 20:37:00 2019 user.notice ath9k-broken-wifi-workaround: node has no wifi, aborting.
Mon Jun  3 20:42:00 2019 user.notice ath9k-broken-wifi-workaround: node has no wifi, aborting.
...

batctl bietet unter anderem eine komfortable Möglichkeit, das batman-adv-Kernelmodul zu konfigurieren, um Debugging-Informationen wie Originatortabellen sowie Übersetzungstabellen und das Debug-Protokoll anzuzeigen. In der zugehörigen Manpage findet man viele Beispiele und Erklärungen dazu.

Welche B.A.T.M.A.N.-ADV Version verwendet wir erfahren wir wie folgt.

 batctl o | grep adv
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/72:5f:bf:8f:4f:fb (bat0/30:b5:c2:86:4e:c0 BATMAN_V)]

Eine Statistikübersicht des laufenden Systems erhalten wir mit der Option s.

 batctl s
	tx: 77797
	tx_bytes: 18491601
	tx_dropped: 80
	rx: 470476
	rx_bytes: 329029050
	forward: 575400
	forward_bytes: 130076381
	mgmt_tx: 1472475
	mgmt_tx_bytes: 106155234
	mgmt_rx: 2205028
	mgmt_rx_bytes: 159350140
	frag_tx: 16658
	frag_tx_bytes: 13091663
	frag_rx: 74130
	frag_rx_bytes: 57501200
	frag_fwd: 109
	frag_fwd_bytes: 84629
	tt_request_tx: 988
	tt_request_rx: 1323
	tt_response_tx: 161
	tt_response_rx: 895
	tt_roam_adv_tx: 20
	tt_roam_adv_rx: 17
	dat_get_tx: 0
	dat_get_rx: 2631
	dat_put_tx: 0
	dat_put_rx: 896
	dat_cached_reply_tx: 7

Gateways mit Bandbreitenangaben

Die Option gwl zeigt alle erreichbaren Gateways mit aktueller Bandbreite im Freifunknetz

 batctl gwl
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/72:5f:bf:8f:4f:fb (bat0/30:b5:c2:86:4e:c0 BATMAN_V)]
  Router            ( throughput) Next Hop          [outgoingIf]  Bandwidth
  f2:00:22:07:00:0d (       18.9) 2e:74:66:bd:2d:29 [     mesh0]: 1024.0/1024.0 MBit
* f2:00:23:07:00:0d (     1000.0) 7a:a9:26:18:01:24 [  mesh-vpn]: 1024.0/1024.0 MBit

Liste aller Clients

Eine Auflistung aller Clients im Freifunknetz sehen wir mit Angabe der Option tg

 batctl tg
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/72:5f:bf:8f:4f:fb (bat0/30:b5:c2:86:4e:c0 BATMAN_V)]
   Client             VID Flags Last ttvn     Via        ttvn  (CRC       )
   01:00:5e:7f:ff:fa   -1 [....] (142) ca:10:5e:58:d1:7b (144) (0x7c4ea5d5)
   01:00:5e:7f:ff:fa   -1 [....] (152) 0a:2a:6b:7f:21:e3 (159) (0xf3c5a950)

...

Summe aller WiFi-Nutzer im Netz

Wollegn wir wissen wieviele der zuvor abgefragten Clients als WLAN-Nutzer eingebucht sind erweitern wir die vorherige Abfrage wie folgt.

 batctl tg | grep W | wc -l
99

Liste der lokalen Nutzer

Wollen wir eine Liste aller lokalen Nutzer sehen bemühen wir die Option tl beim Befehl batctl.

 batctl tl
[B.A.T.M.A.N. adv openwrt-2018.1-5, MainIF/MAC: primary0/72:5f:bf:8f:4f:fb (bat0/30:b5:c2:86:4e:c0 BATMAN_V), TTVN: 107]
Client             VID Flags    Last seen (CRC       )
30:b5:c2:86:4e:c0   -1 [.P....]   0.000   (0xb49fafa9)
30:b5:c2:86:4e:c0    0 [.P....]   0.000   (0x155ab5db)
33:33:00:00:00:02   -1 [.P....]   0.000   (0xb49fafa9)
33:33:ff:00:00:01   -1 [.P....]   0.000   (0xb49fafa9)
33:33:00:02:10:01   -1 [.P....]   0.000   (0xb49fafa9)
01:00:5e:00:00:01   -1 [.P....]   0.000   (0xb49fafa9)
33:33:ff:40:f7:dc   -1 [.P....]   0.000   (0xb49fafa9)
33:33:ff:86:4e:c0   -1 [.P....]   0.000   (0xb49fafa9)
00:87:01:fc:fb:e6   -1 [....W.] 345.370   (0xb49fafa9)
33:33:00:00:00:01   -1 [.P....]   0.000   (0xb49fafa9)

Anzahl Lokaler WLAN-Clients

Auch hier können wir über die Erweiterung des Befehls uns sehr leicht ausgeben lassen, wieviele WLAN-Nutzer wir lokal haben.

 batctl tl | grep W | wc -l
1

Belegung der Netzwerkports am Router

Möchte man abfragen welche Ports an dem Freifunkrouter belegt, also Ethernet-Kabel angesteckt wurden, kann man dies wie folgt ermitteln.

 swconfig dev switch0 show | grep 'link:'
	link: port:0 link:up speed:1000baseT full-duplex txflow rxflow 
	link: port:1 link:up speed:1000baseT full-duplex auto
	link: port:2 link:up speed:1000baseT full-duplex txflow rxflow auto
	link: port:3 link:down
	link: port:4 link:down
	link: port:5 link:down
	link: port:6 link:down

Will man den FF-Router per MQTT zu Monitoringzwecken an seine Heimautomatisierung anbinden, so ist das (wegen des im FF-Image fehlenden OpenWrt-Pakets mosquitto-client) in einfacher Form nur indirekt per SSH machbar. Am einfachsten packt man dazu die nachfolgenden Zeilen in ein Shell-Skript, das man dann z.B. alle 5 Minuten von einem anderen Linux-Rechner (z.B. Raspberry Pi) als Cronjob starten lässt:

#!/bin/sh
ffroutername=marienplatz           # Name des FF-Routers
ffrouterip=192.168.178.63          # IP-Adresse des FF-Routers im Heimnetz
ffnodeip=fe80::62e3:27ff:febd:b9be # Adresse des FF-Routers im FF-Netz, aus map.ffmuc.net ersichtlich
datatype=statistics                  # auch nodeinfo und neighbours sind möglich
ssh root@$ffrouterip gluon-neighbour-info -i br-client -p 1001 -r $datatype -d $ffnodeip | mosquitto_pub -h localhost -t ffmuc/$ffroutername/$datatype -s

Damit werden Daten aus gluon-neighbour-info direkt dem Heimautomatisierungs-System (z.B. OpenHAB, FHEM) als JSON zur Verfügung gestellt. Interessiert man sich dabei nur für die Anzahl eingebuchter Clients, geht die letzte Zeile dieses Skripts auch einfacher mit Hilfe des oben beschriebenen batctl-Befehls:

mosquitto_pub -h localhost -t ffmuc/$ffroutername/clients -m `ssh root@$ffrouterip batctl tl | grep W | wc -l`

Voraussetzung ist natürlich, dass der Autologin per SSH eingerichtet ist.

Möchte man einzelne Konfigurationsparameter ändern, verwenden wir wiederum den Befehl uci gefolgt von der Option set. Mit unter hat es sich als zweckmäßig erwiesen vor umfangreichen Änderung eine Sicherheitskopie der bestehenden Konfiguration anzufertigen. Um dieses z.B. auf einer lokalen Admin-Workstation oder in einen passenden sicheren Cloudspeicher zu kopieren oder um es bei temporären Änderung anschließend wieder einfach wiederherstellen zu wollen.

 uci export network > /tmp/network.uci

Zum Wiederherstellen (restore) geht man dann wie folgt vor.

 cat /tmp/network.uci | uci import

Will man die gesicherte Konfiguration lokal speichern, kopiert man die zuvor erstellte Sicherungskopie einfach auf den lokalen Rechner. Da wir über die lokale Konfigurationsdatei unsere Freifunkknoten definiert haben, können wir einfach den Host über den definierten Namen ansprechen, in diesem Konfigurationsbeispiel kopieren wir die Sicherungskopie vom Knoten ff_pliening_gbw_od auf den lokalen Rechner ins aktuelle lokale Verzeichnis, repäsentiert durch den Punkt ..

 scp ff_pliening_gbw_od:/tmp/network.uci .

Im folgenden Beispiel wollen die die hinterlegten Kontaktinformationen abändern. Zunächst fragen wir ab, welche Informationen hier in diesem Konfigurationsbeispiel hinterlegt ist.

 uci show gluon-node-info.@owner[0].contact
gluon-node-info.cfg02c290.contact='[email protected]'

Hier ändern wir nun die eMail-Adresse unseren Wünschen entsprechend ab.

 uci set gluon-node-info.@owner[0].contact='[email protected]'
 uci commit

Fragen wir nun erneut den geänderten Parameter ab, werden uns die aktualisierten Daten ausgegeben.

 uci show gluon-node-info.@owner[0].contact
gluon-node-info.cfg02c290.contact='[email protected]'

Auf der Karte von Freifunk München werden die geänderten Daten dann auch entsprechend ausgegeben. Bild: Bildschirmhardcopy des betreffenden Freifunk-Knotens auf der Karte

In folgendem Konfigurationsbeispiel wollen wir den Knotennamen oder auch Hostname genannt, abändern. Auch hier fragen wir zunächst ab, welcher Wert gesetzt ist.

 uci show | grep hostname
system.@system[0].pretty_hostname='ff_pliening_gbw_ug'
system.@system[0].hostname='ffplieninggbwug'

Diesen Wert ändern wir nun in einen etwas sprechenderen Namen ab.

 uci set system.@system[0].pretty_hostname='ff_pliening_gänsbrunnenweg_ug'
 uci commit system

Fragen wir nun erneut den geänderten Parameter ab, werden uns die aktualisierten Daten ausgegeben.

 uci show | grep hostname
system.@system[0].hostname='ff_pliening_gänsbrunnenweg_ug'

Auf der Karte von Freifunk München werden die geänderten Daten nach ein paar Minuten dann auch entsprechend ausgegeben. Bild: Bildschirmhardcopy des betreffenden Freifunk-Knotens auf der Karte

Möchte man die im Router hinterlegten Geodaten abändern, da z.B. ein vorhandener Router seinen Aufstellungsort geändert hat, oder weil man zu besseren Darstellung auf der Karte, geht man wie folgt vor.

Auf der Karte sucht man den gewünschten Kartenausschnitt und wählt das PIN-Icon rechts oben am Bildschirm an. Bild: PIN-Icon zur Auswahl der Koordinaten auf der Freifunkkarte
Mit dem erscheinenden Fadenkreuz markieren wir dann die Stelle an dem der vorhandene Knoten zukünftig in der Karte erscheinen soll. In der linken Bildschirmhälfte erscheinen dann die Koordinaten und in dem Rahmen Uci auch direkt die benötigten Befehle zum Ändern der Konfiguration. Bild: Bildschirmhardcopy der Freifunkkarte mit ausgewählten Geo-Koordinaten Die Befehle aus dem Rahmen Uci kopieren wir dann einfach und fügen diese in unserem Shell-Fenster ein, mit dem wir die SSH-Verbindung mit unserem Freifunk-Knoten halten. Bsp.:

uci set gluon-node-info.@location[0]='location'; uci set gluon-node-info.@location[0].share_location='1';uci set gluon-node-info.@location[0].latitude='48.198675325';uci set gluon-node-info.@location[0].longitude='11.798149645';uci commit gluon-node-info

Nach kurzer Zeit wird dann der Router auf der Karte an der neuen gewünschten Stelle angezeigt. Bild: Freifunkkarte mit Anzeige der gewählten Nodes

In der Standardkonfiguration ist die Webseite eines FF-Knotens nur lokal am Router oder aus dem Freifunk-Netz heraus erreichbar. Möchte man sie auch aus dem (lokalen) LAN erreichen können, d.h. mit HTTP unter der IP-Adresse, die der Internet Router dem Knoten gegeben hat, dann muss man auf dem Knoten einen Regelsatz hinzufügen:

 uci set firewall.wan_http=rule
 uci set firewall.wan_http.name=wan_http
 uci set firewall.wan_http.src=wan
 uci set firewall.wan_http.proto=tcp
 uci set firewall.wan_http.dest_port=80
 uci set firewall.wan_http.target=ACCEPT
 uci commit
 /etc/init.d/firewall reload

Dann sollte ein Aufruf, wie z.B. http://192.168.1.xx, die Webseite des Knoten anzeigen. Die spezifische IP-Adresse des Knotens kann z.B. bei einer Fritzbox im Menü „Netzwerk“ herausgesucht werden, oder mit dem Befehl ifconfig br-wan auf dem Knoten selbst.

PS: Dies ist eine Kopie der Anleitung 'http auf WAN Port verfügbar machen' von Freifunk Stuttgart.

Will man seinen Knoten, sei es weil man diesen anderweitig weiterverwenden oder weg-/weitergeben möchte, von der Knotenkarte löschen, gibt es leider aktuell keinen direkten Löschbutton auf der Knotenkarte. Würde man den Router einfach nur so abstecken, würde für bis zu sieben Tage auf der Karte ein roter Kreis erscheinen, was hinlänglich als Störung oder defekter Router mit Problemen gleichgesetzt wird.

Daher empfiehlt es sich in einer solchen Situation den Node manuell von der Karte zu nehmen.

 uci set gluon-node-info.@location[0].share_location=0
 uci commit gluon-node-info

Nach ein paar Minuten verschwindet der Router auf der Karte und wir können diesen nun abstecken und abbauen.

Möchte man auf einem Router einen zweiten Admin für den Backupfall einen Zugriff gewähren, ist es notwendig dessen SSH-Publickey auf dem Knoten zu hinterlegen. Da wir unseren Knoten, auf denen wir mittels SSH zugreifen ausreichend in unserer lokalen SSH-Clientkonfigurationsdatei ~/.ssh/config ausreichend hinterlegt haben, brauchen wir keine IP-Adressen und User angeben, sondern können direkt auf die betreffenden Nodes so zugreifen.

Wir kopieren nun den Publickey des zweiten Admins in die Datei /etc/dropbear/authorized_keys und gehen dabei wie folgt vor:

 cat ~/.ssh/id_rsa_piraten.pub | ssh ff_pliening_gbw_ug 'cat >> /etc/dropbear/authorized_keys'

Dass bei der SSH eine Schlüsselbasierter Login einem Passwort gesichertem Zugriff vorzuziehen ist, gilt nicht nur für Server sondern sollte grundsätzlich unserem Grundverständnis an Sicherheit entsprechen. SSH-Zugang für den User root mit Passwort ist hinlänglich als nogo allgemeingültig er- und anerkannt.

Bei der Ersteinrichtung unseres Knotens über die WEG GUI wird bei aktueller Firmware auch deshalb gar keine Möglichkeit zur Vergabe eines Passwortes für den Nutzer root angeboten, sondern ausschließlich die Möglichkeit gegeben ein SSH-Schlüssel (public-key) zu hinterlegen.

Will man nun ganz sicher gehen, oder ist als verantwortlicher (LINUX-)Admin von Haus aus ein klein wenig paranoid, kann man den Zugang nur mit Passwort und den Zugang für den Nutzer Root mit Passwort bei SSH-Daemon dropbear auch komplett deaktivieren. Hierzu setzen wir die beiden betreffenden Zeilen in der zugehörigen Konfigurationsdatei des SSH-Daemon auf off.

 vim /etc/config/dropbear
/etc/config/dropbear
config dropbear
#	Django : 2019-06-14
#	default: option PasswordAuth 'on'
#	         option RootPasswordAuth 'on'
	option PasswordAuth 'off'
	option RootPasswordAuth 'off'
	option Port         '22'
#	option BannerFile   '/etc/banner'

Anschließend starten wir den Router einmal neu, damit dieser die Konfigurationsänderung aktiviert.

 reboot

Versuchen wir uns nun ohne passenden SSH-Key am Node anzumelden, erfolgt keine Passwort-Abfrage mehr und wir werden freundlich mit einem Permission denied (publickey). darauf hingewiesen, dass es ohne Hände keine Kekse mehr gibt, kurzum ohne SSH-Schlüssel ist kein Zugang mehr möglich, auch nicht mittels Passwort!

 ssh root@2001:608:a01:102:da0d:17ff:feff:569e
Permission denied (publickey).

Bei einem Update des Routers mit einer neuen Firmware werden diese Einstellungen überschrieben - wir müssen diese Konfigurationsänderung dann erneut vornehmen!

Normalerweise funkt unser Freifunk-WLAN-Router auf Kanal 6. Ist dieser Kanal schon durch andere WLAN überbelegt bzw. haben wir zur Versorgung einer Halle mehrere Router am Start, kann es zweckmäßig sein, den vorbelegten Kanal 6 zu wechseln.

Im folgenden Konfigurationsbeispiel wechseln wir zum Kanal 1.

 uci set wireless.radio0.channel=1

Dieser Befehl ändern „nur“ den Kanal bis zum nächsten Neustart/reboot des Routers. Wollen wir die Kanaländerung resetfest machen führen wir nachfolgende Befehle aus.

 uci set gluon-core.@wireless[0].preserve_channels=1
 uci commit
 wifi

Will man wissen welche Kanäle verwendet werden, greift man auf folgenden Befehl zurück. Nachfolgendes Beispiel zeigt einen TP-Link TL-WDR4300.

 uci show | grep channel
wireless.radio0.channel='6'
wireless.radio1.channel='44'

Möchte man dem Freifunk-Knoten an seinem Internet-Router nicht die komplette Bandbreite des Internetanschluss zur Verfügung stellen, kann neben einer zeitlichen Begrenzung auch eine Traffic-/Bandbreitenbegrenzung zweckmäßig sein. In nachfolgendem Beispiel steuern die Optionen limit_ingress die ungefähre, maximale Bandbreite für den Downstream bzw. limit_egress für Upstream zum Internet (Angaben in kB/s). Mittels der Option enabled wird die Begrenzung gesteuert: Ein Wert von 1 aktiviert sie, 0 deaktiviert sie wieder.

 uci set simple-tc.mesh_vpn='interface'
 uci set simple-tc.mesh_vpn.ifname='mesh-vpn'
 uci set simple-tc.mesh_vpn.enabled='1'
 uci set simple-tc.mesh_vpn.limit_ingress='25000'
 uci set simple-tc.mesh_vpn.limit_egress='5000'
 uci commit

Bei größeren Installationen, insbesondere bei Versorgung von größeren Arealen, Hallen oder auch Zelten kann es an gebracht sein, mit Hilfe der Sendeleistung einzelner Zellen eine gewisse Art Lastverteilung vorzunehmen. So würde es keinem helfen z.B. in einem großen Festzelt in jeder der vier Ecken einen Router aufzustellen, der dann das komplette Zelt überstrahlt. Durch Verringerung der Sendeleistung können einzelne Funkzellen verkleinert werden und somit die Anzahl gleichzeitig eingebuchter Clients besser auf alle vier Sender verteilt werden.

Bei der Veränderung der Sendeleistung ist in Deutschland zwingend darauf zu achten, dass nicht versehentlich die maximale abgestrahlte Sendeleistung (Sendeleistung plus ggf. vorhandene Antennen mit Richtwirkung) im Frequenzbereich 2,400 GHz - 2,4835 GHz von 100 mW überschritten wird!

Der für die Sendeleistung relevante Konfigurationsoption kann nun mit dem Befehl iwinfo radio0 txpower abgefragt werden.

 iwinfo radio0 txpower
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
   3 dBm (   1 mW)
   4 dBm (   2 mW)
   5 dBm (   3 mW)
   6 dBm (   3 mW)
   7 dBm (   5 mW)
   8 dBm (   6 mW)
   9 dBm (   7 mW)
  10 dBm (  10 mW)
* 11 dBm (  12 mW)
  12 dBm (  15 mW)
  13 dBm (  19 mW)
  14 dBm (  25 mW)
  15 dBm (  31 mW)
  16 dBm (  39 mW)
  17 dBm (  50 mW)
  18 dBm (  63 mW)
  19 dBm (  79 mW)
  20 dBm ( 100 mW)

Das gezeigte Beispiel zeigt nun die möglichen Einstellungen eines TP-Link CPE210 v1.0, die der verwendete Chipsatz/Sendeeinheit technisch mitbringt. der mit dem Stern gekennzeichnete Wert repräsentiert die aktuellen Einstellungen. Hier nochmals die eindringliche Warnung, nicht die Sendeleistung über die vorgegebenen 11 dBm (12 mW) erhöhen, da der Outdoor-Router über eine interne Richtantenne (Antennengewinn von 9dBi laut Datenblatt) verfügt!

In folgendem Beispiel wollen wir nun die Abgestrahlte Sendeleistung auf ~ 60 mW verringern- Wir stellen daher die Sendeleistung auf 9 dBm ein.

 uci set wireless.radio0.txpower=9
 uci commit wireless
 wifi

Eine erneute Abfrage zeigt nun den geänderten Wert:

 iwinfo radio0 txpower
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
   3 dBm (   1 mW)
   4 dBm (   2 mW)
   5 dBm (   3 mW)
   6 dBm (   3 mW)
   7 dBm (   5 mW)
   8 dBm (   6 mW)
*  9 dBm (   7 mW)
  10 dBm (  10 mW)
  11 dBm (  12 mW)
  12 dBm (  15 mW)
  13 dBm (  19 mW)
  14 dBm (  25 mW)
  15 dBm (  31 mW)
  16 dBm (  39 mW)
  17 dBm (  50 mW)
  18 dBm (  63 mW)
  19 dBm (  79 mW)
  20 dBm ( 100 mW)

Zusätzlich zu den beiden Freifunk WLAN-Netzen Client und Mesh, kann ein Router auch noch ein verschlüsseltes privates WLAN ausstrahlen, welches dann nicht über Freifunk ausgeleitet wird, sondern lokal vor Ort in das lokale Netzwerk bzw. lokalen privaten Netzeinwahlknoten übergeben wird.

Einrichtung

In folgendem Konfigurationsbeispiel wollen wir ein privates WLAN mit der

  • SSID=privacy-is-not-acrime! und dem zugehörigen
  • Privaten Schlüssel=N3v3r-7ru57-the-g0vernment! einrichten.
 uci set wireless.wan_radio0=wifi-iface
 uci set wireless.wan_radio0.device=radio0
 uci set wireless.wan_radio0.network=wan
 uci set wireless.wan_radio0.mode=ap
 uci set wireless.wan_radio0.encryption=psk2
 uci set wireless.wan_radio0.ssid="privacy-is-not-acrime!"
 uci set wireless.wan_radio0.key="N3v3r-7ru57-the-g0vernment!"
 uci set wireless.wan_radio0.disabled=0
 uci commit wireless
 wifi

Deaktivierung

Zur Deaktivierung dieses zuvor eingerichteten privaten WLANs nutzen wir folgende Befehle.

 uci set wireless.wan_radio0.disabled=1
 uci commit wireless
 wifi

In Gemeinschaftsunterkünften wie z.B. Jugendherbergen, Asylhilfeeinrichtungen oder auch im familiären Haushalt, kann es erforderlich sein bzw. werden, den Zugang zum Internet zeitlich zu reglementieren. Bevor man nun einzelne Freifunk-Router per 230V-Zeitschaltuhr hart vom Stromnetz trennt, sollte man lieber das nachfolgende ash-Shellscript verwenden. (Anmerkung: Etwas eleganter lässt sich diese Aufgabe ab der Firmware-Version v2019.0.8 mit der neuen Funktion ap-timer lösen, mehr dazu im Abschnitt weiter unten. )

ASH-Script

Zunächst wollen wir uns die Konfiguration per Script einmal ansehen. Dazu legen wir uns ein kleines ash-Shellscript an, dass wir dann bei Bedarf entweder händisch oder cronjob-gesteuert aufrufen.

 vim /root/stop_wlan.sh
/root/stop_wlan.sh
#!/bin/ash
# Script zum (De-)Aktivieren der unterschiedlichen Client-WLANs
 
# $1 : erste uebergebene Variable :
#                                   2 = 2.4 GHz Freifunk-Client-Netz
#                                   5 = 5   GHz Freifunk-Client-Netz
#                                   p = 2.4 GHz Freifunk-Client-Netz
#
# $2 : zweite uebergebene Variable:
#                                   off = WLAN ausschalten
#                                   on  = WLAN einschalten
 
# WLAN(s) ausschalten
if [ $2 = "off" ] ; then
   if [ $1 = "2" ] ; then
      uci set wireless.client_radio0.disabled=1 
   elif [ $1 = "5" ] ; then
      uci set wireless.client_radio1.disabled=1
   else 
      uci set wireless.wan_radio0.disabled=1
   fi
fi
 
# WLAN(s) einschalten
if [ $2 = "on" ] ; then
   if [ $1 = "2" ] ; then
      uci set wireless.client_radio0.disabled=0
   elif [ $1 = "5" ] ; then
      uci set wireless.client_radio1.disabled=0
   else
      uci set wireless.wan_radio0.disabled=0
   fi
fi
 
# Konfigurationsaenderung(en) persistieren
uci commit wireless
wifi

Das Script statten wir zum Aufruf mit den entsprechenden x-Rechten aus.

 chmod +x /root/stop_wlan.sh

Wollen wir nun ein WLAN umschalten, geben wir zwei Parameter an:

  • erster Parameter
  • zweiter Parameter
    • off : WLAN ausschalten
    • on : WLAN einschalten

So deaktivert z.B. folgender Aufruf das 5 GHz Client-WLAN: /root/stop_wlan.sh 5 off und folgender Aufruf würde es wieder aktivieren: /root/stop_wlan.sh 5 on. Da wir das natürlich nicht jedesmal per Hand ausführen wollen, legen wir uns entsprechende cronjobs an. Dazu hinterlegen wir in der User-crontab des Nutzers root entsprechend unsere zeitlichen Vorstellungen.

 crontab -e
# 2.5 GHz Client WLAN um 22:30 Uhr ausschalten
30 22 * * * /root/stop_wlan.sh 2 off > /dev/null 2>&1
 
# 5 GHz Client WLAN um 22:30 Uhr ausschalten
30 22 * * * /root/stop_wlan.sh 5 off > /dev/null 2>&1
 
# privates verschluesseltes WLAN um 00:00 Uhr ausschalten
* 0 * * *   /root/stop_wlan.sh p off > /dev/null 2>&1
 
# um 6:45 Uhr alle WLANs wieder aktivieren
45 6 * * *  /root/stop_wlan.sh 2 on > /dev/null 2>&1
45 6 * * *  /root/stop_wlan.sh 5 on > /dev/null 2>&1
45 6 * * *  /root/stop_wlan.sh p on > /dev/null 2>&1

In dem gezeigtem Beispiel würden um 22:30 Uhr jeweils die Freifunk Client-Netze sowie das private verschlüsselte WLAN um 00:00 Uhr ausgeschaltet, sowie frühmorgens um 6:45 Uhr alle drei WLANs wieder eingeschaltet.

AP-Timer

Seit der Firmware-Version v2019.0.8 3) gibt es nun eine Konfigurationsoption, die man am einfachsten bei der Konfiguration über die Konfiguration über die WEB-GUI von LuCi erreichen und konfigurieren kann.

Auf der Konsole können wir uns hierzu dann die gesetzten Optionen mit Hilfe des Befehls uci show anzeigen lassen.

 uci show ap-timer
ap-timer.settings=ap-timer
ap-timer.settings.enabled='1'
ap-timer.settings.type='day'
ap-timer.all=day
ap-timer.all.on='06:20'
ap-timer.all.off='23:59'

In der Konfigurationsdatei /etc/config/ap-timer werden diese dann entsprechend persistiert.

/etc/config/ap-timer
config ap-timer 'settings'
	option enabled '1'
	option type 'day'
 
config day 'all'
	list on '06:20'
	list off '23:59'

Wollen wir die Zeiten via SSH ändern, setzen wir die entsprechenden ap-timer-Optionen. In nachfolgendem Beispiel wollen wir das WLAN morgens um 8:00 Uhr ein- und nachmittags um 17:45 Uhr wieder ausschalten.

 uci set ap-timer.all.on='08:00'
 uci set ap-timer.all.off='17:45'
 uci commit

Bisweilen kann es erforderlich werden, einzelne Clients auf Basis ihrer MAC-Adresse auszusperren. Die kann verschiedene Gründe haben, sei es nur zum Schutz des Client selbst oder auch zum Schutz anderer Nutzer vor Störungen.

WICHTIG:
Eine derartige Beeinflussung/Beschränkung muss wohl überlegt und wohl durchdacht und begründet sein, denn die widerspricht eindeutig den Freifunk Nutzungsbedingungen:

  1. Freier Transit :
    EigentümerInnen bestätigen, freien Transit über ihre freie Netzwerkinfrastruktur anzubieten. EigentümerInnen bestätigen, die Daten, die seine freie Netzwerkinfrastruktur passieren, weder störend zu beeinträchtigen noch zu verändern.

Im folgenden Beispiel werden die Clients mit den MAC-Adressen 00:11:22:33:44:55 und 00:11:DE:AD:BE:EF beim 2,4 GHz WLAN ausgesperrt.

 uci set wireless.client_radio0.macfilter=deny
 uci set wireless.client_radio0.maclist='00:11:22:33:44:55 00:11:DE:AD:BE:EF'
 uci commit
 /etc/init.d/network restart

Hat man neben dem 2,4 GHz einen Router, der ein 5 GHz WLAN ausstrahlt, muss man auch noch radio1 berücksichtigen.

 uci set wireless.client_radio1.macfilter=deny
 uci set wireless.client_radio1.maclist='00:11:22:33:44:55 00:11:DE:AD:BE:EF'
 uci commit
 /etc/init.d/network restart

Mehrere MAC-Adressen werden hierbei einfach, wie in diesem Konfigurationsbeispiel zu sehen, durch ein Leerzeichen getrennt.

Zum Entsperren einer hinterlegten MAC-Adresse löscht man diese einfach aus dem Parameter maclist, also in obigen Beispielen würde man zum Entsperren des Clients 00:11:DE:AD:BE:EF diese löschen und nur noch die 00:11:22:33:44:55 als zu sperrende MAC-Adresse angeben:

 uci set wireless.client_radio0.maclist='00:11:22:33:44:55'
 uci set wireless.client_radio1.maclist='00:11:22:33:44:55'
 uci commit
 /etc/init.d/network restart

Will man die definierten Optionen wieder gänzlich löschen, lässt man die Parameter-Angaben leer.

 uci set wireless.client_radio0.macfilter=''
 uci set wireless.client_radio0.macfilter=''
 uci set wireless.client_radio0.maclist=''
 uci set wireless.client_radio1.maclist=''
 uci commit
 /etc/init.d/network restart

Auf Grund des großen Wachstums der Nodeanzahl im Freifunknetz München, wurde im Mitte 2019 das Gesamtnetz von ursprünglich drei Segmenten auf 12 4) erweitert. Basierend auf hinterlegten Geo-Daten und auch umliegender WLAN-Access-Points erfolgt die Segmentauswahl vollautomatisch und könnte zukünftig bei weiterem Zuwachs an Freifunkknoten noch weiter aufgeteilt werden.

Aktuell5) gibt es folgende Segmente:

SSID Segment-Name IPv4-Prefix IPv6-Prefix Wien IPv6-Prefix München
muenchen.freifunk.net/muc_cty ffmuc_muc_cty 10.80.128.0/21 2001:678:e68:100::/64 2001:678:ed0:100::/64
muenchen.freifunk.net/muc_nord ffmuc_muc_nord 10.80.136.0/21 2001:678:e68:101::/64 2001:678:ed0:101::/64
muenchen.freifunk.net/muc_ost ffmuc_muc_ost 10.80.144.0/21 2001:678:e68:102::/64 2001:678:ed0:102::/64
muenchen.freifunk.net/muc_sued ffmuc_muc_sued 10.80.152.0/21 2001:678:e68:103::/64 2001:678:ed0:103::/64
muenchen.freifunk.net/muc_west ffmuc_muc_west 10.80.160.0/21 2001:678:e68:104::/64 2001:678:ed0:104::/64
muenchen.freifunk.net/uml_nord ffmuc_uml_nord 10.80.168.0/21 2001:678:e68:105::/64 2001:678:ed0:105::/64
muenchen.freifunk.net/uml_ost ffmuc_uml_ost 10.80.176.0/21 2001:678:e68:106::/64 2001:678:ed0:106::/64
muenchen.freifunk.net/uml_sued ffmuc_uml_sued 10.80.184.0/21 2001:678:e68:107::/64 2001:678:ed0:107::/64
muenchen.freifunk.net/uml_west ffmuc_uml_west 10.80.192.0/21 2001:678:e68:108::/64 2001:678:ed0:108::/64
muenchen.freifunk.net/welt ffmuc_welt 10.80.200.0/21 2001:678:e68:109::/64 2001:678:ed0:109::/64
muenchen.freifunk.net/gauting ffmuc_gauting 10.80.208.0/21 2001:678:e68:10a::/64 2001:678:ed0:10a::/64
muenchen.freifunk.net/freising ffmuc_freising 10.80.216.0/21 2001:678:e68:10b::/64 2001:678:ed0:10b::/64
muenchen.freifunk.net/augsburg ffmuc_augsburg 10.80.224.0/21 2001:678:e68:10c::/64 2001:678:ed0:10c::/64

Will man in Erfahrung bringen, welche Segmente momentan zur Verfügung stehen, kann man diese mit Hilfe des folgenden Aufrufs abfragen.

 ls /lib/gluon/domains | cut -f1 -d "."
ffmuc_freising
ffmuc_gauting
ffmuc_muc_cty
ffmuc_muc_nord
ffmuc_muc_ost
ffmuc_muc_sued
ffmuc_muc_west
ffmuc_uml_nord
ffmuc_uml_ost
ffmuc_uml_sued
ffmuc_uml_west
ffmuc_welt

Die aktuelle Segmentzuordnung am eigenen Knoten kann man mit folgendem Befehl abfragen:

 uci show gluon.core.domain
gluon.core.domain='ffmuc_uml_ost'

Der Knoten befindet sich also demnach im Segment ffmuc_uml_ost. Will man diesen Knoten nun z.B. in das Segment ffmuc_muc_ost versetzen, schreibt man in die betreffende Konfigurationsoption den neuen Segmentnamen. Soll der „Umzug“ des Routers in ein anderes Segment dauerhaft bleiben, deaktivieren wir den Domain-Director zusätzlich auch noch mit uci set ffmuc.director.enabled='0'.

 uci set gluon.core.domain='ffmuc_uml_ost'
 uci set ffmuc.director.enabled='0'
 uci commit
 gluon-reconfigure
 reboot
 

Um die Dauerhaftigkeit dieses Umzugs wieder aufzulösen und den Router wieder selbst seine „richtige“ Domäne finden zu lassen, macht man diese Einstellung wieder rückgängig:

 # uci set gluon.core.domain='ffmuc_uml_sued'
 uci set ffmuc.director.enabled='1'
 uci commit
 gluon-reconfigure
 reboot

Ein TP-Link CPE210 bietet neben seinem Uplink-Ethernet-Port noch einen weiteren sog. Passthrough-Port LAN1 zur Verfügung. Über diesen Ethernet-Port kann ein weiteres Gerät versorgt werden.

Es wird jedoch nicht der WAN-Port „durchgeschliffen“, sondern das Freifunk Client-Netz!

Die aktuellen Einstellungen können wir hierzu folgender Maßen abfragen:

 uci show system.poe_passthrough
system.poe_passthrough=gpio_switch
system.poe_passthrough.name='PoE Passthrough'
system.poe_passthrough.gpio_pin='20'
system.poe_passthrough.value='0'

Aktivierung

Zum Aktivieren des Passthrough-Port gehen wir wie folgt vor:

 uci set system.poe_passthrough.value='1'
 uci commit system

Deaktivierung

Wollen wir den Port von der Ferne aus deaktivieren setzen wir die Option system.poe_passthrough.value='0'.

 uci set system.poe_passthrough.value='0'
 uci commit system

Möchte man seinen WLAN-Router erneut in den Konfigurationsmodus versetzen, um ihn dann mit dem Web-Browser via http://192.168.1.1 administrieren, verwendet man folgenden Aufruf.

 uci set "gluon-setup-mode.@setup_mode[0].enabled=1"
 uci commit gluon-setup-mode
 reboot

Möchte man den Router wieder in den Anfangszustand zurücksetzen, also die vorhandene Konfiguration komplett löschen, geht man wir folgt vor.

 firstboot
This will erase all settings and remove any installed packages. Are you sure? [N/y]
 y
/dev/mtdblock5 is mounted as /overlay, only erasing files
 reboot

Anschließend ist der Router zurückgesetzt, und man kann die Konfiguration unter http://192.168.1.1 wieder neu beginnen.

In aller Regel wird man bemüht sein, die Firmware seines bzw. seiner Router immer auf einen aktuellen Stand zu halten. Dies nicht nur aus Sicherheitsaspekten heraus, sondern auch um an Neuerungen teilhaben zu können. Die Freifunk-Community in München stellt dazu drei unterschiedliche Releasezwige zur Verfügung : https://firmware.ffmuc.net/

  • experimental : Hier werden brandaktuelle Neuerungen eingebaut und daher kann eine 100%ige Gewähr übernommen werden, ob auch wirklich alle Funktionen den gewünschten Erfolg bringen, bzw. auch alle bugfixes die bekannten Fehlfunktionen eliminiert haben.
  • testing Bevor eine Firmware großflächig im Releasezweig stable ausgerollt, wird diese von einem größeren Testfeld auf Herz und Nieren getestet.
  • stable : Wie der Name schon andeutet, ist dies der Releasezweig, der in aller Regel bei produktiven Umgebungen zum Einsatz kommen wird.

Den aktuell eingestellten Releasezweig können wir mit Hilfe des nachfolgenden Befehls abfragen.

 uci show autoupdater.settings
autoupdater.settings=autoupdater
autoupdater.settings.enabled='1'
autoupdater.settings.branch='experimental'
autoupdater.settings.version_file='/lib/gluon/release'

Der Router würde also demnach bei einem Update des Releasezweigs experimental sich automatisiert eine neue Firmware laden. Dies sollte man i.d.R. nur dann machen, wenn man auch wirklich weiss was man da macht und wenn man einen kurzen Draht zu den Firmewarecoreentwicklern hat.

Will man den Firmwarezweig manuell dauerhaft ändern setzen wir den Branch entsprechend z.B. auf die option stable.

 uci set autoupdater.settings.enabled='1'
 uci set autoupdater.settings.branch='stable'
 uci commit autoupdater

Eine erneute Abfrage zeigt nun, dass der Branch stable künftig verwendet wird.

 uci show autoupdater.settings.branch
autoupdater.settings.branch='stable'

Mit Hilfe des Befehls autoupdater kann man nun manuell eingreifen und die Firmware zielgerichtet updaten - mit Angabe der Option -h werden alle Optionen angezeigt.

 autoupdater -h
Usage: autoupdater [options] [<mirror> ...]

Possible options are:
  -b, --branch BRANCH  Override the branch given in the configuration.

  -f, --force          Always upgrade to a new version, ignoring its priority
                       and whether the autoupdater even is enabled.

  -h, --help           Show this help.

  -n, --no-action      Download and validate the manifest as usual, but do not
                       really flash a new firmware if one is available.

  --fallback           Upgrade if and only if the upgrade timespan of the new
                       version has passed for at least 24 hours.

  --force-version      Skip version check to allow downgrades.

  <mirror> ...         Override the mirror URLs given in the configuration. If
                       specified, these are not shuffled.

Das Update der Firmware kann manuell angestoßen werden, dazu verwendet man die Option -f. Somit wir aus dem aktuell definierten Releasezweig ein Update gesucht, geholt und bei Verfügbarkeit auch installiert.

 autoupdater -f
Retrieving manifest from http://[2001:608:a01::27]/stable/sysupgrade//stable.manifest ...
No new firmware available.

Durch Angbane des Branches kann man unabhängig vom konfigurierten Releasezweig eine spezielle Firmware installieren. Im folgenden Beispiel erzwingen wir den Firmwareupdate aus dem Zweig experimantal.

 autoupdater -b experimental -f
Retrieving manifest from http://firmware.ffmuc.net/experimental/sysupgrade//experimental.manifest ...
Stopping cron...
Stopping haveged...
Stopping micrond...
Stopping sysntpd...
Stopping gluon-radvd...
Stopping uhttpd...
Stopping sse-multiplexd...
Stopping gluon-respondd...
vm.drop_caches = 3
Downloading image:  3328 / 3328 KiB
Stopping network...
Killed by signal 1.
Killed by signal 1.
packet_write_wait: Connection to UNKNOWN port 65535: Broken pipe

Beide Beispiele setzen natürlich voraus, dass der Firmware-Server erreichbar ist. Alternativ ist es auch möglich das Firmware-Image manuell herunterladen bzw. auf den Router kopieren. Im folgenden Beispiel holen wir uns zuerst das Image auf unseren Admin-Rechner und kopieren es dann via scp auf den Router um es abschließend per Hand zu installieren.

In folgendem Beispiel gehen wir mal davon aus, dass wir uns nicht 100%ig sicher sind welches Router-Modell in Verwendung ist. Alos fragen wir zunächst ab, welches Routermodell da im Einsatz ist.

 lua -e 'print(require("platform_info").get_model())'
Ubiquiti UniFiAP Outdoor+

Wir werden uns also erst einmal von der Firmwareseite das gewünschte Image auf unseren Admin-Rechner herunterladen.

 wget https://firmware.ffmuc.net/experimental/sysupgrade/gluon-ffmuc-v2019.0.4~exp86-ubiquiti-unifiap-outdoor+-sysupgrade.bin

Anschließend kopieren wir diese Date in das Zielverzeichnis /tmp auf unseren Freifunk-Knoten.

 $ scp gluon-ffmuc-v2019.0.4~exp86-ubiquiti-unifiap-outdoor+-sysupgrade.bin ff_pliening_gbw_test:/tmp/
##############################################################################
#                                                                            #
#      ╭∩╮( ͡° ل͟ ͡° )╭∩╮   This is not your server!   ╭∩╮( ͡° ل͟ ͡° )╭∩╮      #
#                                                                            #
#             Unauthorized access to this system is prohibited !             #
#                                                                            #
#    This system is actively monitored and all connections may be logged.    #
#         By accessing this system, you consent to this monitoring.          #
#                                                                            #
##############################################################################
gluon-ffmuc-v2019.0.4~exp86-ubiquiti-unifiap-outdoor+-sysupgrade.bin                                                                        100% 3968KB 211.7KB/s   00:18    
Killed by signal 1.
Killed by signal 1.

Bevor wir nun die Firmware installieren, leeren wir noch die caches auf dem Router, nachdem wir uns dort per SSH angemeldet haben.

 ssh ff_pliening_gbw_od
 echo 3 > /proc/sys/vm/drop_caches

Zum Updaten verwenden wir den Befehl sysupgrade - bei Angabe der Option _h werden die möglichen Optionen angezeigt.

 sysupgrade -h
Usage: /sbin/sysupgrade [<upgrade-option>...] <image file or URL>
       /sbin/sysupgrade [-q] [-i] <backup-command> <file>

upgrade-option:
	-f <config>  restore configuration from .tar.gz (file or url)
	-i           interactive mode
	-c           attempt to preserve all changed files in /etc/
	-n           do not save configuration over reflash
	-p           do not attempt to restore the partition table after flash.
	-T | --test
	             Verify image and config .tar.gz but do not actually flash.
	-F | --force
	             Flash image even if image checks fail, this is dangerous!
	-q           less verbose
	-v           more verbose
	-h | --help  display this help

backup-command:
	-b | --create-backup <file>
	             create .tar.gz of files specified in sysupgrade.conf
	             then exit. Does not flash an image. If file is '-',
	             i.e. stdout, verbosity is set to 0 (i.e. quiet).
	-r | --restore-backup <file>
	             restore a .tar.gz created with sysupgrade -b
	             then exit. Does not flash an image. If file is '-',
	             the archive is read from stdin.
	-l | --list-backup
	             list the files that would be backed up when calling
	             sysupgrade -b. Does not create a backup file.

Das Update der Firmware stoßen wir nun wie folgt an.

 sysupgrade /tmp/gluon-ffmuc-v2019.0.4~exp86-ubiquiti-unifiap-outdoor\+-sysupgrade.bin
Image metadata not found
Saving config files...
Commencing upgrade. Closing all shell sessions.
Killed by signal 1.
Killed by signal 1.
packet_write_wait: Connection to UNKNOWN port 65535: Broken pipe

3)
Ende Juli 2019
4)
Stand Anfang Juni 2019
5)
Stand Ende Oktober 2021
  • knb/ssh.1569181637.txt.gz
  • Zuletzt geändert: 2020/06/09 17:00
  • (Externe Bearbeitung)