Pimp my Node: Unterschied zwischen den Versionen
(127 dazwischenliegende Versionen von 15 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
<noinclude> | |||
<div style="text-align: center; background-color:#e135734d; font-weight: bold; padding: 1px;"> | |||
< [[Experteneinstellungen|Optional: Experteneinstellungen]] [[Mitmachen|Übersicht]] | |||
</div> | |||
</noinclude> | |||
[[Kategorie:Mitmachen]] | [[Kategorie:Mitmachen]] | ||
Hier finden sich interessante Optionen für etwas versiertere Nutzer. | |||
Diese Seite wurde größtenteils für die Classic Firmware geschrieben. | |||
Wir - die KBU Gemeinschaft - stellen seit Jahren nur noch Firmware mit Gluon zur Verfügung (Image/Firmware-Server : [https://images.ffkbu.de https://images.ffkbu.de]) , die originale Dokumentation ist in englisch auf [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu finden. | |||
Weitere Befehle/Möglichkeiten können auch im übergreifenden Wiki von [https://freifunk.net/ freifunk.net] auf [https://wiki.freifunk.net/ wiki.freifunk.net] im Artikel [https://wiki.freifunk.net/Konsole Konsole] nachgeschlagen werden. | |||
Die Möglichkeiten und Abweichungen von der Standardkonfiguration sind vielfältig. Diese sollten aber nur dann durchgeführt werden, wenn der Durchführende genau weiß, was er da macht. Eine fehlerhaft Konfiguration kann zum Beispiel zu Störungen im Netzwerk führen und es könnten illegitime Maßnahmen implementiert werden. Beide zuvor genannten Beispiele würden zu einem Ausschluss aus unserem Netzwerk führen. Außerdem könnte das Gerät unbedienbar zerstört werden. Dennoch kann man gute Gründe haben die ein Abweichen von den Defaultwerten sinnvoll machen. | |||
== Antennen == | |||
=== externe Antennen === | |||
[[Datei:Beispiel externe Antennen.png|mini|600px|Beispiel_externe_Antennen.png]] | |||
Die meisten Router/Accesspoints haben abnehmbare Stabantennen mit SMA-Reverse Stecker mit Rundstrahlcharakteristik. | |||
Alternativ kann man einfach im Zubehör externe Antennen und Antennenkabel nachkaufen, die vielleicht leichter aufzustellen sind, oder eine Richtwirkung haben. | |||
Es gibt auch Füße mit Ösen für Schrauben und mit Magneten zur Problemlosen Montage. | |||
{| class="wikitable" | |||
|- | |||
| | |||
[[Datei:Antenne Magnetfuss mit Quad-Richtantenne.jpg|150px|mini|ohne|Magnetfuss mit Quad-Richtantenne]] | |||
|| | |||
[[Datei:Antenne Magnetfuss mit Stabantenne.jpg|270px|mini|ohne|Magnetfuss mit Löchern für Schraubmontage mit Stabantenne]] | |||
|| | |||
[[Datei:Antenne Richtantenne am Router.jpg|150px|mini|ohne| Quad-Richtantenne am Router]] | |||
|} | |||
=== Adapter für interne Antennen === | |||
Die Firma [http://Frixtender.de Frixtender.de] stellt sogennante Pigtails, "Schweineschwänzchen" , die es einem ermöglichen an Geräten an den internen Antennenanschlüssen oder Prüfanschlüssen Buchsen und somit auch externe Antennen anzuschließen. | |||
== Netztheorie/Technik und Entwicklung == | == Netztheorie/Technik und Entwicklung == | ||
Vertiefung | Vertiefung | ||
Zeile 10: | Zeile 51: | ||
== Arbeiten auf der Shell == | == Arbeiten auf der Shell == | ||
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell. | |||
Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ]. | |||
=== | <small> | ||
uci show # Parameter anzeigen mit Feldname | |||
uci get # Parameter anzeigen ohne Feldname | |||
uci set # Parameter setzen | |||
uci commit # speichern | |||
reboot # neustarten | |||
</small> | |||
=== gluon-info Informationen === | |||
Ab 2022.1 steht | |||
gluon-info | |||
zur Verfügung und zeigt... | |||
nichts anderes als auf der Konfigurationsseite | |||
http://192.168.1.1/cgi-bin/config/admin/info | |||
wie | |||
Hostname: ffkbuu-08154711 | |||
MAC address: 1c:irgendwas:6e | |||
Hardware model: TP-Link TL-WA801ND v5 | |||
Gluon version / Site version: v2022.1-12-g9667075+ / 91af32c | |||
Firmware release: v2022.1-Wireguard | |||
Site: Freifunk KBU | |||
Public VPN key: n/a | |||
MAC zeigt die | |||
network.client.macaddr | |||
und | |||
network.local_node_dev.peer_macaddr | |||
=== Gluon Version === | |||
cat /lib/gluon/release | |||
Ab Gluon 2022.1 kann die mit gluon-info abgefragt werden | |||
=== Neustart in den Konfigurations-Modus === | |||
Manchmal ist es Notwendig in den Konfigurations-Modus zu starten. Dies beinhaltet die Weboberfläche des Systems zum ersten Einrichten eines Freifunk-Routers. Für gewöhnlich hält man ein paar Sekunden lang die Reset Taste gedrückt. | |||
An der SSH-Konsole kann man folgenden Befehl / folgende Befehle eingeben: | |||
==== neu ==== | |||
gluon-enter-setup-mode # ab gluon 2022.1 | |||
==== alt ==== | |||
uci set gluon-setup-mode.@setup_mode[0].enabled=1 | |||
uci commit gluon-setup-mode | |||
reboot | |||
=== Hood/Domain abfragen/setzen (Multidomain-Firmware) === | |||
==== Hood/Domain Abfragen ==== | |||
Ab der Multihood-Version vom Februar 2022 (gluon-ffkbu-v2021.1.2) kann (mit SSH an der Konsole) per | |||
<small>uci get gluon.core.domain</small> | |||
die Domain/Hood abgefragt werden, ältere Versionen geben einen Fehler aus. | |||
==== Hood/Domain Setzen ==== | |||
Mit | |||
<small>gluon-switch-domain ffkbu_hood_bonn</small> | |||
<small>gluon-switch-domain ffkbu_hood_umland</small> | |||
kann derzeit die zwischen Bonn und Umland gewählt werden. Köln kommt bald! – Ehrlich! | |||
Der Router wird automatisch neugestartet! (Kann mit "--no-reboot" dazwischen unterbunden werden.) | |||
Man kann natürlich auch weiterhin in den Konfigurationsmodus starten und die Konfigurationsoberfläche nutzen. | |||
=== IPv6 SSH === | |||
Ihr verbindet euch mit eurem router via | |||
<pre> | |||
ssh root@<Link-local Adresse des Nodes>%<interface> | |||
</pre> | |||
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden. | |||
=== Firmware aktualisieren === | |||
Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren. | |||
==== Kurzfassung ==== | |||
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels: | |||
<pre> | |||
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ | |||
ssh root@<Link-local Adresse des Nodes>%<interface> | |||
cd /tmp/ | |||
sysupgrade -i -b config.tar.gz | |||
sysupgrade -v -f config.tar.gz firmware.bin & | |||
</pre> | |||
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt. | |||
Für die Details, einfach weiter lesen. ;) | |||
Für updates auf die neuste 2017-10 lede basierte gluon firmware sollte man die -sysupgrade variante nehmen und dann nicht "-f config.tar.gz" verwenden, weil der Router dann ggf. in den Config-Mode bootet nach dem update. Das kann unerwünscht sein, wenn man nur remote-Zugriff auf den Router hat. Durch die Wahl der -sysupgrade variante bleiben trotzdem alle Konfigurationen (Nodename, ssh-pw, geocorrds, Kontaktinfo usw) erhalten. Getestet auf v9 und v11 beim wr841 von einer 2016er gluon-Version aus. Das sieht dann so aus: | |||
<pre> | |||
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ | |||
ssh root@<Link-local Adresse des Nodes>%<interface> | |||
cd /tmp/ | |||
sysupgrade -v firmware.bin & | |||
</pre> | |||
==== Sysupgrade unter beibehaltung der Einstellungen ==== | |||
Für diese Variante kann das -sysupgrade.bin image verwendet werden, es muss sich aber um ein "kompatibles" upgrade, d.h. innerhalb einer hood und zwischen nicht zu unterschiedlichen Versionen handeln. | |||
1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen. | |||
2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].) | |||
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk]. | |||
3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code> | |||
4. sysupgrade starten. | |||
<pre> | |||
cd /tmp/ | |||
sysupgrade -v firmware.bin | |||
</pre> | |||
5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;) | |||
==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ==== | |||
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels | |||
<pre> | |||
sysupgrade -n firmware.bin | |||
</pre> | |||
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per | |||
<pre> | |||
sysupgrade -i firmware.bin | |||
</pre> | |||
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) ) | |||
Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig). | |||
In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen | |||
<pre> | |||
/etc/dropbear/authorized_keys | |||
/etc/dropbear/dropbear_dss_host_key | |||
/etc/dropbear/dropbear_rsa_host_key | |||
/etc/config/gluon-node-info | |||
/etc/config/system | |||
</pre> | |||
erstellen und per <code>tar -cz config > config.tar.gz</code> packen. | |||
Das gleiche erreicht man "interaktiv" per | |||
<code> | |||
sysupgrade -i -b config.tar.gz | |||
</code>. | |||
Danach kann man mittels | |||
<pre> | |||
sysupgrade -v -f config.tar.gz firmware.bin & | |||
</pre> | |||
das ganze unbeaufsichtigt laufen lassen. | |||
==== TFTP ==== | |||
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;) | |||
* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/]) | |||
<pre> | |||
sudo apt-get install tftpd-hpa tftp | |||
sudo chown -R tftp /srv/tftp/ | |||
</pre> | |||
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage]. | |||
<pre> | <pre> | ||
vim /etc/default/tftpd-hpa | |||
TFTP_USERNAME="tftp" | |||
TFTP_DIRECTORY="/srv/tftp" | |||
TFTP_ADDRESS="0.0.0.0:69" | |||
TFTP_OPTIONS="-s -c" | |||
service tftpd-hpa restart | |||
</pre> | </pre> | ||
* Dann muss man noch herausfinden, auf welcher IP der Router nach welchem Dateinamen fragt. Eine gute Quelle ist openWRT, z.B. für den beliebten tl-wr841n finden sich die Infos je nach Version [http://wiki.openwrt.org/toh/tp-link/tl-wr841nd#tftp_recovery_via_bootloader_for_v8_v9_v10_v11 hier]. | |||
Falls noch Fragen offen bleiben, [https://www.freifunk-bingen.de/forum/hilfe-unterst%C3%BCtzung/flashen-eines-gebrickten-tp-link-routers-tftp die $Anderen wissen auch was]. ;) | |||
=== Hostnamen ändern === | |||
Standardmäßig besteht der Hostname des Nodes aus dem Namen der Hood der MAC-Adresse des Routers. <br> | |||
: ''z.B.: ffkbuu-xyxyxyxyxyxy '' | |||
Diesen kann man individualisieren mit Ort oder laufender Nummer: | |||
: ''Bonn-Bahnhofstr-112 , Ponnyhof-Kleindorf-vorne , Notunterkunft-ff02'' | |||
Wenn man im Konfigurationsmodus Leerzeichen verwendet oder sonstige Zeichen die als "echter" Hostname nicht gebraucht werden können, erstellt die Firmware automatisch zwei Einträge: | |||
: system.@system[0].pretty_hostname='Musterstadt Musterweg' | |||
: system.@system[0].hostname='Musterstadt_Musterweg' | |||
(Man beachte das Leerzeichen bzw den Unterstrich!) | |||
oder aus | |||
"peters erstä rutä" | |||
macht die Firmware dann | |||
: system.@system[0].pretty_hostname='peters erstä rutä' | |||
: system.@system[0].hostname='peterserstrut' | |||
Möchte man den Hostnamen und den "pretty_hostname" per SSH und uci Befehl eigenständig ändern, so ist bei "hostname" der Syntax (nur ASCII-Zeichen, keine Umlaute,ect) zu beachten. | |||
<pre> | <pre> | ||
uci set system.@system[0].pretty_hostname='Musterstadt Musterweg' | |||
uci set system.@system[0].hostname='Musterstadt_Musterweg' | |||
uci commit system | |||
reboot | |||
</pre> | </pre> | ||
Der "pretty_hostname" muß nicht gesetzt werden. | |||
Der Hostname wird erst nach einem Neustart übernommen. Dies kann mit "reboot" an der Konsole ausgeführt werden | |||
Der "pretty_hostname" wird sofort übernommen, und bei der nächsten Kartenaktualisierung auch dort als Name des Routers angezeigt. | |||
= | Eigentlich gibt es den Befehl "pretty-hostname" dafür. Der ist eigentlich auch leichter anzuwenden, als | ||
"uci set system.@system[0].pretty_hostname=" davor zu setzen, bei Leerzeichen sind aber Anführungsstriche oder Hochkommas nicht zu vergessen! | |||
: pretty-hostname "Peters Router" | |||
Die Abfrage mit dem Befehl "pretty-hostname" gibt diesen, aber nicht den Hostnamen aus. | |||
<pre> | |||
root@petersertrut $ pretty-hostname | |||
peters erstä rutä | |||
root@petersertrut $ | |||
</pre> | |||
=== IPv6 ping === | |||
<pre> | <pre> | ||
ping6 <Link-lokale Adresse des Nodes>%<interface> | |||
</pre> | </pre> | ||
Siehe [[#IPv6_SSH]]. | |||
=== Authentifizierung === | |||
==== Passwort ändern ==== | |||
Das funktioniert wie in jedem Unix: | |||
''' | root@kbu-Windeck-01:~# '''passwd''' | ||
Changing password for root | |||
New password: '''''{na, hier gebt ihr das Passwort ein, und es wird nicht angezeigt, nichts!}''''' | |||
Retype password: '''''{nochmal eingeben}''''' | |||
passwd: password for root changed by root | |||
root@kbu-Windeck-01:~# | |||
==== | ==== Passwort-Authentifizierung abstellen ==== | ||
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt). | |||
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern: | |||
<pre>config dropbear | |||
option PasswordAuth 'off' | |||
option RootPasswordAuth 'off' | |||
option Port '22' | |||
# option BannerFile '/etc/banner'</pre> | |||
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen. | |||
==== SSH public key auf Node aufspielen ==== | |||
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert. | |||
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren: | |||
<pre> | <pre> | ||
scp -6 | scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys | ||
ssh root@< | </pre> | ||
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen: | |||
<pre> | |||
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>/etc/dropbear/authorized_keys' | |||
</pre> | </pre> | ||
Sollte beim Kopierversuch die Meldung | |||
<pre>ssh: Could not resolve hostname fe80:</pre> | |||
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen. | |||
==== NTP-Bug in Firmware 1.2.1b beseitigen ==== | |||
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben: | |||
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht: | |||
<pre>config timeserver 'ntp' | |||
list server '2a03:4000:2:494::2' | |||
list server '2a01:4f8:161:2461:e4::1' | |||
list server '2a02:180:1:1::551f:bb4b' | |||
option enabled '1' | |||
option enable_server '0'</pre> | |||
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam. | |||
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen. | |||
=== LAN Kopplung === | === LAN Kopplung === | ||
Eine LAN Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN fähigen Switch und eine bestehende | Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen. | ||
==== TL-WR841ND ==== | ==== TL-WR841ND ==== | ||
03/2014: Hier wird über | 03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1. | ||
''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware | 05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 . | ||
# | |||
# | ''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen: | ||
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0). | |||
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird. | |||
Zeile 86: | Zeile 360: | ||
config interface 'freifunk' | config interface 'freifunk' | ||
option ifname 'bat0' #LAN-Kopplung: ifname eth1 entfernt | option ifname 'bat0' #LAN-Kopplung: ifname eth1 (bzw. eth0, s.o.) entfernt | ||
option type 'bridge' | option type 'bridge' | ||
option proto 'none' | option proto 'none' | ||
Zeile 105: | Zeile 379: | ||
config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt | config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt | ||
option ifname 'eth1' | option ifname 'eth0' # ab TL-841N(D) v9: eth0, bis v8: eth1 . Bei falschem Interface läuft das mesh-lan über den blauen Port. Wer's mag... | ||
option proto 'batadv' | option proto 'batadv' | ||
option mesh 'bat0' | option mesh 'bat0' | ||
Zeile 111: | Zeile 385: | ||
''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional) | ''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional) | ||
<pre> | <pre> | ||
#config wifi-iface 'wifi_mesh' | #config wifi-iface 'wifi_mesh' | ||
Zeile 178: | Zeile 452: | ||
option proto 'batadv' | option proto 'batadv' | ||
option mesh 'bat0' | option mesh 'bat0' | ||
</pre> | |||
==== Router mit GLUON vollständig zurücksetzen (Factory Reset) ==== | |||
Folgende Schritte setzen einen auf GLUON basierenden Freifunkknoten auf den Zustand zurück, als dieser erstmals von der Stock-Firmware geflasht worden ist. | |||
<ref>[https://forum.freifunk.net/t/vollstandiger-reset-von-gluon/4395 Vollständiger reset von gluon]</ref> | |||
<ref>[https://wiki.bremen.freifunk.net/Anleitungen/SSH-Node-Verwaltung#node-zur%C3%BCcksetzen SSH-Node-Verwaltung]</ref> | |||
# Auf die Kommandozeile der Routers mittels SSH verbinden (s.o.). | |||
# Den Befehl <code>firstboot</code> eingeben und mit Enter bestätigen (damit wird die Overlay-Partition formatiert). | |||
# Anschließende die Sicherheitsabfrage mit <code>y</code> bestätigen. '''ACHTUNG:''' Wirklich ALLE Einstellungen werden gelöscht! | |||
# Abschließend den Router mit dem Befehl <code>reboot</code> neustarten, woraufhin der Router in den Config-Modus neu startet. | |||
'''HINWEIS:''' Nach dem Zurücksetzen generiert der Router einen neuen VPN-Key! | |||
=== Clientnetz an-/abschalten === | |||
[https://wiki.freifunk.net/Konsole#Clientnetz_zeitgesteuert_an-.2Fabschalten Zeitgesteuert (wiki.freifunk.net)] oder manuell mal eben den Zugang ausschalten... ? | |||
client0 = Freifunk Zugang 2,4 GHz | |||
client1 = Freifunk Zugang 5 GHz | |||
primary0 = Privates WLAN | |||
... | |||
ifconfig client0 down | |||
ifconfig client0 up | |||
</ | === Farbiger Prompt === | ||
(wurde in die Firmware 2022.1.1 eingebaut) | |||
[[Datei:Farbiger-prompt.png|mini|rechts|alternativtext=Screenshot Farbiger Prompt|Screenshot Farbiger Prompt]] | |||
Allgemein wird mit \033[ die Farbe eingeleitet und mit m beendet, muss jedoch in Eckige klammern gesetzt und die noch escaped, mit einem Backslash versehen werden. Dazwischen befinden sich die Parameter \u für aktueller User, \h aktueller Hostname, $PWD das aktuelle Verzeichnis und das Shell-Zeichen $ wechelt zu # automatisch wenn die UID 0 ist (root). Man könnte /w statt $PWD benutzen, dann wird im eigenen Home-Verzeichnis nicht dieses ausgeschrieben sondern mit einer Tilde ~ abgekürzt. | |||
[https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit ANSI escape code] {en} | |||
==== echo Befehl ==== | |||
Mit | |||
echo "PS1='\[\033[38;5;199;1m\]\h \[\033[38;5;227;1m\]\$PWD\[\033[0m\] \[\033[38;5;199;1m\]\$\[\033[0m\] '" >.profile | |||
wird im /root die Datei .profile erstellt und <br> | |||
der Eintrag ''PS1='\[\033[38;5;199;1m\]\h \[\033[38;5;227;1m\]$PWD\[\033[0m\] \[\033[38;5;199;1m\]$\[\033[0m\] ''' eintragen. | |||
(Achtung: beim echo Befehl muss $PWD mit \ escaped werden, da sonst der aktuelle Wert ''/root'' genommen wird, und suggeriert dass man immer im Verzeichnis /root ist.) | |||
Dies ist einfach nach einem Login mit copy&paste durchführbar. | |||
==== profile-Datei bearbeiten ==== | |||
Alternativ kann man mit dem Editor ''vi'' in der Datei ''/etc/profile'' die Zeilen | |||
... | |||
case "$TERM" in | |||
xterm*|rxvt*) | |||
export PS1='\[\e]0;\u@\h: \w\a\]'$PS1 | |||
;; | |||
esac | |||
... | |||
ungefähr so anpassen: | |||
... | |||
case "$TERM" in | |||
xterm*|rxvt*) | |||
# export PS1='\[\e]0;\u@\h: \w\a\]'$PS1 | |||
export PS1='\[\033[31;1m\]\h \[\033[32;1m\]$PWD\[\033[0m\] \[\033[31m\]\$\[\033[0m\] ' | |||
;; | |||
esac | |||
... | |||
==== Aus der Ferne ==== | |||
Unter Linux oder auf einem Freifunk-Router mit | |||
echo "PS1='\[\033[31;1m\]\h \[\033[32;1m\]\$PWD\[\033[0m\] \[\033[31m\]\$\[\033[0m\] '" >/tmp/ffprofile | |||
eine temporäre Datei anlegen und mit | |||
scp /tmp/ffprofile freifunkrouter01:.profile | |||
scp /tmp/ffprofile freifunkrouter02:.profile | |||
scp /tmp/ffprofile freifunkrouter03:.profile | |||
... | |||
auf die verschiedenen Freifunk-Router kopieren. | |||
Wenn lokal auf dem Freifunk-Router schon eine .profile Datei existiert, dann nur noch | |||
scp .ffprofile freifunkrouter01:.profile | |||
==== Andere Farben ==== | |||
[[Datei:Screenshot-promptinfarbe.png|mini]] | |||
Oben genannte Farben sind ... Hellrot (31;1), Hellgrün (32;1) und Rot (32) ...für... Host, Verzeichnis, Prompt. | |||
Für unsere Freifunkfarben kann man Magenta, Gelb, Magenta aus der 16er Palette | |||
PS1='\[\033[35;1m\]\h \[\033[33;1m\]$PWD\[\033[0m\] \[\033[35;1m\]$\[\033[0m\] ' | |||
oder aus der 256er Palette nehmen: | |||
PS1='\[\033[38;5;199;1m\]\h \[\033[38;5;227;1m\]$PWD\[\033[0m\] \[\033[38;5;199;1m\]\$\[\033[0m\] ' | |||
Einfach obige Zeile an der Konsole eingeben und ausprobieren! | |||
Die Farben kann man im [https://tldp.org/HOWTO/Bash-Prompt-HOWTO/x329.html Bash-Prompt-HOWTO auf tldp.org] oder im | |||
[https://techgoat.net/index.php?id=119 Artikel Farben im Linux-Terminal auf techgoat.net] nachlesen | |||
== Einsperren des Freifunk-Routers in eine DMZ == | == Einsperren des Freifunk-Routers in eine DMZ == | ||
Wer seinen Freifunk-Router einsperren und/oder die Bandbreite begrenzen möchte, kann dies am einfachsten tun, indem er ihn an seiner Firewall an einen eigenen Netzwerkport klemmt und diesen dann als DMZ konfiguriert. Ein KBU-Freifunk-Router | Wer seinen Freifunk-Router einsperren und/oder die Bandbreite begrenzen möchte, kann dies am einfachsten tun, indem er ihn an seiner Firewall an einen eigenen Netzwerkport klemmt und diesen dann als DMZ konfiguriert. Ein KBU-Freifunk-Router muss zur Zeit im LAN DHCP, DNS, im Internet NTP sowie mit den [[fastd]]-Knoten reden können. Folgendes Bespiel für eine iptables-Firewall nimmt an, dass der Freifunk-Router über eth2 angeschlossen ist: | ||
# eth2 darf nur | # eth2 darf nur DNS, NTP, DHCP und ansonsten mit den fastdX reden | ||
iptables -i eth2 -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT | iptables -i eth2 -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT | ||
iptables -i eth2 -A FORWARD -p udp --dport 67:68 --sport 67:68 -j ACCEPT | iptables -i eth2 -A FORWARD -p udp --dport 67:68 --sport 67:68 -j ACCEPT | ||
iptables -i eth2 -A INPUT -p udp --dport 53 -j ACCEPT | iptables -i eth2 -A INPUT -p udp --dport 53 -j ACCEPT | ||
iptables -i eth2 -A INPUT -p tcp --dport 53 -j ACCEPT | iptables -i eth2 -A INPUT -p tcp --dport 53 -j ACCEPT | ||
iptables -i eth2 -A INPUT -p | iptables -i eth2 -A INPUT -p udp --dport 123 -j ACCEPT | ||
iptables -i eth2 -A FORWARD -p udp --dport 53 -j ACCEPT | iptables -i eth2 -A FORWARD -p udp --dport 53 -j ACCEPT | ||
iptables -i eth2 -A FORWARD -p tcp --dport 53 -j ACCEPT | iptables -i eth2 -A FORWARD -p tcp --dport 53 -j ACCEPT | ||
iptables -i eth2 -A FORWARD -p | iptables -i eth2 -A FORWARD -p udp --dport 123 -j ACCEPT | ||
iptables -i eth2 -A FORWARD --dst 176.9.41.253 -j ACCEPT | iptables -i eth2 -A FORWARD --dst 176.9.41.253 -j ACCEPT | ||
iptables -i eth2 -A FORWARD --src 176.9.41.253 -j ACCEPT | iptables -i eth2 -A FORWARD --src 176.9.41.253 -j ACCEPT | ||
Zeile 208: | Zeile 567: | ||
iptables -i eth2 -A INPUT -j DROP | iptables -i eth2 -A INPUT -j DROP | ||
iptables -i eth2 -A FORWARD -j DROP | iptables -i eth2 -A FORWARD -j DROP | ||
# eth2 darf maximal 2000 kbit/s ein- und ausgehenden | # eth2 darf maximal 2000 kbit/s ein- und ausgehenden Traffic machen | ||
wondershaper eth2 2000 2000 | wondershaper eth2 2000 2000 | ||
Prinzipiell könnte man den Traffic noch weiter einschränken. DHCP und DNS müssen nur zum DHCP- bzw. DNS-Server funktionieren und der Traffic zu den fastd-Servern ließe sich auf TCP Port 80 und UDP Port 10000 begrenzen. | Prinzipiell könnte man den Traffic noch weiter einschränken. DHCP und DNS müssen nur zum DHCP- bzw. DNS-Server funktionieren, und der Traffic zu den fastd-Servern ließe sich auf TCP-Port 80 und UDP-Port 10000 begrenzen. | ||
===Alternative: Einsperren im VLAN=== | |||
siehe: [[FF-Router einsperren im VLAN]] | |||
== Weboberfläche aktivieren == | |||
Im Normalbetrieb ist erst mal kein Zugriff notwendig (und auch erst mal nicht vorgesehen). Das läuft einfach! ;-) Und es gibt im Normalbetrieb eben auch keine Weboberfläche, welches Sicherheitslücken haben könnte. | |||
Zum ersten Konfigurieren schaltet mal den Router in einen Konfig-Modus. Der Router nimmt dann in diesem Modus nicht mehr am Freifunknetzwerk teil. Nun kann man dann Rechner an die LAN-Ports des Freifunkrouters anschließen und über eine Weboberfläche per Browser den Router konfigurieren oder updaten. Das sollte aber nur ganz selten notwendig sein. Nach einem Reboot des Routers geht das Gerät dann wieder in den Freifunk-Modus mit deinen Konfigurationsänderungen. | |||
Wenn man Spaß am Basteln hat, kann man die Weboberfläche aber auch im Normalbetrieb aktivieren. Für die Absicherung muss man dann aber selber sorgen, denn standardmäßig ist das nicht abgesichert. Hier die Anleitung nach [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen: | |||
Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über [https://map.kbu.freifunk.net/ die Karte] oder per [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] via | |||
Die generelle IPv6-Adresse erfährt man durch Eingabe von | |||
ifconfig | grep Global | |||
Die IPv6-Adresse ("inet6 adr") kann man nun im Browser in eckigen Klammern und vorangestelltem "http://" aufrufen (zum Beispiel: http://[2001:67c:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]/) und gelangt so zur Weboberfläche LuCI. | |||
Falls der Router nicht per IPv6 http liefern sollte, kann man das per SSH beheben. Dazu folgendes nach dem Login auf der Shell vom Router ausführen: | |||
uci delete uhttpd.main.listen_http | |||
uci delete uhttpd.main.listen_https | |||
uci add_list uhttpd.main.listen_http='[::]:80' | |||
uci add_list uhttpd.main.listen_http='0.0.0.0:80' | |||
uci add_list uhttpd.main.listen_https='[::]:80' | |||
uci add_list uhttpd.main.listen_https='0.0.0.0:80' | |||
uci commit uhttpd | |||
/etc/init.d/uhttpd enable | |||
== Uplink mit Android-Tethering/USB Netzwerkkarte == | |||
(SSH-Zugangserfahrung nötig) | |||
Das ganze sei von Anfang an als "sportlich" zu betrachten. Leider sind mobile 3g-/LTE-Tarife fast ausnahmslos nach einem bestimmten Volumen gedrosselt (üblicherweise auf 64 bis 56 kbit/s (neuere NetzclubSim sogar auf 32 kbit/s), Ausnahme bilden hier nur "LTE Zuhause" "DSL" Ersatz Tarife -> 386kbit/s). | |||
Da Freifunk auch bei Nichtbenutzung Daten überträgt, ist nur bei "LTE Zuhause"-Tarifen interessant, dies als Dauerlösung zu nutzen. Dort ist aber wiederum meist ein LTE-Router vor Ort und man kann den Router auch "traditionell" via LAN Kabel anbinden. | |||
Bei Benutzung als Uplink bei Straßenfesten/Festivals etc. ist wahrscheinlich, dass erstens das Datenvolumen schnell aufgebraucht sein wird und zweitens ab einer bestimmten Größe auch das 3g-Netz vor Ort überlastet ist. Wenn man es dennoch machen will (mehrere Sim-Karten/spezieller hochvolumiger Tarif/vom Netzbetreiber gesponserter Uplink (träum)), sollte man die Benutzung von LTE erwägen. Auch dort könnten aber durch zukünftige Adapation Überlasterscheinungen auftreten. Desweitern nutzen 2g/3g/4g auch dasselbe Backbone, welcher dann auch für LTE ein Flaschenhals darstellt. | |||
Muss nochmal nachprüfen, aber wenn, dann nicht uninteressant: Der WLAN-Zugang des Telefons (CM7) wurde per Tethering weitergeleitet und bei Abschalten gab es fallback auf 3g -> nicht schöne, aber einfache "Immer"netzlösung? Mein Tablet zeigt nicht dieses Verhalten.) | |||
Eine ausführliche und fortgeschriebene Anleitung für Gluon für USB-Tethering und USB-3G-Dongle (UMTS-Stick) gibt es bei im Freifunk Rheinbach [http://wiki.freifunk-rheinbach.de Wiki] unter [http://wiki.freifunk-rheinbach.de/index.php/UMTS UMTS] und [http://wiki.freifunk-rheinbach.de/index.php/USB-Support USB-Support]. | |||
Blablabla, jetzt geht es los: | |||
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren: | |||
- Per SSH in den Router einloggen | |||
- Installieren der notwendigen Treiber | |||
<pre> | |||
opkg update | |||
opkg install kmod-usb-uhci kmod-usb-net-rndis | |||
</pre> | |||
Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!) | |||
- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu: | |||
<pre> | |||
config interface 'wan2' | |||
option ifname 'usb0' | |||
option proto 'dhcp' | |||
option type 'bridge' | |||
</pre> | |||
Auch unter LuCi sollte dies konfigurierbar sein. | |||
- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren. | |||
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten. | |||
<pre> | |||
ifup wan2 | |||
</pre> | |||
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache) | |||
== Zusätzlich zum Freifunk auch privates WLAN einrichten == | |||
Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.) | |||
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt. | |||
Das private WLAN kann per SSH in der Konsole aktiviert werden: | |||
<pre> | |||
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="$SSID" | |||
uci set wireless.wan_radio0.key="$KEY" | |||
uci set wireless.wan_radio0.disabled=0 | |||
uci commit | |||
wifi | |||
</pre> | |||
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden. | |||
Zum Deaktivieren des Ganzen wie folgt vorgehen: | |||
<pre> | |||
uci set wireless.wan_radio0.disabled=1 | |||
uci commit | |||
wifi | |||
</pre> | |||
== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse == | |||
Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten. | |||
Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst: | |||
<pre> | |||
#!/bin/ash | |||
FAILCOUNTFILE=/var/run/mesh0_failcount | |||
MAXFAILCOUNT=10 | |||
# check mesh connections with different originators and nexthops, MAC is 17 chars long | |||
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l` | |||
if [ $count -gt 1 ]; then ## more than a single mesh with itself is left | |||
echo 0 > $FAILCOUNTFILE | |||
else | |||
if [ -f $FAILCOUNTFILE ]; then | |||
read failcount < $FAILCOUNTFILE | |||
failcount=$(($failcount+1)) | |||
if [ $failcount -ge $MAXFAILCOUNT ]; then | |||
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"` | |||
sync | |||
reboot | |||
fi | |||
echo $failcount > $FAILCOUNTFILE | |||
else | |||
echo 1 > $FAILCOUNTFILE | |||
fi | |||
fi | |||
</pre> | |||
Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst: | |||
<pre> | |||
# batctl o | grep mesh0 | |||
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6) | |||
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8) | |||
</pre> | |||
Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so: | |||
<pre> | |||
#!/bin/ash | |||
FAILCOUNTFILE=/var/run/mesh0_failcount | |||
MAXFAILCOUNT=10 | |||
# check mesh connections with different originators and nexthops, MAC is 17 chars long | |||
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l` | |||
if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all? | |||
read failcount < $FAILCOUNTFILE # If it exist then there is a number in. | |||
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists | |||
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again! | |||
echo 0 > $FAILCOUNTFILE | |||
exit | |||
fi | |||
else # no nexthop different than originator exists | |||
failcount=$(($failcount+1)) | |||
if [ $failcount -ge $MAXFAILCOUNT ]; then | |||
echo 0 > $FAILCOUNTFILE # Reset counter before reboot | |||
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info | |||
sync | |||
reboot | |||
fi | |||
echo $failcount > $FAILCOUNTFILE | |||
fi | |||
else | |||
echo 0 > $FAILCOUNTFILE | |||
fi | |||
</pre> | |||
Das Script wird dann noch ausführbar gemacht: | |||
<pre> | |||
chmod +x /root/check_mesh.sh | |||
</pre> | |||
Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute: | |||
<pre> | |||
* * * * * /root/check_mesh.sh > /dev/null 2>&1 | |||
</pre> | |||
Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen. | |||
Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar: | |||
<pre> | |||
# ls -al | grep failcount | |||
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622 | |||
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812 | |||
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159 | |||
</pre> | |||
Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen. | |||
== Client-WLAN nachts automatisch ausstellen == | |||
In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet. | |||
<pre> | |||
#!/bin/ash | |||
STOP_HOUR=0 # needs to be smaller than START_HOUR!!! | |||
START_HOUR=7 # disable client0 network device if it's active | |||
# and hour is between STOP_HOUR and START_HOUR | |||
hour=`date +"%H"` | |||
ip addr list client0 > /dev/null 2>&1 | |||
if [ $? -eq 0 ]; then # client network is on | |||
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off | |||
uci set wireless.client_radio0.disabled=1 | |||
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600) | |||
uci commit wireless | |||
/etc/init.d/network restart | |||
fi | |||
else # client network is off | |||
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on | |||
uci set wireless.client_radio0.disabled=0 | |||
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600) | |||
uci commit wireless | |||
/etc/init.d/network restart | |||
fi | |||
fi | |||
</pre> | |||
Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute: | |||
<pre> | |||
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1 | |||
</pre> | |||
'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz... | |||
'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann): | |||
<pre> | |||
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1 | |||
</pre> | |||
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird. | |||
== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist == | |||
Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist. | |||
Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird: | |||
<pre> | |||
#!/bin/ash | |||
FAILCOUNTFILE=/var/run/mesh0_nogatewaycount | |||
MAXFAILCOUNT=2 | |||
# check mesh connections with different originators and nexthops, MAC is 17 chars long | |||
batctl gwl | grep -q "No gateways in range" | |||
no_gw=$? | |||
if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all? | |||
read failcount < $FAILCOUNTFILE # If it exist then there is a number in. | |||
if [ ${no_gw} -eq 1 ]; then # There is a gateway | |||
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount | |||
failcount=$(($failcount-1)) | |||
echo $failcount > $FAILCOUNTFILE | |||
if [ $failcount -eq 0 ]; then | |||
# turn on client network | |||
uci set wireless.client_radio0.disabled=0 | |||
uci commit wireless | |||
wifi | |||
fi | |||
exit | |||
fi | |||
else # no nexthop different than originator exists | |||
failcount=$(($failcount+1)) | |||
if [ $failcount -eq $MAXFAILCOUNT ]; then | |||
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info | |||
# turn off client network | |||
uci set wireless.client_radio0.disabled=1 | |||
uci commit wireless | |||
wifi | |||
fi | |||
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT | |||
echo $failcount > $FAILCOUNTFILE | |||
fi | |||
fi | |||
else | |||
echo 0 > $FAILCOUNTFILE | |||
fi | |||
</pre> | |||
Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute: | |||
<pre> | |||
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1 | |||
</pre> | |||
Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet. | |||
== Freifunk-Monitor: Router-Status per E-Mail == | |||
Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten. | |||
(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!) | |||
<pre> | |||
Hallo, Liebe Mitstreiter! | |||
Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen. | |||
Axel und ich möchten unseren Teil beitragen. | |||
Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen. | |||
Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche). | |||
Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen! | |||
Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch. | |||
Wie ihr das wieder abschaltet steht unten. | |||
--------------- | |||
Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile): | |||
echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit | |||
Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen): | |||
uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit | |||
Kommando zum E-Mail-Adresse prüfen: | |||
uci get gluon-node-info.@owner[0].contact | |||
Kommando zum Monitoring abschalten: | |||
uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit | |||
--------------- | |||
Frohes Freifunken, | |||
KaterMikesch & G3ntleman | |||
</pre> | |||
== Freifunk-Knoten von der Map entfernen == | |||
Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten. | |||
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten: | |||
1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren. | |||
2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen: | |||
... | |||
config location | |||
option share_location '0' | |||
... | |||
3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router: | |||
uci set gluon-node-info.@location[0].share_location=0 | |||
uci commit gluon-node-info | |||
In allen drei Fällen dann den Router nochmal ins Freifunk-Netz hängen (durchstarten) und ein paar Minuten warten, bis der dem Router zugeordnete Punkt mit dem Router-Namen beim nächsten Update der Map-Daten von der Karte verschwindet. | |||
<noinclude> | |||
<div style="text-align: center; background-color:#e135734d; font-weight: bold; padding: 1px;"> | |||
< [[Experteneinstellungen|Optional: Experteneinstellungen]] [[Mitmachen|Übersicht]] | |||
</div> | |||
</noinclude> |
Aktuelle Version vom 15. Januar 2023, 16:05 Uhr
Hier finden sich interessante Optionen für etwas versiertere Nutzer.
Diese Seite wurde größtenteils für die Classic Firmware geschrieben.
Wir - die KBU Gemeinschaft - stellen seit Jahren nur noch Firmware mit Gluon zur Verfügung (Image/Firmware-Server : https://images.ffkbu.de) , die originale Dokumentation ist in englisch auf http://gluon.readthedocs.org zu finden.
Weitere Befehle/Möglichkeiten können auch im übergreifenden Wiki von freifunk.net auf wiki.freifunk.net im Artikel Konsole nachgeschlagen werden.
Die Möglichkeiten und Abweichungen von der Standardkonfiguration sind vielfältig. Diese sollten aber nur dann durchgeführt werden, wenn der Durchführende genau weiß, was er da macht. Eine fehlerhaft Konfiguration kann zum Beispiel zu Störungen im Netzwerk führen und es könnten illegitime Maßnahmen implementiert werden. Beide zuvor genannten Beispiele würden zu einem Ausschluss aus unserem Netzwerk führen. Außerdem könnte das Gerät unbedienbar zerstört werden. Dennoch kann man gute Gründe haben die ein Abweichen von den Defaultwerten sinnvoll machen.
Antennen
externe Antennen
Die meisten Router/Accesspoints haben abnehmbare Stabantennen mit SMA-Reverse Stecker mit Rundstrahlcharakteristik.
Alternativ kann man einfach im Zubehör externe Antennen und Antennenkabel nachkaufen, die vielleicht leichter aufzustellen sind, oder eine Richtwirkung haben.
Es gibt auch Füße mit Ösen für Schrauben und mit Magneten zur Problemlosen Montage.
Adapter für interne Antennen
Die Firma Frixtender.de stellt sogennante Pigtails, "Schweineschwänzchen" , die es einem ermöglichen an Geräten an den internen Antennenanschlüssen oder Prüfanschlüssen Buchsen und somit auch externe Antennen anzuschließen.
Netztheorie/Technik und Entwicklung
Vertiefung
Arbeiten auf der Shell
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.
Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle .
uci show # Parameter anzeigen mit Feldname uci get # Parameter anzeigen ohne Feldname uci set # Parameter setzen uci commit # speichern reboot # neustarten
gluon-info Informationen
Ab 2022.1 steht
gluon-info
zur Verfügung und zeigt... nichts anderes als auf der Konfigurationsseite
http://192.168.1.1/cgi-bin/config/admin/info
wie
Hostname: ffkbuu-08154711 MAC address: 1c:irgendwas:6e Hardware model: TP-Link TL-WA801ND v5 Gluon version / Site version: v2022.1-12-g9667075+ / 91af32c Firmware release: v2022.1-Wireguard Site: Freifunk KBU Public VPN key: n/a
MAC zeigt die
network.client.macaddr
und
network.local_node_dev.peer_macaddr
Gluon Version
cat /lib/gluon/release
Ab Gluon 2022.1 kann die mit gluon-info abgefragt werden
Neustart in den Konfigurations-Modus
Manchmal ist es Notwendig in den Konfigurations-Modus zu starten. Dies beinhaltet die Weboberfläche des Systems zum ersten Einrichten eines Freifunk-Routers. Für gewöhnlich hält man ein paar Sekunden lang die Reset Taste gedrückt.
An der SSH-Konsole kann man folgenden Befehl / folgende Befehle eingeben:
neu
gluon-enter-setup-mode # ab gluon 2022.1
alt
uci set gluon-setup-mode.@setup_mode[0].enabled=1 uci commit gluon-setup-mode reboot
Hood/Domain abfragen/setzen (Multidomain-Firmware)
Hood/Domain Abfragen
Ab der Multihood-Version vom Februar 2022 (gluon-ffkbu-v2021.1.2) kann (mit SSH an der Konsole) per
uci get gluon.core.domain
die Domain/Hood abgefragt werden, ältere Versionen geben einen Fehler aus.
Hood/Domain Setzen
Mit
gluon-switch-domain ffkbu_hood_bonn gluon-switch-domain ffkbu_hood_umland
kann derzeit die zwischen Bonn und Umland gewählt werden. Köln kommt bald! – Ehrlich!
Der Router wird automatisch neugestartet! (Kann mit "--no-reboot" dazwischen unterbunden werden.)
Man kann natürlich auch weiterhin in den Konfigurationsmodus starten und die Konfigurationsoberfläche nutzen.
IPv6 SSH
Ihr verbindet euch mit eurem router via
ssh root@<Link-local Adresse des Nodes>%<interface>
Hierbei findet ihr die Link-local Adresse z.B. auf der Karte, es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise eth0
für den LAN Port und wlan0
fürs WLAN. Mit ifconfig
lässt sich das leicht herausfinden.
Firmware aktualisieren
Neben dem Upgrade per Config_Mode, für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe #TFTP um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.
Kurzfassung
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ ssh root@<Link-local Adresse des Nodes>%<interface> cd /tmp/ sysupgrade -i -b config.tar.gz sysupgrade -v -f config.tar.gz firmware.bin &
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt. Für die Details, einfach weiter lesen. ;)
Für updates auf die neuste 2017-10 lede basierte gluon firmware sollte man die -sysupgrade variante nehmen und dann nicht "-f config.tar.gz" verwenden, weil der Router dann ggf. in den Config-Mode bootet nach dem update. Das kann unerwünscht sein, wenn man nur remote-Zugriff auf den Router hat. Durch die Wahl der -sysupgrade variante bleiben trotzdem alle Konfigurationen (Nodename, ssh-pw, geocorrds, Kontaktinfo usw) erhalten. Getestet auf v9 und v11 beim wr841 von einer 2016er gluon-Version aus. Das sieht dann so aus:
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ ssh root@<Link-local Adresse des Nodes>%<interface> cd /tmp/ sysupgrade -v firmware.bin &
Sysupgrade unter beibehaltung der Einstellungen
Für diese Variante kann das -sysupgrade.bin image verwendet werden, es muss sich aber um ein "kompatibles" upgrade, d.h. innerhalb einer hood und zwischen nicht zu unterschiedlichen Versionen handeln.
1. Firmware_herunterladen und Signatur/Checksumme prüfen.
2. Firmware per scp auf den Router kopieren scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
. (Siehe #IPv6_SSH.)
Es ist wichtig die firmware nach /tmp
zu kopieren, das ist eine Ram disk.
3. Per ssh mit dem Router verbinden ssh root@<Link-local Adresse des Nodes>%<interface>
4. sysupgrade starten.
cd /tmp/ sysupgrade -v firmware.bin
5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)
Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.)
Bei einem Upgrade von einer inkompatiblen Version mittels sysupgrade
muss man normalerweise mittels
sysupgrade -n firmware.bin
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat sysupgrade
einen interaktiven Modus, den man per
sysupgrade -i firmware.bin
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )
Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).
In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
/etc/dropbear/authorized_keys /etc/dropbear/dropbear_dss_host_key /etc/dropbear/dropbear_rsa_host_key /etc/config/gluon-node-info /etc/config/system
erstellen und per tar -cz config > config.tar.gz
packen.
Das gleiche erreicht man "interaktiv" per
sysupgrade -i -b config.tar.gz
.
Danach kann man mittels
sysupgrade -v -f config.tar.gz firmware.bin &
das ganze unbeaufsichtigt laufen lassen.
TFTP
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [1] ;)
- TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [2])
sudo apt-get install tftpd-hpa tftp sudo chown -R tftp /srv/tftp/
- Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der manpage.
vim /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="-s -c" service tftpd-hpa restart
- Dann muss man noch herausfinden, auf welcher IP der Router nach welchem Dateinamen fragt. Eine gute Quelle ist openWRT, z.B. für den beliebten tl-wr841n finden sich die Infos je nach Version hier.
Falls noch Fragen offen bleiben, die $Anderen wissen auch was. ;)
Hostnamen ändern
Standardmäßig besteht der Hostname des Nodes aus dem Namen der Hood der MAC-Adresse des Routers.
- z.B.: ffkbuu-xyxyxyxyxyxy
Diesen kann man individualisieren mit Ort oder laufender Nummer:
- Bonn-Bahnhofstr-112 , Ponnyhof-Kleindorf-vorne , Notunterkunft-ff02
Wenn man im Konfigurationsmodus Leerzeichen verwendet oder sonstige Zeichen die als "echter" Hostname nicht gebraucht werden können, erstellt die Firmware automatisch zwei Einträge:
- system.@system[0].pretty_hostname='Musterstadt Musterweg'
- system.@system[0].hostname='Musterstadt_Musterweg'
(Man beachte das Leerzeichen bzw den Unterstrich!) oder aus "peters erstä rutä" macht die Firmware dann
- system.@system[0].pretty_hostname='peters erstä rutä'
- system.@system[0].hostname='peterserstrut'
Möchte man den Hostnamen und den "pretty_hostname" per SSH und uci Befehl eigenständig ändern, so ist bei "hostname" der Syntax (nur ASCII-Zeichen, keine Umlaute,ect) zu beachten.
uci set system.@system[0].pretty_hostname='Musterstadt Musterweg' uci set system.@system[0].hostname='Musterstadt_Musterweg' uci commit system reboot
Der "pretty_hostname" muß nicht gesetzt werden.
Der Hostname wird erst nach einem Neustart übernommen. Dies kann mit "reboot" an der Konsole ausgeführt werden
Der "pretty_hostname" wird sofort übernommen, und bei der nächsten Kartenaktualisierung auch dort als Name des Routers angezeigt.
Eigentlich gibt es den Befehl "pretty-hostname" dafür. Der ist eigentlich auch leichter anzuwenden, als "uci set system.@system[0].pretty_hostname=" davor zu setzen, bei Leerzeichen sind aber Anführungsstriche oder Hochkommas nicht zu vergessen!
- pretty-hostname "Peters Router"
Die Abfrage mit dem Befehl "pretty-hostname" gibt diesen, aber nicht den Hostnamen aus.
root@petersertrut $ pretty-hostname peters erstä rutä root@petersertrut $
IPv6 ping
ping6 <Link-lokale Adresse des Nodes>%<interface>
Siehe #IPv6_SSH.
Authentifizierung
Passwort ändern
Das funktioniert wie in jedem Unix:
root@kbu-Windeck-01:~# passwd Changing password for root New password: {na, hier gebt ihr das Passwort ein, und es wird nicht angezeigt, nichts!} Retype password: {nochmal eingeben} passwd: password for root changed by root root@kbu-Windeck-01:~#
Passwort-Authentifizierung abstellen
Wichtig: Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt). Falls das erfolgreich funktioniert, kann man die Datei /etc/config/dropbear wie folgt ändern:
config dropbear option PasswordAuth 'off' option RootPasswordAuth 'off' option Port '22' # option BannerFile '/etc/banner'
Nach einem Neustart des Routers mittels reboot sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.
SSH public key auf Node aufspielen
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert. Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. ACHTUNG: Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>/etc/dropbear/authorized_keys'
Sollte beim Kopierversuch die Meldung
ssh: Could not resolve hostname fe80:
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels reboot übernommen.
NTP-Bug in Firmware 1.2.1b beseitigen
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben: Editiert wird die Datei /etc/config/system. Dort findet man einen Eintrag config timeserver 'ntp'. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
config timeserver 'ntp' list server '2a03:4000:2:494::2' list server '2a01:4f8:161:2461:e4::1' list server '2a02:180:1:1::551f:bb4b' option enabled '1' option enable_server '0'
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels reboot wirksam. Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.
LAN Kopplung
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.
TL-WR841ND
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.
05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .
vim /etc/config/network - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
- Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
- Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'wan' option ifname 'eth0' option proto 'dhcp' option type 'bridge' option accept_ra '0' option auto '1' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '0 1 2 3 4' config interface 'freifunk' option ifname 'bat0' #LAN-Kopplung: ifname eth1 (bzw. eth0, s.o.) entfernt option type 'bridge' option proto 'none' option auto '1' option accept_ra '1' option macaddr '10:fe:ed:f1:53:84' config interface 'mesh' option proto 'batadv' option mtu '1528' option mesh 'bat0' config interface 'mesh_vpn' option ifname 'mesh-vpn' option proto 'batadv' option mesh 'bat0' option macaddr '12:fe:ed:f2:53:84' config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt option ifname 'eth0' # ab TL-841N(D) v9: eth0, bis v8: eth1 . Bei falschem Interface läuft das mesh-lan über den blauen Port. Wer's mag... option proto 'batadv' option mesh 'bat0'
vim /etc/config/wireless - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
#config wifi-iface 'wifi_mesh' # option device 'radio0' # option network 'mesh' # option mode 'adhoc' # option ssid '02:d1:11:37:fc:39' # option bssid '02:d1:11:37:fc:39
TL-WDR4300
Das gleiche nochmal für den 4300er
vim /etc/config/network
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' option type 'bridge' option accept_ra '0' option auto '1' option macaddr 'a2:f3:c1:65:81:cd' config switch option name 'eth0' option reset '1' option enable_vlan '1' config switch_vlan option device 'eth0' option vlan '1' option ports '0t 2 3 4 5' config switch_vlan option device 'eth0' option vlan '2' option ports '0t 1' config interface 'freifunk' option ifname 'bat0' #LAN-Kopplung: ifname eth0.1 entfernt option type 'bridge' option proto 'none' option auto '1' option accept_ra '1' option macaddr 'a0:f3:c1:64:81:cc' config interface 'mesh' option proto 'batadv' option mtu '1528' option mesh 'bat0' config interface 'mesh_vpn' option ifname 'mesh-vpn' option proto 'batadv' option mesh 'bat0' option macaddr 'a2:f3:c1:65:81:cc' config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt option ifname 'eth0.1' option proto 'batadv' option mesh 'bat0'
Router mit GLUON vollständig zurücksetzen (Factory Reset)
Folgende Schritte setzen einen auf GLUON basierenden Freifunkknoten auf den Zustand zurück, als dieser erstmals von der Stock-Firmware geflasht worden ist. [1] [2]
- Auf die Kommandozeile der Routers mittels SSH verbinden (s.o.).
- Den Befehl
firstboot
eingeben und mit Enter bestätigen (damit wird die Overlay-Partition formatiert). - Anschließende die Sicherheitsabfrage mit
y
bestätigen. ACHTUNG: Wirklich ALLE Einstellungen werden gelöscht! - Abschließend den Router mit dem Befehl
reboot
neustarten, woraufhin der Router in den Config-Modus neu startet.
HINWEIS: Nach dem Zurücksetzen generiert der Router einen neuen VPN-Key!
Clientnetz an-/abschalten
Zeitgesteuert (wiki.freifunk.net) oder manuell mal eben den Zugang ausschalten... ?
client0 = Freifunk Zugang 2,4 GHz client1 = Freifunk Zugang 5 GHz primary0 = Privates WLAN
...
ifconfig client0 down ifconfig client0 up
Farbiger Prompt
(wurde in die Firmware 2022.1.1 eingebaut)
Allgemein wird mit \033[ die Farbe eingeleitet und mit m beendet, muss jedoch in Eckige klammern gesetzt und die noch escaped, mit einem Backslash versehen werden. Dazwischen befinden sich die Parameter \u für aktueller User, \h aktueller Hostname, $PWD das aktuelle Verzeichnis und das Shell-Zeichen $ wechelt zu # automatisch wenn die UID 0 ist (root). Man könnte /w statt $PWD benutzen, dann wird im eigenen Home-Verzeichnis nicht dieses ausgeschrieben sondern mit einer Tilde ~ abgekürzt.
ANSI escape code {en}
echo Befehl
Mit
echo "PS1='\[\033[38;5;199;1m\]\h \[\033[38;5;227;1m\]\$PWD\[\033[0m\] \[\033[38;5;199;1m\]\$\[\033[0m\] '" >.profile
wird im /root die Datei .profile erstellt und
der Eintrag PS1='\[\033[38;5;199;1m\]\h \[\033[38;5;227;1m\]$PWD\[\033[0m\] \[\033[38;5;199;1m\]$\[\033[0m\] ' eintragen.
(Achtung: beim echo Befehl muss $PWD mit \ escaped werden, da sonst der aktuelle Wert /root genommen wird, und suggeriert dass man immer im Verzeichnis /root ist.)
Dies ist einfach nach einem Login mit copy&paste durchführbar.
profile-Datei bearbeiten
Alternativ kann man mit dem Editor vi in der Datei /etc/profile die Zeilen
... case "$TERM" in xterm*|rxvt*) export PS1='\[\e]0;\u@\h: \w\a\]'$PS1 ;; esac ...
ungefähr so anpassen:
... case "$TERM" in xterm*|rxvt*) # export PS1='\[\e]0;\u@\h: \w\a\]'$PS1 export PS1='\[\033[31;1m\]\h \[\033[32;1m\]$PWD\[\033[0m\] \[\033[31m\]\$\[\033[0m\] ' ;; esac ...
Aus der Ferne
Unter Linux oder auf einem Freifunk-Router mit
echo "PS1='\[\033[31;1m\]\h \[\033[32;1m\]\$PWD\[\033[0m\] \[\033[31m\]\$\[\033[0m\] '" >/tmp/ffprofile
eine temporäre Datei anlegen und mit
scp /tmp/ffprofile freifunkrouter01:.profile scp /tmp/ffprofile freifunkrouter02:.profile scp /tmp/ffprofile freifunkrouter03:.profile ...
auf die verschiedenen Freifunk-Router kopieren.
Wenn lokal auf dem Freifunk-Router schon eine .profile Datei existiert, dann nur noch
scp .ffprofile freifunkrouter01:.profile
Andere Farben
Oben genannte Farben sind ... Hellrot (31;1), Hellgrün (32;1) und Rot (32) ...für... Host, Verzeichnis, Prompt.
Für unsere Freifunkfarben kann man Magenta, Gelb, Magenta aus der 16er Palette
PS1='\[\033[35;1m\]\h \[\033[33;1m\]$PWD\[\033[0m\] \[\033[35;1m\]$\[\033[0m\] '
oder aus der 256er Palette nehmen:
PS1='\[\033[38;5;199;1m\]\h \[\033[38;5;227;1m\]$PWD\[\033[0m\] \[\033[38;5;199;1m\]\$\[\033[0m\] '
Einfach obige Zeile an der Konsole eingeben und ausprobieren!
Die Farben kann man im Bash-Prompt-HOWTO auf tldp.org oder im Artikel Farben im Linux-Terminal auf techgoat.net nachlesen
Einsperren des Freifunk-Routers in eine DMZ
Wer seinen Freifunk-Router einsperren und/oder die Bandbreite begrenzen möchte, kann dies am einfachsten tun, indem er ihn an seiner Firewall an einen eigenen Netzwerkport klemmt und diesen dann als DMZ konfiguriert. Ein KBU-Freifunk-Router muss zur Zeit im LAN DHCP, DNS, im Internet NTP sowie mit den fastd-Knoten reden können. Folgendes Bespiel für eine iptables-Firewall nimmt an, dass der Freifunk-Router über eth2 angeschlossen ist:
# eth2 darf nur DNS, NTP, DHCP und ansonsten mit den fastdX reden iptables -i eth2 -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -i eth2 -A INPUT -p udp --dport 53 -j ACCEPT iptables -i eth2 -A INPUT -p tcp --dport 53 -j ACCEPT iptables -i eth2 -A INPUT -p udp --dport 123 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 53 -j ACCEPT iptables -i eth2 -A FORWARD -p tcp --dport 53 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 123 -j ACCEPT iptables -i eth2 -A FORWARD --dst 176.9.41.253 -j ACCEPT iptables -i eth2 -A FORWARD --src 176.9.41.253 -j ACCEPT iptables -i eth2 -A FORWARD --dst 178.63.59.41 -j ACCEPT iptables -i eth2 -A FORWARD --src 178.63.59.41 -j ACCEPT iptables -i eth2 -A FORWARD --dst 37.120.169.214 -j ACCEPT iptables -i eth2 -A FORWARD --src 37.120.169.214 -j ACCEPT iptables -i eth2 -A FORWARD --dst 37.221.195.47 -j ACCEPT iptables -i eth2 -A FORWARD --src 37.221.195.47 -j ACCEPT iptables -i eth2 -A FORWARD --dst 78.46.68.75 -j ACCEPT iptables -i eth2 -A FORWARD --src 78.46.68.75 -j ACCEPT iptables -i eth2 -A FORWARD --dst 84.201.35.206 -j ACCEPT iptables -i eth2 -A FORWARD --src 84.201.35.206 -j ACCEPT iptables -i eth2 -A INPUT -j DROP iptables -i eth2 -A FORWARD -j DROP # eth2 darf maximal 2000 kbit/s ein- und ausgehenden Traffic machen wondershaper eth2 2000 2000
Prinzipiell könnte man den Traffic noch weiter einschränken. DHCP und DNS müssen nur zum DHCP- bzw. DNS-Server funktionieren, und der Traffic zu den fastd-Servern ließe sich auf TCP-Port 80 und UDP-Port 10000 begrenzen.
Alternative: Einsperren im VLAN
siehe: FF-Router einsperren im VLAN
Weboberfläche aktivieren
Im Normalbetrieb ist erst mal kein Zugriff notwendig (und auch erst mal nicht vorgesehen). Das läuft einfach! ;-) Und es gibt im Normalbetrieb eben auch keine Weboberfläche, welches Sicherheitslücken haben könnte.
Zum ersten Konfigurieren schaltet mal den Router in einen Konfig-Modus. Der Router nimmt dann in diesem Modus nicht mehr am Freifunknetzwerk teil. Nun kann man dann Rechner an die LAN-Ports des Freifunkrouters anschließen und über eine Weboberfläche per Browser den Router konfigurieren oder updaten. Das sollte aber nur ganz selten notwendig sein. Nach einem Reboot des Routers geht das Gerät dann wieder in den Freifunk-Modus mit deinen Konfigurationsänderungen.
Wenn man Spaß am Basteln hat, kann man die Weboberfläche aber auch im Normalbetrieb aktivieren. Für die Absicherung muss man dann aber selber sorgen, denn standardmäßig ist das nicht abgesichert. Hier die Anleitung nach Freifunk Kiel, um auf die Weboberfläche zu gelangen:
Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über die Karte oder per IPv6 ssh via Die generelle IPv6-Adresse erfährt man durch Eingabe von
ifconfig | grep Global
Die IPv6-Adresse ("inet6 adr") kann man nun im Browser in eckigen Klammern und vorangestelltem "http://" aufrufen (zum Beispiel: http://[2001:67c:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]/) und gelangt so zur Weboberfläche LuCI.
Falls der Router nicht per IPv6 http liefern sollte, kann man das per SSH beheben. Dazu folgendes nach dem Login auf der Shell vom Router ausführen:
uci delete uhttpd.main.listen_http uci delete uhttpd.main.listen_https uci add_list uhttpd.main.listen_http='[::]:80' uci add_list uhttpd.main.listen_http='0.0.0.0:80' uci add_list uhttpd.main.listen_https='[::]:80' uci add_list uhttpd.main.listen_https='0.0.0.0:80' uci commit uhttpd /etc/init.d/uhttpd enable
Uplink mit Android-Tethering/USB Netzwerkkarte
(SSH-Zugangserfahrung nötig)
Das ganze sei von Anfang an als "sportlich" zu betrachten. Leider sind mobile 3g-/LTE-Tarife fast ausnahmslos nach einem bestimmten Volumen gedrosselt (üblicherweise auf 64 bis 56 kbit/s (neuere NetzclubSim sogar auf 32 kbit/s), Ausnahme bilden hier nur "LTE Zuhause" "DSL" Ersatz Tarife -> 386kbit/s). Da Freifunk auch bei Nichtbenutzung Daten überträgt, ist nur bei "LTE Zuhause"-Tarifen interessant, dies als Dauerlösung zu nutzen. Dort ist aber wiederum meist ein LTE-Router vor Ort und man kann den Router auch "traditionell" via LAN Kabel anbinden. Bei Benutzung als Uplink bei Straßenfesten/Festivals etc. ist wahrscheinlich, dass erstens das Datenvolumen schnell aufgebraucht sein wird und zweitens ab einer bestimmten Größe auch das 3g-Netz vor Ort überlastet ist. Wenn man es dennoch machen will (mehrere Sim-Karten/spezieller hochvolumiger Tarif/vom Netzbetreiber gesponserter Uplink (träum)), sollte man die Benutzung von LTE erwägen. Auch dort könnten aber durch zukünftige Adapation Überlasterscheinungen auftreten. Desweitern nutzen 2g/3g/4g auch dasselbe Backbone, welcher dann auch für LTE ein Flaschenhals darstellt. Muss nochmal nachprüfen, aber wenn, dann nicht uninteressant: Der WLAN-Zugang des Telefons (CM7) wurde per Tethering weitergeleitet und bei Abschalten gab es fallback auf 3g -> nicht schöne, aber einfache "Immer"netzlösung? Mein Tablet zeigt nicht dieses Verhalten.)
Eine ausführliche und fortgeschriebene Anleitung für Gluon für USB-Tethering und USB-3G-Dongle (UMTS-Stick) gibt es bei im Freifunk Rheinbach Wiki unter UMTS und USB-Support.
Blablabla, jetzt geht es los: Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:
- Per SSH in den Router einloggen - Installieren der notwendigen Treiber
opkg update opkg install kmod-usb-uhci kmod-usb-net-rndis
Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)
- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:
config interface 'wan2' option ifname 'usb0' option proto 'dhcp' option type 'bridge'
Auch unter LuCi sollte dies konfigurierbar sein.
- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren. - Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.
ifup wan2
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)
Zusätzlich zum Freifunk auch privates WLAN einrichten
Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.) Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt. Das private WLAN kann per SSH in der Konsole aktiviert werden:
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="$SSID" uci set wireless.wan_radio0.key="$KEY" uci set wireless.wan_radio0.disabled=0 uci commit wifi
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden. Zum Deaktivieren des Ganzen wie folgt vorgehen:
uci set wireless.wan_radio0.disabled=1 uci commit wifi
Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse
Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.
Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:
#!/bin/ash FAILCOUNTFILE=/var/run/mesh0_failcount MAXFAILCOUNT=10 # check mesh connections with different originators and nexthops, MAC is 17 chars long count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l` if [ $count -gt 1 ]; then ## more than a single mesh with itself is left echo 0 > $FAILCOUNTFILE else if [ -f $FAILCOUNTFILE ]; then read failcount < $FAILCOUNTFILE failcount=$(($failcount+1)) if [ $failcount -ge $MAXFAILCOUNT ]; then touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"` sync reboot fi echo $failcount > $FAILCOUNTFILE else echo 1 > $FAILCOUNTFILE fi fi
Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
# batctl o | grep mesh0 62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6) 62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:
#!/bin/ash FAILCOUNTFILE=/var/run/mesh0_failcount MAXFAILCOUNT=10 # check mesh connections with different originators and nexthops, MAC is 17 chars long count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l` if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all? read failcount < $FAILCOUNTFILE # If it exist then there is a number in. if [ $count -gt 0 ]; then # At least one originator with different nexthop exists if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again! echo 0 > $FAILCOUNTFILE exit fi else # no nexthop different than originator exists failcount=$(($failcount+1)) if [ $failcount -ge $MAXFAILCOUNT ]; then echo 0 > $FAILCOUNTFILE # Reset counter before reboot logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info sync reboot fi echo $failcount > $FAILCOUNTFILE fi else echo 0 > $FAILCOUNTFILE fi
Das Script wird dann noch ausführbar gemacht:
chmod +x /root/check_mesh.sh
Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
* * * * * /root/check_mesh.sh > /dev/null 2>&1
Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.
Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
# ls -al | grep failcount -rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622 -rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812 -rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.
Client-WLAN nachts automatisch ausstellen
In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script restrict_client_access.sh ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.
#!/bin/ash STOP_HOUR=0 # needs to be smaller than START_HOUR!!! START_HOUR=7 # disable client0 network device if it's active # and hour is between STOP_HOUR and START_HOUR hour=`date +"%H"` ip addr list client0 > /dev/null 2>&1 if [ $? -eq 0 ]; then # client network is on if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off uci set wireless.client_radio0.disabled=1 uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600) uci commit wireless /etc/init.d/network restart fi else # client network is off if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on uci set wireless.client_radio0.disabled=0 uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600) uci commit wireless /etc/init.d/network restart fi fi
Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
Hinweis: Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script vereinfachen, da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...
Wichtig : Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.
Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist
Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.
Folgendes Script kann in /root/client-off-if-mesh-off.sh abgelegt (und via chmod +x /root/client-off-if-mesh-off.sh ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:
#!/bin/ash FAILCOUNTFILE=/var/run/mesh0_nogatewaycount MAXFAILCOUNT=2 # check mesh connections with different originators and nexthops, MAC is 17 chars long batctl gwl | grep -q "No gateways in range" no_gw=$? if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all? read failcount < $FAILCOUNTFILE # If it exist then there is a number in. if [ ${no_gw} -eq 1 ]; then # There is a gateway if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount failcount=$(($failcount-1)) echo $failcount > $FAILCOUNTFILE if [ $failcount -eq 0 ]; then # turn on client network uci set wireless.client_radio0.disabled=0 uci commit wireless wifi fi exit fi else # no nexthop different than originator exists failcount=$(($failcount+1)) if [ $failcount -eq $MAXFAILCOUNT ]; then # logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info # turn off client network uci set wireless.client_radio0.disabled=1 uci commit wireless wifi fi if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT echo $failcount > $FAILCOUNTFILE fi fi else echo 0 > $FAILCOUNTFILE fi
Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.
Freifunk-Monitor: Router-Status per E-Mail
Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.
(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)
Hallo, Liebe Mitstreiter! Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen. Axel und ich möchten unseren Teil beitragen. Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen. Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche). Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen! Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch. Wie ihr das wieder abschaltet steht unten. --------------- Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile): echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen): uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit Kommando zum E-Mail-Adresse prüfen: uci get gluon-node-info.@owner[0].contact Kommando zum Monitoring abschalten: uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit --------------- Frohes Freifunken, KaterMikesch & G3ntleman
Freifunk-Knoten von der Map entfernen
Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten. Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:
1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.
2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
... config location option share_location '0' ...
3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
uci set gluon-node-info.@location[0].share_location=0 uci commit gluon-node-info
In allen drei Fällen dann den Router nochmal ins Freifunk-Netz hängen (durchstarten) und ein paar Minuten warten, bis der dem Router zugeordnete Punkt mit dem Router-Namen beim nächsten Update der Map-Daten von der Karte verschwindet.