Zur Administration unseres bzw. unserer Freifunk-Knoten verwenden wir die SSH1). Uns wird hier der volle Zugriff auf den Router gestattet. Er kann damit im laufenden Betrieb konfiguriert werden, es können seine Laufzeitparameter abgefragt und zusätzliche Programme gestartet werden. Ohne Vorkenntnisse ist die SSH für den Einsteiger meist ein Buch mit sieben Siegeln. Es lohnt sich daher einen Blick in einschlägige Anleitungen im WWW. Diese enthalten viele hilfreiche Informationen rund um die SSH, wie zum Beispiel in Djangos WIKI im Kapitel Secure Shell.
Zur Authentifikations als berechtigter User gegenüber dem SSH-Diensst benötigt man ein SSH-Schlüsselpaar, welches wir entweder schon besitzen (im ~/.ssh-Verzeichnis unseres Linuxsystems oder unter Windows mit PuTTYgen erstellt haben) oder uns für den Zugriff auf unseren Freifunkrouter hier erstellen wollen. Aktuell 2) empfehlen wir Ed25519-Schlüssel, einem Elliptic Curve Signature Schema, welches beste Sicherheit bei vertretbarem rechnerischem Aufwand verspricht. Somit werden wir uns einen ED25519-Schlüssel mit ausreichend großer Schlüssellänge erstellen.
Dies funktioniert jedoch nur mit Firmware neuer als v2023.x, nicht mit der Firmware für nicht mehr unterstützte Geräte v2022.x. Diese benötigen RSA und zudem spezielle Konfiguration auf dem Endgerät, die nicht mehr als sicher gilt, um darauf noch zugreifen zu können.
$ ssh-keygen -t ed25519 -C django@nausch.org -f ~/.ssh/id_ed25519_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_ed25519_ff. Your public key has been saved in /home/django/.ssh/id_ed25519_ff.pub. The key fingerprint is: 44:8b:1a:de:ad:be:ef:23:af:65:b7:e6:1a:bf:98:3d django@nausch.org The key's randomart image is: +--[ RSA 4096]----+ | ... | | o.o . | | +.o o | | ..+= . | | ooo S | | + .+oF | | +.. . | | . *E | | ++=o | +-----------------+
Unter Windows wird gerne PuTTY als SSH-Client eingesetzt. Das Tool PuTTYgen ist in diesem Kontext für die Generierung und Verwaltung von SSH-Schlüsselpaare zuständig.
Zum Anlegen eines neuen Schlüsselpaares klicken wir auf Generate und bewegen die Maus eine Zeit lang über dem Fenster hin und her. Bei der Schlüsselgenerierung werden Zufallszahlen benötigt, die von PuTTYgen aus diesen zufälligen Mausbewegungen abgeleitet werden.
Danach erscheint der public key des generierten Schlüsselpaares, der jetzt nur noch mit einem Passwort verschlüsselt werden muss. Dazu geben wir im Feld Key passphrase ein Kennwort ein und bestätigen es im Feld Confirm passphrase. Dieses Passwort wird in Zukunft bei jeder Benutzung des Schlüsselpaares, genauer des privaten Teils, benötigt, z.B. beim Einloggen auf den Freifunk-Knoten per SSH. Im Feld Key comment hat man die Möglichkeit, dem Schlüsselpaar einen wiedererkennbaren Namen zu geben, z.B. „Mein Freifunk-SSH-Key“. Zum Schluss speichern wird mit Save private key das Schlüsselpaar in einer .PPK-Datei ab. Der Inhalt des großen Textfeldes Public key for pasting into OpenSSH authorized_keys file stellt den public key-Teil des Schlüssels dar, in einer Form, die man auf dem Freifunkrouter bei der Installation oder nachträglich in der Datei /etc/dropbear/authorized_keys ablegen kann. Er kann dort einfach mit Copy&Paste herauskopiert werden. Es ist darauf zu achten, dass der gesamte Inhalt des Textfelds in eine Zeile geschrieben wird. Wie der Name public key schon andeutet, muss dieser Teil des Schlüsselpaares nicht geheim gehalten werden und kann in dieser Form verbreitet werden.
Um nun nicht jedes mal beim Aufbau einer SSH-Verbindung zu einem unserer Knoten Parameter wie user und die doch sehr langen IPv6-Adressen angeben zu müssen, hinterlegen wir die entsprechenden Daten in der Konfigurationsdatei unseres lokalen SSH-Clients auf unserem Adminrechner. Können wir den Zielhost direkt erreichen, so brauchen wir die IPv6-Adresse nicht mit [ maskieren, wir können diese also direkt angeben, wie in folgendem Beispiel:
Hostname 2001:608:a01:106:822a:a8ff:feea:fae3
.
Die Verwendung einer eignen individuellen SSH-Clientkonfigurationsdatei hat darüber hinaus auch noch zusätzlich den Vorteil, dass z.B. von einem Netz aus, bei dem „nur“ IPv4-Adressen Verwendung finden, wir keinen zusätzlichen Sprunghost angeben brauchen. Hier müssen wir lediglich dann darauf achten, dass die IPv6-Zieladresse mit Hilfe von [ ] entsprechend maskiert wird, wie im nachfolgenden Beispiel beim Host ff_pliening_gbw_od-e dann:
Hostname [2001:608:a01:106:822a:a8ff:feea:fae3]
.
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 eigenen Sprunghost, der dann das Bindeglied zwischen IPv4 und IPv6 herstellt, mit Namen jumphost, der natürlich auch eine entsprechende Konfiguration aufweist. Der sicherheitsbewusste Admin von entsprechenden Hosts/Servern und Freifunkknoten wird natürlich unterschiedliches Schlüsselmaterial für die verschiedenen Systeme (Sprunghosts und anderen Servern) und den Freifunkknoten verwenden. Die jeweiligen Schlüssel werden mit dem Parameter IdentityFile
definiert.
$ vim ~/.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_ed25519_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_ed25519_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 neue_firmware.bin ff_pliening_gbw_od-e:/tmp
Hier wird nun ohne Umwege die Datei neue_firmware.bin in das /tmp-Verzeichnis des Routers ff_pliening_gbw_od kopiert.
Zu Hause im eigenen LAN kann man unter Windows mit dem PuTTY SSH-Client ganz einfach auf seine Freifunk-Router zugreifen, wenn man bei der Installation seinen public key dort abgelegt hat.
Nach dem Öffnen von PuTTY wird man im Fenster PuTTY Configuration dazu aufgefordert, den Host Name (or IP address) des Freifunk-Routers anzugeben. Der Hostname des Knotens ist der um Interpunktion und Leerzeichen reduzierte Name des Knotens (z.B. wird aus „1. Knoten in Pasing“ ein Hostname „1knoteninpasing“).
Zielsicherer ist es jedoch, die IP-Adresse des Knotens im LAN zu benutzen. Diese findete man z.B. auf den Konfigurationsseiten des eigenen Internetrouters, z.B. dem Speedport oder der Fritz!Box, unter „Einstellungen zum Heimnetzwerk (LAN)“ oder DHCP-Einstellungen heraus. Zielführend kann auch die Benutzung eines Netzwerkscanners wie nmap oder die Fing-App unter Android sein.
Im nächsten Schritt muss die Datei mit dem SSH-Key auswählen, den man auf dem Router hinterlegt hat. Dies geschieht über die Einstellung Private key file for authentication unter Connection → SSH → Auth. Danach kann man unter Session die Einstellungen mit einem Namen bei Saved Sessions versehen und mit Save abspeichern und die SSH-Verbindung mit Open starten.
Falls die Verbindung zu Stande kommt, hat man die richtige IP-Adresse und den passenden Key gewählt. Man wird nun aufgefordert, das Passwort einzugeben, mit dem man den private key abgesichert hat. Schließlich hat man eine Eingeabeaufforderung mit Administrationsrechten bzw. root-Shell auf dem Router.
Zur Abfrage von Konfigurationsparametern bemühen wir den Befehl uci
des gleichnamigen Unified Configuration Interface, welches intern von OpenWrt verwendet wird. 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 des Router ist mit dem Kommando show möglich:
uci show
Diese Liste ist sehr lang. 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='django@nausch.org'
Alle Parameter einer Sektion 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='django@nausch.org' 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 'django@nausch.org' config system
Diese Information ist veraltet
Zur Ausgabe der Anzahl der aktuell (lokal) verbundenen Clients verwendet man folgenden Aufruf:
grep -cEo "\[.*W.*\]+" /sys/kernel/debug/batman_adv/bat0/transtable_local
3
Anmerkung: Unterhalb von /sys/kernel/debug/batman_adv/bat0
findet man in read-only „Pseudo“-Dateien auch alle weiteren Debug-Tabellen, die auch mit den verschiedenen Optionen von batctl
(vgl. unten) zugänglich sind.
cat /lib/gluon/release
v2020.2.1
cat /lib/gluon/gluon-version
v2020.2+
Zur Anzeige des verwendeten Router-Modells benutzt man den Befehl lua
.
lua -e 'print(require("platform_info").get_model())'
TP-Link TL-WR940N v6
Die SSID kann nur geändert werden, in dem man die Domain bzw. das Segment ändert. Siehe dazu den Abschnitt Ändern der Domain.
WICHTIG: Das Abändern der zum Segment passenden SSID ist gemäß der Nutzungsbedingungen nicht gestattet!
Wollen wir wissen welche SSID3) (WLAN-Kennung) unser Freifunkknoten ausstrahlt, bedienen wir uns folgendem Aufruf:
uci show wireless | grep ssid
Die SSID des Mesh-Netzes ermitteln wir mit folgendem Befehl:
uci show wireless | grep mesh_id
Wenn ein Router nur ein 2,4 GHz WLAN oder ein 5GHz ausstrahlt, dann wird nur nur ein Zeile für radio0 ausgegeben. Wenn es sich um ein Routermodell handelt, das sowohl ein 2,4 GHz als auch ein 5 GHz WLAN ausstrahlt, werden dort zwei Konfigurationswertpaaren ausgegeben:
# uci show wireless | grep 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'
Bei der Fehlersuche ist es 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 des 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 ausgegeben.
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. ...
Die Ausgabe kann mit Strg-C abgebrochen werden.
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 wird, erfahren wir wie folgt:
batctl o | grep adv
[B.A.T.M.A.N. adv openwrt-2018.1-8, MainIF/MAC: primary0/72:5f:bf:8f:4f:fb (bat0/30:b5:c2:86:4e:c0 BATMAN_V)]
Eine Übersicht über die Laufzeitstatistik des Batman-Moduls erhalten wir mit der Option show.
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
Die Option gwl zeigt alle erreichbaren Gateways mit geschätzten, aktuellen Bandbreitewerten 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
Eine Auflistung aller Clients im Freifunknetz sehen wir mit Angabe der Option tg (transglobal).
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) ...
Wollen wir wissen, wie viele der zuvor abgefragten Clients als WLAN-Nutzer eingebucht sind, erweitern wir die vorherige Abfrage wie folgt.
batctl tg | grep W | wc -l
99
Dies ist die Anzahl aller WLAN-Nutzer an allen Knoten im Netz, nicht die Anzahl am eigenen Router.
Wollen wir eine Liste aller lokalen Nutzer sehen, bemühen wir die Option tl (translocal).
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)
Clients mit dem noPurge-Flag sind interne Artefakte und dürfen nicht mitgezählt werden.
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
Möchte man abfragen, welche Ports am Freifunkrouter belegt sind, also wo Ethernetkabel 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 Freifunkouter per MQTT zu Monitoringzwecken an seine Heimautomatisierung anbinden, so ist das (wegen des in der Freifunk-Firmware 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 lokaler WLAN-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, verwendet man den Befehl uci
gefolgt von der Option set.
Vor umfangreichen Änderung sollte man eine Sicherheitskopie der bestehenden Konfiguration anzufertigen.
uci export network > /tmp/network.uci
Zum Wiederherstellen geht man dann wie folgt vor:
cat /tmp/network.uci | uci import
Will man die gesicherte Konfiguration auf dem Administrations-PC speichern, kopiert man die erstellte Sicherungskopie mit scp oder WinSCP 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 Beispiel kopieren wir die Sicherungskopie vom Knoten ff_pliening_gbw_od
auf den lokalen Rechner ins aktuelle Verzeichnis, repäsentiert durch den Punkt .
.
scp ff_pliening_gbw_od:/tmp/network.uci .
Im folgenden Beispiel wollen wir die hinterlegten Kontaktinformationen ändern. Zunächst fragen wir ab, welche Informationen hier hinterlegt sind:
uci show gluon-node-info.@owner[0].contact
gluon-node-info.cfg02c290.contact='django@nausch.org'
Hier ändern wir nun die eMail-Adresse unseren Wünschen entsprechend ab:
uci set gluon-node-info.@owner[0].contact='django@it.piratenpartei-bayern.de' 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='django@it.piratenpartei-bayern.de'
Auf der Karte von Freifunk München werden die geänderten Daten nach ein paar Minuten entsprechend ausgegeben:
In folgendem Beispiel wollen wir den Knotennamen oder auch Hostname genannt, ändern. Auch hier fragen wir zunächst ab, welcher Wert gesetzt ist:
# pretty-hostname ff_pliening_gbw_ug
Diesen Wert ändern wir nun in einen etwas sprechenderen Namen ab (hier sind auch Emojis zugelassen 😉):
pretty-hostname ff_pliening_gänsbrunnenweg_ug
Fragen wir nun erneut den geänderten Parameter ab, werden uns die aktualisierten Daten ausgegeben:
# pretty-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:
Siehe dazu auch den Gluon Administrationsguide.
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.
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.
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.
Standardmäßig ist der WiFi Mesh eingeschaltet um nahe Knoten miteinander über WiFi zu verbinden. Dies lässt sich mit folgenden Befehlen abschalten:
uci set wireless.mesh_radio0.disabled=1 uci set wireless.mesh_radio1.disabled=1 uci commit wireless wifi
Anschließend ist das WiFi Mesh abgeschaltet.
Siehe dazu auch Gluon Administrationsguide.
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 Web 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
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.
In folgendem Konfigurationsbeispiel wollen wir ein privates WLAN mit der
privacy-is-not-acrime!
und dem zugehörigen 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
Zur Deaktivierung dieses zuvor eingerichteten privaten WLANs nutzen wir folgende Befehle.
uci set wireless.wan_radio0.disabled=1 uci commit wireless wifi
In manchen Unterkünften oder auch im familiären Haushalt, kann es erforderlich sein bzw. werden, den Zugang zum Internet zeitlich zu reglementieren. Dazu wird „einfach“ ein Eintrag in den Aufgabendienst cron, hier micron.d geschrieben, in dem die Datei mit dem Editor VI erstellt wird:
vi /usr/lib/micron.d/wifioff
Drücke i um in den Schreibmodus zu gelangen.
Für tägliche Abschaltung von 21 bis 7 Uhr, sollte die Datei wie folgt aussehen:
0 21 * * * ifconfig client0 down; ifconfig client1 down 0 7 * * * ifconfig client0 up; ifconfig client1 up
Für die Syntax gibt es viele hilfreiche Seiten, wie beispielsweise Crontab.guru.
Anschließende drücke ESC und gib :wq ein um die Änderungen zu speichern.
Abschließend muss der Deamon die Konfiguration neu laden, damit der Cronjob aktiv geschaltet ist.
/etc/init.d/micrond reload
Siehe dazu auch den Freifunk Konsolenguide.
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:
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 |
Die aktuelle Liste aller Segment/Domains kann man auf Github finden: https://github.com/freifunkMUC/site-ffm/tree/stable/domains
Die aktuelle Segmentzuordnung am eigenen Knoten kann man mit folgendem Befehl abfragen:
# uci show gluon.core.domain gluon.core.domain='ffmuc_welt'
Der Knoten befindet sich also demnach im Segment ffmuc_welt. Will man diesen Knoten nun z.B. in das Segment ffmuc_muc_ost versetzen, schreibt man in die betreffende Konfigurationsoption den neuen Segmentnamen. Siehe dazu (siehe auch Gluon Administrationsguide).
gluon-switch-domain ffmuc_muc_ost
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'
Zum Aktivieren des Passthrough-Port gehen wir wie folgt vor:
uci set system.poe_passthrough.value='1' uci commit system
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.
gluon-enter-setup-mode
Siehe dazu auch den Gluon Administrationsguide.
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/
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 autoupdater.settings=autoupdater autoupdater.settings.enabled='1' autoupdater.settings.branch='stable' autoupdater.settings.version_file='/lib/gluon/release'
Siehe dazu auch den Gluon Administrationsguide.
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
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 Angabe des Branches kann man unabhängig vom konfigurierten Releasezweig eine spezielle Firmware installieren. Im folgenden Beispiel erzwingen wir den Firmwareupdate aus dem Zweig experimental.
autoupdater -b experimental -f
Falls wir uns nicht 100%ig sicher sind welches Router-Modell in Verwendung ist, kann man das mit dem folgenden Befehl abfragen (siehe dazu auch den Gluon Administrationsguide):
# lua -e 'print(require("platform_info").get_model())' Extreme Networks WS-AP3825i
Wir werden also erst einmal von der Firmwareseite das gewünschte Image unter Upgrade suchen: https://firmware.ffmuc.net/?q=Extreme%20Networks%20WS-AP3825i
Anstatt die Datei downzuloaden, kann man den Link mit Rechtsklick auf „Link kopieren“ kopieren.
Anschließend kann führen wir das Update mit dem Befehl sysupgrade durch, wobei hier der Link von oben kopiert werden kann:
echo 3 > /proc/sys/vm/drop_caches sysupgrade https://firmware.ffmuc.net/stable/sysupgrade/gluon-ffmuc-v2022.10.5-extreme-networks-ws-ap3825i-sysupgrade.bin
Siehe dazu auch Gluon Administrationsguide.
Falls wir uns nicht 100%ig sicher sind welches Router-Modell in Verwendung ist, kann man das mit dem folgenden Befehl abfragen (siehe dazu auch den Gluon Administrationsguide):
# lua -e 'print(require("platform_info").get_model())' Extreme Networks WS-AP3825i
Die vorigen Beispiele setzen 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.
Wir werden uns also erst einmal von der Firmwareseite das gewünschte Image unter Upgrade auf unseren Admin-Rechner herunterladen: https://firmware.ffmuc.net/?q=Extreme%20Networks%20WS-AP3825i
Anschließend kopieren wir diese Date in das Zielverzeichnis /tmp auf unseren Freifunk-Knoten. Hier nutzen wir beispielsweise die IP 192.168.1.1 für den Knoten:
$ scp gluon-ffmuc-v2022.10.5-extreme-networks-ws-ap3825i-sysupgrade.bin root@192.168.1.1:/tmp/new_sysupgrade_image.bin
Bevor wir nun die Firmware installieren, leeren wir noch die caches auf dem Router, nachdem wir uns dort per SSH angemeldet haben.
$ ssh root@192.168.1.1
# 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.
Das Update der Firmware stoßen wir nun wie folgt an.
sysupgrade /tmp/new_sysupgrade_image.bin
Saving config files... Commencing upgrade. Closing all shell sessions.