Freifunkblog

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.

• My fork can be found here.
• WireGuard Plugin branch can be found here.

Overview

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.

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.

• Add command line functionality for the wg_tun plugin, include it along with the Refactor of command line arguments issue,
• Add more developer documentation for BMX7 newcomers, like Plugin Creation and Glossary,
• Create the bmx7 Debian package (check here),
• Rework mlc into mlc-ng (as reported here).

Final Thoughts

I’m very happy I got the chance to help Freifunk’s goals and hope to continue however I can.

Battlmesh V12 was super nice and I look forward to next year’s (I hope it’s Netherlands).

At last, I would like to thank my mentors Paul Spooren and Axel Neumann for their advice and way they approach cooperation.

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.

Firmware Wizard

There have been some updates to the Firmware Selector since last update.
And the working version along with the source can be found here.

LuCI app for Sysupgrade

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.

GSOC 2019 is drawing to a close and with it the first part of the HTTP API. To be completely honest this is not where I’d hoped to be at this stage, but we’ve set up a solid foundation for future work to build the rest of the API.

A Framework

I wrote about choosing a web framework a while back. The choice I arrived at, Iron, was in retrospect not the best choice. I chose it because I liked its middleware model, but it has only recently been renewed and most of its ecosystem hasn’t been updated in three years. This meant writing a lot of new middleware for the API. Additionally the only existing Iron testing framework was difficult to use and relied on fragile string manipulation to generate Request objects. I wrote a new testing framework called Anneal which uses hyper to generate Request objects and follows a builder pattern to simplify testing.

A Service

The HTTP Api is designed to operate as an independent service within a Qaul instance. An instance may disable the API, or not ever include it, and things should still work. Currently the mechanism by which services communicate is still a work in progress but a big part of the api was trying to pull as much of the boilerplate code used for validating incoming requests into the http-api service as possible.

Authentication is handled by the api, parsing of JSON:API requests (using the json-api crate I talked about in a previous post) is handled by the API, scoping of requests is handled by the api. The benefits of this model will become more apparent as we start to give services HTTP APIs.

A Plan

While my work on Qaul under GSOC is coming to a close I fully intend to complete my work on the HTTP API. I have a branch for adding unit tests to the api waiting on my user creation merge request, I have been experimenting with implementing an inter-service messaging system.

I added an http-api service, built login and logout endpoints, built a hot pluggable mount middleware for use in mounting services, implemented middleware for dealing with cookies and authenticating with cookies. I have written extensive error messages and documentation for all of these components and hopefully the foundation they have created will allow future development of the API to proceed with ease.

So long, and thanks for all the fish.

GSoC 2019 is coming to an end and for this reason it is unfortunately my last blog post on freifunk. For this reason, I would like to start by thanking the freifunk community, Google and, in particular, my mentors for the opportunity to participate in this rather special program. In this post I will present what has been done, what has not worked out and what is still to be done.

Code and APK

You can find the application code at my github repository:
https://github.com/kdebiec/GSoC_2019
And the application itself, ready to use here:
https://github.com/kdebiec/GSoC_2019/releases/tag/GSoC_2019_final
(Please note that you need the “Retroshare Service/Core” application in order for the application to work properly. – backend application that you can build from the Retroshare repository: https://github.com/RetroShare/RetroShare)

Overview

The aim of my project as I mentioned in my first post is to build a mobile application oriented around the chat, with a big focus on the modern look. The new logo, which is also part of this project, was intended to reflect new direction of this software.

Logo

Below you can see the new Retroshare logo, which is the main logo for this application, and in other projects its use will depend on the acceptance by users and the profile of the project.

App

I have posted my proposed design in this post. Now it’s time to show off final design, but it is difficult to describe the appearance of the application and it makes little sense to paste several screens here. Because of this I recorded a walkthrough of the application. You can check it out here:

Illustrations of empty screens are provided by Icons8. Thanks for them!

Application was fully written in Dart using Flutter. This should ensure relative code readability, an optional ability to port the code to iOS, and relatively fast application performance.

Features

Functionalities that are now available in the application:

• add friend via certificate and share ours,
• create with avatar, change and delete our identities,
• see friends locations,
• create public room (lobby),
• send and receive message,
• add and remove contact
• search for chats, contacts, people,
• discover public rooms,
• see rooms participants,
• signin, signup;

Roadmap

There are still many interesting things to do in this project and for this reason I intend to continue my work. In particular, I would like to focus on these features:

• Make a good use of and improve Retroshare’s Json api event system. This will enable app to have message notifications and optimize its performance.
• Bundle backend and frontend into one app. Current system is confusing and leaves much to be desired. Who wants to manage the process themselves that is still in the background anyway?
• Explore possibility to add tor option as it is in Retroshare desktop app.
• Improve chat backend, especially much needed storage of history.
• After merging Retroshare’s short certs, add QR code as a default way to add friends. This will involve redesigning the way it works now.
• At this point, user still have to be aware of how Retroshare works under the hood. Future improvements have to be made so user will have to only operate with identities. For example, now, after adding friend we have to yet find his identity in search box to add him to contact and finally after those steps we can message him.
• The website is already a bit outdated and it could use a new look. As soon as the application is ready, I would like to refresh website.
• As you can see on video, rooms name are also ‘Error’, which of course is not the name of room. Due to lack of native support of 64int in Dart, lobbies ids can’t be loaded and so does names. Thanks to my mentor, Gio, solution is already in PR, and after merge, some minor changes have yet to be done on frontend side.

Conclusion

During this program I tried to build a very good application base that can be further developed, which I hope will make futher improvements easy. Unfortunately, during this period I was not able to meet all the milestones, specifically, the chat backend has not been improved. In spite of everything, I intend, according to my Roadmap, to improve the chat backend as well as add more functions to the app so that it can be considered as a production version.

I encourage everyone, especially current Retroshare users, to test the new app. I hope you like it.

Once again, I would like to thank my mentors for their help in recent months.

During this coding phase I added OpenWrt Makefiles to package conTest and the attenuator control software.
In addition some documentation was added, but most of the time I spend chasing the down the errors mentioned in the last blog post.

This error seems to be, that a certain attenuation gets repeated, while the config says something different.
After some long error hunting sessions RegMon[link] was added to the testbed to retrieve more information on the connection and hopefully
the error itself. RegMon allows to monitor the time consumption of ath9k wireless cards In there the error does not show up. While in
figure 1 the attenuation for signal 1 seems to be repeated, the RegMon diagramm (fig 2) does not show this behaviour. In figure 2 you can see
the time a wireless card spends sending (red) or receiving (blue) data, idling (yellowish) or taking care of interference (pink).
If the connection is dampened the needed time for sending/receiving data increases, as a more robust MCS, spatial stream and guard interval
combination is selected. Based on figure 1 I would expect the cards to have a higher busy time portion than shown in figure 2 at the problematic section.

Unfortunately an update broke the functionality of the regmon evaluation scripts, so I started to port it from R to Python3 to use it in future debugging sessions.
Figure 3 shows console output from the control program. The shown attention values are acquired from the digital attenuator shortly after the value was set
by the software. These values are as expected and show the correct behavior. The difference between the attenuation values on signal 0 and signal 1
originate from an added analogous attenuator.

Interestingly, after several tests with linear increasing/decreasing attenuation, the behaviour on figure 1 could not be observed.

I started to dig into the driver software of the Vaunix Labbrick attenuator, but did not find problematic code so far. But the first next step should be,
that the RegMon evaluation script is usable again. After that I will continue to look into the driver of the digital attenuator and in the worst case dive
into tcpdump, to see how it acquires the signal strength values.