Freifunk Köln, Bonn und Umgebung - Benutzerbeiträge [de]

Pimp my Node

2016-10-06T21:13:45Z

Echse: /* Weboberfläche aktivieren */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.

Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ].

=== IPv6 SSH ===
Ihr verbindet euch mit eurem router via
<pre>
ssh root@<Link-local Adresse des Nodes>%<interface>
</pre>
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden.

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade unter beibehaltung der Einstellungen ====

Für diese Variante kann das -sysupgrade.bin image verwendet werden, es muss sich aber um ein "kompatibles" upgrade, d.h. innerhalb einer hood und zwischen nicht zu unterschiedlichen Versionen handeln.

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].)
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%<interface>
</pre>
Siehe [[#IPv6_SSH]].

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über [https://map.kbu.freifunk.net/ die Karte] oder per [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] via
Die generelle IPv6-Adresse erfährt man durch Eingabe von
ifconfig | grep Global
Die IPv6-Adresse ("inet6 adr") kann man nun im Browser in eckigen Klammern und vorangestelltem "http://" aufrufen (zum Beispiel: http://[2001:67c:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]/) und gelangt so zur Weboberfläche LuCI.

Falls der Router nicht per IPv6 http liefern sollte, kann man das per SSH beheben. Dazu folgendes nach dem Login auf der Shell vom Router ausführen:
uci delete uhttpd.main.listen_http
uci delete uhttpd.main.listen_https

uci add_list uhttpd.main.listen_http='[::]:80'
uci add_list uhttpd.main.listen_http='0.0.0.0:80'
uci add_list uhttpd.main.listen_https='[::]:80'
uci add_list uhttpd.main.listen_https='0.0.0.0:80'

uci commit uhttpd

/etc/init.d/uhttpd enable

== Uplink mit Android-Tethering/USB Netzwerkkarte ==
(SSH-Zugangserfahrung nötig)

Das ganze sei von Anfang an als "sportlich" zu betrachten. Leider sind mobile 3g-/LTE-Tarife fast ausnahmslos nach einem bestimmten Volumen gedrosselt (üblicherweise auf 64 bis 56 kbit/s (neuere NetzclubSim sogar auf 32 kbit/s), Ausnahme bilden hier nur "LTE Zuhause" "DSL" Ersatz Tarife -> 386kbit/s).
Da Freifunk auch bei Nichtbenutzung Daten überträgt, ist nur bei "LTE Zuhause"-Tarifen interessant, dies als Dauerlösung zu nutzen. Dort ist aber wiederum meist ein LTE-Router vor Ort und man kann den Router auch "traditionell" via LAN Kabel anbinden.
Bei Benutzung als Uplink bei Straßenfesten/Festivals etc. ist wahrscheinlich, dass erstens das Datenvolumen schnell aufgebraucht sein wird und zweitens ab einer bestimmten Größe auch das 3g-Netz vor Ort überlastet ist. Wenn man es dennoch machen will (mehrere Sim-Karten/spezieller hochvolumiger Tarif/vom Netzbetreiber gesponserter Uplink (träum)), sollte man die Benutzung von LTE erwägen. Auch dort könnten aber durch zukünftige Adapation Überlasterscheinungen auftreten. Desweitern nutzen 2g/3g/4g auch dasselbe Backbone, welcher dann auch für LTE ein Flaschenhals darstellt.
Muss nochmal nachprüfen, aber wenn, dann nicht uninteressant: Der WLAN-Zugang des Telefons (CM7) wurde per Tethering weitergeleitet und bei Abschalten gab es fallback auf 3g -> nicht schöne, aber einfache "Immer"netzlösung? Mein Tablet zeigt nicht dieses Verhalten.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T21:09:59Z

Echse: /* IPv6 ping */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.

Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ].

=== IPv6 SSH ===
Ihr verbindet euch mit eurem router via
<pre>
ssh root@<Link-local Adresse des Nodes>%<interface>
</pre>
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden.

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade unter beibehaltung der Einstellungen ====

Für diese Variante kann das -sysupgrade.bin image verwendet werden, es muss sich aber um ein "kompatibles" upgrade, d.h. innerhalb einer hood und zwischen nicht zu unterschiedlichen Versionen handeln.

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].)
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%<interface>
</pre>
Siehe [[#IPv6_SSH]].

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T21:09:11Z

Echse: /* IPv6 ping */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.

Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ].

=== IPv6 SSH ===
Ihr verbindet euch mit eurem router via
<pre>
ssh root@<Link-local Adresse des Nodes>%<interface>
</pre>
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden.

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade unter beibehaltung der Einstellungen ====

Für diese Variante kann das -sysupgrade.bin image verwendet werden, es muss sich aber um ein "kompatibles" upgrade, d.h. innerhalb einer hood und zwischen nicht zu unterschiedlichen Versionen handeln.

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].)
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%<interface>
</pre>
Siehe [[SSH_IPv6]].

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T21:06:39Z

Echse: /* Sysupgrade */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.

Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ].

=== IPv6 SSH ===
Ihr verbindet euch mit eurem router via
<pre>
ssh root@<Link-local Adresse des Nodes>%<interface>
</pre>
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden.

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade unter beibehaltung der Einstellungen ====

Für diese Variante kann das -sysupgrade.bin image verwendet werden, es muss sich aber um ein "kompatibles" upgrade, d.h. innerhalb einer hood und zwischen nicht zu unterschiedlichen Versionen handeln.

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].)
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T21:03:32Z

Echse: /* IPv6 SSH */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.

Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ].

=== IPv6 SSH ===
Ihr verbindet euch mit eurem router via
<pre>
ssh root@<Link-local Adresse des Nodes>%<interface>
</pre>
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden.

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen. 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.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].)
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T21:03:04Z

Echse: /* Arbeiten auf der Shell */ IPv6 SSH vorgezogen und deduplikation

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Voraussetzung für folgende Befehle sind eine Verbindung mit dem KBU-Freifunk-Netz sowie ein Terminal / Shell.

Zusätzlich zu den auf dieser Seite erläuterten Modifikationen gibt es im [https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle ].

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-local Adresse des Nodes>%<interface>
</pre>
Hierbei findet ihr die Link-local Adresse z.B. auf der [https://map.kbu.freifunk.net/ Karte], es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist unter Linux typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN. Mit <code>ifconfig</code> lässt sich das leicht herausfinden.

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen. 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.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>. (Siehe [[#IPv6_SSH]].)
Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:58:34Z

Echse: /* Kurzfassung */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin ruhig das komplette Image (nicht die -sysupgrade variante) sein darf, falls das in die RAM disk passt.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen. 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.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden. Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:55:43Z

Echse: /* Sysupgrade */ use tmp!

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin das komplette Image (nicht die -sysupgrade variante) ist.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen. 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.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden. Es ist wichtig die firmware nach <code>/tmp</code> zu kopieren, das ist eine [https://wiki.openwrt.org/doc/howto/generic.sysupgrade#for_sysupgrade-based_upgrades Ram disk].

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:51:53Z

Echse: /* Sysupgrade */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin das komplette Image (nicht die -sysupgrade variante) ist.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

1. [[Firmware_herunterladen]] und Signatur/Checksumme prüfen. 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.

2. Firmware per scp auf den Router kopieren <code>scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/ </code>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden.

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:49:55Z

Echse: /* Kurzfassung */ nicht -sysupgrade verwenden

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== Firmware aktualisieren ===

Neben dem Upgrade per [[Config_Mode]], für den man sich per Kabel direkt mit dem Node verbinden muss, kann man auch remote per ssh upgraden. Direkt vorweg, falls etwas schief läuft, siehe [[#TFTP]] um das ganze doch wieder (per direkt LAN verbindung, aber ohne funktionierendes Webinterface) zu reparieren.

==== Kurzfassung ====
Die größte Erfolgsquote hat (meiner leidvollen Erfahrung nach) ein upgrade mittels:
<pre>
scp firmware.bin root@\[<Link-local Adresse des Nodes>%<interface>\]:/tmp/
ssh root@<Link-local Adresse des Nodes>%<interface>
cd /tmp/
sysupgrade -i -b config.tar.gz
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Wobei firmware.bin das komplette Image (nicht die -sysupgrade variante) ist.
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

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>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden.

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:47:27Z

Echse: /* Firmware aktualisieren */ nohup not installed on nodes -.-

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== 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 ====
<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>
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

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>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden.

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:36:28Z

Echse: /* Firmware aktualisieren */

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== 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 ====
<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
nohup sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
Für die Details, einfach weiter lesen. ;)

==== Sysupgrade ====

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>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden.

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

5. beten, dass es sich um ein "kompatibles" upgrade handelt. ;)

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
nohup sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-06T20:32:22Z

Echse: /* Firmware aktualisieren */ wget Bescheibung entfernt (keine überprüfung des downloads, geht per https häufig nicht,...), etwas umstrukturiert, nohup ergänzt,...

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== 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.

==== Sysupgrade ====

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>.
Hierbei findet ihr die Link-local Adresse z.B. auf der [Karte](https://map.kbu.freifunk.net/), es ist die IPv6 Adresse, die mit fe80:: beginnt. Interface ist typischerweise <code>eth0</code> für den LAN Port und <code>wlan0</code> fürs WLAN, das könnt ihr mit <code>ifconfig</code> herausfinden.

3. Per ssh mit dem Router verbinden <code>ssh root@<Link-local Adresse des Nodes>%<interface></code>

4. sysupgrade starten.
<pre>
cd /tmp/
sysupgrade -v firmware.bin
</pre>

==== Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) ====
Bei einem Upgrade von einer inkompatiblen Version mittels <code>sysupgrade</code> muss man normalerweise mittels
<pre>
sysupgrade -n firmware.bin
</pre>
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat <code>sysupgrade</code> einen interaktiven Modus, den man per
<pre>
sysupgrade -i firmware.bin
</pre>
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi, mit ":wq" für write-quit wird gespeichert und vi beendet ;) )

Je nach Route zum Router, Router, Menschen, die durch den WLAN Empfang laufen,... kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Sicher passiert das z.B., wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
nohup sysupgrade -v -f config.tar.gz firmware.bin &
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-05T20:03:27Z

Echse: /* Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) */ Verbindungsabbruch passiert auch ohne VPN tunnel (I tried... ;)

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

==== Node ohne Uplink (mesh node) ====
<pre>
scp -6 -v -r firmware.bin root@\[<Link-lokale Adresse des Nodes>%eth0\]:../tmp/ // Firmware auf den Node schieben (md5 prüfen!)
ssh root@<Link-lokale Adresse des Nodes>%eth0
cd ../tmp/
sysupgrade -v firmware.bin
</pre>

==== 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 kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Z.B. passiert das, wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -f config.tar.gz firmware.bin
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-10-05T19:43:54Z

Echse: /* Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.) */ sysupgrade -i -b statt tar gz von Hand.

[[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 Ressourcen, wie [http://gluon.readthedocs.org/ http://gluon.readthedocs.org] zu Rate ziehen.

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, 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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der 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-lokale 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

==== Node ohne Uplink (mesh node) ====
<pre>
scp -6 -v -r firmware.bin root@\[<Link-lokale Adresse des Nodes>%eth0\]:../tmp/ // Firmware auf den Node schieben (md5 prüfen!)
ssh root@<Link-lokale Adresse des Nodes>%eth0
cd ../tmp/
sysupgrade -v firmware.bin
</pre>

==== 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 kann es sein, dass die SSH-Verbindung während des interaktiven Upgrades abbricht. Genauer passiert das, wenn man nur durch einen VPN-Tunnel Verbindung hat. (Nicht fleißig am Backbone mitgearbeitet? ;) Das ist blöd, weil man am Ende noch den Neustart bestätigen muss (etwas unsinnig).

In diesem Fall sollte man besser eine Konfigurationsdatei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen.
Das gleiche erreicht man "interaktiv" per
<code>
sysupgrade -i -b config.tar.gz
</code>.

Danach kann man mittels
<pre>
sysupgrade -f config.tar.gz firmware.bin
</pre>
das ganze unbeaufsichtigt laufen lassen.

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Standardweboberfläche hat) kann man häufig noch per TFTP recht komfortabel eine neue Firmware einspielen. [http://wiki.openwrt.org/doc/howto/generic.flashing.tftp] ;)

* TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [http://www.cyberciti.biz/faq/install-configure-tftp-server-ubuntu-debian-howto/])
<pre>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der [http://linux.die.net/man/8/tftpd manpage].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per SSH:
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <Link-lokale Adresse des Nodes>%eth0
</pre>

=== IPv6 SSH ===
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
<pre>
ssh root@<Link-lokale Adresse des Nodes>%eth0
</pre>

=== Passwort-Authentifizierung abstellen ===
'''Wichtig:''' Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.

=== SSH public key auf Node aufspielen ===
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert.
Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
<pre>
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</pre>
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. '''ACHTUNG:''' Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels ''reboot'' übernommen.

==== NTP-Bug in Firmware 1.2.1b beseitigen ====
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben:
Editiert wird die Datei ''/etc/config/system''. Dort findet man einen Eintrag ''config timeserver 'ntp'''. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

=== LAN Kopplung ===
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.

==== TL-WR841ND ====
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.

05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .

''vim /etc/config/network'' - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
#Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
#Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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 [http://wiki.freifunk.in-kiel.de/wiki/Firmware Freifunk Kiel], um auf die Weboberfläche zu gelangen:

Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. [[Pimp_my_Node#IPv6_ssh|IPv6 ssh]] auf den Router:
ssh root@LinkLokaleIPv6adresse_des_routers%Schnittstelle
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWRT-Router mit USB, Android-USB-tethering-fähigem Gerät und einfachen USB-Ethernet-Adaptern (nachprüfen!!!) funktionieren:

- Per SSH in den Router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)

- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter LuCi sollte dies konfigurierbar sein.

- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren.
- Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum Deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse ==

Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.

Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
</pre>

Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
<pre>
# batctl o | grep mesh0
62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6)
62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
</pre>

Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10

# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
</pre>

Das Script wird dann noch ausführbar gemacht:
<pre>
chmod +x /root/check_mesh.sh
</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/check_mesh.sh > /dev/null 2>&1
</pre>

Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.

Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
<pre>
# ls -al | grep failcount
-rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622
-rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812
-rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
</pre>

Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.

== Client-WLAN nachts automatisch ausstellen ==

In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script ''restrict_client_access.sh'' ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.

<pre>
#!/bin/ash

STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR

hour=`date +"%H"`

ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
</pre>

Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
</pre>

'''Hinweis:''' Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script ''vereinfachen'', da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...

'''Wichtig ''': Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
<pre>
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
</pre>
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.

== Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist ==

Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.

Folgendes Script kann in ''/root/client-off-if-mesh-off.sh'' abgelegt (und via ''chmod +x /root/client-off-if-mesh-off.sh'' ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:

<pre>
#!/bin/ash

FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2

# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?

if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi

</pre>

Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
<pre>
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
</pre>

Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.

== Freifunk-Monitor: Router-Status per E-Mail ==

Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.

(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)

<pre>
Hallo, Liebe Mitstreiter!

Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.

Axel und ich möchten unseren Teil beitragen.

Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.

Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).

Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!

Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.

Wie ihr das wieder abschaltet steht unten.

---------------

Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):

echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit

Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):

uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit

Kommando zum E-Mail-Adresse prüfen:

uci get gluon-node-info.@owner[0].contact

Kommando zum Monitoring abschalten:

uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit

---------------

Frohes Freifunken,

KaterMikesch & G3ntleman
</pre>

== Freifunk-Knoten von der Map entfernen ==

Wenn man einen Freifunk-Router in eine andere Hood überführen oder anderweitig verwenden möchte, ist es eine gute Sitte, keine blinkenden roten Punkte auf der Karte zu hinterlassen, die üblicherweise auf Störungen bzw. Ausfälle hindeuten.
Zum Austragen des Routers aus der Karte kannst Du einen der folgenden Wege beschreiten:

1. Den Router in den Config-Mode überführen (durch längeres Drücken des Reset-Buttons, bis alle LEDs aufblinken) und in der Konfigurationsoberfläche das entsprechende Häkchen deaktivieren.

2. Wenn Du per ssh auf den Router kommst, dann kannst Du in der Datei /etc/config/gluon-node-info folgenden Paramter (von 1 auf 0) setzen:
<pre>
...
config location
option share_location '0'
...
</pre>

3. Alternativ zu 2 ebenfalls via ssh und UCI-Kommando auf dem Router:
<pre>
# uci set gluon-node-info.@location[0].share_location=0
# uci commit gluon-node-info
</pre>

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.

Pimp my Node

2016-03-28T21:26:49Z

Echse: /* via TFTP */ link nach bingen, danke d0b

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

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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

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

==== Upgrade von inkompatibler Konfiguration (Lagacy auf Gluon, wechsel der 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 Settings überschreiben lassen. Auf einem Node den man nur per ssh erreicht ist das unpraktisch, da auch Passwörter und ssh keys 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, das 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 host name des Nodes, der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi ;)

Je nach Route zum Router kann es sein, dass die ssh Verbindung abbricht während des interactiven upgrades. Genauer passiert das, 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 unsinniger weise). In diesem Fall sollte man besser eine config datei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen. Danach kann man mittels
<pre>
sysupgrade -f config.tar.gz firmware.bin
</pre>
das ganze unattended laufen lassen.

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Stock Webinterface 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>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Config anpassen & neustarten. Das "-c create file" braucht man um vom router Dateien zu senden (config 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 man page].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 wäre 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 des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per ssh
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Paßwort-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).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== 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.
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>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</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:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive 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.

=== Node überträgt keine Statistiken ===
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:
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:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== 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 ===
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.

==== 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.

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:
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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:

# 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 kein Webinterface, 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.

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:

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:
ssh root@LinkLocalIPv6adresse_des_routers%Interface
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 zum Webinterface 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:
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 Zugang Erfahrung 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 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.
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies 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:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

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

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, quick hack (and 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 ursächlich ist, 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, das 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
</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
</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
</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.

Pimp my Node

2016-03-26T16:57:57Z

Echse: /* Firmware aktualisieren */ sysupgrade for incompatible version: only keep ssh keys (and stuff)

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

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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

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

==== Upgrade von inkompatibler Konfiguration (Lagacy auf Gluon, wechsel der 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 Settings überschreiben lassen. Auf einem Node den man nur per ssh erreicht ist das unpraktisch, da auch Passwörter und ssh keys 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, das 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 host name des Nodes, der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi ;)

Je nach Route zum Router kann es sein, dass die ssh Verbindung abbricht während des interactiven upgrades. Genauer passiert das, 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 unsinniger weise). In diesem Fall sollte man besser eine config datei mit z.B. folgenden Zeilen
<pre>
/etc/dropbear/authorized_keys
/etc/dropbear/dropbear_dss_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/config/gluon-node-info
/etc/config/system
</pre>
erstellen und per <code>tar -cz config > config.tar.gz</code> packen. Danach kann man mittels
<pre>
sysupgrade -f config.tar.gz firmware.bin
</pre>
das ganze unattended laufen lassen.

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Stock Webinterface 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>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Config anpassen & neustarten. Das "-c create file" braucht man um vom router Dateien zu senden (config 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 man page].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 wäre 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].

=== Hostnamen des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per ssh
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Paßwort-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).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== 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.
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>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</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:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive 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.

=== Node überträgt keine Statistiken ===
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:
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:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== 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 ===
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.

==== 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.

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:
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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:

# 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 kein Webinterface, 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.

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:

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:
ssh root@LinkLocalIPv6adresse_des_routers%Interface
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 zum Webinterface 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:
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 Zugang Erfahrung 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 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.
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies 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:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

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

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, quick hack (and 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 ursächlich ist, 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, das 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
</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
</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
</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.

Pimp my Node

2016-03-26T16:33:51Z

Echse: /* Hostnamen des Nodes ändern */ per uci im neuen gluon

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

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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

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

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Stock Webinterface 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>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Config anpassen & neustarten. Das "-c create file" braucht man um vom router Dateien zu senden (config 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 man page].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 wäre 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].

=== Hostnamen des Nodes ändern ===
Standardmäßig ist der Hostname des Nodes gleich der MAC-Adresse des Routers. Möchte man den Hostnamen ändern, so kann man dies per ssh
<pre>
uci set system.@system[0].hostname=what-ever-dude
uci commit
reboot
</pre>
Die Änderung wird erst nach dem Kommando ''reboot'' (danach startet der Node neu) wirksam.

=== IPv6 ping ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Paßwort-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).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== 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.
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>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</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:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive 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.

=== Node überträgt keine Statistiken ===
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:
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:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== 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 ===
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.

==== 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.

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:
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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:

# 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 kein Webinterface, 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.

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:

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:
ssh root@LinkLocalIPv6adresse_des_routers%Interface
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 zum Webinterface 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:
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 Zugang Erfahrung 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 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.
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies 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:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

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

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, quick hack (and 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 ursächlich ist, 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, das 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
</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
</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
</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.

Pimp my Node

2016-03-25T20:54:35Z

Echse: /* via TFTP */

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

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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

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

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Stock Webinterface 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>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Config anpassen & neustarten. Das "-c create file" braucht man um vom router Dateien zu senden (config 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 man page].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 wäre 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].

=== Hostnamen des Nodes ändern ===
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 ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Paßwort-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).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== 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.
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>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</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:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive 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.

=== Node überträgt keine Statistiken ===
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:
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:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== 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 ===
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.

==== 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.

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:
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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:

# 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 kein Webinterface, 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.

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:

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:
ssh root@LinkLocalIPv6adresse_des_routers%Interface
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 zum Webinterface 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:
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 Zugang Erfahrung 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 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.
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies 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:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

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

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, quick hack (and 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 ursächlich ist, 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, das 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
</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
</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
</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.

Pimp my Node

2016-03-25T20:54:11Z

Echse: /* via TFTP */ mehr Infos und Links -> UnBrick tl-wr841n Anleitung

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

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.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung 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 ].

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

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

==== Node ''zu Fuß'' updaten ====
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.

==== via TFTP ====
Wenn mal ein Router nicht mehr bootet, aber der Bootloader noch funktioniert, (oder man einfach keinen Bock auf das Stock Webinterface 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>
aptitude install tftpd-hpa
sudo chown -R tftp /srv/tftp/
</pre>
* Config anpassen & neustarten. Das "-c create file" braucht man um vom router Dateien zu senden (config 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 | man page].
<pre>
vim /etc/default/tftpd-hpa

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="-s -c"

service tftpd-hpa restart
</pre>
* 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 wäre 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].

=== Hostnamen des Nodes ändern ===
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 ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Paßwort-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).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== 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.
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>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</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:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive 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.

=== Node überträgt keine Statistiken ===
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:
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:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== 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 ===
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.

==== 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.

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:
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'
</pre>

== 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:

# 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 kein Webinterface, 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.

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:

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:
ssh root@LinkLocalIPv6adresse_des_routers%Interface
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 zum Webinterface 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:
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 Zugang Erfahrung 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 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.
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies 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:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

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

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

== Automatischer Neustart bei längerem Mesh-Verlust, quick hack (and 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 ursächlich ist, 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, das 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
</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
</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
</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.

Überprüfen der Signatur

2015-10-31T08:27:31Z

Echse: /* Download der Hashsummen und Signaturen */ Anpassung für Rampones aktuelle inline binary sig

[[Kategorie:Mitmachen]]
[[Kategorie:Signaturen]]

Damit sichergestellt ist, dass die heruntergeladene Freifunk-Firmware auch wirklich die ist, welche wir erstellt und zum Download angeboten haben, sollten unbedingt die Hash-Werte (d.h. ein eindeutiger Fingerabdruck) der Firmware-Dateien und die korrekte Signatur der von uns bereitgestellten Hash-Wert-Datei geprüft werden. Dieses ist vermutlich der schwierigste Teil der Installation und wird von Einzelnen gelegentlich übergangen, getreu der Kölschen Lebensweisheit ''"Et hät noch immer joot jejange"''. Darauf sollte man sich aber in der heutigen Zeit nicht verlassen.

Die Datei mit den Hash-Werten ist mit unserem GPG-Schlüssel signiert. Der heimliche Austausch einer Freifunk-Firmware und des entsprechenden Hash-Wertes ist also nicht möglich, da die Signatur nur bei unveränderter Hash-Wert-Datei gültig bleibt. Unser öffentlicher GPG-Schlüssel ist auf den gängigen Keyservern wie pgp.mit.edu und subkeys.pgp.net hinterlegt.

Wer sich mit GPG noch nicht auskennt, kann sich z.B. unter [https://www.gnupg.org www.gnupg.org] aufschlauen.

== Schlüssel besorgen ==

'''Unseren (alten) GPG-Schlüssel bekommt man z.B. unter Linux/Unix von der Kommandozeile aus so:'''
# gpg --recv-key '0FA27C6E4'

'''Achtung:''' Der alte Schlüssel ist nur noch bis Ende 2014 gültig gewesen, so dass die Überprüfung der Signatur aus 2014 zu einer Warnung führt:
gpg: Good signature from "Freifunk-KBU Release Signing Key (Used by jenkins.kbu.freifunk.net) <info@kbu.freifunk.net>"
gpg: Note: This key has expired!
Primary key fingerprint: E3B3 AF2B 6B54 149B 9313 4EC0 E782 EAC7 FA27 C6E4

'''Den seit 2015 gültigen GPG-Schlüssel für Signaturen aus 2015 erhält man mit:'''
# gpg --recv-key 0xFEE7BD18

Künftige Releases werden also mit diesem Key signiert sein.

'''Achtung:''' Nur zu überprüfen, ob die Key-IDs (bspw. 0x01DE5D6C) übereinstimmen reicht nicht! Diese können sehr leicht gefälscht werden.

'''Für die aktuellen Gluon Beta-Releases muss man [[Benutzer:Rampone|Rampone]]s GPG-Key importieren:'''
# gpg --recv-key 0x01DE5D6C

Dieser Key hat den Fingerprint 456A 3DB8 7D34 F3C5 2B2C 3FA8 7585 3500 01DE 5D6C. Am besten sollte man überprüfen, dass dieser mit dem in der Konsole angegebenen Schlüssel übereinstimmt und ob er in der Geschichte dieses Wiki-Eintrags geändert/manipuliert wurde. Weiterhin kann man überprüfen, dass er dem Schlüssel entspricht, den man über die Keyserver bekommt, wenn man nach "rampone %$($(#@AT@$($(# gmail.com" sucht. Natürlich ohne Leer- und Sonderzeichen.

== Download der Hashsummen und Signaturen ==

Nach dem Download der beiden Dateien
* [https://kbu.freifunk.net/files/release/latest/SHA256SUMS SHA256-Summen]
* [https://kbu.freifunk.net/files/release/latest/SHA256SUMS.sign Signaturen]
prüft man dann einfach die Signatur mit

$ gpg --verify SHA256SUMS.sign
gpg: Signature made Wed 27 Aug 2014 10:40:01 PM CEST using RSA key ID FA27C6E4
gpg: Good signature from "Freifunk-KBU Release Signing Key (Used by jenkins.kbu.freifunk.net) <info@kbu.freifunk.net>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E3B3 AF2B 6B54 149B 9313 4EC0 E782 EAC7 FA27 C6E4

Die Signatur ist also korrekt.

Bei den Gluon Beta-Releases wird Signatur und Unterschrift in einer Datei veröffentlicht:

* [https://213.165.82.133/images/factory/SHA512SUMS.sign Signaturen]
Diese wird mittels
$ gpg <SHA512SUMS.sign > SHA512SUMS
überprüft und in ein lesbares Format übersetzt.

Den Fingerprint des Schlüssels prüft man am besten einmal offline bei unseren [http://kbu.freifunk.net/wiki/index.php?title=Hauptseite regelmäßigen Treffen].

==Hash prüfen==
Hat man eine authentische Liste mit den Hashes wie oben beschrieben erhalten und überprüft kann man nun selbst den Hash-Wert der heruntergeladenen Firmware (hier am Beispiel des Routers TL WR841n mit der Hardware-Version 9) berechnen

$ sha256sum ff-kbu-tl-wr841n-v9-1.2.1b.bin
2a3df4ea2e10cc9697a80fa0db7cf962fca052ec5d669779ae79e0345da16b30 ff-kbu-tl-wr841n-v9-1.2.1b.bin

und mit dem Hash-Wert in der signierten und zuvor korrekt verifizierten Datei vergleichen:

$ grep ff-kbu-tl-wr841n-v9-1.2.1b.bin SHA256SUMS
2a3df4ea2e10cc9697a80fa0db7cf962fca052ec5d669779ae79e0345da16b30 ./ff-kbu-tl-wr841n-v9-1.2.1b.bin
2a3df4ea2e10cc9697a80fa0db7cf962fca052ec5d669779ae79e0345da16b30 ./untested/barrier_breaker/ff-kbu-tl-wr841n-v9-1.2.1b.bin

Damit ist die heruntergeladenen Datei auch genau die, die wir für Freifunk erstellt und angeboten haben. Unter der Voraussetzung, dass uns niemand den privaten GPG-Schlüssel entwendet und das Passwort zur Sicherung des privaten Schlüssels geknackt hat. Letzteres ist sehr sehr unwahrscheinlich.

KBU Gluon Firmware

2015-10-08T19:32:34Z

Echse: Klicktiefe verkürzt ;)

[[Kategorie:Mitmachen]]

Auf dieser Seite wird erläutert, wie du die aktuelle Gluon Firmware auf einem frischen Router installierst, bzw. die original Firmware durch Gluon ersetzt. Letztere befindet sich im beta-Status innerhalb KBUs, basiert aber auf einen stabilen Release des original Gluons, alternativ kann weiterhin die stabile [[KBU Classic Firmware]] (fast) uneingeschränkt verwendet werden, Gluon ist gerade vor allen Dingen zur Unterstuetzung neuerer Hardware angedacht.
Unter [[Gluon_Config_Mode | Config Mode]] findest Du die Information wie Du einen Router mit installierter KBU Gluon Firmware kofigurierst, unter [[Pimp_my_Node | Pimp my Node]] geht es dann weiter in die Tiefe. ;)

== Freifunk Firmware installieren ==
=== Freifunk Firmware auswählen ===
Die Firmware ist vom Router-Modell abhängig. Das Modell und die Versionsnummer deines Routers findest du auf der Rückseite des Gerätes.

[[Datei:wr741nd_pi3.jpg||400px|thumb|center]]

Bitte wähle die Firmware für deinen Router anhand des Modells und der Version:

{|class="wikitable center"
|-
|[[File:tl-wr740n.jpg|center|thumb|200px]]
|[[File:tl-wr740n.jpg|center|thumb|200px]]
|[[File:tl-wr841n.jpg|center|thumb|200px]]
|[[File:tl-wr842n.jpg|center|thumb|200px]]
|-
|style="text-align:center" | TL-WR740N(D) [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr740n-nd-v4.bin v4.x] (außer v4.27)
|style="text-align:center" | TL-WR741N(D) [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr741n-nd-v1.bin v1.x], [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr741n-nd-v2.bin v2.x], [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr741n-nd-v4.bin v4.x]
|style="text-align:center" | TL-WR841N(D) [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr841n-nd-v3.bin v.3.x], [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr841n-nd-v5.bin v5.x], [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr841n-nd-v7.bin v7.x], [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr841n-nd-v8.bin v8.x], [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr841n-nd-v9.bin v9.x]
|style="text-align:center" | TL-WR842N(D) [https://kbu.freifunk.net/files/release/1.2.1/ff-kbu-tl-wr842n-v1-1.2.1a.bin v1.x], [https://kbu.freifunk.net/files/release/1.2.1/ff-kbu-tl-wr842n-v2-1.2.1b.bin v2.x]
|-
|[[File:tl-wr1043nd.jpg|center|thumb|200px]]
|[[File:tl-wdr3500.jpg|center|thumb|200px]]
|[[File:tl-wdr3600.jpg|center|thumb|200px]]
|[[File:tl-wdr4300.jpg|center|thumb|200px]]
|-
|style="text-align:center" | TL-WR1043ND [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wr1043n-nd-v1.bin v1.x]
|style="text-align:center" | TL-WDR3500 [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wdr3500-v1.bin v1.x]
|style="text-align:center" | TL-WDR3600 [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wdr3600-v1.bin v1.x]
|style="text-align:center" | TL-WDR4300 [https://213.165.82.133/images/factory/gluon-ffkbu-0.6+exp20150910-tp-link-tl-wdr4300-v1.bin v1.x]
|}

[[Benutzer:Rampone|Rampone]] stellt unter https://213.165.82.133/images/factory/ weitere aktuelle Gluon builds bereit, hier einfach anhand der Dateiendung die zu deinem Modell passende Version auswählen.

Hinweis: Das optionale (D) in der Produktbezeichnung steht für die Produktvariante mit auswechselbaren Antennen, was den Router ein paar Euro teuerer macht. Von den Antennen abgesehen ist die Hardware die selbe, dementsprechend gibt es nur eine Firmware für die Modelle mit und ohne (D).

Nach dem Herunterladen der Firmware ist es grundsätzlich sinnvoll die [[Überprüfen der Signatur|Signatur der Datei zu überprüfen]]. Während des Gluon Beta-Tests werden jedoch nicht alle Versionen signiert.

=== Router mit dem Computer verbinden ===
Dafür solltest du Deinen Router mit Strom versorgen sowie die Netzwerkkarte deines PC mit einen der gelben Ports des Routers verbinden, hier reicht ein handelsübliches LAN Kabel. Am PC muss die Netzwerkkarte auf Automatische IP-Adresse beziehen (DHCP) eingestellt sein und WLAN sollte vorübergehend deaktiviert werden.<ref name="wlanOff">Da der Router (noch) nicht mit dem Internet verbunden ist könnte euer Rechner (je nach Setup) versuchen sich über WLAN mit evtl. bestehenden Funknetzen zu verbinden, obwohl ein LAN Kabel angeschlossen ist.</ref>

=== Freifunk Firmware einspielen ===
Jetzt kannst du den Router einfach über den Browser konfigurieren.

Dazu rufst du in deinen Browser die auf der Router Rückseite angegebene Adresse auf, in der Regel http://192.168.1.1 (je nach Typ auch http://192.168.0.1) oder http://tplinklogin.net.

Bevor du weitermachst, musst du dich erst anmelden. Die Standrad-Username / -Passwort Kombination ist ebenfalls auf der Routerrückseite zu finden, in der Regel: admin / admin

Dein Browserfenster müsste nun so aussehen – Folge hier dem Link "System Tools".

[[File:TP_link_01_start.png|center|thumb|800px]]

Als nächste wählst du aus dem Menü "Firmware Upgrade" (1). Danach kannst du die vorhin (in Schritt 2) geladene Datei zum Hochladen auswählen (2). Nach einem Klick auf "Upgrade" (3) beginnt der Prozess.

[[File:TP_link_02_firmware.png|center|thumb|800px]]

Du musst noch einmal kurz bestätigen …

[[File:TP_link_03_firmware_file.png|center|thumb|800px]]

… und die Installation läuft. Während die Installation läuft, zieh bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel – denn dann ist dein Router hinüber.

[[File:TP_link_04_upgrade_progress.png|center|thumb|800px]]

'''Bei TL-WR841N v8.4:''' Beim Flashen über das Firmware-Upgrade der Original-Firmware tritt ggf. folgender Fehler auf:
''Error code: 23002''
''The uploaded file name is too long!''
Hier hilft einfaches Umbenennen der herunter geladenen Freifunk-Firmware.

Nachdem die Firmware fertig eingespielt ist, startet der Router automatisch neu.

Dass der Router neu startet merkst du auch am kurzen Aufblinken der Lämpchen an deinem Router.

[[File:TP_link_05_firmware_reboot_finished.png|center|thumb|800px]]

Jetzt ist der Router nicht mehr unter der angegeben Adresse sichtbar und eine Fehlermeldung erscheint. Das ist gut so. Denn nun läuft nicht mehr die alte Firmware sondern die neue, tolle Freifunk Firmware auf deinem Router.

=== Anschluss ans Internet ===
Nach dem automatischen Neustart ist der Router direkt im Normalbetrieb. Wenn keine weiteren Freifunk-Router in der dirkten Umgebung sind, musst Du allerdings den Freifunk-Router noch per Ethernetkabel mit Deinem Internet-Router verbinden, damit der Freifunk-Router auch Internet-Zugriff gewährt. Dazu wird der '''blaue''' Port des Freiunk-Routers mit dem Gästenetz-Port Deines Internet-Routers verbunden. Falls Du dort kein Gästenetz eingerichtet hast oder das gar nicht geht, tut's auch ein "normaler" LAN-Port Deines Routers, wo Du auch deinen Laptop etc. einstöpseln würdest. Ein Gästenetz wäre nur noch etwas sicherer. Eventuell musst Du die Filterregeln für das Gästenetz anpassen, da manche Router in der Standardkonfiguration nur bestimmte Ports freigegeben haben.

'''WICHTIG:''' Wer hier in einer Firma oder gar einer städtischen Einrichtung ''mal eben'' einen Freifunk-Router an deren Intranet anschließt, schadet damit unter Umständen dem Freifunk-Projekt, da das nicht unbemerkt bleibt und fast immer gegen interne Sicherheitsrichtlinien verstößt. Sowas muss von der jeweiligen IT-Leitung explizit erlaubt werden. Wir wollen die Verantwortlichen nicht verärgern sondern überzeugen!

=== Installation überprüfen ===
Nach erfolgreichem Boot sollte Dein Router nun ein offenes WLAN mit SSID kbu.freifunk.net anzeigen. Nach wenigen Minuten sollte er bei erfolgreichem Internetanschluss ausserdem auf https://map.kbu.freifunk.net auftauchen. (Als neuer Knoten mit kryptischem Namen unter Aktuelles).

[[File:Map-kbu-fresh-router-screen-shot.png|center|thumb|800px|Hier wurde offenbar vor kurzem ein neuer Router (freifunkXXX) eingerichtet aber noch kein Name vergeben.]]

=== Sinnvolle Ergänzungen ===
Wer seinen Router auch zukünftig auf der [https://map.kbu.freifunk.net Karte] wiederfinden möchte sollte dem Router noch einen Nickname und Koordinaten spendieren. Außerdem ist es sinnvoll, für Kontaktanfragen eine E-Mailadresse zu hinterlegen. Hierzu muss der Router noch einmal manuell im [[Gluon_Config_Mode | Config Mode]] neu gestartet werden.

=== Fragen? ===

Solltest Du Fragen zur Einrichtung des Routers haben oder Einträge Deines Knoten ändern wollen, schreibe gerne an unsere [[Mailingliste|E-Mail]]. Gerne kannst Du auch bei unseren regelmäßigen Treffen in Bonn oder Köln vorbeischauen.

{{TOCright}}

===Logos===
An die unverwechselbaren Vorlagen/Vorgaben von https://wiki.freifunk.net/Freifunk-Styles sollten wir uns imho schon halten :)

Dateien extern, weil Dateiupload im Wiki noch nicht freigeschaltet ist.
* [http://cerberon.net/~egeist/kbu/logo_raw/v2.kbu.png Version 2] als PNG
* [http://cerberon.net/~egeist/kbu/logo_raw/v3.kbu.png Version 3] als PNG

Auf Basis von
* [http://wiki.freifunk.net/Datei:Freifunk_Hotspot_Sticker.png Freifunk_Hotspot_Sticker.png]
und mit den Wünschen von zwei gewerbsmäßigen Freifunk-Nutzern ist Folgendes entstanden:
* [http://wiki.freifunk.net/images/c/c9/Freifunk_Free-WiFi-spot_Sticker.png Freifunk_Free-WiFi-spot_Sticker.png]
was auf Basis einer eigens neu erstellten SVG-Datei zu folgendem PDF führt:
* [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Freifunk_Free-WiFi-spot.pdf] ([http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Versionsverwaltung hier])

Übergangsweise werden als Hinweis und Werbung einfache Farbausdrucke innen an die Glastüren bzw. Schaufensterscheiben geklebt. Das hält natürlich nur, bis der Fensterputzer das nächste Mal vorbei kommt.

So sieht das dann aus: [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot_Baeckerei.jpg Freifunk_Free-WiFi-spot_Baeckerei.jpg]

Für den Druck von Aufklebern benötigt man i.d.R. CMYK Dateien, die mit dem Tool Scribus aus der SVG-Datei erzeugt werden können.

Leider scheint das Drucken von Scheibenaufklebern (Bild auf der Klebeseite) aber eine zunächst teuere Angelegenheit zu sein, da Kleinstmengen nicht möglich sind:

Bestes aktuell vorhandenes Angebot: konstanter Preis von 127,74€ (netto) bis 275 Stück Abnahme, erst bei mehr wird dann etwas rabbatiert. Mehr als 100 werden wir in nächster Zeit im Raum KBU aber wohl nicht benötigen.
Anfragen zum Freifunk_Free-WiFi-spot_Sticker bitte an [[Benutzer:nunatak|nunatak]].

===Flyer===

* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/flyer_ffkbu_v5_jhonny.bee.pdf Flyer von Jhonny.bee als PDF] (Hinweis: Wegen der nicht mehr zu bewerbenden info@-Kontaktadresse - Mailingliste ist besser - und der fehlerhaft attributierten register-Map bitte nicht mehr verteilen!)
* neuere Version: [http://wiki.freifunk.net/Datei:KBU-Bonn-Freifunk-Nachbar-Flyer.pdf Flyer als PDF] mit Knoten-Karte der Bonner Altstadt von Januar 2015 (Initiative von G3ntleman in Zusammenarbeit mit Bene, Simon und Nunatak). Diese Flyer (professionell gedruckt) sind bei unseren Treffen erhältlich.

===Vortrag===

* [https://goo.gl/4Zu396 Freifunk-Vortrag] von Simon, gehalten @ Socialbar als 10 Minuten-Vortrag mit anschließender Diskussion.

===Plakate===

* [http://media.freifunk.net/u/simon/m/freifunk-kbu-plakat/ Plakate] in Format A0 können im Netzladen abgegriffen werden. Jeder der Orte weiß sie werbewirksam aufzuhängen ist aufgerufen sich welche abzuholen.

===Aufkleber===

* [[Benutzer:g3ntleman|g3ntleman]] hat [http://kbu.freifunk.net/wiki/images/8/84/Freifunk-KBU-Hotspot-Hochkant.pdf.zip Aufkleber] produzieren lassen, um auf ein Freifunk WLAN hinzuweisen. Es gibt noch welche - meldet euch auf der Mailingliste, wenn ihr welche bekommen möchtet.

====Gewerbe====
Bitte mit [[Benutzer:EGeist|eGeist]] Kontakt aufnehmen, zwecks Koordinierung und Erstellung von Vorlagen.

[[Datei:Aufkleber Gewerbe v1.0.png|thumb|400px|links|Vorschlag/Entwurf]]
Hier ein Entwurf um ggf. einen Anreiz für Gewerbetreibende zu schaffen, einen Uplink zur Verfügung zu stellen. (Prestige)
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.pdf Entwurf als PDF]
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.odp Entwurf als OpenDocument Folie .odp]
Ggf. sollte die Überlegung einfließen, ob Gewerbetreibende ihre Kunden wirlkich Duzen wollen.

[[Datei:A4-Kurzinfo-Geschaeft.png|thumb|400px|links|Eine von [[Benutzer:Echse|Echse]] modifizierte Version des Entwurfes findet sich (als LaTeX/pdf) [https://github.com/Echsecutor/Freifunk-Huerth-Pr/tree/master/A4-Kurzinfo-Geschaeft hier].]]
 

=== Node Labels ===
[[Datei:Node-Labels_Brother_Ptouch.png]]
* Für Brother P-Touch
* [[Datei:Node-Labels Brother Ptouch.zip]]
[[Kategorie:internes]]

{{TOCright}}

===Logos===
An die unverwechselbaren Vorlagen/Vorgaben von https://wiki.freifunk.net/Freifunk-Styles sollten wir uns imho schon halten :)

Dateien extern, weil Dateiupload im Wiki noch nicht freigeschaltet ist.
* [http://cerberon.net/~egeist/kbu/logo_raw/v2.kbu.png Version 2] als PNG
* [http://cerberon.net/~egeist/kbu/logo_raw/v3.kbu.png Version 3] als PNG

Auf Basis von
* [http://wiki.freifunk.net/Datei:Freifunk_Hotspot_Sticker.png Freifunk_Hotspot_Sticker.png]
und mit den Wünschen von zwei gewerbsmäßigen Freifunk-Nutzern ist Folgendes entstanden:
* [http://wiki.freifunk.net/images/c/c9/Freifunk_Free-WiFi-spot_Sticker.png Freifunk_Free-WiFi-spot_Sticker.png]
was auf Basis einer eigens neu erstellten SVG-Datei zu folgendem PDF führt:
* [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Freifunk_Free-WiFi-spot.pdf] ([http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Versionsverwaltung hier])

Übergangsweise werden als Hinweis und Werbung einfache Farbausdrucke innen an die Glastüren bzw. Schaufensterscheiben geklebt. Das hält natürlich nur, bis der Fensterputzer das nächste Mal vorbei kommt.

So sieht das dann aus: [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot_Baeckerei.jpg Freifunk_Free-WiFi-spot_Baeckerei.jpg]

Für den Druck von Aufklebern benötigt man i.d.R. CMYK Dateien, die mit dem Tool Scribus aus der SVG-Datei erzeugt werden können.

Leider scheint das Drucken von Scheibenaufklebern (Bild auf der Klebeseite) aber eine zunächst teuere Angelegenheit zu sein, da Kleinstmengen nicht möglich sind:

Bestes aktuell vorhandenes Angebot: konstanter Preis von 127,74€ (netto) bis 275 Stück Abnahme, erst bei mehr wird dann etwas rabbatiert. Mehr als 100 werden wir in nächster Zeit im Raum KBU aber wohl nicht benötigen.
Anfragen zum Freifunk_Free-WiFi-spot_Sticker bitte an [[Benutzer:nunatak|nunatak]].

===Flyer===

* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/flyer_ffkbu_v5_jhonny.bee.pdf Flyer von Jhonny.bee als PDF] (Hinweis: Wegen der nicht mehr zu bewerbenden info@-Kontaktadresse - Mailingliste ist besser - und der fehlerhaft attributierten register-Map bitte nicht mehr verteilen!)
* neuere Version: [http://wiki.freifunk.net/Datei:KBU-Bonn-Freifunk-Nachbar-Flyer.pdf Flyer als PDF] mit Knoten-Karte der Bonner Altstadt von Januar 2015 (Initiative von G3ntleman in Zusammenarbeit mit Bene, Simon und Nunatak). Diese Flyer (professionell gedruckt) sind bei unseren Treffen erhältlich.

===Vortrag===

* [https://goo.gl/4Zu396 Freifunk-Vortrag] von Simon, gehalten @ Socialbar als 10 Minuten-Vortrag mit anschließender Diskussion.

===Plakate===

* [http://media.freifunk.net/u/simon/m/freifunk-kbu-plakat/ Plakate] in Format A0 können im Netzladen abgegriffen werden. Jeder der Orte weiß sie werbewirksam aufzuhängen ist aufgerufen sich welche abzuholen.

===Aufkleber===

* [[Benutzer:g3ntleman|g3ntleman]] hat [http://kbu.freifunk.net/wiki/images/8/84/Freifunk-KBU-Hotspot-Hochkant.pdf.zip Aufkleber] produzieren lassen, um auf ein Freifunk WLAN hinzuweisen. Es gibt noch welche - meldet euch auf der Mailingliste, wenn ihr welche bekommen möchtet.

====Gewerbe====
Bitte mit [[Benutzer:EGeist|eGeist]] Kontakt aufnehmen, zwecks Koordinierung und Erstellung von Vorlagen.

[[Datei:Aufkleber Gewerbe v1.0.png|thumb|400px|links|Vorschlag/Entwurf]]
Hier ein Entwurf um ggf. einen Anreiz für Gewerbetreibende zu schaffen, einen Uplink zur Verfügung zu stellen. (Prestige)
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.pdf Entwurf als PDF]
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.odp Entwurf als OpenDocument Folie .odp]
Ggf. sollte die Überlegung einfließen, ob Gewerbetreibende ihre Kunden wirlkich Duzen wollen.

 
[[Datei:A4-Kurzinfo-Geschaeft.png|thumb|400px|rechts|Stotzheimer Entwurf]]
Eine von [[Benutzer:Echse|Echse]] modifizierte Version des Entwurfes findet sich (als LaTeX/pdf) [https://github.com/Echsecutor/Freifunk-Huerth-Pr/tree/master/A4-Kurzinfo-Geschaeft hier].

=== Node Labels ===
[[Datei:Node-Labels_Brother_Ptouch.png]]
* Für Brother P-Touch
* [[Datei:Node-Labels Brother Ptouch.zip]]
[[Kategorie:internes]]

{{TOCright}}

===Logos===
An die unverwechselbaren Vorlagen/Vorgaben von https://wiki.freifunk.net/Freifunk-Styles sollten wir uns imho schon halten :)

Dateien extern, weil Dateiupload im Wiki noch nicht freigeschaltet ist.
* [http://cerberon.net/~egeist/kbu/logo_raw/v2.kbu.png Version 2] als PNG
* [http://cerberon.net/~egeist/kbu/logo_raw/v3.kbu.png Version 3] als PNG

Auf Basis von
* [http://wiki.freifunk.net/Datei:Freifunk_Hotspot_Sticker.png Freifunk_Hotspot_Sticker.png]
und mit den Wünschen von zwei gewerbsmäßigen Freifunk-Nutzern ist Folgendes entstanden:
* [http://wiki.freifunk.net/images/c/c9/Freifunk_Free-WiFi-spot_Sticker.png Freifunk_Free-WiFi-spot_Sticker.png]
was auf Basis einer eigens neu erstellten SVG-Datei zu folgendem PDF führt:
* [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Freifunk_Free-WiFi-spot.pdf] ([http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Versionsverwaltung hier])

Übergangsweise werden als Hinweis und Werbung einfache Farbausdrucke innen an die Glastüren bzw. Schaufensterscheiben geklebt. Das hält natürlich nur, bis der Fensterputzer das nächste Mal vorbei kommt.

So sieht das dann aus: [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot_Baeckerei.jpg Freifunk_Free-WiFi-spot_Baeckerei.jpg]

Für den Druck von Aufklebern benötigt man i.d.R. CMYK Dateien, die mit dem Tool Scribus aus der SVG-Datei erzeugt werden können.

Leider scheint das Drucken von Scheibenaufklebern (Bild auf der Klebeseite) aber eine zunächst teuere Angelegenheit zu sein, da Kleinstmengen nicht möglich sind:

Bestes aktuell vorhandenes Angebot: konstanter Preis von 127,74€ (netto) bis 275 Stück Abnahme, erst bei mehr wird dann etwas rabbatiert. Mehr als 100 werden wir in nächster Zeit im Raum KBU aber wohl nicht benötigen.
Anfragen zum Freifunk_Free-WiFi-spot_Sticker bitte an [[Benutzer:nunatak|nunatak]].

===Flyer===

* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/flyer_ffkbu_v5_jhonny.bee.pdf Flyer von Jhonny.bee als PDF] (Hinweis: Wegen der nicht mehr zu bewerbenden info@-Kontaktadresse - Mailingliste ist besser - und der fehlerhaft attributierten register-Map bitte nicht mehr verteilen!)
* neuere Version: [http://wiki.freifunk.net/Datei:KBU-Bonn-Freifunk-Nachbar-Flyer.pdf Flyer als PDF] mit Knoten-Karte der Bonner Altstadt von Januar 2015 (Initiative von G3ntleman in Zusammenarbeit mit Bene, Simon und Nunatak). Diese Flyer (professionell gedruckt) sind bei unseren Treffen erhältlich.

===Vortrag===

* [https://goo.gl/4Zu396 Freifunk-Vortrag] von Simon, gehalten @ Socialbar als 10 Minuten-Vortrag mit anschließender Diskussion.

===Plakate===

* [http://media.freifunk.net/u/simon/m/freifunk-kbu-plakat/ Plakate] in Format A0 können im Netzladen abgegriffen werden. Jeder der Orte weiß sie werbewirksam aufzuhängen ist aufgerufen sich welche abzuholen.

===Aufkleber===

* [[Benutzer:g3ntleman|g3ntleman]] hat [http://kbu.freifunk.net/wiki/images/8/84/Freifunk-KBU-Hotspot-Hochkant.pdf.zip Aufkleber] produzieren lassen, um auf ein Freifunk WLAN hinzuweisen. Es gibt noch welche - meldet euch auf der Mailingliste, wenn ihr welche bekommen möchtet.

====Gewerbe====
Bitte mit [[Benutzer:EGeist|eGeist]] Kontakt aufnehmen, zwecks Koordinierung und Erstellung von Vorlagen.

[[Datei:Aufkleber Gewerbe v1.0.png|thumb|400px|links|Vorschlag/Entwurf]]
Hier ein Entwurf um ggf. einen Anreiz für Gewerbetreibende zu schaffen, einen Uplink zur Verfügung zu stellen. (Prestige)
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.pdf Entwurf als PDF]
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.odp Entwurf als OpenDocument Folie .odp]
Ggf. sollte die Überlegung einfließen, ob Gewerbetreibende ihre Kunden wirlkich Duzen wollen.

[[Datei:A4-Kurzinfo-Geschaeft.png|thumb|400px|rechts|Stotzheimer Entwurf]]
Eine von [[Benutzer:Echse|Echse]] modifizierte Version des Entwurfes findet sich (als LaTeX/pdf) [https://github.com/Echsecutor/Freifunk-Huerth-Pr/tree/master/A4-Kurzinfo-Geschaeft hier].

=== Node Labels ===
[[Datei:Node-Labels_Brother_Ptouch.png]]
* Für Brother P-Touch
* [[Datei:Node-Labels Brother Ptouch.zip]]
[[Kategorie:internes]]

{{TOCright}}

===Logos===
An die unverwechselbaren Vorlagen/Vorgaben von https://wiki.freifunk.net/Freifunk-Styles sollten wir uns imho schon halten :)

Dateien extern, weil Dateiupload im Wiki noch nicht freigeschaltet ist.
* [http://cerberon.net/~egeist/kbu/logo_raw/v2.kbu.png Version 2] als PNG
* [http://cerberon.net/~egeist/kbu/logo_raw/v3.kbu.png Version 3] als PNG

Auf Basis von
* [http://wiki.freifunk.net/Datei:Freifunk_Hotspot_Sticker.png Freifunk_Hotspot_Sticker.png]
und mit den Wünschen von zwei gewerbsmäßigen Freifunk-Nutzern ist Folgendes entstanden:
* [http://wiki.freifunk.net/images/c/c9/Freifunk_Free-WiFi-spot_Sticker.png Freifunk_Free-WiFi-spot_Sticker.png]
was auf Basis einer eigens neu erstellten SVG-Datei zu folgendem PDF führt:
* [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Freifunk_Free-WiFi-spot.pdf] ([http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot.pdf Versionsverwaltung hier])

Übergangsweise werden als Hinweis und Werbung einfache Farbausdrucke innen an die Glastüren bzw. Schaufensterscheiben geklebt. Das hält natürlich nur, bis der Fensterputzer das nächste Mal vorbei kommt.

So sieht das dann aus: [http://wiki.freifunk.net/Datei:Freifunk_Free-WiFi-spot_Baeckerei.jpg Freifunk_Free-WiFi-spot_Baeckerei.jpg]

Für den Druck von Aufklebern benötigt man i.d.R. CMYK Dateien, die mit dem Tool Scribus aus der SVG-Datei erzeugt werden können.

Leider scheint das Drucken von Scheibenaufklebern (Bild auf der Klebeseite) aber eine zunächst teuere Angelegenheit zu sein, da Kleinstmengen nicht möglich sind:

Bestes aktuell vorhandenes Angebot: konstanter Preis von 127,74€ (netto) bis 275 Stück Abnahme, erst bei mehr wird dann etwas rabbatiert. Mehr als 100 werden wir in nächster Zeit im Raum KBU aber wohl nicht benötigen.
Anfragen zum Freifunk_Free-WiFi-spot_Sticker bitte an [[Benutzer:nunatak|nunatak]].

===Flyer===

* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/flyer_ffkbu_v5_jhonny.bee.pdf Flyer von Jhonny.bee als PDF] (Hinweis: Wegen der nicht mehr zu bewerbenden info@-Kontaktadresse - Mailingliste ist besser - und der fehlerhaft attributierten register-Map bitte nicht mehr verteilen!)
* neuere Version: [http://wiki.freifunk.net/Datei:KBU-Bonn-Freifunk-Nachbar-Flyer.pdf Flyer als PDF] mit Knoten-Karte der Bonner Altstadt von Januar 2015 (Initiative von G3ntleman in Zusammenarbeit mit Bene, Simon und Nunatak). Diese Flyer (professionell gedruckt) sind bei unseren Treffen erhältlich.

===Vortrag===

* [https://goo.gl/4Zu396 Freifunk-Vortrag] von Simon, gehalten @ Socialbar als 10 Minuten-Vortrag mit anschließender Diskussion.

===Plakate===

* [http://media.freifunk.net/u/simon/m/freifunk-kbu-plakat/ Plakate] in Format A0 können im Netzladen abgegriffen werden. Jeder der Orte weiß sie werbewirksam aufzuhängen ist aufgerufen sich welche abzuholen.

===Aufkleber===

* [[Benutzer:g3ntleman|g3ntleman]] hat [http://kbu.freifunk.net/wiki/images/8/84/Freifunk-KBU-Hotspot-Hochkant.pdf.zip Aufkleber] produzieren lassen, um auf ein Freifunk WLAN hinzuweisen. Es gibt noch welche - meldet euch auf der Mailingliste, wenn ihr welche bekommen möchtet.

====Gewerbe====
Bitte mit [[Benutzer:EGeist|eGeist]] Kontakt aufnehmen, zwecks Koordinierung und Erstellung von Vorlagen.

Hier ein Entwurf um ggf. einen Anreiz für Gewerbetreibende zu schaffen, einen Uplink zur Verfügung zu stellen. (Prestige)
[[Datei:Aufkleber Gewerbe v1.0.png|thumb|400px|links|Vorschlag/Entwurf]]
 
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.pdf Entwurf als PDF]
* [http://cerberon.net/~egeist/kbu/flyer_u_praesentationen/Aufkleber_Gewerbe.odp Entwurf als OpenDocument Folie .odp]

Ggf. sollte die Überlegung einfließen, ob Gewerbetreibende ihre Kunden wirlkich Duzen wollen.

Eine von [[Benutzer:Echse|Echse]] modifizierte Version des Entwurfes findet sich (als LaTeX/pdf) [https://github.com/Echsecutor/Freifunk-Huerth-Pr/tree/master/A4-Kurzinfo-Geschaeft hier].

=== Node Labels ===
[[Datei:Node-Labels_Brother_Ptouch.png]]
* Für Brother P-Touch
* [[Datei:Node-Labels Brother Ptouch.zip]]
[[Kategorie:internes]]

Kategorie:Mitmachen

2015-09-04T07:26:11Z

Echse:

In dieser Kategorie finden sich die How-Tos und Do-It-Yoursefl Anleitungen. Als einstieg empfiehlt sich die [[Mitmachen | gleichnamige Wiki-Seite]]. ;)

Kategorie:Mitmachen

2015-09-04T07:24:05Z

Echse: Die Seite wurde neu angelegt: „In dieser Kategorie finden sich die How-Tos und Do-It-Yoursefl Anleitungen.“

In dieser Kategorie finden sich die How-Tos und Do-It-Yoursefl Anleitungen.

Gluon Config Mode

2015-08-31T11:14:51Z

Echse: init. remake der Config_Mode Seite für gluon

Grundsätzlich ist unsere Freifunk Firmware so konzipiert, dass der Betreiber eines Nodes keinerlei Konfigurationsarbeiten durchführen muss. Das bedeutet, nach dem Aufspielen unserer Firmware, kann der Betreiber direkt loslegen und ist Teil unseres Freifunk-Netzwerkes. Allerdings empfiehlt es sich dem eigenen Router zumindest noch einen Nickname und Koordinaten zu geben, um diesen auf der [https://map.kbu.freifunk.net Karte] wieder zu finden.

Es ist weiterhin möglich, ein Passwort zu setzen (oder einen ssh public key zu hinterlegen) um den Node per Fernzugriff zu warten. Diese Option macht das manuelle Neustarten im Config Mode wie hier beschrieben in Zukunft überflüssig.
Wer dann noch mehr coole Dinge ausprobieren möchte kann unter [[Pimp my Node]] stöbern, sobald ein Fernzugriff wie hier beschrieben eingerichtet wurde.

=Config Mode=
==Knöpfe drücken==
Zunächst wird der PC mit dem Router über Netzwerkkabel verbunden (gelbe LAN Ports am Router).

{|class="wikitable center"
|-
[[File:wr741nd_pi4-5.jpg|center|thumb|800px]]
|-
[[File:Back-of-TL-WR841N-v9.jpg|center|thumb|800px]]
|}

Wenn der Router gestartet ist drückst du die QSS Taste (schwarzer Knopf) ca 6-10 Sekunden (bis der Router neu startet, das sieht man daran, dass alle Lampen einmal an- und ausgehen). Bei den neueren Versionen des TL-WR841N(D) heißt die zu drückende Taste "WPS/RESET".
#bei manchen Routern (z.B. bei älteren Modellen des WR841N) muss man jetzt das Netzwerkkabel am Router umstecken (blauer WAN Port)
#Abwarten, bis der PC eine neue LAN-Verbindung aufgebaut hat (DHCP ist aktivieren, evtl. WLAN am PC deaktivieren)
#Adresse http://192.168.1.1 aufrufen.

==Web GUI==
Wenn im letzten Schritt alles geklappt hat sollte unter http://192.168.1.1 das hier zu sehen sein:

[[File:Gluon-config-welcome.png|center|thumb|800px]]

===Fernzugriff einrichten===
Wenn Du einen ssh-key hinterlegen oder einen Nutzername/Passwort für die Fernwartung konfigurieren willst (um beim nächsten mal nicht wieder per Knopfdruck in den Config Mode wechseln zu müssen) solltest Du das zuerst unter ''Expert Mode'' (link rechts oben) -> ''Remote access tun'', bevor Du die Daten auf der Wizard Seite einträgst.

[[File:Gluon-config-expert-mode.png|center|thumb|800px]]

Das hinterlegen eines Schlüssels ist sicherer und komfortabler (zumindest für Linux Nutzer). Mehr Infos gibt's z.B. [http://rcsg-gsir.imsb-dsgi.nrc-cnrc.gc.ca/documents/internet/node31.html hier].

===Nickname und Koordinaten eingeben===
Nachdem evtl. der Fernzugriff eingerichtet wurden kehrst Du auf die ''Wizard'' Seite (link rechts oben) zurück. Hier gibst Du einen beliebigen '''Node name''' ein und wählst '''Show node on the map''' aus.

[[File:Gluon-config-coords.png|center|thumb|800px]]

Die Ziel-Koordinaten (Latitde/Longitude) an denen der Router stehen soll findest Du z.B. im Kartendienst Deiner Wahl. Z.B. unter https://www.openstreetmap.org Adresse suchen, '''Query Features''' (Fragezeichen rechts unten) anklicken und dann bis zum nächsten Node durchwurschteln. Im Bild unten wäre Location: 50.9184406, 6.9188078 die gewünschte Info.

[[File:Osm-screen-shot.png|center|thumb|800px]]

* Altitude (Höhe) ist nicht zwingend erforderlich, aber bei mehreren Routern in einem Hochhaus vielleicht hilfreich.

* Contact info kann angegeben werden, wird aber veröffentlicht

* Ein Klick auf Save & Restart führt erwartungsgemäß zum Neustart mit den gemachten Änderungen. Sobald der Router neugestartet und wieder über den '''blauen''' Port richtung Internet verbunden ist sollte er nach wenigen Minuten mit neuem Namen und Koordinaten auf der [https://map.kbu.freifunk.net Karte] auftauchen.

Datei:Osm-screen-shot.png

2015-08-31T11:06:10Z

Echse:

Datei:Gluon-config-coords.png

2015-08-31T11:01:17Z

Echse:

Datei:Gluon-config-expert-mode.png

2015-08-31T10:52:39Z

Echse:

Datei:Gluon-config-welcome.png

2015-08-31T10:46:37Z

Echse:

Datei:Back-of-TL-WR841N-v9.jpg

2015-08-31T10:39:51Z

Echse:

Pimp my Node

2015-08-31T10:33:04Z

Echse: Disclaimer aus der Config_Mode hierher verschoeben. Über die web-Gui kann man wohl kaum viel kaputt machen. ;)

Pimp my Node

2015-08-31T10:25:39Z

Echse: hint: gluon docu

[[Kategorie:Mitmachen]]

Hier finden sich interessante Optionen für etwas versiertere Nutzer. Wer Gluon verwendet sollte unbedingt auch Gluon spezifische Resourcen, wie http://gluon.readthedocs.org , zu Rate ziehen.

== Netztheorie/Technik und Entwicklung ==
Vertiefung

*[[FSM-Dynamisches-Bridging]]
*[[Batman_adv]]
*[[Entwicklung]]
*[[Firmware|Firmware/Betriebssystem]]

== Arbeiten auf der Shell ==
Vorraussetzung 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.

=== IPv6 ping ===
<pre>
ping6 <link local Adresse des Nodes>%eth0
</pre>

=== IPv6 ssh ===
Hinter der link local Adresse "%" + "Netzwerk Interface an eurer Kiste" (Hier im Beispiel eth0)
<pre>
ssh root@<link local Adresse des Nodes>%eth0
</pre>

=== Hostnamen des Nodes ändern ===
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.

=== Node überträgt keine Statistiken ===
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:
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:
<pre>config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'</pre>
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels ''reboot'' wirksam.
Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.

==== 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>

=== 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.
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>
scp -6 id_rsa4096.pub root@[<link local Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
</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:
<pre>
cat ~/.ssh/id_rsa4096.pub | ssh root@[<link local Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
</pre>

Sollte beim Kopierversuch die Meldung
<pre>ssh: Could not resolve hostname fe80:</pre>
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive 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.

=== Paßwort-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).
Falls das erfolgreich funktioniert, kann man die Datei ''/etc/config/dropbear'' wie folgt ändern:
<pre>config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'</pre>
Nach einem Neustart des Routers mittels ''reboot'' sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Rotuer einzuloggen.

=== Firmware aktualisieren ===
==== Node mit uplink ====

<pre>
ssh root@<link local Adresse des Nodes>%eth0 // SSH Verbindung zum Node aufbauen, eth0 ist das lokale Interface, ggf. durch wlan0 etc. ersetzen
cd ../tmp/ // in das Verzeichnis "tmp" wechseln
free // Freien Speicher prüfen
wget http://pfad/zur/firmware.bin // Firmware herunterladen und dann
sysupgrade -v firmware.bin // Firmware-Upgrade durchführen
</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.

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

=== Node ''zu Fuß'' updaten ===
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.

=== 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.

==== 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.

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:
#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).
#config interface 'mesh_lan' -> kompl. codeblock hinzugefügt, dieser bewirkt das über ethX (switch) gemeshed wird.

<pre>
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'
</pre>

''vim /etc/config/wireless'' - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist auskommentiert (optional)
<pre>
#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
</pre>

==== TL-WDR4300 ====
Das gleiche nochmal für den 4300er

''vim /etc/config/network''
<pre>
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'

</pre>

== 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:

# 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 kein Webinterface, 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.

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:

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:
ssh root@LinkLocalIPv6adresse_des_routers%Interface
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 zum Webinterface 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:
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 Zugang Erfahrung 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 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.
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.)

Blablabla, jetzt geht es los:
Das ganze habe ich mit einem 1043ND und einem droid 2.3CM7 Telefon und einem droid 2.2 Tablet ausprobiert, sollte aber auf jeglichen OpenWrt Router mit USB, Android USB tethering fähigem Gerät und einfachen USB ethernet Adaptern (nachprüfen!!!) funktionieren:

- Per ssh in den router einloggen
- Installieren der notwendigen Treiber

<pre>
opkg update
opkg install kmod-usb-uhci kmod-usb-net-rndis
</pre>

Dies sollte, falls ihr noch keine USB Unterstützung in der Firmware hat auch diese über dependencies 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:

<pre>
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
</pre>

Auch unter Luci sollte dies konfigurierbar sein.

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

<pre>
ifup wan2
</pre>
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)

== Zusätzlich zum Freifunk auch privates WLAN einrichten ==

Es ist möglich ein privates WLAN anzulegen, das mit dem WAN Port gebridged und separat zum Mesh Netzwerk ist. (Bitte beachten, dass Mesh on Wan nicht zeitgleich mit aktiviert werden sollte.)
Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt.
Das private WLAN kann per SSH in der Konsole aktiviert werden:
<pre>
uci set wireless.wan_radio0=wifi-iface
uci set wireless.wan_radio0.device=radio0
uci set wireless.wan_radio0.network=wan
uci set wireless.wan_radio0.mode=ap
uci set wireless.wan_radio0.encryption=psk2
uci set wireless.wan_radio0.ssid="$SSID"
uci set wireless.wan_radio0.key="$KEY"
uci set wireless.wan_radio0.disabled=0
uci commit
wifi
</pre>
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden.
Zum deaktivieren des Ganzen wie folgt vorgehen:
<pre>
uci set wireless.wan_radio0.disabled=1
uci commit
wifi
</pre>

KBU Gluon Firmware

2015-08-31T10:19:40Z

Echse: url

[[Kategorie:Mitmachen]]

Auf dieser Seite wird erläutert, wie du die aktuelle Gluon Firmware auf einen frischen Router installierst, d.h. die original Firmware durch Gluon ersetzt. Letztere befindet sich im Beta-Status, alternativ kann weiterhin die stabile [[KBU_Classic_Firmware]] (fast) uneingeschränkt verwendet werden.

== Freifunk Firmware installieren ==
=== Freifunk Firmware auswählen ===
Die Firmware ist vom Router-Modell abhängig. Das Modell und die Versionsnummer deines Routers findest du auf der Rückseite des Gerätes.

[[Datei:wr741nd_pi3.jpg||400px|thumb|center]]

[[Benutzer:Rampone |Rampone]] stellt unter https://213.165.82.133/images/factory/ die aktuellen Gluon builds bereit. Hier einfach anhand der Dateiendung die zu deinem Modell passende Version auswählen.

Hinweis: Das optionale (D) in der Produktbezeichnung steht für die Produktvariante mit auswechselbaren Antennen, was den Router ein paar Euro teuerer macht. Von den Antennen abgesehen ist die Hardware die selbe, dementsprechend gibt es nur eine Firmware für die Modelle mit und ohne (D).

Nach dem Herunterladen der Firmware ist es grundsätzlich sinnvoll die [[Überprüfen der Signatur|Signatur der Datei zu überprüfen]]. Während des Gluon Beta-Tests werden jedoch nicht alle Versionen signiert.

=== Router mit dem Computer verbinden ===
Dafür solltest du Deinen Router mit Strom versorgen sowie die Netzwerkkarte deines PC mit einen der gelben Ports des Routers verbinden, hier reicht ein handelsübliches LAN Kabel. Am PC muss die Netzwerkkarte auf Automatische IP-Adresse beziehen (DHCP) eingestellt sein und WLAN sollte vorübergehend deaktiviert werden.<ref name="wlanOff">Da der Router (noch) nicht mit dem Internet verbunden ist könnte euer Rechner (je nach Setup) versuchen sich über WLAN mit evtl. bestehenden Funknetzen zu verbinden, obwohl ein LAN Kabel angeschlossen ist.</ref>

=== Freifunk Firmware einspielen ===
Jetzt kannst du den Router einfach über den Browser konfigurieren.

Dazu rufst du in deinen Browser die auf der Router Rückseite angegebene Adresse auf, in der Regel http://192.168.1.1 oder http://tplinklogin.net .

Bevor du weitermachst, musst du dich erst anmelden. Die Standrad-Username / -Passwort Kombination ist ebenfalls auf der Routerrückseite zu finden, in der Regel: admin / admin

Dein Browserfenster müsste nun so aussehen – Folge hier dem Link "System Tools".

[[File:TP_link_01_start.png|center|thumb|800px]]

Als nächste wählst du aus dem Menü "Firmware Upgrade" (1). Danach kannst du die vorhin (in Schritt 2) geladene Datei zum Hochladen auswählen (2). Nach einem Klick auf "Upgrade" (3) beginnt der Prozess.

[[File:TP_link_02_firmware.png|center|thumb|800px]]

Du musst noch einmal kurz bestätigen …

[[File:TP_link_03_firmware_file.png|center|thumb|800px]]

… und die Installation läuft. Während die Installation läuft, zieh bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel – denn dann ist dein Router hinüber.

[[File:TP_link_04_upgrade_progress.png|center|thumb|800px]]

'''Bei TL-WR841N v8.4:''' Beim Flashen über das Firmware-Upgrade der Original-Firmware tritt ggf. folgender Fehler auf:
''Error code: 23002''
''The uploaded file name is too long!''
Hier hilft einfaches Umbenennen der herunter geladenen Freifunk-Firmware.

Nachdem die Firmware fertig eingespielt ist, startet der Router automatisch neu.

Dass der Router neu startet merkst du auch am kurzen Aufblinken der Lämpchen an deinem Router.

[[File:TP_link_05_firmware_reboot_finished.png|center|thumb|800px]]

Jetzt ist der Router nicht mehr unter der angegeben Adresse sichtbar und eine Fehlermeldung erscheint. Das ist gut so. Denn nun läuft nicht mehr die alte Firmware sondern die neue, tolle Freifunk Firmware auf deinem Router.

=== Anschluss ans Internet ===
Nach dem automatischen Neustart ist der Router direkt im Normalbetrieb. Wenn keine weiteren Freifunk-Router in der dirkten Umgebung sind, musst Du allerdings den Freifunk-Router noch per Ethernetkabel mit Deinem Internet-Router verbinden, damit der Freifunk-Router auch Internet-Zugriff gewährt. Dazu wird der '''blaue''' Port des Freiunk-Routers mit dem Gästenetz-Port Deines Internet-Routers verbunden. Falls Du dort kein Gästenetz eingerichtet hast oder das gar nicht geht, tut's auch ein "normaler" LAN-Port Deines Routers, wo Du auch deinen Laptop etc. einstöpseln würdest. Ein Gästenetz wäre nur noch etwas sicherer. Eventuell musst Du die Filterregeln für das Gästenetz anpassen, da manche Router in der Standardkonfiguration nur bestimmte Ports freigegeben haben.

'''WICHTIG:''' Wer hier in einer Firma oder gar einer städtischen Einrichtung ''mal eben'' einen Freifunk-Router an deren Intranet anschließt, schadet damit unter Umständen dem Freifunk-Projekt, da das nicht unbemerkt bleibt und fast immer gegen interne Sicherheitsrichtlinien verstößt. Sowas muss von der jeweiligen IT-Leitung explizit erlaubt werden. Wir wollen die Verantwortlichen nicht verärgern sondern überzeugen!

=== Installation überprüfen ===
Nach erfolgreichem Boot sollte Dein Router nun ein offenes WLAN mit SSID kbu.freifunk.net anzeigen. Nach wenigen Minuten sollte er bei erfolgreichem Internetanschluss ausserdem auf https://map.kbu.freifunk.net auftauchen. (Als neuer Knoten mit kryptischem Namen unter Aktuelles).

[[File:Map-kbu-fresh-router-screen-shot.png|center|thumb|800px|Hier wurde offenbar vor kurzem ein neuer Router (freifunkXXX) eingerichtet aber noch kein Name vergeben.]]

=== Sinnvolle Ergänzungen ===
Wer seinen Router auch zukünftig auf der [https://map.kbu.freifunk.net Karte] wiederfinden möchte sollte dem Router noch einen Nickname und Koordinaten spendieren. Hierzu muss der Router noch einmal manuell im [[Gluon_Config_Mode | Config Mode]] neu gestartet werden.

=== Fragen? ===

Solltest Du Fragen zur Einrichtung des Routers haben oder Einträge Deines Knoten ändern wollen, schreibe gerne an unsere [[Mailingliste|E-Mail]]. Gerne kannst Du auch bei unseren regelmäßigen Treffen in Bonn oder Köln vorbeischauen.

KBU Gluon Firmware

2015-08-31T10:19:14Z

Echse: url typo

[[Kategorie:Mitmachen]]

Auf dieser Seite wird erläutert, wie du die aktuelle Gluon Firmware auf einen frischen Router installierst, d.h. die original Firmware durch Gluon ersetzt. Letztere befindet sich im Beta-Status, alternativ kann weiterhin die stabile [[KBU_Classic_Firmware]] (fast) uneingeschränkt verwendet werden.

== Freifunk Firmware installieren ==
=== Freifunk Firmware auswählen ===
Die Firmware ist vom Router-Modell abhängig. Das Modell und die Versionsnummer deines Routers findest du auf der Rückseite des Gerätes.

[[Datei:wr741nd_pi3.jpg||400px|thumb|center]]

[[Benutzer:Rampone |Rampone]] stellt unter https://213.165.82.133/images/factory/ die aktuellen Gluon builds bereit. Hier einfach anhand der Dateiendung die zu deinem Modell passende Version auswählen.

Hinweis: Das optionale (D) in der Produktbezeichnung steht für die Produktvariante mit auswechselbaren Antennen, was den Router ein paar Euro teuerer macht. Von den Antennen abgesehen ist die Hardware die selbe, dementsprechend gibt es nur eine Firmware für die Modelle mit und ohne (D).

Nach dem Herunterladen der Firmware ist es grundsätzlich sinnvoll die [[Überprüfen der Signatur|Signatur der Datei zu überprüfen]]. Während des Gluon Beta-Tests werden jedoch nicht alle Versionen signiert.

=== Router mit dem Computer verbinden ===
Dafür solltest du Deinen Router mit Strom versorgen sowie die Netzwerkkarte deines PC mit einen der gelben Ports des Routers verbinden, hier reicht ein handelsübliches LAN Kabel. Am PC muss die Netzwerkkarte auf Automatische IP-Adresse beziehen (DHCP) eingestellt sein und WLAN sollte vorübergehend deaktiviert werden.<ref name="wlanOff">Da der Router (noch) nicht mit dem Internet verbunden ist könnte euer Rechner (je nach Setup) versuchen sich über WLAN mit evtl. bestehenden Funknetzen zu verbinden, obwohl ein LAN Kabel angeschlossen ist.</ref>

=== Freifunk Firmware einspielen ===
Jetzt kannst du den Router einfach über den Browser konfigurieren.

Dazu rufst du in deinen Browser die auf der Router Rückseite angegebene Adresse auf, in der Regel http://192.168.1.1 oder http://tplinklogin.net .

Bevor du weitermachst, musst du dich erst anmelden. Die Standrad-Username / -Passwort Kombination ist ebenfalls auf der Routerrückseite zu finden, in der Regel: admin / admin

Dein Browserfenster müsste nun so aussehen – Folge hier dem Link "System Tools".

[[File:TP_link_01_start.png|center|thumb|800px]]

Als nächste wählst du aus dem Menü "Firmware Upgrade" (1). Danach kannst du die vorhin (in Schritt 2) geladene Datei zum Hochladen auswählen (2). Nach einem Klick auf "Upgrade" (3) beginnt der Prozess.

[[File:TP_link_02_firmware.png|center|thumb|800px]]

Du musst noch einmal kurz bestätigen …

[[File:TP_link_03_firmware_file.png|center|thumb|800px]]

… und die Installation läuft. Während die Installation läuft, zieh bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel – denn dann ist dein Router hinüber.

[[File:TP_link_04_upgrade_progress.png|center|thumb|800px]]

'''Bei TL-WR841N v8.4:''' Beim Flashen über das Firmware-Upgrade der Original-Firmware tritt ggf. folgender Fehler auf:
''Error code: 23002''
''The uploaded file name is too long!''
Hier hilft einfaches Umbenennen der herunter geladenen Freifunk-Firmware.

Nachdem die Firmware fertig eingespielt ist, startet der Router automatisch neu.

Dass der Router neu startet merkst du auch am kurzen Aufblinken der Lämpchen an deinem Router.

[[File:TP_link_05_firmware_reboot_finished.png|center|thumb|800px]]

Jetzt ist der Router nicht mehr unter der angegeben Adresse sichtbar und eine Fehlermeldung erscheint. Das ist gut so. Denn nun läuft nicht mehr die alte Firmware sondern die neue, tolle Freifunk Firmware auf deinem Router.

=== Anschluss ans Internet ===
Nach dem automatischen Neustart ist der Router direkt im Normalbetrieb. Wenn keine weiteren Freifunk-Router in der dirkten Umgebung sind, musst Du allerdings den Freifunk-Router noch per Ethernetkabel mit Deinem Internet-Router verbinden, damit der Freifunk-Router auch Internet-Zugriff gewährt. Dazu wird der '''blaue''' Port des Freiunk-Routers mit dem Gästenetz-Port Deines Internet-Routers verbunden. Falls Du dort kein Gästenetz eingerichtet hast oder das gar nicht geht, tut's auch ein "normaler" LAN-Port Deines Routers, wo Du auch deinen Laptop etc. einstöpseln würdest. Ein Gästenetz wäre nur noch etwas sicherer. Eventuell musst Du die Filterregeln für das Gästenetz anpassen, da manche Router in der Standardkonfiguration nur bestimmte Ports freigegeben haben.

'''WICHTIG:''' Wer hier in einer Firma oder gar einer städtischen Einrichtung ''mal eben'' einen Freifunk-Router an deren Intranet anschließt, schadet damit unter Umständen dem Freifunk-Projekt, da das nicht unbemerkt bleibt und fast immer gegen interne Sicherheitsrichtlinien verstößt. Sowas muss von der jeweiligen IT-Leitung explizit erlaubt werden. Wir wollen die Verantwortlichen nicht verärgern sondern überzeugen!

=== Installation überprüfen ===
Nach erfolgreichem Boot sollte Dein Router nun ein offenes WLAN mit SSID kbu.freifunk.net anzeigen. Nach wenigen Minuten sollte er bei erfolgreichem Internetanschluss ausserdem auf https://map.kbu.freifunk.net auftauchen. (Als neuer Knoten mit kryptischem Namen unter Aktuelles).

[[File:Map-kbu-fresh-router-screen-shot.png|center|thumb|800px|Hier wurde offenbar vor kurzem ein neuer Router (freifunkXXX) eingerichtet aber noch kein Name vergeben.]]

=== Sinnvolle Ergänzungen ===
Wer seinen Router auch zukünftig auf der [http://map.kbu.freifunk.net/geomap.html Karte] wiederfinden möchte sollte dem Router noch einen Nickname und Koordinaten spendieren. Hierzu muss der Router noch einmal manuell im [[Gluon_Config_Mode | Config Mode]] neu gestartet werden.

=== Fragen? ===

Solltest Du Fragen zur Einrichtung des Routers haben oder Einträge Deines Knoten ändern wollen, schreibe gerne an unsere [[Mailingliste|E-Mail]]. Gerne kannst Du auch bei unseren regelmäßigen Treffen in Bonn oder Köln vorbeischauen.

KBU Gluon Firmware

2015-08-31T10:18:06Z

Echse: Init. Im wesentlichen von der Classic Seite kopiert und angepasst.

[[Kategorie:Mitmachen]]

Auf dieser Seite wird erläutert, wie du die aktuelle Gluon Firmware auf einen frischen Router installierst, d.h. die original Firmware durch Gluon ersetzt. Letztere befindet sich im Beta-Status, alternativ kann weiterhin die stabile [[KBU_Classic_Firmware]] (fast) uneingeschränkt verwendet werden.

== Freifunk Firmware installieren ==
=== Freifunk Firmware auswählen ===
Die Firmware ist vom Router-Modell abhängig. Das Modell und die Versionsnummer deines Routers findest du auf der Rückseite des Gerätes.

[[Datei:wr741nd_pi3.jpg||400px|thumb|center]]

[[Benutzer:Rampone |Rampone]] stellt unter https://213.165.82.133/images/factory/ die aktuellen Gluon builds bereit. Hier einfach anhand der Dateiendung die zu deinem Modell passende Version auswählen.

Hinweis: Das optionale (D) in der Produktbezeichnung steht für die Produktvariante mit auswechselbaren Antennen, was den Router ein paar Euro teuerer macht. Von den Antennen abgesehen ist die Hardware die selbe, dementsprechend gibt es nur eine Firmware für die Modelle mit und ohne (D).

Nach dem Herunterladen der Firmware ist es grundsätzlich sinnvoll die [[Überprüfen der Signatur|Signatur der Datei zu überprüfen]]. Während des Gluon Beta-Tests werden jedoch nicht alle Versionen signiert.

=== Router mit dem Computer verbinden ===
Dafür solltest du Deinen Router mit Strom versorgen sowie die Netzwerkkarte deines PC mit einen der gelben Ports des Routers verbinden, hier reicht ein handelsübliches LAN Kabel. Am PC muss die Netzwerkkarte auf Automatische IP-Adresse beziehen (DHCP) eingestellt sein und WLAN sollte vorübergehend deaktiviert werden.<ref name="wlanOff">Da der Router (noch) nicht mit dem Internet verbunden ist könnte euer Rechner (je nach Setup) versuchen sich über WLAN mit evtl. bestehenden Funknetzen zu verbinden, obwohl ein LAN Kabel angeschlossen ist.</ref>

=== Freifunk Firmware einspielen ===
Jetzt kannst du den Router einfach über den Browser konfigurieren.

Dazu rufst du in deinen Browser die auf der Router Rückseite angegebene Adresse auf, in der Regel http://192.168.1.1 oder http://tplinklogin.net .

Bevor du weitermachst, musst du dich erst anmelden. Die Standrad-Username / -Passwort Kombination ist ebenfalls auf der Routerrückseite zu finden, in der Regel: admin / admin

Dein Browserfenster müsste nun so aussehen – Folge hier dem Link "System Tools".

[[File:TP_link_01_start.png|center|thumb|800px]]

Als nächste wählst du aus dem Menü "Firmware Upgrade" (1). Danach kannst du die vorhin (in Schritt 2) geladene Datei zum Hochladen auswählen (2). Nach einem Klick auf "Upgrade" (3) beginnt der Prozess.

[[File:TP_link_02_firmware.png|center|thumb|800px]]

Du musst noch einmal kurz bestätigen …

[[File:TP_link_03_firmware_file.png|center|thumb|800px]]

… und die Installation läuft. Während die Installation läuft, zieh bitte auf keinen Fall den Stecker oder das Netzwerk-Kabel – denn dann ist dein Router hinüber.

[[File:TP_link_04_upgrade_progress.png|center|thumb|800px]]

'''Bei TL-WR841N v8.4:''' Beim Flashen über das Firmware-Upgrade der Original-Firmware tritt ggf. folgender Fehler auf:
''Error code: 23002''
''The uploaded file name is too long!''
Hier hilft einfaches Umbenennen der herunter geladenen Freifunk-Firmware.

Nachdem die Firmware fertig eingespielt ist, startet der Router automatisch neu.

Dass der Router neu startet merkst du auch am kurzen Aufblinken der Lämpchen an deinem Router.

[[File:TP_link_05_firmware_reboot_finished.png|center|thumb|800px]]

Jetzt ist der Router nicht mehr unter der angegeben Adresse sichtbar und eine Fehlermeldung erscheint. Das ist gut so. Denn nun läuft nicht mehr die alte Firmware sondern die neue, tolle Freifunk Firmware auf deinem Router.

=== Anschluss ans Internet ===
Nach dem automatischen Neustart ist der Router direkt im Normalbetrieb. Wenn keine weiteren Freifunk-Router in der dirkten Umgebung sind, musst Du allerdings den Freifunk-Router noch per Ethernetkabel mit Deinem Internet-Router verbinden, damit der Freifunk-Router auch Internet-Zugriff gewährt. Dazu wird der '''blaue''' Port des Freiunk-Routers mit dem Gästenetz-Port Deines Internet-Routers verbunden. Falls Du dort kein Gästenetz eingerichtet hast oder das gar nicht geht, tut's auch ein "normaler" LAN-Port Deines Routers, wo Du auch deinen Laptop etc. einstöpseln würdest. Ein Gästenetz wäre nur noch etwas sicherer. Eventuell musst Du die Filterregeln für das Gästenetz anpassen, da manche Router in der Standardkonfiguration nur bestimmte Ports freigegeben haben.

'''WICHTIG:''' Wer hier in einer Firma oder gar einer städtischen Einrichtung ''mal eben'' einen Freifunk-Router an deren Intranet anschließt, schadet damit unter Umständen dem Freifunk-Projekt, da das nicht unbemerkt bleibt und fast immer gegen interne Sicherheitsrichtlinien verstößt. Sowas muss von der jeweiligen IT-Leitung explizit erlaubt werden. Wir wollen die Verantwortlichen nicht verärgern sondern überzeugen!

=== Installation überprüfen ===
Nach erfolgreichem Boot sollte Dein Router nun ein offenes WLAN mit SSID kbu.freifunk.net anzeigen. Nach wenigen Minuten sollte er bei erfolgreichem Internetanschluss ausserdem auf https://maps.kbu.freifunk.net auftauchen. (Als neuer Knoten mit kryptischem Namen unter Aktuelles).

[[File:Map-kbu-fresh-router-screen-shot.png|center|thumb|800px|Hier wurde offenbar vor kurzem ein neuer Router (freifunkXXX) eingerichtet aber noch kein Name vergeben.]]

=== Sinnvolle Ergänzungen ===
Wer seinen Router auch zukünftig auf der [http://map.kbu.freifunk.net/geomap.html Karte] wiederfinden möchte sollte dem Router noch einen Nickname und Koordinaten spendieren. Hierzu muss der Router noch einmal manuell im [[Gluon_Config_Mode | Config Mode]] neu gestartet werden.

=== Fragen? ===

Solltest Du Fragen zur Einrichtung des Routers haben oder Einträge Deines Knoten ändern wollen, schreibe gerne an unsere [[Mailingliste|E-Mail]]. Gerne kannst Du auch bei unseren regelmäßigen Treffen in Bonn oder Köln vorbeischauen.

Datei:Map-kbu-fresh-router-screen-shot.png

2015-08-31T09:37:41Z

Echse:

Diskussion:Mitmachen

2015-08-31T09:05:46Z

Echse: Die Seite wurde neu angelegt: „Ich würde noch ne Empfehlung dazu schreiben, welche Firmware der unbedarfte Neuling denn nu nehmen soll. Mir wurde auf der Froscon Gluon ans Herz gelegt und s…“

Ich würde noch ne Empfehlung dazu schreiben, welche Firmware der unbedarfte Neuling denn nu nehmen soll. Mir wurde auf der Froscon Gluon ans Herz gelegt und soweit ich das sehe scheint das gut zu laufen und weniger zukünftige Probleme zu versprechen? [[Benutzer:Echse|Echse]] ([[Benutzer Diskussion:Echse|Diskussion]]) 11:05, 31. Aug. 2015 (CEST)

Benutzer:Echse

2015-08-31T09:03:38Z

Echse: Die Seite wurde neu angelegt: „Echsecutor, aka [http://sebastian-schmittner.de/ Sebastian Schmittner]“

Echsecutor, aka [http://sebastian-schmittner.de/ Sebastian Schmittner]

Mitmachen

2015-08-31T08:59:01Z

Echse: /* Freifunk Firmware auswählen */ Bissl bla bla Gluon VS Classic ergänzt.

[[Kategorie:Mitmachen]]
{{TOCright}}
== Wie kann ich mitmachen? ==
Entdecke die [[Nutzen|Vorteile]] von Freifunk und werde selbst Freifunker! Um selber einen Freifunk Router zu betreiben, sind folgende Schritte notwendig:

#Router auswählen
#Freifunk Firmware auswählen
#Freifunk Firmware installieren

Die Installation und Konfiguration ist ganz einfach und du benötigst keine technischen Kenntnisse. Wenn du dieser Anleitung folgst, kann eigentlich nichts schiefgehen.

Falls du Fragen hast, kannst du dich jederzeit an unsere [[Mailingliste|E-Mail]] wenden uns im [[IRC]] besuchen oder zu einem unserer Treffen kommen. Oder werfe mal einen Blick in die [[FAQ]].

Los geht's!

== Router auswählen ==
[[File:tl-wr841n.jpg|right|thumb|100px|TL-WR841N(D)]]
[[File:tl-wdr3600.jpg|right|thumb|100px|TL-WDR3600]]
Cool, dass du selbst Freifunker_in werden willst!

Als Einstieg bietet sich der recht kostengünstige Router TP-Link TL-WR841N an, der für ca. 20,-€ erhältlich ist. Dieser funkt im weit verbreiteten 2.4 GHz Frequenzband.

Wer neuere Smartphones/Tablets/Notebooks/etc. im 5 GHz-Frequenzband via Freifunk versorgen möchte, kann hierzu z.B. den TP-Link TL-WDR3600 (für ca. 45,-€) einsetzen, welcher beide Fequenzbänder unterstützt.

Wir unterstützen auch noch weitere Router, schau einfach mal in die Tabelle im nächsten Schritt.

== Freifunk Firmware auswählen ==
Für den Router brauchst du die sogenannte Firmware (Betriebssystem), die du auf deinem Router installieren musst.
Die Firmware ist vom Router-Modell abhängig. Das Modell und die Versionsnummer deines Routers findest du auf der Rückseite des Gerätes.

Da wir gerade 2 verschiedene Versionen von Firmware im Einsatz haben, solltest Du Dich nun entscheiden zwischen der älteren [[KBU Classic Firmware]] und der [[KBU Gluon Firmware]], welche bisher aber nur beta Status hat. Die Classic Firmware ist weiterhin funktional und in einem stabilen Zustand, allerdings funktionieren nicht mehr alle Features (z.B. Statistiken) und ein Upgrade von der classic Firmware zur neuen Gluon Firmware ist zur Zeit schwierig. Die neue Gluon Firmware verspricht mehr aufwärts Kompatibilität und es gibt eine ganze Reihe positiver Erfahrungen. Zumindest eine Neuinstallation sollte in der Regel problemlos verlaufen. Aber der beta Status hat natürlich seinen Grund, die Gluon Firmware wird zur zeit aktiv weiterentwickelt und es ist mit Bugs zu rechnen. Du hast die Qual der Wahl und wie immer bei Freifunk heißt es: selber ausprobieren!

[[Kategorie:Mitmachen]]