Hello there! I am Angie Ortiz Giraldo, one of the students selected for Google Summer of Code 2021, I’m very happy for have this opportunity and share this overview about my GSoC project. In this project I will be working with LibreMesh organization, a sub-organization of Freifunk in this GSoC. I am interested in software development and Community Networks environment. In this field, I have worked in different projects about Community Networks in Colombia that have implemented LibreMesh for their networks. For this reason, I am interested in improve and expand LibreMesh functionalities in some way.
About LibreMesh
LibreMesh is a modular framework for creating OpenWrt-based firmware for wireless mesh nodes. Several communities around the world use LibreMesh as the foundation of their local mesh firmwares. The project includes the development of several tools. The firmware is the main piece and allow simple deployment of auto-configurable multi-radio mesh networks. If you want to know more about LibreMesh you can go to the project website.
My GSoC Project
The main idea of this project seeks to improve the implementation of the administration interface of the Pirania captive portal which is implemented in LibreMesh, a plugin used in different Community Networks. I propose to divide the project in three important pillars: Solution design, Coding and Documentation. Every stage will have different task to do, and some deliverables.
Deliverables
Develop an UI proposal for the Pirania captive portal.
Plugin for the LimeApp that implements the UI with the required functionalities.
Coding tests for the functionalities implemented.
Write blog posts about different project stages.
Write documentation about features, and how to add plugins to Lime-App.
And more!
To sum up, this in a first approach about the project, but I hope to share some advances soon đ
Hello everyone, I am Ayush Shrivastava, one of the students selected for Google Summer of Code 2021 for Irdest sub-organization under the umbrella organization freifunk. If youâre wondering which topic/project the blog is focused on, then you may give it a look here!
Irdest
Well, if you donât know, then let me first introduce what Irdest(irde.st) is and what it does/supports. So, Irdest is a software suite that allows users to create an internet-independent, decentralized, wireless, adhoc mesh network. It removes all the dependencies of the user from a specific single service and enables users to create a mesh of their own. In this network mesh, users can communicate to each other via messaging(both, individual and Room) and placing voice calls. Irdest network mesh service also allows users to share files between them without relying on the internet. And also when a user enters the Irdest mesh network(note that user needs not connected to the internet i.e., without having an IP address, it can be a P2P connection over Wi-Fi or Bluetooth), their IP address is completely hidden thereby maintaining privacy andreducing possible breaches that may occur. In the irdest network mesh, as soon as a user enters the network, they are assigned an ID, which is a unique cryptographic key that helps identifying the users. All the messages/calls/file transfers made in Irdest network mesh are completely end to end encrypted, again a positive sign from security & Privacy perspective. Currently, Irdest is supported for Linux & Android devices. For android, it is pretty much in incubation state and there are a bunch of points & directions where we can improve. This summer, I aim to implement some features on android client from the irdest upstream.
WARNING: This blog has a tons of mentions of FFI, you may get overwhelmed by the term, so it stands for Foreign Function Interface.
Current Progress & FFI Overview
So this was what Irdest is all about and a higher level overview of how things really work in it. As mentioned previously, the android client is pretty much in its incubation state, so we wish to implement it in a clean & modern way. So, since we want to make use of features supported by Irdest(in upstream) on the android application, therefore we need to maintain/create a binding or kind of a link between core Irdest code that makes all this internet independent network mesh possible & application codebase(to call those methods from). The point is that the core Irdest code that supports these functionalities is written natively in Rust, and we we want to utilize this pre-written library on android, without writing it again(in Kotlin)for android. So to make it possible, weâre going to write an FFI Layer(Iâll write in detail about FFI in some other post, but for the time being it is sufficient to know that by FFI we can call functions written in a specific language(mostly native languages like C++, C, Rust) from some other languages). This FFI layer currently exists in the module, but it is a bit old-fashioned, so in the initial phase of my coding period I plan and propose to rewrite this layer with best possible modern day FFI practices and following some standard references. The most crucial part of this project is this FFI layer, because it is the fundamental building block for the android project, once it is set and ready, then weâll be able to use the functions and services provided in the native Irdest library written in Rust and extend our further development process via writing the application.
FFI Implementation – A Blueprint
The FFI already is quite notorious for the undefined behavior and on top of it, there is very less official documentation available on Rust-Kotlin FFI so this makes it more tricky & challenging to implement, but for the course of our development process, weâll be following and taking inspiration from how Mozilla have implemented FFI integration between their existing rust library and their firefox android client. Another instance where they use Rust-Kotlin FFI is their Glean project(a telemetry service). Iâll be taking most of the inspiration by and practices being followed in Glean, as a result of which weâll be writing FFI bindings on our own. After once weâve written FFI layer, my next step will be to test it again thoroughly and make sure it works perfectly and does not has any bugs residing.
Further Development:
Once we have a robust FFI layer ready, then Iâll move to core android development process, thatâll entail writing UI for the application, architecting it properly, modularizing the application codebase and following the Modern Android Dev practices. Well this will be a relatively easier job to do in comparison to that of writing FFI layer xD My next step after this would be implementing the chat service in the application. Weâll focus in its detailing after weâre done with the very first milestone, the âFFI Layerâ. We’ll see the plan of action for chat service in a separate blogpost, after the first coding phase : )
Thanks for reading! Cheers, Until next time we meet!
Hey everyone , hope everyone is doing fine. I am delighted to have been given this opportunity to work for OpenWRT project under Freifunk.
A little about myself
I am currently a sophomore at Birla Institute of Technology, Mesra. I have always been interested in the technical aspect of the world, as to how from the stroke of a keyboard does one get to build/execute such seemingly daunting tasks with such ease.
The curiosity led me to the beautiful world of automation and containerisation along with managing these tasks at scale.
Apart from being a tech-nerd, I have always loved to explore the great mysteries of life, watch football, and play Golf among many others.
I am always ready to talk about the above at any time, so feel free to contact me.
Project Overview
OpenWRT is a Linux distribution for off the shelf Wi-Fi routers. People who want to make and distribute their personal packages, often for development purposes, so far have the option to build the whole firmware from zero, but very few people use the OpenWRT SDKs.
The idea behind this project is to provide the user with an interface where they can simply put in their GitHub repo URL, which can be then compiled and built into an executable Docker Image fit for Launch in k3d cluster, and also available locally.
Benefits to Community
This project will be beneficial for users since now they won’t have to build everything from scratch, and now only provide the URL of their source code.
Additionally, it will also try to achieve the following goals :
Autonomy: no external person is needed for the platform.
Build with many different targets like brcm2708, ar71xx, x86, sunxi, etc…
Rebuilding after every commit can become possible.
And many more âŠ..
Deliverables
A front-end made using flask and python, where the user just needs to login and enter his/her repo URL.
A backend made up using python and shell scripting for creating Docker Image based on the provided source-code.
A database that stores this build docker image, made using MY-SQL database.
A backend service integrating the above with k3d cluster for hosting docker container made using the container.
Next steps
I would be starting from implementing scripts for setting up the entire environment as well as working on the deployment of the newly created docker image on the local k3d cluster. I will also be in touch with my mentor , regarding the execution cycle and scope for improvement of the project.
This year, we were finally accepted back as an organization at the Google Summer of Code. In the meantime, the application and selection phase is over. Google has given us 9 project slots. We didn’t make the decision easy and chose the best ones out of the applications.
Organizations
Freifunk manages projects for different initiatives as an umbrella organization. In this Google Summer of Code we have Retroshare, irdest, OpenWrt, LibreMesh and freifunk itself on board.
Timeline
Currently we are in the community bonding period. During this time, all preparations are made so that the students can do their tasks. Also, they should dive into the communities and get to know people and tools.
Coding officially starts on June 7. All projects must be completed by August 23.
Our Google Summer of Code projects in 2021
Title
Organization
Student
OpenWRT PPA
OpenWrt
Neelaksh Singh
Irdest Android Client
irdest
Ayush Shrivastava
Android native app for network selection capability in LibreMesh routers
LibreMesh
TomĂĄs Assenza
RetroShare WEBUI
RetroShare
Avinash
Freifunk Digital Twin – test on your virtual mesh before going productive
OpenWrt
pschreiber
OpenWrt Device Page
OpenWrt
Aditi-Singh
Freifunk Radio Ressource Management with IEEE 802.11v
OpenWrt
Valerius_B
Updation of the Json Schema to latest version (2020-12) along with the form generation and validation with the updated schema of the tools
freifunk
sh15h4nk
LibreMesh Pirania UI
LibreMesh
Angie Ortiz Giraldo
You can find more details for every projects on our GSoC dashboard.
Google Summer of Code is Google’s summer program for students to learn about, and get involved in open source. It’s happening again for the 17th year in 2021! Over 16,000 students from 111 countries have participated.
Motivate students to begin participating in open source development.
Help open source projects bring in new, excited developers into their communities who stay long after their GSoC ends.
Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits.
Give students exposure to real-world software development scenarios (e.g., testing, version control, software licensing, mailing-list etiquette, etc.).
Create more open source code.
How does GSoC work?
Programming online from their home, student participants spend 10 weeks on their projects (about 175 total hrs) earning stipends upon completion of their milestones. Volunteer mentors help students plan their time, answer questions and provide guidance on best practices, project-specific tools, and community norms while helping integrate students into their communities.
Students receive an invaluable learning experience, an introduction to the global FOSS community and something that potential employers love to see on resumes!
Mentoring orgs will gain new contributions & contributors along with recognition from Google and a higher profile for their project.
How to apply for freifunk @ GSoC 2021?
Pick an idea from our projects page and get in touch with mentors and the community.
Discuss your ideas and proposals.
Submit a draft of your proposal early, so we can give you feedback.
If you have any general questions, join our Matrix room.
Student applications are open March 29 – April 13, 2021.
Who can apply?
In short: you have to be at least 18 years when you register and you need to be enrolled in or accepted into a post-secondary academic program, including a college, university, masters program, PhD program, undergraduate program, licensed coding school. For all details, please see GSoC’s FAQ.
Am 23.04.2020 wurde auf dem Server von wiki.freifunk.net ĂŒber eine SicherheitslĂŒcke weitere Software installiert, die anscheinend auf anderen Servern nach Ă€hnlichen SicherheitslĂŒcken gesucht hat. Am MediaWiki selbst wurden soweit ersichtlich keine Ănderungen vorgenommen oder Daten abgefischt. Der Zugriff blieb anscheinend auf den Webserver-Benutzer begrenzt. Da Analysen in der Richtung aber keine 100%ige Sicherheit bieten können, sollten alle Menschen mit Wiki-Accounts ihre Passwörter dort Ă€ndern, auch wenn die Passwörter in der Wiki-Datenbank nach Stand der Technik sicher als Hash abgelegt sind (pbkdf2/sha256). Diejenigen, die sich seit dem 23.04.2020 neu registriert haben, wurden von uns gesondert informiert. Das Wiki nutzt Accounts nur zur Abwehr von Spam und bietet keine persönlichen PostfĂ€cher oder Ă€hnliches, entsprechend liegen im Wiki keine personenbezogenen Daten abseits vom gehashten Passwort (und ggf. E-Mail-Adresse) vor.
Der Hack wurde am 27.04.2020 bemerkt, das Wiki offline genommen, der Rechner komplett neu installiert und die Datenbank aus einem sicheren Backup aus der Zeit vor dem Hack wiederhergestellt. Am 30.04.2020 ging die neue Installation online.
Technischer Hintergrund
Als Einfallstor wurde PHPUnit benutzt, das versehentlich als Development-Dependency via PHP Composer installiert wurde. Composer installiert AbhĂ€ngigkeiten im “vendor”-Verzeichnis, das in der installierten alten MediaWiki-Version von auĂen zugĂ€nglich war.
Verzeichnisse mit internem Code waren nach auĂen sichtbar (das wurde in MediaWiki vor einiger Zeit per .htaccess behoben)
Composer installiert in der Voreinstellung auch Developer-AbhÀngigkeiten
Wir haben die Software nicht regelmĂ€Ăig aktuell gehalten. Leider ist das angesichts von AbhĂ€ngigkeiten wie dem Freifunk-Skin nicht immer ganz einfach.
MaĂnahmen
Der Prozess zum Einrichten und Aktualisieren des Wikis wurde weitgehend automatisiert. Wir werden das Wiki in Zukunft aktuell halten und im Zweifelsfall AktualitÀt der Software höher priorisieren als FunktionalitÀt wie das Skin.
Zur Vermeidung von Datenhalden werden in Zukunft komplett ungenutzte Accounts automatisch gelöscht bzw. inaktive Accounts nach einiger Zeit deaktiviert und die diesen Accounts zugeordneten Passwort-Hashes und E-Mail-Adressen aus der Datenbank entfernt.
Beim Erstellen von Accounts wird jetzt darauf hingewiesen, ein sicheres Passwort zu setzen, das fĂŒr keinen anderen Dienst benutzt wird.
Vielen Dank an alle, die sich schnell gekĂŒmmert haben und halfen, die SicherheitslĂŒcke schnell zu schlieĂen.
Wie erwartet hatten wir auf dem 36C3 eine tolle Zeit und sind uns einig, dass man das alte Jahr kaum besser beenden kann, als mit Gleichgesinnten die Nacht zum Tag zu machen und sich mit Mate oder Tschunk in der Hand auszutauschen.
Aber nach dem 36C3 ist vor dem 37C3 und damit uns keine Post-Congress-Depression packt, haben wir âRefreshing Memoriesâ betrieben und keine âRessource Exhaustionâ vorgenommen. Anfang der Woche trafen sich Interessierte, die wir zuvor ĂŒber das Freifunk Forum und die Mailingliste WLAN News eingeladen hatten, in einem Mumble. Wir haben offen besprochen, was gut gelaufen ist und wie wir unsere Freifunk Assembly auf dem nĂ€chsten Congress noch spannender und fĂŒr alle Beteiligten besser gestalten können.
Los gehtâs mit einer kurzen Intro.
Warum eigentlich OIO?
Das OIO bietet allen Freifunk Communities einen galaktischen Orbit um
Projekte vorzustellen
vor Ort Projekte mit anderen Freifunker*innen zu realisieren
Freifunk Themen zu diskutieren
Miteinander eine gute Zeit zu haben
Neue Projekte zu entwickeln
Wer hat mitgemacht?
FĂŒr den 36C3 haben sich regelmĂ€Ăig 3-4 Communities aktiv an der Orga der Freifunk Assembly beteiligt und eingebracht. Auf dieser Grundlage haben wir die Entscheidung fĂŒr 2 Schiffe mit ingesamt 24 SitzplĂ€tzen getroffen.
Ein paar Zahlen
Das OIO Orgateam hat vor Ort in Leipzig rund 670 Stunden (!) in Bau des Hafens, der Schiffe, des Leuchtturms auf dem Felsen, des Workshop-Domes und der OIO-Stage gesteckt. DafĂŒr noch einmal Respekt und ein dickes Dankeschön!!!! Auch wenn wir viel vom letzten Jahr wiederverwenden konnten, mussten Bauteile und die schicken Flaschenlampen neu produziert werden. FĂŒr die Veranstaltungstechnik sind weitere Ausgaben angefallen und auch unvermeidliche Transportkosten schlugen zu Buche. Per 26.01.2020 fehlten noch 1.900,42 ⏠in der Kasse und somit folgt ein ernst gemeinter
Spendenaufruf
Wir bitten jeden Menschen und vor allem die Freifunk Communities darum, sich an der Spendenaktion unter http://spenden.oio.social/ und dort unter 36C3 OIO â Open Infrastructure Orbit zu beteiligen und ein paar Taler beizusteuern. NatĂŒrlich sind diese Spenden steuerlich abzugsfĂ€hig und helfen dabei, das die Freifunk Assembly auch beim 37C3 wieder in dem sicheren OIO Hafen anlegen kann ;-).
Nachbrenner und Fazit aus dem Mumble
Aktive Teilnahme
Fangen wir mal offen und selbstkritisch damit an wie es um die aktive Teilnahme von FF Communities an der FF Assembly im OIO bestellt war. Leider waren es nur wenige und wir haben gelernt, dass es grundsĂ€tzlich nicht an Interesse oder Motivation mangelte. Vielmehr waren die im Vorfeld zum 36c3 gewĂ€hlten InformationskanĂ€le nicht ausreichend bzw. nicht umfassend genug und mĂŒssen in Zukunft noch stĂ€rker und regelmĂ€ssiger mit klaren Informationen bespielt werden, damit sich mehr FF Communities aktiv an der FF Assembly im OIO beteiligen.
In 2019 haben wir diese InformationskanÀle genutzt:
WĂŒnschenswert ist, dass die lokalen Communities auf ihren Seiten mit aktuellen Hinweisen auf den 37C3 / OIO / FF Assembly verweisen und ihre eigenen Social Media KanĂ€le nutzen, um diese Informationen weiter zu verbreiten.
Inhalte
Gut informiert sein heiĂt nicht, ein wenig von Allem zu wissen, sondern alles von den Dingen auf die es ankommt. Wir Organisatoren haben offensichtlich nicht klar genug kommuniziert, dass das OIO allen Freifunk Communities einen galaktischen Orbit bietet, um Projekte vorzustellen oder solche vor Ort mit anderen Freifunker*innen zu realisieren.
Weiterhin bestand offensichtlich Unklarheit darĂŒber, dass wir uns
aktive Mitarbeit in der Freifunk Assembly âim Hafen des OIOâ von
allen wĂŒnschten, die sich fĂŒr einen Voucher unter
https://wiki.freifunk.net/36c3/Participants
gemeldet haben.
Offensichtlich war auch die von uns im Wiki
gewĂ€hlte Formulierung âsich mit anderen einen Sitzplatz teilen
möchtenâ wohl zu schwammig und fĂŒhrte zu leichten Spannungen auf
dem Congress aufgrund unterschiedlicher Erwartungshaltungen. Das Orga
Team hatte feste SitzplĂ€tze fĂŒr alle aktiven Beteiligten
einkalkuliert und kam so auf 2 Schiffe mit insgesamt 24 PlÀtzen.
Viele passive Participants sind allerdings davon ausgegangen, dass
ein Voucher auch automatisch einen festen Sitzplatz beinhaltet.
Das werden wir in 2020 besser machen. FĂŒr den 37C3 werden wir eine noch genauer zu definierende prozentuale Verteilung aus Named-Seats (also mit klarem Personen & Community Bezug) und Shared-Seats (nicht reservierbar) haben. Bei den Shared-Seats wird somit auch das Kleben eines Community Stickers auf dem Tisch oder das Stehen lassen eines Laptops nicht zu einem dauerhaften Sitzplatzanspruch fĂŒhren. SelbstverstĂ€ndlich werden wir alle Inhalte verbessern und versprechen heute schon eine klare und regelmĂ€Ăige Kommunikation.
Auch die entsprechenden AbsĂ€tze/Formulierungen in den Vouchercode-Mails und die Mailingaktion hinsichtlich Spendenaufruf und CallForParticipation an die âerfolgreichen Vouchercode-Nutzendenâ hatte leider kaum einen erkennbaren Erfolg.
Brainstorming
Wir haben in die Runde gefragt, was sich alle Beteiligten wĂŒnschen und woran wir beim kommenden Congress denken sollen.
Mehr Beteiligung beim Auf- und Abbau von allen Communities und
Freifunker*innen
Spendentrommel stĂ€rker und frĂŒher rĂŒhren
Spenden von FF Vereinen gesondert erbitten
Spendenhöhe empfehlen- z. B. X ⏠pro Person
Verweis auf steuerliche AbzugsfÀhigkeit von Spenden unter
spenden.oio.social
Fördergelder ĂŒber Freifunk Landesförderung NRW beantragen –
Beispiel: FF Community X stellt Projekt A vor und dafĂŒr wird eine
AusstellungsflÀche mit X SitzplÀtze benötigt, hierdurch entstehen
Kosten in Höhe von X ⏠und deshalb wird durch die FF Community X
ein Antrag auf Förderung beim Land NRW gestellt.
Voucher in Verbindung mit Spendenaufruf
stÀrker an Freifunk Assembly AktivitÀt koppeln, aktive
Teilnehmer*innen werden somit bei der Vouchervergabe bevorzugt, denn
aufgrund der VielfÀltigkeit der anfallenden TÀtigkeiten kann
jede/r etwas Aktives beitragen
Wiki
wird mit klaren Formulierungen entsprechend aktualisiert.
Ideensammlung
Das Beste kommt zum Schluss! Hier sind Eure Ideen was wir diesen Jahr zusÀtzlich machen sollen:
Analoge Community Karte aufhĂ€ngen â GröĂe: 2 * A0
Freifunk Logo auf geeignete groĂe plakative Stelle drucken/sprayen /projizieren
Freifunk von erhöhter Stelle auf den Boden als âbewegtes Logoâ projizieren
Freifunker*innen in einer Vorstellungsrunde persönlich kennenlernen – Domo “mieten” – loser Austausch ohne definierte Themen
FF Projekte / Inhalte vorstellen und ĂŒber alle KanĂ€le kommunizieren
Projekte vorbereiten, die explizit auf dem Congress bearbeitet werden (Arbeitsgruppen, Workshops), um dort auch zu Arbeitsergebnissen zu kommen.
Vielen Dank an alle die mitgemacht haben und auch in Zukunft mitmachen werden.
It has been a wild ride and this post marks the completion of GSoC 2019 for WireGuard Tunneling in BMX7. Throughout the summer a lot of effort has been put into coding, documentation and codebase restructuring; it has been a appetizer for what awaits us coming Autumn.
During the final phase of GSoC 2019, focus has been put into recombining what has already been done. An ideal goal had been to extend the wg_tun plugin functionality with the routing of traffic between associated peers, but this remains a work in progress. Testing has taken place and quite a few SIGSEGVs have monopolized interest. Also, research has been contacted on whether and how to cryptographic primitives used in BMX7 and WireGuard. This seems infeasible currently, due to the differences between cryptographic keys of the two.
Here we see the successful communication between two bmx7-wg nodes and their association; of course while in testing SIGSEGVs are out to hunt you.
The wg_tun Plugin
Our ultimate and prime goal has been the beta release of this plugin. The plugin offers BMX7 the capability of setting up an iproute2 WireGuard device interface with a unique pair of keys that is automatically looking for all available peers and establishes a connection with them.
In the current approach we have designed along with Axel an approach about the unique cryptographic address assigned to the wg interface (a concept similar to the existing), where the BMX7-WG auto-configured IPv6 address is a product of the unique prefix fd77::16 and the first 14 bytes of the node’s SHA224 hash. Research goes on in this to figure out the best approach (network and cryptography wise).
In the past days we saw the creation of wg_status option and the addition of debug flags to inform an administrator of the state of his WG device (related commit).
At this stage, testing is being performed to analyse the behaviour of the plugin after the associations among peers and include more status information and more options for the control of the plugin by the user.
The “misses”
Of course when you go too optimistic into the dark something’s gonna not work out.
In this project the misses can be summarized in: devoting more time than initially expected into studying and researching and dropping some core goals for the sake of more important ones.
The goals we “skipped” have been the Debian Package and the refactoring of Mesh Linux Containers to aid with testing.
In the studying part, I was supposed to devote only the community bonding period and part of the first phase to study white paper and get up to speed with theory between what needed be implemented and fiddled. I ended up devoting time throughout all the phases, but I’m happy with what I’ve learned.
Further Work
The intention to continue work on BMX7 is trivial to answer. GSoC has been a good experience and way to get started with the codebase of BMX7, but free flowing, detrimental work is scheduled for after it.
This marks the end of GSoC 2019 and I am proud to announce the project has come to a mature stage. It has been a great pleasure to work with my mentors Paul Spooren and Moritz Warning.
System updates with OpenWrt has been a trickier part for ever. This application is made to make the process easier and seamless. It is inspired by Attended Sysupgrade app and simplifies updating to newer versions.
The Sysupgrade app utilizes the JSONs created upon build as proposed in openwrt/openwrt#2192 (comment) (which utilizes the splitting of variables from phase 1).
Using this application:
Vanilla(Default) sysupgrade images from openwrt server can be flashed directly onto the devices.
Installed packages can be retained utilizing a custom image generated via ASU
The work for the app is still in progress and is yet to be reviewed by the community. There is still some time till it gets merged to LuCI. The PR for the same can be found here.
Conclusion
It has been a great experience working throughout the summer. I have learnt quite a lot from this experience and would like to give the experience back by being the part of the community in the future too. I would like to thank my mentors and Freifunk as they gave me the opportunity to work under them and to work for the world of open source.
Coverage report integration. Final coverage output
CI integration with Travis. The build was split in two stages: unit testing and package build:
I have writen tests for the following core parts: lime.config, lime.network, lime.wireless, lime.utils. Quality of the tests is diverse, some are just stubs so we can improve them in the future, but some are good.
Tests for packages: firstbootwizard has been improved in order to support unit testing and a first simple test is in place. To write more tests more changes to FBW are needed.
Integration tests: lime-config with device support
iwinfo fake library, with many helper functions to easily fake a device and station connected, etc.
Uci testing environment helpers
Device support: A simple device support was implemented. For the moment this needs the /etc/board.json of the device and the /etc/config/network and /etc/config/wireless that are generated by OpenWRT on the first boot. With this files a testing environment is created using uci and iwinfo so for the tests a device is emulated. Using this infrastructure a lime-config test was implemented. For the moment only LibreRouter-v1 device is supported but it is very easy to add more devices.
Here is a reference PR with all the work I did for this GSoC. In order to have this work merged I created many small PR in the LibreMesh repository: #562, #563, #564, #565, #566, #567 and #568. Some of the work is not yet in PR to LibreMesh to don’t overwhelm the reviewers.
Future work
Add more devices.
Discuss if writing an integration test that uses lime-defaults and lime-defaults-factory with a device and check that the result is what it is expected is helpful, and if it is, write this tests.
Provide a way to test packages that use ubus library.
Explore how to use this testing environment in other openwrt Lua packages outside of LibreMesh. Even C code should be easily tested with automatic Lua bindings.
Lessons learned
Unit testing framework
After working with Busted I think it has been an excellent choice choice as unit testing framework. It is very well documented, very powerful and at the same time is easy to use. I used it for writing very different tests and I never missed something. Mocks and stubs are good and asserts are powerful.
At first my idea was to create a fake library because I thought that this could be easy and at the same time very handy for the tests. I implemented quickly a fake library but it did not behave the same as the uci library in many corner cases. I realized that behaving exactly the same will take a lot of work and if it does not behave exactly the same it will be very annoying because the tests will work differently than in production. And that is a very bad idea.
So I decided to try to use the real UCI library and create a clean environment for each test with helper functions. It was very easy to do it as UCI provides a way to change the config environment.
Docker image
A side effect of basing the testing Docker image in Alpine Linux is that it is ABI compatible with OpenWrt x86_64 packages because both use musl C library. This allow us to easily use some openwrt libraries like luci.ip, uci, etc directly from public OpenWrt packages. This keeps the testing maintenance effort low as we are not having to build this libraries by ourselves.
Lua is powerful
Coming from a Python background I thought I will miss many things but from a language perspective that was not the case!
