SoC -> BMX7 -> Freifunk

This year I decided to retry my luck with GSoC, I sat down, studied available projects and contacted the BMX7 team for the project concerning the establishment of WireGuard secure tunnels on the BMX7 mesh routing protocol.

It was a match, with my mentors being Paul Spooren and Axel Neumann.
So here we go!

Overview

Excuse me if I’m lazy, but the specific scope of the project can be found on it’s abstract here at it’s official GSoC project page.

Community bonding

The days have already kicked in and we are 1 week in the community bonding period, which stretches from 6th of May until the 26th.
On the 27th the first coding period starts and we are well underway.

We have co-discussed with my mentors and the goals we’d like to set for it are:

  • Connect with the freifunk and bmx routing community.
  • Refactor proposal to become more detailed on the implementation specifics
  • Setup a testing environment (we’ll return to that)
  • Create a bmx7 Debian Package
  • Reading:
    • Understand the bmx7 functionality and description system
    • Study the cryptography used by Wireguard
    • Declare my bibliography and resources
  • Study the tun.c source code

Setup of TestEnvs

Testing is a huge topic on mesh software. The purpose is to emulate the functionality and needs of a mesh topology.

For this task two ideas came in mind:

  • Create an armboard/embedded setup and run bmx7. This would be great to establish on the hsgr for future experiments/needs.
  • Virtualize everything either with Qemu, Linux Containers(LXC) or Qubes Proxy VMs. Especially the last option had a lot of juice.

This is also the first task I took in hand during the community bonding.
The sad result was that I dropped the arm board play. I setup a couple of shared raspberry pis and a beagleboard black with openwrt (which supports bmx7 by default), but the ensuing hassle of interconnecting was too much and time was restrictive.
Nice experiment, will return back to it with more weapons.

The approach I chose after that (and after discussing with my mentors) was to contain myself to a simple lxc setup and a qemu one (both with bridges set all along), to have both the single process and full virtualization capabilities. Cleaner and easier, especially if one takes in account the projects that can be found to support this.

Examples include:

Qubes Network Proxy VMs I won’t even discuss. Even though I’ve setup some for personal administrative use on my Qubes, their scope got way out of hand. Maybe again I’m wrong, but future iterations when time limits are lighter will prove me wrong(and this paragraph deleted).

Documentation

Upon landing on the home github page of bmx7, one will admittedly notice the detailed README page. I did too and I started skimming through it long before I submitted my proposal to get a grasp on the protocol itself. One problem that I noticed was length. Extremely detailed, but with such length on a single page that nice topics as: Plugins, Tunnel Announcements and Usage got intertwined in an unfriendly way.

For this reason I began to work on my fork and I split entities apart to help me focus on the specific topics I wanted to give weight per-time.

Community

Freifunk is a great community with great software achievements and a noblest goal. I want to be part of this community; slowly with patience and knowledge (even without knowing german).

My branch for GSoC can be found here, where I intend to create the special plugin under /lib/bmx7_wgtun.

Happy Summer of Code everybody!