Mitgliederversammlung 2019

Am 20.01.2019 hat die diesjährige Mitgliederversammlung des Stratum 0 stattgefunden. Aktuell gibt es nur das live mitgeschriebene Protokoll. Die ins Reine geschriebene Version wird noch folgen.

Beschlussfähigkeit

Die Mitgliederversammlung hat das notwendige Quorum erreicht und war daher nach Satzung beschlussfähig. Nach den Berichten des Vorstandes und der Vertrauensperson wurde der alte Vorstand entlastet.

Space 3.0

Anschließend wurde diskutiert wie sich die Mitgliederversammlung die Communitiy im Space vorstellt und welche Erwartungen an einen Space in fünf Jahren gestellt werden. Die Diskussion hat gezeigt, dass es hier verschiedene Erwartungen und Wahrnehmungen an das Leben im Space gibt. Konsens war, dass für die weitere Entwicklung eine Vergrößerung des Spaces förderlich wäre.

Wahlen

Anschließend wurde ein neuer Vorstand gewählt. Der neue Vorstand besteht aus:

  • larsan (Lars Andresen) als 1. Vorsitzender
  • reneger (René Stegmaier) als 2. Vorsitzender
  • Emantor (Rouven Czerwinski) als Schatzmeister
  • chamaeleon (Linda Fliß), Chaosrambo (Daniel Thümen) und Chrissi^ (Chris Fiege) als Beisitzer

blinry (Sebastian Morr) und rohieb (Roland Hieber) scheiden damit aus dem Vorstand aus. Der neue Vorstand dankt blinry und rohieb für ihre Arbeit. Dies gilt besonders für rohieb, der seit der Gründung des Stratum 0 im Vorstand aktiv war.

Als Rechnungsprüfer wurden shoragan (Jan Lübbe) und sonnenschein (Angela Schmitt) bestätigt.

dStulle (Daniel Sturm) wurde von der Mitgliederversammlung als Vertrauensperson bestätigt.

Freifunk: Project Parker

Project Parker: Klassisches Routing für Freifunk

Shoragan und ich haben auf dem 35C3 über das Project Parker gesprochen. Unsere Vortragsankündigung lautete:

Gluon mit BATMAN setzt klassisch auf ein großes Layer 2 Netz, was in den großen Freifunk Communities zu Problemen führt. Diese Communities begegnen den Problemen i.d.R. mit der Segmentierung des Netzes in Domains. Innerhalb dieser Domains wird allerdings das klassische Netz (BATMAN) eingesetzt.

Mit “Project Parker” versuchen wir diese Probleme durch klassisches Routing in einem hierarchischem Netz zu lösen: Jeder Freifunk-Knoten mit Uplink ist Gateway für sein Netzsegment, macht DHCP und ist DNS-Cache. Das Routing mit BATMAN beschränkt sich nun auf kleine Mesh-Netze innerhalb des gesamten Netzes.

Wir stellen in unserem Talk unsere Architektur vor und zeigen welchen Stand unsere Umsetzung erreicht hat.

Hier unsere Ankündigung im OIO pretalx.

Unsere Präsentation kann man hier herunterladen.

Update 20190109: Unser Talk ist online verfügbar.

Freifunk CI - Ein Jahr später

Vor einem Jahr haben wir angekündigt uns mit Continuous Integration und Testing von Gluon auf echter Hardware beschäftigen zu wollen. Dieser Beitrag soll unsere bisherigen Ergebnisse zusammenfassen und einen aktuellen Ausblick geben.

Eines vorweg: Continuous Integration ist noch nicht gelöst. Aktuell bauen wir unsere Software händisch. Dieser Betrag beschreibt unseren Fortschritt beim Testing.

Hardware

Die von uns zusammengestellte Hardware ist stark von den folgenden Faktoren getrieben:

  • Wir brauchen bestimmte Funktionen, wie z.z. B.nbsp;B. Power Switches und Serial-Ports.
  • Die Hardware darf nicht teuer sein, um einfach weitere Instanzen aufbauen zu können.
  • Tests müssen vollständig automatisch ohne Eingriff eines Benutzers möglich sein.

Unsere Hardware besteht daher aus den folgenden Komponenten:

  • Test-Server: Ein RaspberryPi 3 mit Raspbian
  • Power Switch: Zum Schalten der Spannungsversorgung des Routers benutzen wir 8-fach Relaisboards aus dem Maker-Zubehör. Die Relais werden direkt von GPIOs des RaspberryPi gesteuert. Die Relais werden auf der Ausgangsseite der Netzteile der Router eingeschleift.
  • Knöpfe am Router drucken: zum Drücken von Knöpfen am Router benutzen wir ebenfalls Relais. Hierzu wird das Relais parallel zum Knopf des Routers angeschlossen.
  • Serial Port: Die Serielle Schnittstelle des Routers wird mit einem USB-Seriell-Wandler (auch aus dem Maker-Zubehör) per USB an den RaspberryPi angeschlossen. Diese Wandler sind auch direkt mit 3.3V Logik- Spannung verfügbar und daher ohne weitere Wandler einsetzbar.
  • Ethernet: Mindestens die Client-Seite des Routers muss vom RaspberryPi aus erreichbar sein. Wir schließen das Client-Netz daher direkt mit einem USB-Ethernet Adapter an.
  • Device under Test: Welche Hardware hier zum Einsatz kommt ist davon abhängig welche Hardware getestet werden soll. Wir haben unsere Tests mit einem TP-Link WR-841 gestartet. Im Wesentlichen haben wir diesen Router gewählt, weil der finanzielle Schaden so gering ist, falls wir den Router in der Entwicklung zerstören.

Die folgenden Bilder sollen einen Überblick über unseren Aufbau geben:

Test-Server mit Relaisboard zum Schalten der Spannungsversorgung
Test-Server mit Relaisboard zum Schalten der Spannungsversorgung
Gesamter Aufbau: Oben Test-Server und unten Device-under-Test
Gesamter Aufbau: Oben Test-Server und unten Device-under-Test

Software

Unsere Software besteht aus den folgenden Teilen:

  • Betriebssystem auf dem Testserver
  • Test-Automation
  • Wissen, wie der Router zu bedienen ist
  • Tests

Betriebssystem

Als Betriebssystem auf dem Test-Server kommt ein Stock Raspbian zum Einsatz. Somit steht uns auf dem Test-Server alle Werkzeuge eines normalen Linux zur Verfügung.

Wesentliche Änderungen am Betriebssystem sind:

  • Hardware-Initialisierung: Um GPIOs nutzen zu können müssen die GPIOs exportiert werden. Die Tests gehen davon aus, dass vom System durchgeführt wurde. Hierfür können z. B. Systemd-Units zum Einsatz kommen.
  • Benutzer: Für alle Braunschweiger Freifunker, die an dieser Hardware arbeiten werden eigene Benutzer angelegt.

Test-Automation

Als Testautomatisierung kommt labgrid zum Einsatz. Labgrid bietet die Infrastruktur, die notwendig ist, um ein Embedded Device in einen bestimmten Zustand zu bringen und anschließend auf diesem Gerät Befehle ausführen zu können.

Labgrid wurde zuvor nicht in einer low-cost Umgebung eingesetzt. Daher mussten einige zusätzliche Treiber entwickelt werden:

  • SmallUbootDriver: Der Bootloader auf den günstigen TP-Link Routern ist, im Gegensatz zu Bootloadern auf größeren Embedded-Devices, sehr minimalistisch. Darüber hinaus verhält sich der Bootloader anders, als andere UBoot-basierte Bootloader. Der SmallUbootDriver ist in der Lage diesen Bootloader zu steuern.
  • SysfsDigitalOutput: Um die GPIOs auf dem RaspberryPi nutzen zu können ist ein Treiber für diese notwendig. Dieser wird von SysfsDigitalOutput bereit gestellt.

Hardwarewissen

Hardwarewissen, sowie die Tests sind im Git-Repository ffbs-ci zusammengefasst.

Um die Hardware ansteuern und somit den Zustand des Device under Test steuern zu können muss labgrid Wissen über Hardware und Software haben.

Das Wissen über die vorhandene Hardware ist im local.yaml abgelegt. Dort ist beschrieben, wie die serielle Schnittstelle erreicht wird, welche GPIOs für die Steuerung der Spannungsversorgung und des Reset-Buttons verwendet werden sollen. Darüber hinaus können dort Konfigurationen für die verwendeten Treiber angegeben werden.

Auch wird dort festgelegt welche Strategy labgrid zur Steuerung der Hardware benutzt. In einer Strategy ist das Wissen abgelegt, wie das DUT in Zustände gebracht werden kann. Im Fall des TP-Link WR-841 sind die folgenden und einige weitere) Zustände in der SmallUbootStrategy definiert:

  • uboot: Das System befindet sich in einer UBoot-Konsole.
  • good_config: Das System wurde mit einer als funktionierend bekannten Firmware per TFTP geflashed und befindet sich nun im Config-Mode.
  • good_running: Das System hat den Config-Mode verlassen und befindet sich nun im normalen Betrieb.
  • new_running: Eine neue Firmware wurde über den Auto-Updater des als funktionierend bekannten Systems geflashed und befindet sich nun im normalen Betrieb.

Tests

Labgrid kommt mit einem Plugin für pytest. Die Tests sind daher für pytest geschrieben. Unsere Tests befinden sich aktuell in test_uboot_strategy.py.

Um das Schreiben von Tests zu vereinfachen setzen wir auf pytest-fixtures: Erwartet ein Test einen Parameter und es gibt eine Fixture mit diesem Namen, so gibt pytest die Fixture als Parameter mit in den Test.

Für unsere Tests sind Fixtures definiert, die das DUT vor einem Test in die Zustände der Strategy bringen. Die folgende Fixture bringt das DUT in den Zustand uboot, also den Bootloader.

1
2
3
@pytest.fixture(scope="function")
def in_uboot(strategy):
    strategy.transition("uboot")

Der folgende Test prüft dann, ob der Bootloader überhaupt funktioniert. Dieser Test ist eher als ein vorbereitender Test zu verstehen.

1
2
3
4
5
6
7
def test_uboot(target, in_uboot):
    command = target.get_driver('UBootDriver')
    stdout, stderr, returncode = command.run('version')
    assert returncode == 0
    assert len(stdout) > 0
    assert len(stderr) == 0
    assert 'U-Boot' in '\n'.join(stdout)

Der folgende Test hingegen prüft, ob im Config-Mode, die vorgeschlagenen Koordinaten korrekt sind. Wir ändern diese Koordinaten in unserem Gluon auf eine Koordinate in Braunschweig, (etwas unauffälliger Lokalpatriotismus) daher ist es sinnvoll zu prüfen, ob diese im Image auch korrekt abgelegt werden.

1
2
3
4
5
6
7
8
def assert_web(url, text_to_find):
    r = requests.get(url)
    assert r.status_code == 200, "Trying to get url {} failed with status code {}. Was looking for text '{}' there...".format(url, r.status_code, text_to_find)
    assert text_to_find in r.text, "Could not find '{}' in {}. Site returned:\n{}".format(text_to_find, url, r.text)

def test_good_config_default_coordinates(target, in_good_config):
    assert_web("http://192.168.1.1/cgi-bin/config/wizard", "10.52378")
    assert_web("http://192.168.1.1/cgi-bin/config/wizard", "52.26469")

Testabdeckung

Aktuell befinden sich in unserer Sammlung insgesamt 73 Tests. Mit diesen Tests sind wir in der Lage das Update eines Routers von einer als funktionierend bekannten Version auf eine neue Version zu testen und in dieser neuen Version Tests durchzuführen.

pytest mit Tests
pytest mit Tests

Die Tests beschränken sich dabei aktuell auf Tests der für Freifunk Braunschweig spezifischen Erweiterungen, sowie der grundsätzlichen Überprüfung der Konnektivität zum Freifunk Braunschweig Netzwerk.

Hierbei werden viele für den Benutzer wahrnehmbare Funktionen, wie z. B. das Aussehen und der Funktionsumfang der Weboberfläche der Router noch gar nicht getestet. Hier ist also durchaus noch Luft nach oben.

Ausblick

Mit den nächsten Schritten soll es nun in zwei Richtungen weiter gehen.

Zum Einen soll das Freifunk-Lab um weitere Router erweitert und die Testsammlung auf diese Router angepasst werden. Hierbei soll besonders auf andere Architekturen geachtet werden.

Zum Anderen soll eine wirkliche Continuous Integration erreicht werden: Werden Änderungen auf eines der Freifunk Braunschweig Repositories gepusht, so sollen diese automatisch gebaut und auf der Hardware getestet werden.

Anschließend ist denkbar dies ebenfalls für den Gluon Upstream zu tun. Dies könnte die Gluon-Entwickler mit zeitnahen Smoke Tests ihrer Änderungen versorgen.

Mitarbeit an diesen Themen ist gern gesehen. Freifunk Braunschweig ist unter Kontakt zu erreichen.

Freifunk Braunschweig Event WLAN

Freifunk Braunschweig hat, gefördert durch die Stadt Braunschweig, WLAN-Equipment für Veranstaltungen angeschafft. Mittlerweile ist die Inbetriebnahme abgeschlossen und die Ausstattung ist bereit für die erste größere Veranstaltung.

Accesspoints des Event-WLAN
Accesspoints des Event-WLAN

Hintergrund

Der Rat der Stadt Braunschweig verfolgt seit einiger Zeit das Ziel, mehr WLAN in der Stadt anzubieten. Ein Baustein dabei ist die Kooperation der Stadt mit HTP und BS-Energy. Zusammen bieten diese an einigen zentralen Punkten der Innenstadt zeitlich begrenzten und zensierten Internetzugang an.

Als ein weiterer Baustein wird auch Freifunk Braunschweig gefördert. Der Rat der Stadt hat mit dem Beschluss 16-03066 Freifunk Braunschweig insgesamt 4.500 € zugesagt.

Freifunk Braunschweig hat daraufhin ein Konzept für den Einsatz des Geldes erarbeitet:

  • Mit einem Teil des Geldes soll Hardware für das Testen von Freifunk- Firmware auf realen Geräten beschafft und aufgebaut werden. Die so geschaffene Infrastruktur kann z.B. mit einer Embedded Testing Suite wie Labgrid benutzt werden, um die weitere Entwicklung zu vereinfachen.
  • Der größere Teil des Geldes soll für die Anschaffung von WLAN-Equipment für Events ausgegeben werden.

Die Anschaffung von Event-WLAN bietet folgende Vorteile:

  • Durch den Einsatz von Freifunk auf Veranstaltungen wird die Idee des offenen WLANs weiter beworben.
  • Wenn die Geräte an einer zentralen Stelle verfügbar sind stehen diese auch Nutzern zur Verfügung, für die sich die Anschaffung selber nicht lohnen würde.

Hardware

Richtfunkstrecke für größere Distanzen
Richtfunkstrecke für größere Distanzen

Bei der Auswahl der WLAN-Hardware wurden folgende Anforderungen berücksichtigt:

  • Es soll die Versorgung von mehreren 100 Geräten mit WLAN möglich sein.
  • Die Geräte sollten permanent oder zeitweise für den Einsatz im Außenbereich geeignet sein.
  • Im Paket sollte das notwendige Zubehör wie Ethernet-Switche, Netzwerkkabel und ein Mini-Server als Controller enthalten sein.
  • Es sollten ausreichend Geräte zum Versorgen größerer Flächen, wie z.B. bei Veranstaltungen wie dem Hacken Open Air oder im nördlichen Bürgerpark vorhanden sein.

Die Auswahl fiel auf Geräte von Ubiquiti. Beschafft wurde folgende Hardware:

  • 2x Ubiquiti NanoBeam ac Gen2: Für Richtfunkstrecken
  • 4x Ubiquiti UAP-AC-Pro: Indoor-Accesspoints
  • 7x Ubiquiti UAP-AC-M: Outdoor-Accesspoints
  • 5x Ubiquiti UAP-AC-M-Pro: Outdoor-Accesspoints
  • 3x Ubiquiti UAP-AC-Lite: Indoor-Accesspoint
  • PCEngines APU2C4: Mini-Server
  • 3x ZyXEL GS1900 Managed PoE-Switch mit 8 Kupfer-Ports und 2 Faser-Ports
  • Huawei e5885 LTE Router
  • Netzwerkkabel: 20x 0,5 m; 5x 20 m; 5x 10 m; 10x 5 m
  • Mehrfachsteckdosen
  • Boxen zum Transport

Inbetriebnahme

Nachdem die gesamte Hardware eingetroffen war, wurde das System an insgesamt drei Treffen in Betrieb genommen.

Beim ersten Treffen wurden Geräte inventarisiert und Kabel mit Schildern versehen. Damit soll sichergestellt werden, dass alle Geräte ihren Weg zurück zum Braunschweger Event-WLAN finden. Kabel länger als 1 m wurden darüber hinaus an beiden Enden mit Namen versehen. So ist es möglich auch bei vielen Kabeln noch beide Enden zuordnen zu können.

Beim nächsten Treffen wurde der Server und der WLAN-Controllers eingerichtet. Bei diesem Treffen wurden darüber hinaus alle Geräte in Betrieb genommen. Außerdem wurden Konzepte für den Aufbau und den Betrieb eines Event-WLAN-Netzes erarbeitet.

Beim letzten Treffen wurde die (Fern-) Wartbarkeit des Systems verbessert. Das Event-Netz war nun bereit für einen ersten größeren Test.

Testbetrieb

Beim Testbetrieb waren zeitweise über 40 Geräte mit dem WLAN verbunden.
Beim Testbetrieb waren zeitweise über 40 Geräte mit dem WLAN verbunden.

Ein Test konnte auf einer Hacker-Veranstaltung durchgeführt werden. Hier waren fast 30 Personen mit diversen Geräten anwesend. Es wurden mehrere Gebäude, sowie Außenbereiche mit WLAN versorgt. In der größten Ausbaustufe waren elf Accesspoints in Betrieb und versorgen über 40 Clients mit Netzwerkzugang. Auf dem Event wurden in vier Tagen weit über 100 GB Daten über das WLAN ausgetauscht.

Das Feedback zur Qualität des WLAN auf dieser Veranstaltung war durchaus positiv. Beim Auf- und Abbau hat sich die Vorbereitung der vorherigen Treffen als gut erwiesen.

WLAN auf Deinem Event?

Outdoor-Accesspoint während des Testaufbaus
Outdoor-Accesspoint während des Testaufbaus

Mit dieser Hardware ist Freifunk in der Lage WLAN auf mittleren Events zur Verfügung zu stellen. Wir sind nun auf der Suche nach Veranstaltungen im Stadtgebiet, auf denen die Technik getestet werden kann.

Kontakt kann über kontakt@freifunk-bs.de hergestellt werden.

CoderDojo Braunschweig

Die Braunschweiger Zeitung hat uns zum 24. CoderDojo besucht und einen Artikel über uns geschrieben. Die Anmeldung zum 25. CoderDojo am 18.11. erfolgt über eventbrite.

Nach dem 24. CoderDojo, hier ein kurzer Zwischenbericht.

Seit Mitte 2014 findet das CoderDojo Braunschweig - mit einige Aussetzern - monatlich statt. An einem Samstagnachmittag betreuen dann unsere Mentoren für einige Stunden interessierte Kinder und Jugendliche, die sich spielend programmieren beibringen.

Angefangen hat alles, als Eltern bei uns anfragten, ob wir nicht dabei helfen könnten in Braunschweig ein solches CoderDojo aufzubauen, da sie zu dem Zeitpunkt mit ihrer Tochter regelmäßig nach Berlin fuhren. Das Interesse geweckt, fuhren direkt 7 Entitäten mit zum nächsten CoderDojo-Termin nach Berlin, um sich mal anzuschauen, was das eigentlich genau ist. Kurz darauf stand für uns fest: Das wollen wir auch.

Je nach Erfahrungslevel beginnen die Kinder und Jugendlichen beispielsweise mit Scratch, einer aufs Erlernen ausgelegte Programmiersprache und -Umgebung. Den Sprung zur Hardwareebene schaffen kleine Platinencomputer wie das BBC-micro:bit, von denen wir einige zur Verfügung stellen können. Wenn auf eine visualisierte Darstellung des Codes verzichtet werden kann, kommt gerne die Programmiersprache Python zum Einsatz.

Auch 3D-Druck, bei dem die Modelle ähnlich wie beim Programmieren erstellt werden können, oder der Bau eines Elektromotors ist bei uns möglich.

Octopress Workflow: Online Preview

As a hackerspace a blog is another great opportunity to use all that nerd tools that we tend to talk about. For example this blog is hosted using Octopress. And, of course, content is managed using Git and gitli.

Since rohieb has just added another way of writing and previewing blog posts, I want to update our blog’s documentation.

Working Offline

This is the oldest and most bare metal way of writing and previewing a new post. This basically means installing Ruby and Octopress on your machine. Valodim has written some documentation in one of our first blog posts.

Collaboration

If you want online collaboration, you may want to give our Etherpad integration a try.

Ever noticed the hourglass tool in a Stratum 0 pad? If you write your post in a pad and click that icon, bogomir will render a blog containing just your article. I have prepared a demo pad with some source from an old post.

Another nice thing about this workflow is that you don’t need a local Ruby setup. But: The big disadvantage is that you are not able to test the images you have embedded into your post (since there is no way to upload them).

All-yes online preview

Git has the advantage of branches, i.e. related versions of code running parallel. For an overview of working with Git branches, refer to the chapter Git Branching in the Pro Git book.

Usually the master branch is used to build the actual blog at https://stratum0.org/blog/.

This workflow introduces a new branch into the blog Git: The preview branch is used to build a preview at https://sandbox.stratum0.org/blog/.

This is done using GitLab CI. The actual magic is configured in .gitlab-ci.yml. In this case you can use all features of Octopress – including embedded images.

Another advantage of this workflow if the possibility to review new posts. If you think you finished your work you can clean up your Git history and file a merge request. It’s then up to someone else to have a look at your work, maybe correct some last typos and then merge it into master and thus publish your post.