Pimp my Node: Unterschied zwischen den Versionen
Took (Diskussion | Beiträge) K (→Freifunk-Monitor: Router-Status per E-Mail: back online! :-)) |
(cserv wird nich mehr genutzt, weg damit.) |
||
| Zeile 141: | Zeile 141: | ||
==== NTP-Bug in Firmware 1.2.1b beseitigen ==== | ==== NTP-Bug in Firmware 1.2.1b beseitigen ==== | ||
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben: | Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben: | ||
Version vom 2. September 2016, 21:58 Uhr
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 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
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 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 Github-Wiki der Freifunk-Gluon-Firmware eine ausführliche Liste nützlicher Befehle .
Firmware aktualisieren
Node mit uplink
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
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)
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
Upgrade von inkompatibler Konfiguration (Legacy auf Gluon, Wechsel des Hood, etc.)
Bei einem Upgrade von einer inkompatiblen Version mittels sysupgrade muss man normalerweise mittels
sysupgrade -n firmware.bin
die aktuellen Einstellungen überschreiben lassen. Auf einem Node, den man nur per SSH erreicht, ist das unpraktisch, da auch Passwörter und SSH-Schlüssel gelöscht werden. Zum Glück hat sysupgrade einen interaktiven Modus, den man per
sysupgrade -i firmware.bin
startet. Hier kann man (nachdem man bestätigt hat, dass ein Teil der Konfiguration übernommen werden soll) die Liste an zu sichernden Dingen bearbeiten. Die gluon-node-info (Geo-Koordinaten und Kontaktadresse) so wie vor allem die drobbear/*keys sollte man behalten, evtl auch System mit dem Hostnamen des Nodes. Der Rest kann gelöscht werden, falls man da keine wichtigen Anpassungen vorgenommen hat. ('dd' löscht Zeilen in vi ;) )
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
/etc/dropbear/authorized_keys /etc/dropbear/dropbear_dss_host_key /etc/dropbear/dropbear_rsa_host_key /etc/config/gluon-node-info /etc/config/system
erstellen und per tar -cz config > config.tar.gz packen. Danach kann man mittels
sysupgrade -f config.tar.gz firmware.bin
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. [1] ;)
- TFTP-Server auf dem lokalen Rechner installieren (Kurzfassung von z.B. [2])
aptitude install tftpd-hpa sudo chown -R tftp /srv/tftp/
- Konfiguration anpassen & neu starten. Das "-c create file" braucht man, um vom Router Dateien zu senden (Konfiguration sichern), "-s" da sonst absolute Pfade angegeben werden müssten (macht der Router natürlich nicht). Mehr zu den Optionen findet man auf der manpage.
vim /etc/default/tftpd-hpa TFTP_USERNAME="tftp" TFTP_DIRECTORY="/srv/tftp" TFTP_ADDRESS="0.0.0.0:69" TFTP_OPTIONS="-s -c" service tftpd-hpa restart
- Dann muss man noch herausfinden, auf welcher IP der Router nach welchem Dateinamen fragt. Eine gute Quelle ist openWRT, z.B. für den beliebten tl-wr841n finden sich die Infos je nach Version hier.
Falls noch Fragen offen bleiben, die $Anderen wissen auch was. ;)
Hostnamen 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:
uci set system.@system[0].hostname=what-ever-dude uci commit reboot
Die Änderung wird erst nach dem Kommando reboot (danach startet der Node neu) wirksam.
IPv6 ping
ping6 <Link-lokale Adresse des Nodes>%eth0
IPv6 SSH
Hinter der Link-lokalen Adresse "%" + "Netzwerk-Schnittelle an eurer Kiste" (hier im Beispiel eth0)
ssh root@<Link-lokale Adresse des Nodes>%eth0
Passwort-Authentifizierung abstellen
Wichtig: Als erstes prüfen, ob man sich mit seinem Schlüsselpaar auf den Router einloggen kann. Man sollte jetzt nicht mehr nach dem Passwort gefragt werden (allerhöchstens nach dem Passwort, welches den privaten Schlüssel schützt). Falls das erfolgreich funktioniert, kann man die Datei /etc/config/dropbear wie folgt ändern:
config dropbear
option PasswordAuth 'off'
option RootPasswordAuth 'off'
option Port '22'
# option BannerFile '/etc/banner'
Nach einem Neustart des Routers mittels reboot sollte es jetzt nur noch möglich sein, sich mit seinem Schlüsselpaar auf den Router einzuloggen.
SSH public key auf Node aufspielen
Möchte man sich nicht immer per Passwort auf den eigenen Node verbinden, so kann man das auch mit einem Schlüsselpaar realisieren. Falls man danach noch die Authentifizierung per Passwort abschaltet (s. nächster Punkt), dann hat man einen sicheren Zugriff auf seinen Node realisiert. Voraussetzung ist natürlich, dass man schon ein gültiges Schlüsselpaar besitzt. Falls dem so ist, so genügt es, den öffentlichen Schlüssel (public key) auf den Node zu übertragen. Das kann mit Hilfe von scp (secure copy) passieren:
scp -6 id_rsa4096.pub root@[<Link-lokale Adresse des Nodes>%eth0]:/etc/dropbear/authorized_keys
Hierbei steht id_rsa.pub für die Datei, die den öffentlichen Schlüssel enthält. ACHTUNG: Obiger Befehl ersetzt die eventuell schon vorhandene Datei authorized_keys auf dem Node. Das ist O.K. für den ersten Schlüssel. Sollen mehrere Schlüssel eingetragen werden (z. B. weil man außer vom Laptop auch vom Tablet auf seinen Node verbinden möchte), kann man das so machen:
cat ~/.ssh/id_rsa4096.pub | ssh root@[<Link-lokale Adresse des Nodes>%eth0] 'umask 077; cat >>.ssh/authorized_keys'
Sollte beim Kopierversuch die Meldung
ssh: Could not resolve hostname fe80:
erscheinen, hat man höchstwahrscheinlich die eckigen Klammern um die IP-Adresse inklusive Schnittstelle vergessen. Dann wird der erste Doppelpunkt schon als Ende des Hostnamens interpretiert! Auch hier werden die Änderungen nach einem Neustart des Routers mittels reboot übernommen.
NTP-Bug in Firmware 1.2.1b beseitigen
Falls sich ein Node-Betreiber wundert, warum sein Node keine Statistiken liefert und es ein Mesh-Only-Node ist (d. h. ohne eigenen Uplink zum Internet), so liegt das an einem Bug in der Firmware. Diesen kann man jedoch mit einfachen Mitteln beheben: Editiert wird die Datei /etc/config/system. Dort findet man einen Eintrag config timeserver 'ntp'. Standardmäßig stehen hier 4 Zeitserver von OpenWRT (in der Form x.openwrt.pool.ntp.org). Diese müssen bei Mesh-Only-Nodes in IPv6-Adressen geändert werden, und zwar so, dass der komplette Konfigurationspunkt wie folgt aussieht:
config timeserver 'ntp'
list server '2a03:4000:2:494::2'
list server '2a01:4f8:161:2461:e4::1'
list server '2a02:180:1:1::551f:bb4b'
option enabled '1'
option enable_server '0'
Auch hier werden die Änderungen erst nach einem Neustart des Nodes mittels reboot wirksam. Dieser Bug soll mit dem nächsten Firmware-Release behoben sein. Man kann die Eintragungen auch in den Nodes mit Internet-Uplink ändern ohne die Funktion zu beeinträchtigen.
Collectd prüfen
Falls es durch das Beheben des NTP-Bugs noch immer nicht zum Übertragen der Statistiken kommt, überprüft mal die Einstellungen eures collectd. Es kann sein, dass beim Firmware-Update diese Konfiguration nicht upgedatet wurde und eine veraltete IPV6-Adresse noch vorhanden ist. So sollte es sein:
vim /etc/collectd.conf // Konfigurationsdatei für collectd zum Bearbeiten öffnen
Zeile 39-44:
<Plugin ping>
TTL 127
Interval 30
Host "fdd3:5d16:b5dd:3::6" // Diesen Eintrag auf Übereinstimmung prüfen
</Plugin>
Zeile 46-50:
<Plugin network>
Server "fdd3:5d16:b5dd:3::6" "25827" // Diesen Eintrag auf Übereinstimmung prüfen
Forward false
</Plugin>
LAN Kopplung
Eine LAN-Kopplung kann in manchen Fällen sinnvoll sein, besonders wenn man einen VLAN-fähigen Switch und eine bestehende Netzwerkverkabelung hat. Hier werden die Switchports angewiesen auch über LAN zu meshen.
TL-WR841ND
03/2014: Hier wird über alle 4 LAN Ports gemeshed, Mesh über WLAN kann man optional noch ausschalten! Folgende Konfiguration stammt von rampone/FF-KBU und wurde an 2 TL-WR841N v.8 getestet mit KBU-FF-Firmware 1.1.
05/2015: Verifiziert (und ergänzt) für TL-WR841N v.9 und KBU-FF-Firmware 1.2.2rc3 .
vim /etc/config/network - Folgende Änderungen wurden an der FF-Firmware vorgenommen:
- Konfigurationsschnittstelle 'freifunk' -> Hier haben wir die ethX-Schnittstelle aus "ifname" rausgenommen, damit kein ff aus dem ethX (switch) rauskommt (X=1 für Hardware bis einschließlich v8, sonst X=0).
- Konfigurationsschnittstelle 'mesh_lan' -> kompletten Codeblock hinzugefügt. Dieser bewirkt, dass über ethX (switch) gemeshed wird.
config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'wan' option ifname 'eth0' option proto 'dhcp' option type 'bridge' option accept_ra '0' option auto '1' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '0 1 2 3 4' config interface 'freifunk' option ifname 'bat0' #LAN-Kopplung: ifname eth1 (bzw. eth0, s.o.) entfernt option type 'bridge' option proto 'none' option auto '1' option accept_ra '1' option macaddr '10:fe:ed:f1:53:84' config interface 'mesh' option proto 'batadv' option mtu '1528' option mesh 'bat0' config interface 'mesh_vpn' option ifname 'mesh-vpn' option proto 'batadv' option mesh 'bat0' option macaddr '12:fe:ed:f2:53:84' config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt option ifname 'eth0' # ab TL-841N(D) v9: eth0, bis v8: eth1 . Bei falschem Interface läuft das mesh-lan über den blauen Port. Wer's mag... option proto 'batadv' option mesh 'bat0'
vim /etc/config/wireless - Hier wird der Codeblock, der für das Mesh über WLAN verantwortlich ist, auskommentiert (optional)
#config wifi-iface 'wifi_mesh' # option device 'radio0' # option network 'mesh' # option mode 'adhoc' # option ssid '02:d1:11:37:fc:39' # option bssid '02:d1:11:37:fc:39
TL-WDR4300
Das gleiche nochmal für den 4300er
vim /etc/config/network
config interface 'loopback'
option ifname 'lo'
option proto 'static'
option ipaddr '127.0.0.1'
option netmask '255.0.0.0'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
option type 'bridge'
option accept_ra '0'
option auto '1'
option macaddr 'a2:f3:c1:65:81:cd'
config switch
option name 'eth0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'eth0'
option vlan '1'
option ports '0t 2 3 4 5'
config switch_vlan
option device 'eth0'
option vlan '2'
option ports '0t 1'
config interface 'freifunk'
option ifname 'bat0' #LAN-Kopplung: ifname eth0.1 entfernt
option type 'bridge'
option proto 'none'
option auto '1'
option accept_ra '1'
option macaddr 'a0:f3:c1:64:81:cc'
config interface 'mesh'
option proto 'batadv'
option mtu '1528'
option mesh 'bat0'
config interface 'mesh_vpn'
option ifname 'mesh-vpn'
option proto 'batadv'
option mesh 'bat0'
option macaddr 'a2:f3:c1:65:81:cc'
config interface 'mesh_lan' #LAN-Kopplung: Codeblock mesh-lan hinzugefuegt
option ifname 'eth0.1'
option proto 'batadv'
option mesh 'bat0'
Einsperren des Freifunk-Routers in eine DMZ
Wer seinen Freifunk-Router einsperren und/oder die Bandbreite begrenzen möchte, kann dies am einfachsten tun, indem er ihn an seiner Firewall an einen eigenen Netzwerkport klemmt und diesen dann als DMZ konfiguriert. Ein KBU-Freifunk-Router muss zur Zeit im LAN DHCP, DNS, im Internet NTP sowie mit den fastd-Knoten reden können. Folgendes Bespiel für eine iptables-Firewall nimmt an, dass der Freifunk-Router über eth2 angeschlossen ist:
# eth2 darf nur DNS, NTP, DHCP und ansonsten mit den fastdX reden iptables -i eth2 -A INPUT -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 67:68 --sport 67:68 -j ACCEPT iptables -i eth2 -A INPUT -p udp --dport 53 -j ACCEPT iptables -i eth2 -A INPUT -p tcp --dport 53 -j ACCEPT iptables -i eth2 -A INPUT -p udp --dport 123 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 53 -j ACCEPT iptables -i eth2 -A FORWARD -p tcp --dport 53 -j ACCEPT iptables -i eth2 -A FORWARD -p udp --dport 123 -j ACCEPT iptables -i eth2 -A FORWARD --dst 176.9.41.253 -j ACCEPT iptables -i eth2 -A FORWARD --src 176.9.41.253 -j ACCEPT iptables -i eth2 -A FORWARD --dst 178.63.59.41 -j ACCEPT iptables -i eth2 -A FORWARD --src 178.63.59.41 -j ACCEPT iptables -i eth2 -A FORWARD --dst 37.120.169.214 -j ACCEPT iptables -i eth2 -A FORWARD --src 37.120.169.214 -j ACCEPT iptables -i eth2 -A FORWARD --dst 37.221.195.47 -j ACCEPT iptables -i eth2 -A FORWARD --src 37.221.195.47 -j ACCEPT iptables -i eth2 -A FORWARD --dst 78.46.68.75 -j ACCEPT iptables -i eth2 -A FORWARD --src 78.46.68.75 -j ACCEPT iptables -i eth2 -A FORWARD --dst 84.201.35.206 -j ACCEPT iptables -i eth2 -A FORWARD --src 84.201.35.206 -j ACCEPT iptables -i eth2 -A INPUT -j DROP iptables -i eth2 -A FORWARD -j DROP # eth2 darf maximal 2000 kbit/s ein- und ausgehenden Traffic machen wondershaper eth2 2000 2000
Prinzipiell könnte man den Traffic noch weiter einschränken. DHCP und DNS müssen nur zum DHCP- bzw. DNS-Server funktionieren, und der Traffic zu den fastd-Servern ließe sich auf TCP-Port 80 und UDP-Port 10000 begrenzen.
Alternative: Einsperren im VLAN
siehe: FF-Router einsperren im VLAN
Weboberfläche aktivieren
Im Normalbetrieb ist erst mal kein Zugriff notwendig (und auch erst mal nicht vorgesehen). Das läuft einfach! ;-) Und es gibt im Normalbetrieb eben auch keine Weboberfläche, welches Sicherheitslücken haben könnte.
Zum ersten Konfigurieren schaltet mal den Router in einen Konfig-Modus. Der Router nimmt dann in diesem Modus nicht mehr am Freifunknetzwerk teil. Nun kann man dann Rechner an die LAN-Ports des Freifunkrouters anschließen und über eine Weboberfläche per Browser den Router konfigurieren oder updaten. Das sollte aber nur ganz selten notwendig sein. Nach einem Reboot des Routers geht das Gerät dann wieder in den Freifunk-Modus mit deinen Konfigurationsänderungen.
Wenn man Spaß am Basteln hat, kann man die Weboberfläche aber auch im Normalbetrieb aktivieren. Für die Absicherung muss man dann aber selber sorgen, denn standardmäßig ist das nicht abgesichert. Hier die Anleitung nach Freifunk Kiel, um auf die Weboberfläche zu gelangen:
Die Weboberfläche des Routers ist nicht über die Link-lokale Adresse, sondern nur über die generelle IPv6-Adresse des Routers zu erreichen. Die IPv6-Adresse bekommt man über SSH (s. 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
opkg update opkg install kmod-usb-uhci kmod-usb-net-rndis
Dies sollte, falls ihr noch keine USB-Unterstützung in der Firmware habt, auch diese über Abhängigkeiten nachinstallieren. (nachprüfen!!!)
- Ihr müsst den Netzwerkzugang für die neue Schnittstelle "usb0" noch konfigurieren. Unter /etc/config/network fügt ihr z.B. folgendes hinzu:
config interface 'wan2'
option ifname 'usb0'
option proto 'dhcp'
option type 'bridge'
Auch unter LuCi sollte dies konfigurierbar sein.
- Nach einem Neustart und einem angeschlossenen Gerät sollte nun der Uplink via dem USB-Netzwerkgerät/Android-Tethering funktionieren. - Sollte das Gerät erst später angeschlossen werden, so könnt ihr mit folgendem Befehl das Netzwerkgerät starten.
ifup wan2
(Dies ist noch nicht ein perfektes Tutorial, werde es nochmal durchprobieren. Einen UMTS-Stick hatte ich auf Anhieb noch nicht zum laufen gebracht. Auch scheint Multiwan in OpenWRT eine interessante Sache)
Zusätzlich zum Freifunk auch privates WLAN einrichten
Es ist möglich ein privates WLAN anzulegen, dass mit dem WAN-Port gebridged und separat zum Mesh-Netzwerk ist. (Bitte beachten, dass "Mesh on Wan" nicht zeitgleich mit aktiviert werden sollte.) Effekt: Das private WLAN wird erweitert, zeitgleich fungiert der Router als Freifunk-Router. Die Netze sind voneinander abgekoppelt. Das private WLAN kann per SSH in der Konsole aktiviert werden:
uci set wireless.wan_radio0=wifi-iface uci set wireless.wan_radio0.device=radio0 uci set wireless.wan_radio0.network=wan uci set wireless.wan_radio0.mode=ap uci set wireless.wan_radio0.encryption=psk2 uci set wireless.wan_radio0.ssid="$SSID" uci set wireless.wan_radio0.key="$KEY" uci set wireless.wan_radio0.disabled=0 uci commit wifi
Bitte ersetze $SSID mit dem Namen deines Heimnetzwerks und $KEY mit deinem bisher üblichen Key (der vom privaten Router). Falls dein Router beide Frequenzbänder unterstützt(2.4 und 5 Ghz) und du in beiden auch privates WLAN aktivieren möchtest, muss dies für radio0 und radio1 mit übernommen werden. Zum Deaktivieren des Ganzen wie folgt vorgehen:
uci set wireless.wan_radio0.disabled=1 uci commit wifi
Automatischer Neustart bei längerem Mesh-Verlust, "quick hack" (und "improved hack") zur Analyse
Bei der Vernetzung von Notunterkünften mit Gluon-Beta (via Euskirchen) ist bei einem CPE210-Uplink aufgefallen, dass sämtliche Mesh-Verbindungen über Stunden ausgefallen waren. Es war zunächst unklar, ob überwiegend die Stromversorgung schuld war, insbesondere da der Uplink-Router mehrfach betroffen und trotzdem via VPN erreichbar war. Dabei war dann nur ein Mesh mit sich selbst via "batctl o" sichtbar. Einzelne Mesh-Only-Router zeigten ebenfalls (selten) Ausfälle über mehrere Stunden: teilweise Nachts, wo Renovierungsarbeiten nicht die Ursache sein konnten.
Um längere Ausfälle zu vermeiden, wurde folgendes Script unter /root/check_mesh.sh abgelegt, dass via cron-Job automatisch jede Minute ausgeführt wird und nach 10 Minuten ohne Mesh-Verbindung einen Reboot auslöst:
#!/bin/ash
FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10
# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`
if [ $count -gt 1 ]; then ## more than a single mesh with itself is left
echo 0 > $FAILCOUNTFILE
else
if [ -f $FAILCOUNTFILE ]; then
read failcount < $FAILCOUNTFILE
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
touch /etc/mesh0_failcount_`date +"%Y-%m-%d_%H%M"`
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
else
echo 1 > $FAILCOUNTFILE
fi
fi
Es muss (hier mit awk, s.o.) nach _unterschiedlichen_ Werten für Originator und NextHop ausschau gehalten werden, denn bei einem fehlenden Mesh zwischen zwei Knoten meshen die Knoten noch mit sich selbst:
# batctl o | grep mesh0 62:e6:28:24:5f:52 0.730s ( 6) 62:e6:28:24:5f:52 [ mesh0]: 62:e6:28:24:5f:52 ( 6) 62:e6:28:72:32:48 0.730s ( 8) 62:e6:28:72:32:48 [ mesh0]: 62:e6:28:72:32:48 ( 8)
Das war lesbar und einfach, aber wegen ständiger Schreibzugriffe schlecht für die Lebensdauer der Flash-Speicher. Besser also nur schreiben, wenn Fehler passieren, etwa so:
#!/bin/ash
FAILCOUNTFILE=/var/run/mesh0_failcount
MAXFAILCOUNT=10
# check mesh connections with different originators and nexthops, MAC is 17 chars long
count=`batctl o | awk '/mesh0/{originator=substr($0,1,17); nexthop=substr($0,37,17); if (originator != nexthop){print originator" "nexthop}}' | wc -l`
if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ $count -gt 0 ]; then # At least one originator with different nexthop exists
if [ $failcount -gt 0 ]; then # We'r lucky, everything is fine again!
echo 0 > $FAILCOUNTFILE
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -ge $MAXFAILCOUNT ]; then
echo 0 > $FAILCOUNTFILE # Reset counter before reboot
logread > /etc/mesh0_failcount_lastwords_`date +"%Y-%m-%d_%H%M"` # DEBUG info
sync
reboot
fi
echo $failcount > $FAILCOUNTFILE
fi
else
echo 0 > $FAILCOUNTFILE
fi
Das Script wird dann noch ausführbar gemacht:
chmod +x /root/check_mesh.sh
Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
* * * * * /root/check_mesh.sh > /dev/null 2>&1
Wichtig ist, dass ein ausreichender Zeitraum zum Aufbau des Mesh-Netzes nach dem Reboot verbleibt. 10 Minuten (MAXFAILCOUNT) sollten hierzu ausreichen.
Im /etc-Verzeichnis (das wurde gewählt, da Änderungen hier einen Neustart überleben) sind dann solche Reboot-Ereignisse ablesbar:
# ls -al | grep failcount -rw-r--r-- 1 root root 0 Oct 26 06:22 mesh0_failcount_2015-10_26_0622 -rw-r--r-- 1 root root 0 Oct 29 08:12 mesh0_failcount_2015-10-29_0812 -rw-r--r-- 1 root root 0 Oct 30 21:59 mesh0_failcount_2015-10-30_2159
Die Vorfälle traten unregelmäßig alle paar Tage auf, wurden aber durch das Script abgefangen.
Client-WLAN nachts automatisch ausstellen
In Jugendherbergen oder Flüchtlingsheimen kann es durch rücksichts- oder gedankenloses Verhalten einzelner Gäste oder Bewohner zu akkustischen Beeinträchtigungen kommen, die durch temporäres Ausschalten des WLAN-Client-Netzes vermindert werden können. Damit kann natürlich nicht verhindert werden, dass einzelne Bewohner sich einen eigenen Freifunk-Router konfigurieren und ins Mesh-Netz hängen - das wäre ja sogar erwünscht. Folgendes Script restrict_client_access.sh ermöglicht das Abschalten in den frühen Morgenstunden (d.h. vor 0 Uhr abzuschalten ist hier nicht berücksichtigt). Es ist bisher für TP-Link TL-WR841-ND, sowie mit TL-WDR4300 und TL-WDR3600 mit der aktuellen Firmware v1.4 getestet.
#!/bin/ash
STOP_HOUR=0 # needs to be smaller than START_HOUR!!!
START_HOUR=7 # disable client0 network device if it's active
# and hour is between STOP_HOUR and START_HOUR
hour=`date +"%H"`
ip addr list client0 > /dev/null 2>&1
if [ $? -eq 0 ]; then # client network is on
if [ $hour -lt ${START_HOUR} -a $hour -ge ${STOP_HOUR} ]; then # turn it off
uci set wireless.client_radio0.disabled=1
uci set wireless.client_radio1.disabled=1 # additional 5GHz wifi exists (e.g. WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
else # client network is off
if [ $hour -ge ${START_HOUR} -o $hour -lt ${STOP_HOUR} ]; then # turn it on
uci set wireless.client_radio0.disabled=0
uci set wireless.client_radio1.disabled=0 # additional 5GHz wifi exists (e.g WDR3600)
uci commit wireless
/etc/init.d/network restart
fi
fi
Das Script kann z.B. einfach im /root/ -Verzeichnis abgelegt werden. Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
* * * * * /root/restrict_client_access.sh > /dev/null 2>&1
Hinweis: Die uci- sowie das Restart-Kommando dürfen nicht ausserhalb der if-Bedingungen das Script vereinfachen, da sie jeweils nur bei einmaligem Umstellen täglich ausgeführt werden dürfen. Sonst verliert man jede Minute das Netz...
Wichtig : Der NTP-Dienst bei Mesh-Only-Routern muss ggf. erst (oder nochmal) nach der hergestellten Mesh-Verbindung durchgestartet werden, da NTP keine großen Zeitsprünge macht. Das kan z.B. durch folgenden Eintrag via Crontab automatisiert werden (hier: zur vollen Minute 8, die ggf. nach längerer Auszeit auch zunächst falsch sein kann):
8 * * * * /etc/init.d/sysntpd restart > /dev/null 2>&1
Besser wäre hier ein Script, dass nach dem erfolgreichen Herstellen einer Mesh-Verbindung zum Uplink den ndtd einmal durchstartet, damit die Zeit initial synchronisiert wird.
Client-WLAN an Mesh-Only-Routern nur aktivieren, wenn Mesh-WLAN vorhanden ist
Bei Routern, die selbst keinen Uplink haben und deshalb davon abhängig sind mit Nachbarn zu meshen, kann das Freifunk-Client-WLAN ausgestellt werden, wenn kein Mesh-Link (und damit auch kein entfernter Uplink) greifbar ist.
Folgendes Script kann in /root/client-off-if-mesh-off.sh abgelegt (und via chmod +x /root/client-off-if-mesh-off.sh ausführbar gemacht) werden, das dann via cron regelmäßig aufgerufen wird:
#!/bin/ash
FAILCOUNTFILE=/var/run/mesh0_nogatewaycount
MAXFAILCOUNT=2
# check mesh connections with different originators and nexthops, MAC is 17 chars long
batctl gwl | grep -q "No gateways in range"
no_gw=$?
if [ -f $FAILCOUNTFILE ]; then # Does the failcount file exist at all?
read failcount < $FAILCOUNTFILE # If it exist then there is a number in.
if [ ${no_gw} -eq 1 ]; then # There is a gateway
if [ $failcount -gt 0 ]; then # We'r lucky, it is fine again, we decrease the failcount
failcount=$(($failcount-1))
echo $failcount > $FAILCOUNTFILE
if [ $failcount -eq 0 ]; then
# turn on client network
uci set wireless.client_radio0.disabled=0
uci commit wireless
wifi
fi
exit
fi
else # no nexthop different than originator exists
failcount=$(($failcount+1))
if [ $failcount -eq $MAXFAILCOUNT ]; then
# logread > /etc/mesh0_failcount_no-mesh_`date +"%Y-%m-%d_%H%M"` # DEBUG info
# turn off client network
uci set wireless.client_radio0.disabled=1
uci commit wireless
wifi
fi
if [ $failcount -le $MAXFAILCOUNT ]; then ## only memorize failcounts up to MAXFAILCOUNT
echo $failcount > $FAILCOUNTFILE
fi
fi
else
echo 0 > $FAILCOUNTFILE
fi
Via "crontab -e" führt dann folgender Eintrag zur Ausführung zu jeder vollen Minute:
* * * * * /root/client-off-if-mesh-off.sh > /dev/null 2>&1
Das obige Script ist dahingehend optimiert, dass nur bei Änderungen des Mesh-Status Daten auf den Flash-Speicher geschrieben werden. Für TP-Link WR 841ND wurde obiges Script getestet.
Freifunk-Monitor: Router-Status per E-Mail
Ich zitiere mal von der Mailingliste - das ganze ist in der Testphase und ich werde den Wiki-Eintrag später noch entsprechend Überarbeiten.
(Dieser Service ist nun wieder aktiv, nach spätestens 40 Minuten Down-Time geht die E-Mail jetzt wieder raus!)
Hallo, Liebe Mitstreiter!
Wir alle arbeiten daran, unser Netz besser, schneller und stabiler zu machen.
Axel und ich möchten unseren Teil beitragen.
Deshalb entwickeln wir den Freifunk-Monitor – eine kleine Software, die Betreiber von Freifunk-Routern auf Wunsch per E-Mail benachrichtigt, wenn ein- oder mehrere seiner Knoten seitens der Karte nicht erreichbar scheinen.
Dieser Service muss derzeit explizit auf einem Router mit mindestens Gluon 1.4 via SSH angeschaltet werden (es gibt derzeit keine Web-Oberfläche).
Wir laden hiermit alle Router-Betreiber ein, den Monitor zu testen!
Rechnet damit, schlimmstenfalls zu viele oder ungerechtfertigte E-Mails vom Monitor zu bekommen - wir testen die Software noch.
Wie ihr das wieder abschaltet steht unten.
---------------
Kommando zum Monitoring einschalten (Achtung, was folgt ist EINE Zeile):
echo "if uci:get_first('gluon-node-info', 'owner', 'send_alerts', '') ~= '' then return true end" > /lib/gluon/announce/nodeinfo.d/send_alerts ; uci set gluon-node-info.@owner[0].send_alerts=1 ; uci commit
Kommando zum E-Mail-Adresse setzen (falls nicht schon geschehen):
uci set gluon-node-info.@owner[0].contact=ff@cocoanuts.org; uci commit
Kommando zum E-Mail-Adresse prüfen:
uci get gluon-node-info.@owner[0].contact
Kommando zum Monitoring abschalten:
uci set gluon-node-info.@owner[0].send_alerts=0 ; uci commit
---------------
Frohes Freifunken,
KaterMikesch & G3ntleman