Routing and WiFi experimentation

The beginning of my work period was pretty busy, not always with Summer of Code things. My mentor math and I had already talked about a lot of the things that needed to happen in order to move qaul.net away from an OLSR based routing protocol and make it extendable as well.

As previously hinted, we are using Rust for the protocol implementation, allowing for easy integrating into the existing C code as well as giving us the option to bit-by-bit rewrite the entire software in Rust, a much more modern and forgiving language. The first thing I tackled was to design a common API for the qaul.net library (libqaul) to use to talk to any networking backend. The routing code holds the state of the network and allows the sending of direct and flooded messages into a network (regardless of implementation under the hood). But to do that we also had to define some common characteristics for nodes and messages.

In the end, a lot of the work was sitting down, going through old notes and determining what our protocol was supposed to do. We looked at existing protocols a lot, thinking about extendability and backwards compatibility. The protocol itself will be binary encoded, although not yet sure which format. There is msgpack, cpnproto/ protobuf as well as some Rust specifics (Rust Object Notation to mention one) to look at. But that shouldn’t actually matter for now. All the versioning and extend-ability are being done in the struct level of the protocol, meaning that we could even switch binary encoding half way through. Keeping the encoding and decoding written in Rust, this is actually incredibly easy with the `From` traits. But I digress…

The protocl we ended up designing can handle any type that already exists in qaul.net, as well as allows for custom user extentions – messages that have a type field and a random binary message payload which allows plugins on both sides to interact with it.

 

So…so far the routing core isn’t doing much routing. But that’s okay, that comes later 🙂 With the networking API in place, we actually have something what we’ve wanted for the last 2 years: a hardware abstraction over any networking backend. The API is implemented in Rust as a trait (think like a Java interface), which makes implementations and even implementation specific code very easy.

The next thing on our todo list is working out how WiFi direct behaves. This is kinda disconnected from the rest of the project, but it’s something that has to happen. For this purpose I’ve written a small demo app (still WIP at the time of this writing), which will let us explore the way that WiFi direct works, how to build mesh groups, etc. These experiments are still ongoing, and we hope to have something to show until the end of the week. I will probably publish a small article on my blog about it – check it out (if you’re reading this in the future 😉 )

All in all, the amount of code written in the first section of GSoC2018 is medium. We have however answered a lot of open questions, have a good plan on how to continue and hope to have more to show off by the time of the next evaluation.

If you’re curious about the progress being made, check out the github repository.

 

Until next time,
Katharina

PowQuty Live Log Second Update

It’s been nearly a month since my last update on the PowQuty Live Log project and i would like to tell you, what has been done
so far and provide information on what will be done in the next month.

PowQuty got updated, to support Slack and mqtt event notification and can already be used in the current PowQuty version.
In addition to this, there have been some bug fixes during the last month and some new features were added.
On event occurrence the event gets stored in a csv file and each entry is displayed in the luci-app. To increase the usability,
a traffic light system will be added, which will show for each event type its occurrence time and show if the current values
are in violation of EN50160.

  • Green: Everything is ok, no violation
  • Yellow: Close to a violation
  • Red: This event time is in violation of the norm
  • The event messages contain a times stamp, the duration of the event and updated event Type information, as well as event type related
    information and GPS data.
    .

    As receiving notifications or emails on every event occasion can get noisy, we decided to provide a weekly summary of the events in
    addition to the regular notifications.
    The user will be able to decide if he wants to receive this summary, every event, or both. We consider using the traffic light system
    here as well, to increase the readability and enable users to understand the quality of their power supply network, without a lot of
    knowledge of the EN50160 norm.
    We discussed individual intervals and keep it in mind as a possible later feature.

    Best regards
    Stefan

    PowQuty Live Log First Update

    As mentioned in my previous blog post, i am going to add a live log and notification system for
    certain events to the power monitoring tool PowQuty. The first steps have been done and the
    configuration has been extended.
    Three types of notifications have been added to the configuration options during the first month of coding.
    Namely email, slack and mqtt. Mqtt was in use before, but was extended to allow a second host and topic for
    the power quality events.
    The powquty configuration page was redesigned to use a separate tab for each notification option
    to increase overview.

    The old configuration page would have been very crowded with all the new options
    The new configuration view with mqtt tab open

    Power quality events, that cause a notification are:

    • Voltage dip between 10% and 90% of the reference voltage of 230V
    • Voltage swell above 110% of the reference voltage of 230V
    • Voltage dip < 10% of the reference voltage
    • More than 5% of the samples of one harmonic are above the threshold

    As the power supply network in Berlin was not willing to provide such events an option for test measurement
    input was needed. A file read flag for powqutyd was added and needs a little bit of clean up
    before a pull request on the upstream powqutyd.
    The library for the USB-oscilloscope provides the number of EN50160 events per measure cycle and
    the kind of each event. As of now some basic slack notifications are added, which provide the event
    type and the event start time from measurement start in milliseconds to the channel and team set
    in the luci web interface or under /etc/conf/powquty.

    Slack notifications with start time in milliseconds relative to measurement start, probably will be UTC or local in the future

    In the notification the type of event is provided to allow the network administrator to react directly
    to the changes, without to check the log any further.
    The other notification options will be added and tested soon.

    Vorstellung eines Freifunk Advisory Councils für die Communities

    Information vom Förderverein freie Netzwerke e.V.

    Liebe Freifunker_Innen,

    wie im November des letzten Jahres angekündigt (siehe http://lists.freifunk.net/pipermail/wlantalk-freifunk.net/2014-November/000391.html), haben wir uns gemeinsam mit Euch Gedanken zur Gründung eines “Freifunk Advisory Councils” gemacht.

    Das zu gründende Freifunk Advisory Council (AC) soll dem Förderverein freie Netzwerke e.V. zukünftig bei Entscheidungen zur Seite stehen.

    Jede Community kann bis zum 14.05.2015 einen Vorschlag für ein Mitglied an die Mailingliste council-kandidaten@freifunk.net melden (ACHTUNG: Alle Eingänge sind über eine öffentliche Mailingliste einsehbar). Zum Besetzungschlüssel des Advisory Councils und Verfahrensweisen haben wir unten alles aufgelistet.

    Das Council wird vorerst auf eine Zeit von 12 Monaten gewählt, in denen auch die weiteren Details zur Zusammenarbeit geklärt werden. Vor allem die möglichst kurzen Fristen zur Beantwortung von Anfragen und Abstimmungspunkten durch die Mitglieder_Innen.

    Weitere Details finden sich unten.

    Rückfragen bitte ins Pad unter https://pad.freifunk.net/p/faq_advisory_council eintragen, wir versuchen Sie so schnell zu bearbeiten.

    Ziel ist es, das Council spätestens im Rahmen des anstehenden WCWs initial zu besetzen.

    Viele Grüße, schönes Wochenende,
    Euer Vorstand des Fördervereins freie Netzwerke e.V. und die Mitwirkenden

    P.S.: Dieser Text ging auch an die Kontaktadressen aller Freifunk Communities in Deutschland.

    Funktionsweise und Aufgaben des Freifunk Advisory Councils (AC)

    Aufgaben

    • Das AC entscheidet in Streitfragen bei der Vergabe von freifunk.net Subdomains oder API Einträgen
    • Beratung und Hilfe zur Beilegung von Streitigkeiten in bzw. zwischen Freifunk Gruppen

    Zusammenstellung

    Zur Einreichung von Vorschlägen wird benötigt:

    • (Vollständiger) Name
    • Bundesland
    • Community (in API eingetragene Stand 17. April 2015)
    • Email/Kontaktadresse

    Sollten die Einreichungen eines Bundeslandes zahlenmäßig die Anzahl der zu entsendenden Repräsentanten übersteigen, organisieren die Communities des Bundeslandes eine Wahl. Bis dahin bleibt die Position
    unbesetzt.

    Die Besetzung ist angelehnt an die föderale Struktur der Bundesrepublik Deutschland: 21 Mitglieder

    • Baden-Württemberg 2
    • Bayern 2
    • Berlin 1
    • Brandenburg 1
    • Bremen 1
    • Hamburg 1
    • Hessen 2
    • Mecklenburg-Vorpommern 1
    • Niedersachsen 2
    • Nordrhein-Westfalen 2
    • Rheinland-Pfalz 1
    • Saarland 1
    • Sachsen 1
    • Sachsen-Anhalt 1
    • Schleswig-Holstein 1
    • Thüringen 1

    Organisiation

    Organisiert und kommuniziert wird über eine Mailingliste, die der Förderverein freie Netzwerke e.V. zur Verfügung stellt. Für Anhörungen oder Diskussion wird ein mumble empfohlen.

    Anfragen

    Jede_r darf Anfragen an das AC per E-Mail richten.

    Abstimmungen im AC über Domain und API Fragen

    • Abstimmungsfragen werden nach Darlegung des Sachverhaltes vom AC als Ja/Nein Fragen formuliert.
    • Entscheide werden mit einfacher Mehrheit beschlossen.
    • Keine Antwort gilt als NEIN.
    • Entscheidungen werden an die Beteiligten des Streitfalles gesendet.
    • Ablehnende Entscheidungen bedürfen einer Begründung.

    Treffen

    • das AC trifft sich mindestens einmal im Jahr in Persona
    • der Termin und Tagesordung wird innerhalb des AC abgestimmt
    • in Härtefällen kann der Förderverein freie Netzwerke e.V. einen Reisekostenzuschuss bewilligen

    Aufnahme neuer Mitglieder, Ausscheiden, Ausschluss, Vertretung

    • Nicht besetzte Positionen sind Enthaltungen.
    • Beim Ausscheiden von Mitgliedern kann nachbesetzt werden, siehe Zusammenstellung.
    • Der Verteilungsschlüssel muss beibehalten werden.
    • Das AC kann Personen mit Zweidrittelmehrheit ausschließen
    • Pro Mitglied kann zusätzlich ein Vertreter bestimmt werden, der bei Verhinderung des Mitglieds einspringt oder bei Ausscheiden des Mitglieds bis zur Nach- oder Neubesetzung dessen Aufgaben übernimmt.

    Reporting

    Das AC verfasst am Ende des Jahres einen zusammenfassenden Bericht, über die Zahl und Art der Anfragen und veröffentlicht diese unter blog.freifunk.net.

    Freifunk-Broschüre “Freie Funknetze in der Praxis” von Medienanstalt Berlin-Brandenburg

    Die Medienanstalt Berlin-Brandenburg (mabb) hat eine eine Broschüre “WLAN für alle – Freie Funknetze in der Praxis” veröffentlicht. Aus der Pressemitteilung: Aktuelle Publikation der mabb informiert umfassend über das Thema „Freifunk“.

    Sie erläutert ausführlich, was sich hinter „Freifunk“ verbirgt und welche Chancen und Risiken mit diesem Netz verbunden sind. Mit der Publikation möchte die mabb die Freifunk-Community dabei unterstützen, die Bekanntheit von Freifunk in der Öffentlichkeit zu vergrößern. Noch kennen zu wenige Bürger und Institutionen die Möglichkeiten dieses Netzes. Und die, die es kennen, haben Bedenken und Vorbehalte es zu nutzen oder selbst anzubieten. Fragen wie „Ist das Freifunk-Netz sicher?“, „Mache ich mich strafbar wenn ich meinen Router für andere öffne?“ oder „Hafte ich für illegale Downloads anderer?“ werden immer wieder gestellt. Die Publikation der mabb greift diese Fragen auf und gibt praktische Erläuterungen und Anwendungshinweise für Nutzer und Anbieter.

    Die Broschüre kann als als PDF heruntergeladen oder analog bestellt werden. Die Inhalte stehen unter einen freien Creative Commons-Lizenz.

     

    Freifunk beim Google Summer of Code

    Google nutzt für viele seiner Dienste OpenSource-Software. Mit dem Google Summer of Code möchte sich Google bei der OpenSource-Gemeinde bedanken und fördert Studenten für ein von Mai bis August laufendes Projekt mit 5500 US$ – in diesem Jahr über 1100 Studenten aus aller Welt.

    Im Jahr 2014 nahm Freifunk wieder am Google Summer of Code teil. Freifunk integriert dabei als Dachorganisation weltweit Initiativen wie guifi.net, ninux.org, wlan slovenija und LibreMesh aus Argentinien. Wir bekamen in diesem Jahr 9 Slots für Projekte, die Studenten in Deutschland, Frankreich, Italien, Spanien und Slowenien bearbeiteten. Die Projekte beschäftigten sich u.a. mit der Freifunk-API, Netzwerkprotokollen und Software zum Communitymanagement. Im Freifunkblog können Details zu den Projekten nachgelesen werden.

    Den Abschluss des diesjährigen Google Summer of Code bildete der Mentors Summit, zu dem jede Organisation zwei Mentoren entsenden darf. Zur Feier des 10-jährige Bestehens waren auch Teilnehmer aus den vergangegen Jahren eingeladen und der Summit wurde um einen Tag verlängert.

    Freifunk fun in USA

    Auf dem Programm stand auch ein Ausflug, wo wir das echte Amerika kennenlernten und gemeinsam mit Teilnehmern aus China und Vietnam Basketball trainierten.

    Mehr als 600 Teilnehmer aus aller Welt trafen sich in San Jose, Kalifornien, und wir hatten die Chance uns über unsere Projekte auszutauschen, neue Kontakte zu knüpfen und nicht zuletzt den 10. Google Summer of Code zu feiern. Als Überraschungsgast zum Jubiläumsempfang war Linus Torvalds geladen. In einem Treffen hatten wir die Gelegenheit, mit ihm über Freifunk zu sprechen.

    Ideen für Projekte im Jahr 2015 können schon jetzt im Wiki eingetragen werden. Falls ihr Kontakte zu Universitäten oder Fachhochschulen habt, sprecht mit Dozenten, Studenten oder Lehrstuhlinhabern, um Unterstützung für Projekte im Sommersemester 2015 zu bekommen.

    Links

    Projektideen http://wiki.freifunk.net/Ideas

    Fotos zum Mentor Summit: https://www.flickr.com/search/?tags=gsoc14

    Linus Torvalds and Dirk Hohndel meetup with Freifunk Community at Google Reunion

    Freifunk attendees had the chance to discuss Community Networks with Linus Torvalds and Dirk Hohndel from Intel at the Google Mentor Summit. Linus said, it was impressive to see the growth of community networks around the world and it is exciting to see so many people working on Linux for embedded devices.

    Linus Torvalds, Mario Behling, Federico Capoano, Freifunk, Google Summer of Code

    GSoC 2014: Hardware Detection [ Final ]

     

    Hi everyone!

    I am very happy to have participated do GSoC 2014, this experience have permitted to me to learn a lot about opensorce comminity and programming, i have learned also Lua programming language, while it seemed a little ugly  to me in the firsts times I ended up loving it.

    This GSoC project permits to people installing Libre-Mesh on their devices and have device specific quirks already solved by the hardware detection module, without user intervention, while it permits to developers to write little modules to easly supports new hardwares and solve their quirks.

    In particular in the second part of my GSoC I have improved hardware detection, in particular I have created a module to autoconfigure TL-WDR3600 and a module that permits to Libre-Mesh to detect wan port of a lot of routers taking advantage of the OpenWRT infrastructure.

    While creating those new modules I have also realized how to improve general Libre-Mesh infrastructure and committed various improvement to the hardware-detection branch, that is now in the official repository ready for merging in develop branch.

    Futhermore, during the last phase of this project I have optimized the code including modules I have written in the first period like usbradio detection module. 

    Obviously all this work have been possible thank to the help of the community that helped me in the whole coding period.

    Best Regards 😉

    Einladung zum Freien Freifunktreffen in Halle am 19.07.2014 (Sommerfest)

    Wie jedes Jahr, trifft sich auch dieses Jahr die hallesche Freifunk-Community im Sommer am Hufeisensee. Es ist ein regionales Treffen, welches offen für alle Freifunk-Communitys ist. Hiermit möchten wir euch einladen am 19.07.2014 vorbei zu schauen.

    Diesmal sind wir zu Gast auf dem Vereinsgelände vom Tauchclub Orca in der Schkeuditzer Str. 70 | 06116 Halle, wo wir uns ab 15 Uhr treffen. Das Gelände bietet alles, was Freifunker für ein produktives Treffen benötigen: Freifunk, Internet, Strom und Grill sind genauso vorhanden, wie Tische und Stühle um eigene Rechentechnik aufzubauen. Die Freifunk Community aus Halle will dieses Treffen nutzen, um einen eigenen Förderverein zu gründen. Der Förderverein soll die Aufgabe übernehmen, das Projekt Freifunk in Halle organisatorisch zu unterstützen. Weitere Informationen gibt es im Freifunk.net-Wiki. Fragen und Anregungen können auch bei uns im Forum diskutiert werden. Gäste werden gebeten, sich anzumelden, um besser planen zu können.

     

    GSoC 2014: Hardware Detection

    Hi everyone!

    Before  starting coding I have been studying Lua programming language I read  some tutorials and I did some practical examples. After that, I went to  the Libre-Mesh architecture to understand better how it is done. When I  understood the programming pattern of LiMe I started coding.

    First of all, I started creating a plug-in module for ath9k-htc based hardware. This module has been tested using a TP-LINK WDR3600 and two TL-WN722N USB radios. While working I have included an hotplug hook so the usb radios can be dynamically plugged and removed from the system while it’s running. 

    After  having the usbradio module almost done I have been working creating a  modular hardware detection plug-in for Libre-Mesh. This hardware  detection module have been completed with clean and configure functions. During the development of this part I have discovered some bugs in the file config.lua and I have solved it.

    Currently, after doing some cleaning and debugging both modules are almost finished.

    Obviously  all this work have been possible thank to the help of the community and  I hope to do my best during the rest of the coding period.

    I will be happy to receive feedback or tips

    Best Regards 😉