Pimp my Node: Unterschied zwischen den Versionen

Aus Freifunk Köln, Bonn und Umgebung
Zur Navigation springen Zur Suche springen
 
(100 dazwischenliegende Versionen von 9 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]] &nbsp; &nbsp; &nbsp; &nbsp; [[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. Wer Gluon verwendet sollte unbedingt auch Gluon spezifische Resourcen, wie http://gluon.readthedocs.org , zu Rate ziehen.  
Hier finden sich interessante Optionen für etwas versiertere Nutzer.  


Die Möglichkeiten und Abweichungen von der Default-Konfiguration 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, ferner könnten illegitime Maßnahmen implementiert werden. Beide zuvor genannten Beispiele würden zu einem Ausschluss aus unserem Netzwerk führen. Dennoch kann man gute Gründe haben die ein Abweichen von den Defaultwerten sinnvoll machen.  
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.




Zeile 16: Zeile 51:


== Arbeiten auf der Shell ==
== Arbeiten auf der Shell ==
Vorraussetzung für folgende Befehle sind eine Verbindung mit dem KBU Freifunk Netz sowie ein Terminal / Shell.
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.  
Vergesst nicht eth0 gegen die Bezeichnung eures Netzwerkinterfaces, welches am Freifunk hängt zu tauschen.
Bei Macbooks via Wlan z.B. "en1" statt "eth0"! Die link local Adresse der jeweiligen node findet ihr auf der [http://register.kbu.freifunk.net KBU Register] Seite. Um Dateien auf dem Node ändern zu können, steht als einziger Editor ''vi'' bzw. ''vim'' zur Verfügung.
   
   
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 ===
=== Firmware aktualisieren ===
==== Node mit uplink ====
 
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>
<pre>
ssh root@<link local Adresse des Nodes>%eth0              // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/  
cd ../tmp/                                              // in das Verzeichnis "tmp" wechseln
ssh root@<Link-local Adresse des Nodes>%<interface>
free                                                    // Freien Speicher prüfen
cd /tmp/
wget http://pfad/zur/firmware.bin                      // Firmware herunterladen und dann
sysupgrade -v firmware.bin &
sysupgrade -v firmware.bin                             // Firmware-Upgrade durchführen
</pre>
</pre>


'''Achtung''': Beim Download der Firmware via wget kann auf dem Router die Integrität der Firmware nicht geprüft werden, da gpg i.d.R. auf den Routern nicht verfügbar ist. Deshalb ist es sicherer, den oben beschriebenen Weg zu wählen, oder die geprüfte Firmware per scp (s.u.) auf den Router zu kopieren.  
==== 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].


==== Node ohne uplink (mesh node) ====
3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>
 
4. sysupgrade starten.
<pre>
<pre>
scp -6 -v -r firmware.bin root@\[<link local Adresse des Nodes>%eth0\]:../tmp/          // Firmware auf den node schieben (md5 checken!)
cd /tmp/   
ssh root@<link local Adresse des Nodes>%eth0
cd ../tmp/   
sysupgrade -v firmware.bin   
sysupgrade -v firmware.bin   
</pre>
</pre>


==== Node ''zu Fuß'' updaten ====
5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)
Wenn man physikalischen Zugriff auf den Freifunk-Router hat, kann man auch einfach in den [[Config_Mode]] wechseln und dort über das entsprechende Menü eine neue Freifunk-Firmware hochladen. Hierbei kann man wählen, ob man die ggf. geänderte Konfiguration beibehalten möchte (upgrade-Image) oder alles von Grund auf neu installiert/konfiguriert. Ggf. muss man zuvor noch ein Root-Passwort setzen, damit das Update möglich wird.
 
==== 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  &gt; 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.


==== via TFTP ====
==== TFTP ====
Wenn mal ein Router nicht mehr normal geflasht werden kann ;-)
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>
<pre>
aptitude install tftpd-hpa
sudo apt-get install tftpd-hpa tftp
sudo chown -R tftp /srv/tftp/
sudo chown -R tftp /srv/tftp/
</pre>
</pre>
Nur noch Config anpassen & neustarten. Das "-c create file" brauche ich damit ich von den Switch aus die config sichern kann.
* 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
vim /etc/default/tftpd-hpa
Zeile 57: Zeile 214:
TFTP_USERNAME="tftp"
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="192.168.23.23:69"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure -c"
TFTP_OPTIONS="-s -c"


service tftpd-hpa restart  
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>
uci set system.@system[0].pretty_hostname='Musterstadt Musterweg'
uci set system.@system[0].hostname='Musterstadt_Musterweg'
uci commit system
reboot
</pre>
Der "pretty_hostname" muß nicht gesetzt werden.


=== Hostnamen des Nodes ändern ===
Der Hostname wird erst nach einem Neustart übernommen. Dies kann mit "reboot" an der Konsole ausgeführt werden
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies in der Datei ''/etc/config/system''. Hier gibt es gleich als ersten Punkt ''config system'' und dort findet man den Eintrag
<pre>option hostname 'aa:bb:cc:dd:ee:ff'</pre>
Hier kann man jetzt aa:bb:cc:dd:ee:ff (diese Adresse sieht bei jedem Node anders aus!) zu dem gewünschten Hostnamen ändern. Eine Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.


=== IPv6 ping ===
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>
<pre>
ping6 <link local Adresse des Nodes>%eth0
root@petersertrut $  pretty-hostname
peters erstä rutä
root@petersertrut $ 
</pre>
</pre>


=== IPv6 ssh ===
=== IPv6 ping ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
<pre>
ssh root@<link local Adresse des Nodes>%eth0
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:~#


=== Paßwort-Authentifizierung abstellen ===
==== 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 Paßwort gefragt werden (allerhöchstens nach dem Paßwort, welches den privaten Schlüssel schützt).
'''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:
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
<pre>config dropbear
Zeile 87: Zeile 292:
         option Port        '22'
         option Port        '22'
#      option BannerFile  '/etc/banner'</pre>
#      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 Rotuer einzuloggen.
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 ===
==== SSH public key auf Node aufspielen ====
Möchte man sich nicht immer per Paßwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Paßwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
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:
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 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
</pre>
Hierbei steht id_rsa.pub für die Datei, die den public key enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist ok für den ersten Key. Sollen mehrere Keys eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
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>
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
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
Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Interface 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.
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.
 
 




=== Node überträgt keine Statistiken ===
==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Auf der [https://kbu.freifunk.net/cserv Cserv Seite] könnt ihr prüfen, ob eurer Node bereits Statistiken übermittelt.
==== 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:
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'''. Defaultmäß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, dass der komplette Konfigurationspunkt wie folgt aussieht:
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'
<pre>config timeserver 'ntp'
         list server '2a03:4000:2:494::2'
         list server '2a03:4000:2:494::2'
Zeile 120: Zeile 321:
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
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.
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.
==== Collectd prüfen ====
Falls es durch das beheben des ntp-Bug noch immer nicht zum übertragen der Statistiken kommt, überprüft mal die Einstellungen eures Collectd. Es kann sein das beim Firmware Update diese Config nicht geupdatet wurde und eine veraltet IPV6 Adresse noch vorhanden ist, so sollte es sein:
<pre>
vim /etc/collectd.conf                            // Config Datei für Collectd zum bearbeiten öffnen
Zeile 39-44:   
<Plugin ping>                   
        TTL 127                 
        Interval 30                       
        Host "fdd3:5d16:b5dd:3::6"                // Diesen Eintrag auf Übereinstimmmung prüfen     
</Plugin>
Zeile 46-50:
<Plugin network>                                       
        Server "fdd3:5d16:b5dd:3::6" "25827"      // Diesen Eintrag auf Übereinstimmmung prüfen               
        Forward false                                 
</Plugin>
</pre>


=== 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 Ntzwerkverkabelung hat. Hier werden die Switchports angwiesen auch über LAN zu meshen.
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 die alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Config stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.
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 .
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:
''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#config interface 'freifunk' -> Hier haben wir das ethX-Interface aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.  
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.  




Zeile 203: 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 271: Zeile 453:
         option mesh 'bat0'
         option mesh 'bat0'
</pre>
</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 muß 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:
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
  # 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
Zeile 299: 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 traffic machen
  # 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===
===Alternative: Einsperren im VLAN===
Zeile 309: Zeile 577:
== Weboberfläche aktivieren ==
== 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 kein Webinterface, welches Sicherheitslücken haben könnte.
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 ein Webinterface 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.
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 das Webinterface aber auch im Normalbetrieb aktivieren. Für die Absicherung muss man dann aber selber sorgen denn per Default 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:
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:


Das Webinterface des Routers ist nicht über die Link-Local-Adresse, sondern nur über die generelle IPv6 Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
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
  ssh root@LinkLocalIPv6adresse_des_routers%Interface
Die generelle IPv6-Adresse erfährt man durch Eingabe von
Die generelle IPv6-Adresse erfährt man durch Eingabe von
   ifconfig | grep Global
   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 zum Webinterface LuCI.
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 diese per SSH beheben. Dazu folgendes nach dem Login auf der Shell vom Router ausführen:
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_http
  uci delete uhttpd.main.listen_https
  uci delete uhttpd.main.listen_https
Zeile 335: Zeile 602:


== Uplink mit Android-Tethering/USB Netzwerkkarte ==
== Uplink mit Android-Tethering/USB Netzwerkkarte ==
(ssh Zugang Erfahrung nötig)
(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).
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 den Router auch "traditionell" via LAN Kabel anbinden.
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 Strassenfesten/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/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.
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.)
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:
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:
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
- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber
- Installieren der notwendigen Treiber


Zeile 353: Zeile 622:
</pre>
</pre>


Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies nachinstallieren. (nachprüfen!!!)
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 da neue Interface "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:
- 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>
<pre>
Zeile 364: Zeile 633:
</pre>
</pre>


Auch unter Luci sollte dies konfigurierbar sein.  
Auch unter LuCi sollte dies konfigurierbar sein.  


- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB Netzwerk Gerät/Android tethering funktionieren.
- 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.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.


Zeile 372: Zeile 641:
ifup wan2
ifup wan2
</pre>
</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)
(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 ==
== Zusätzlich zum Freifunk auch privates WLAN einrichten ==


Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)  
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.
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:
Das private WLAN kann per SSH in der Konsole aktiviert werden:
Zeile 392: Zeile 661:
</pre>
</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.
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:
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
<pre>
uci set wireless.wan_radio0.disabled=1
uci set wireless.wan_radio0.disabled=1
Zeile 398: Zeile 667:
wifi
wifi
</pre>
</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]] &nbsp; &nbsp; &nbsp; &nbsp; [[Mitmachen|Übersicht]]
</div>
</noinclude>

Aktuelle Version vom 15. Januar 2023, 16:05 Uhr

< Optional: Experteneinstellungen         Übersicht

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

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.

Magnetfuss mit Quad-Richtantenne
Magnetfuss mit Löchern für Schraubmontage mit Stabantenne
Quad-Richtantenne am Router

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:

  1. 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).
  2. 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]

  1. Auf die Kommandozeile der Routers mittels SSH verbinden (s.o.).
  2. Den Befehl firstboot eingeben und mit Enter bestätigen (damit wird die Overlay-Partition formatiert).
  3. Anschließende die Sicherheitsabfrage mit y bestätigen. ACHTUNG: Wirklich ALLE Einstellungen werden gelöscht!
  4. 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)

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.

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

Screenshot-promptinfarbe.png

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.


< Optional: Experteneinstellungen         Übersicht