Freifunk für Schornbusch

Router in Schornbusch
Router in Schornbusch
Heute habe ich acht Router in vier Stunden für Schornbusch konfiguriert. Die Container bestehen aus Metall, so dass die Wände ein Funksignal doch recht stark dämpfen. Darum habe ich vier Outdoor-Router (CPE210) für draußen und vier Indoor-Router (WR841ND) im Inneren der Container für einen von zwei Sozialräumen vorgesehen. Einer Router versorgt vom Eingangsgebäude aus die anderen Router mit der Internetanbindung. Die Outdoor-Router werden über Kabel mit den Indoor-Routern verbunden, eine Maßnahme, die sich schon in der Kriegerstraße bewährt hat. Dort verbindet ein gerichtete Outdoor-Router das Haus mit der nächsten Nachbarin, die bereit war uns zu helfen. Der zweite Router versorgt das Haus im Inneren.

Leider ist die Stadt etwas spät auf uns zugekommen und so müssen nachträglich Löcher gebohrt und Kabel wasserdicht durch die Wände geführt werden. Da ich die nächsten Woche keine Zeit habe die Router aufzustellen, werden sich dei Flüchtlinge noch ein Weile gedulden müssen.

Freifunk in der Kriegerstraße

Kriegerstraße 34 Traffic
Kriegerstraße 34 Traffic

Nachdem wir jemanden in der Kriegerstraße gefunden haben, der bereit ist einen Freifunk-Router aufzustellen, läuft langsam auch Freifunk in der Flüchtlingsunterkunft in der Kriegerstraße 34. Die Strecke zwischen den Knoten ist jedoch 160 Meter lang und da kommen die Router oft an ihre Grenzen. Wenn’s läuft, dann läuft’s gut, wenn’s nicht läuft muss ich immer durch Neustarts nachhelfen. Dazu habe ich in einen Router in CRON ein Script eingebaut, dass eine Neustart veranlasst, wenn die Verbindung abgebrochen ist.

5-55/10 * * * * ping -c 1 fda0:747e:ab29:2241:62e3:27ff:fecd:5c0c || ((sleep 70 ; /bin/touch /etc/banner; uptime) | ( grep -e ‚\(day\|min\)‘ | grep -v ‚day‘ )) || /sbin/reboot >/dev/null

Wenn der ping zum nächsten Router fehlschlägt, dann wird der Router neu gestartet, wenn er länger als eine Stunde an war. Mehr über den Anteil nach dem ping steht unter Router hängt öfter? Was tun?

Die langen Ausfälle haben jetzt wohl ein Ende. Die neuste Software vom Juli scheint einige Fehler zu haben. Deshalb habe ich die alte Software vom April installiert. Die zeigt diese Fehler nicht und die Verbindung läuft deutlich stabiler und schneller. Bis zu 6 MBits/s für die Nutzer wurde heute auf der Strecke gemessen. Da kann man sich nicht beklagen. Die meisten sind deutlich langsamer.

Weitere Freifunker gesucht


Zur Zeit suchen wir weitere Freifunker in Rheinbach Stadt und Außenorte.

Vor einem Jahr, zu Rheinbach Classics 2015 haben wir Freifunk in der Rheinbacher Innenstadt angeboten. Es ging um offene Netze von Bürgern für Bürger. Da sprach noch niemand von einer Flüchtlingswelle.

Im Herbst erreichten immer mehr Flüchtlinge Deutschland. Freifunker haben schnell unbürokratisch geholfen und Flüchtlinge in den Unterkünften mit Freifunk versorgt. In Rheinbach gestaltete sich die etwas schwieriger. So sammelten sich Flüchtlinge an den wenigen Hotspots in der Innenstadt, was – aufgrund des Geräuschpegels – nicht bei jedem Wohlgefallen fand. Miteinander reden half meist, eine erste Integrationsübung für alle Seiten.
„Weitere Freifunker gesucht“ weiterlesen

Router hängt öfter? Was tun?

Aus Ramershoven wurde berichtet, dass die Router mehrmals die Woche neu gestartet werden müssen. Auch ich habe schon beobachtet, dass Router nach längerem Betrieb Zeit in einen seltsamen Zustand geraten. Allerdings kann nicht mehrmals in der Woche. Warum dies so ist, ist nicht so einfach zu ermitteln. Es kommt nicht so häufig vor und lässt sich nicht gezielt reproduzieren. Eine vorübergehende Abhilfe soll ein prophylaktischer Neustart pro Tag mittels cron leisten.

Dazu habe ich heute ein wenig mit einem Cron-Job experimentiert. Eigentlich ist es ganz einfach, aber unter OpenWrt gibt es ein paar Haken. Es kann zu einem unendlichen Reboot kommen, wenn cron kurz nach dem Reboot ausgeführt wird. Dies liegt daran, dass die Uhrzeit beim Start des Routers anhand des letzten Zeitstempel der Dateien in /etc gesetzt wird. Wenn die Router-Zeit auf die Uhrzeit des Reboot gesetzt wird, wird sofort ein weiterer Reboot ausgeführt, der wiederum zum Reboot führt.

Um diesen unendlichen Reboot zu vermeiden, habe ich einen Ausdruck entwickelt, der 70 Sekunden wartet, dann den Zeitstempel von /etc/banner ändert und mittels uptime prüft, ob der Router mindestens eine Stunde gelaufen ist. Die Wartezeit von 70 Sekunden stellt auch sicher, dass der Router mindestens eine Minute gelaufen ist, bevor uptime aufgerufen wird.

Das Ausgabeformat von uptime ist nicht sonderlich freundlich für Abfragen, wie die Beispielausgabe von uptime zeigt.

 15:29:31 up 5 days, 40 min,  load average: 0.45, 0.50, 0.47
 15:29:31 up 12:34,  load average: 0.45, 0.50, 0.47
 15:29:31 up 1 day, 55 min,  load average: 0.45, 0.50, 0.47
 15:29:31 up 3 days, 11:24,  load average: 0.45, 0.50, 0.47

Innerhalb der ersten Stunde wird die Zeit, die der Router läuft in Minuten im Format ’n min,‘ angegeben. Nach einer Stunde wechselt das Ausgabeformat zu hh:mm, um nach jeweils 24 Stunden in das Format ’n days?, m min,‘ oder ‚ n days, hh:mm,‘ zu wechseln.

Indem die Ausgabe von uptime auf den String ‚ min,‘ geprüft wird, kann bestimmt werden, ob der Router bereits länger als eine Stunde läuft. Nur dann soll ein Reboot ausgeführt werden und ein unendlicher Reboot verhindert.

Das Vorgehen ist wie folgt:

  1. Es wird 70 Sekunden gewartet. Damit ist die Zeit garantiert eine Minute weiter.
  2. Das Datum der Datei /etc/banner wird auf die aktuelle Zeit gesetzt, damit der Rechner nicht mit der Reboot-Zeit startet.
  3. uptime wird aufgerufen und
  4. mittels grep darauf geprüft, ob der Router länger als eine Stunde an ist.
  5. Wenn nur ‚min‘ in der Ausgabe von uptime enthalten ist, dann entfällt der Neustart.

In der Datei /etc/crontabs/root ist dazu folgender Eintrag zu hinterlegen, der den Router jeden Tag um 5:05 Uhr neu startet.

5 5 * * * ((sleep 70 ; /bin/touch /etc/banner; uptime) | ( grep -e '\(day\|min\)' | grep -v 'day' )) || /sbin/reboot >/dev/null

Nach dem Eintrag z.B. mit crontab -e erfolgt ist, muss dem cron Dämon die Änderung mit /etc/init.d/cron reload bekannt gegeben werden.

Anmerkung: Wichtig ist eine Leerzeile am Ende der Datei, damit cron richtig funktioniert.

Genug für heute.

PS: Der Test, ob der Router länger als eine Stunde läuft, geht leichter über die Datei /proc/uptime. Der Befehl sieht dann so aus:

5 5 * * * sleep 70 ; /bin/touch /etc/banner; test `sed 's#\..*##' /proc/uptime` -ge 3600 && /sbin/reboot >/dev/null

Experimentelle Firmware

Am Freitag habe ich eine neue experimentelle Firmware erstellt und heute unter v2016.1 beta bereitgestellt. Mit der Version 2016.1 gibt es einige Änderungen, die ich nur Stück für Stück begreife und in der Konfiguration einbauen muss.

Mesh

Mit der neuen Gluon Version gibt es zwei Protokolle für die Verbindung der Router untereinander (Meshing) – IBSS (Adhoc) und 802.11s. Das IBSS Netzwerk ist in an der SSID su-ff-mesh erkennbar.

Bisher hatte ich in der Firmware beide Protokolle definiert und aktiviert. Dies ist nur beschränkt sinnvoll. Um sich mit Routern mit alter Firmware v2012.1.2 oder älter, wird weiterhin IBSS benötigt. Router mit Gluon v2016.1 unterhalten sich meines Erachtens besser über 802.11s. Ein Mischbetrieb ist zwar möglich, angeblich könnte es Probleme in größeren Netzen geben. Neuere Router können sich ausschließlich über das neue Protokoll 802.11s verbinden.

Hier in Rheinbach laufen die meisten Knoten mit einer Firmware, die beide Protokolle unterstützt. So nutzen alle WR841ND v10 und WR941ND V6 eine experimentelle Firmware, da die Geräte in Gluon v2015.1.2 nicht unterstützt werden. Dies sind bereits 30% der Router. Tatsächlich nutzen nur noch ~20 Router eine nicht experimentelle Firmware ohne 802.11s Unterstützung.

Mit der Zeit möchte ich daher den Adhoc Verbindungen weg und die Router ausschließlich über 802.11s untereinander verbinden. In der neuen experimentellen Firmware habe ich deshalb das IBSS Netzwerk in der Voreinstellung deaktiviert. Es ist zwar vollständig definiert, aber nach einem Factory Upgrade nicht aktiv. Beim Sysupgrade bleiben die Einstellungen des Routers in der Regel erhalten. D.h. das Adhoc Netzwerk wird durch einen sysupgrade nicht ausgeschaltet. Ob das Adhoc Netzwerk noch verfügbar ist, ist an der SSID su-ff-mesh erkennbar.

IBSS kann mit folgenden Befehlen im Terminal für 2.4 Ghz (radio0) oder – bei Routern, die dieser Frequenz unterstützen, – 5 GHz (radio1) getrennt wieder angeschaltet werden.

 
uci set wireless.ibss_radio0.disabled='0'
uci set wireless.ibss_radio1.disabled='0'
uci commit
wifi

Wird 0 durch 1 ersetzt, wird IBSS entsprechend deaktiviert.

So Schluss jetzt. Es gibt auf GitHub einen neuen Branch Gluon v2016.1.x. Da kann ich mich gleich an ein neues, stabiles Release machen, das auch neuere Hardware unterstützt.

Neues von den Freifunkern aus Köln, Bonn und Umgebung

Hallo, liebe Rheinbacher Freifunkerin!
Hallo, lieber Rheinbacher Freifunker!

Die Freifunker aus Köln, Bonn und Umgebung (KBU) haben Dich vielleicht bereits angeschrieben, weil Du einen Freifunkrouter mit der KBU Classic-Firmware betreibst / betrieben hast und Dich mit Deiner E-Mail-Adresse in ihrer Datenbank eingetragen hast oder von Dieter eingetragen wurdest.

Muster der Statusseite für einen Router in Rheinbach
Muster der Statusseite für einen Router in Rheinbach
In Rheinbach sind wir zum größten Teil nicht mehr bei KBU, sondern beim Freifunk Rheinland e.V. und den Freien Netzwerkern im Rhein-Sieg-Kreis.

Wer sich mit seinem Freifunk-Router unter der ESSID „Freifunk“ verbindet, die Adresse http://10.111.0.1 aufruft und eine Statusseite ähnlich der nebenstehende erhält, der muss nichts mehr tun. Bei einigen Routern könnte noch die alte Statusseite erscheinen oder eine spezielle Rheinbacher Statusseite. Ist der Router auf der Map des Rhein-Sieg-Kreises eingetragen, muss nichts geändert werden.

Meldet sich das Freifunknetz jedoch mit der ESSID „kbu.freifunk.net“, dann muss der Router auf eine neue Software umgestellt werden, wenn es nicht bereits geschehen ist.

Natürlich bin ich / sind wir bei der Umstellung auf unsere Firmware behilflich, aber KBU-Router kann ich / können wir nicht zusätzlich betreuen. Alles geschieht ehrenamtlich in meiner / unserer Freizeit, die begrenzt ist.

Wenn Du Deinen Router weiter mit der KBU-Software betreiben willst, musst Du wie in der KBU-Nachricht beschrieben verfahren. Wenn Du Dich jedoch uns anschließen willst, dann musst Du die Firmware des Rhein-Sieg-Kreises für Rheinbach installieren. Diese Firmware findet sich auf zwei Servern:

http://images.freifunk-rheinbach.de
http://images.freifunk-rhein-sieg.de/rheinbach

Wichtig: Für den Wechsel von der KBU-Classic-Firmware zur neuen Firmware dürfen die alten Einstellungen nicht übernommen werden.
Der Router muss daher vollständig neu konfiguriert werden. Die Konfigurationsseite sollte ausreichend selbsterklärend sein. Die Beschreibung der Freifunker KBU passt auch auf unsere Firmware, nur darf das Image eben nicht von den KBU-Servern bezogen werden, sondern muss von einem der oben angegebenen Server herunter geladen werden.

Hinweise zur Installation finden sich auch auf dieser Web-Seite oder in unserem Wiki.

Neu dabei: Ramershoven

FF-Karte Ramershoven
FF-Karte Ramershoven
Heute sind zwei neue Knoten in Ramershoven dazu gekommen. Mit dem Ramershovener Freifunk können wir auch die dortige Flüchtlingsunterkunft mit einen Zugang zum Internet versehen. Auf einem dritten Router, der bisher über Freifunk Köln, Bonn und Umgebung lief, habe ich bereits die Freifunk Firmware für Freifunk Rheinland e.V. Domäne Wupper installiert. Dieser Router sucht noch ein neues, nettes Zuhause und eine gemütliche Fensterbank in der Peppenhovener Straße oder Eichenstraße.

Für die bessere Abdeckung im Inneren des Übergangsheimes werden die Bewohner zusammenlegen und sich einen weiteren Router selbst kaufen, den ich dann gerne installiere.

Leider gehört Ramershoven zu den weniger gut erschlossenen Ortsteile von Rheinbach. Die Bandbreite der DSL-Anschlüsse liegt dort bei 1 MBit/s. Für diese Bandbreite verbinden sich die beiden TP-LINK TL-WR841ND v10.0 über 90 Meter durch zwei Scheiben und ein paar Bäume ausreichend gut. Hier wäre es schön, wenn die Router einen Lastausgleich beherrschen würden. Dann könnte man über Freifunk und mehrere Router eine höhere Bandbreite bereitstellen, als über einen einzelnen Anschluss. Dabei denke ich nicht an Flüchtlinge in einem Übergangsheim, sondern an die ständigen Bewohner der Ortschaft. Jeder könnte mit der Bandbreite der Summe aller Abschlüsse surfen – natürlich nicht gleichzeitig. Aber wenn man nicht gerade eine große Datei runter lädt, dann hat so ein Internet-Anschluss erheblichen Leerlauf. Dieses ungenutzte Zeit könnte bei einer Lastverteilung über Freifunk von Nachbarn mit genutzt werden.

Neue Firmware

Drei Test-Router
Drei Test-Router
Heute habe ich einen neue Firmware aus dem aktuellen Stand der Software erstellt. Damit läuft jetzt auch mein dritter Test-Router TL-WR841ND v10 mit Freifunk. Auch die bei Rotec im Regal stehenden Router TL-WR941ND v6, von denen ich leider kein Modell habe, werden von dieser Freifunk-Firmware unterstützt.

Ab morgen sind die experimentellen Images auf dem virtuellen Image-Server verfügbar.

PS: Ich weiß, man könnte die Router viel schöner ausleuchten!

TP-LINK TL-WR1043ND V2

Gestern habe ich mich getraut meinen Router TP-LINK TL-WR1043ND V2 auf Freifunk umzustellen. Es hat geklappt. Damit funktionieren die Rheinbacher Images auf folgenden Geräten:

  • TP-LINK TL-WR841N v7.2
  • TP-LINK TL-WR841ND v9.0
  • TP-LINK TL-WR842ND v2.3
  • TP-LINK TL-WR1043ND v2.0
  • TP-LINK TL-WDR3600 v1.0

Für die neueren Modelle TP-LINK TL-WR841ND v10.0 gibt es leider noch kein – funktionierendes – Images. Da muss ich wohl auf das neuen Gluon warten.