Load-correlated distributed bandwidth analysis for LibreMesh networks – #3: Completed test network and broadened scope of the work

The planned test network has been built, employing both fully supported (I just documented them in the tested routers list here) and common home routers (officially unsupported by LibreMesh but supported by OpenWrt).

Employing non supported routers required an expansion of my previous work about making possible an AP-sta (point to multi point access point to clients) network architecture (instead of the default IEEE802.11s mesh). My previous solution relied on BMX6 which will not be included in the next release, in favor of Babeld, so the problem is open again. I provisionally managed to have Babeld on AP and client interfaces adding the following setting in /etc/config/lime on the access point:

config wifi 'radio0'
     list modes 'apname'
     option country 'ES'
     option channel_2ghz '11'
     option apname_ssid 'LibreMesh.org/%H'
     option apname_key 'someAPpassword'
     option apname_encryption 'psk2'
     option distance '100'

 config net 'wirelessap'
     option linux_name 'wlan0-apname'
     list protocols 'babeld:17'

and the following in the /etc/config/lime of the client (taking advantage of the client protocol I added some time ago here):

config wifi 'radio0'
     list modes 'client'
     option country 'ES'
     option channel_2ghz '11'
     option client_ssid 'LibreMesh.org/LiMe-eb7f64'
     option client_key 'someAPpassword'
     option client_encryption 'psk2'
     option distance '100'

 config net 'wirelessclient'
     option linux_name 'wlan0-sta'
     list protocols 'client'
     list protocols 'babeld:17'

For some reason this solution does not propagate the default route obtained from Babeld to the whole network, this does not directly affect my project, anyway I’ll surely manage to fix this in the upcoming days.
In case the usage of such perfectly-working trashware was a blocker, I will receive a few more supported routers in the following days and I will just use those.

Also due to the switch to Babeld, to obtain a complete graph of the network is not yet possible (Babeld being based on the distance vector principle, does not know the whole topography and we’ll have to aggregate it using the new shared-state LibreMesh feature).

During the building of the test network, the planned topography changed a bit resulting in this one (solid lines are cabled connections, directional dotted lines with arrows points from the client to the access point, non-directional dotted lines are proper IEEE802.11s mesh):

All the routers were flashed with OpenWrt 18.06-SNAPSHOT image, which is OpenWrt 18.06.4 with additional fixes appeared in the release branch here compiled locally using OpenWrt buildroot. LibreMesh packages were also compiled in the same process but not included in the compiled image, and installed later using opkg and serving the packages over the local network. This approach showed to be more convenient than expected, additionally, the fallback image is a plain OpenWrt, which decrease the risk of “brikking” the devices.

The complete list of the installed packages from the LibreMesh ones is:

check-date-http first-boot-wizard hotplug-initd-services lime-app lime-debug lime-hwd-ground-routing lime-hwd-openwrt-wan lime-proto-anygw lime-proto-babeld lime-proto-batadv lime-proto-wan lime-system shared-state shared-state-babeld_hosts shared-state-dnsmasq_hosts shared-state-bat_hosts shared-state-persist shared-state-dnsmasq_leases shared-state-pirania

Lately, I got also involved in the development of lime-log-review, which uses liblognorm to decrease the volume of the logs and can be used in my project for storing the key information from the voluminous logs when an incident is detected.

BMX7: Wireguard Tunneling – 2nd Update

The second phase is officially over and within it’s time a lot have happened. First things first, this year’s Battlemesh took place in Paris and it was a blast, the wg_tun plugin saw some great changes and the documentation PR is closed.

For my personal experience on WBMv12 refer to this blog post.

Wireguard on BMX7: wg_tun plugin

Image that shows the successful announcement and reception of keys and ipv6 crypto-addresses.

Initial work on the plugin has been put towards of the first phase and subsequent effort was put before Battlmesh. On Battlemesh along with Axel we created the establishment of a session between two wg-bmx7 nodes.

This work can be found here: https://github.com/bmx-routing/bmx7/tree/WBMv12_session_with_harry

These nodes are able to exchange the public keys of their own interfaces (devices) and assign each other as a peer.

The key decisions of the current implementation are as follows:

  • BMX7 traditionally uses “fd70” as the prefix of an instance’s – auto-assigned on startup – primary IP(v6). The primary IP is the product of this prefix in addition with the first 14 bytes of the public SHA224 key of the interface’s unique identification mechanism.
    In the wg approach we adhere to this scheme and we configure the primary IP of an interface as “fd77” + the 14 bytes of the SHA224 key.
    (Credits to Axel for the idea).
  • The implementation is auto-configurable; meaning that each device that carries a prefix of fd77 when it gets received by other wg-bmx7 interfaces they try to establish a session between them.
  • Cryptographic keys (private and public) exist only in the scope o a single session. Every time an instance gets restarted it spawns new keys.

After Battlemesh and this happily successful result, effort is being put into the handling of some minimal command line arguments as well as the routing of data inside the established tunnels.

Further work will take advantage of the SEMTOR mechanisms provided by BMX7 in combination with the WG plugin.

For more info: either refer to the wg_tun plugin branch, or have a chat with me @luserx0:matrix.org.

BMX7 Github Documentation

The documentation PR was completed and it offers to the GitHub repo a revamped feeling. Details can be found inside the PR.

The total scope of this effort has been to make the BMX7 more approachable by new contributors and users.

The bad

Two goals for this phase it was deemed necessary to push back (and weren’t achieved):

  • Work on mlc to port it’s functionality to mlc-ng,
  • The bmx7 Debian Package.

It’s undoubtedly of utmost importance to have WG secure tunnels working on BMX7 and these goals have been pushed back until secure tunneling is completed.

Final Thoughts and Future Goals

The project itself has proved to be more challenging than expected and it has tested a lot my developer abilities. Hopefully, there is a lot of knowledge to be gained and day by day we get closer to a functioning version of the plugin.

The goals for the final phase should be:

  • The establishment of routing between bmx7-wg instances and the successful completion of the beta.
  • Documentation of the added code and it’s functionality.
  • Proper command-line controlling facilities for users (experienced and not).
  • Research on reuse of cryptographic keys (WG keys with BMX7 keys) and proper handling of the wg interfaces on the bmx7 ecosystem (kernel calls, avl trees and argument hierarchy).
  • Further work on contributor and user documentation.
  • Stretch: Work on MLC to mlc-ng

GSoC 2019 – Upgrading the Meshenger App – Update 2

Meshenger App

In my previous blog post, I had achieved the authentication at the initial handshake in the app. Since then there has been quite a lot of progress in upgrading the Meshenger app.

Progress Till Now

1.) Refactoring of the codebase

Initially, I started with the refactoring of the codebase in order to allow different means of connection to the client. For e.g. contacting a client over the server or Internet, enabling direct calls in layer 3 networks with the help of multicast groups and pim6sd. etc. I am working on enabling the calls over the Internet.

Firstly, I started by removing the “challenge” from the entire codebase. Challenge was used as a security parameter but now as authentication has been developed, it became redundant. Secondly, I refactored the Contact (Client data) and AppData (User data) class to hold different connection data like mac address, port and the hostname. I moved the identifier and address in the “connection_data” ArrayList and stored the data structure serialized as a string in the Contacts database which needed to hold different contact data of the form List<ConnectionData>. I added this data to the QR-Presenter Activity ‘s QR-Code and parsed in the QR-Scan Activity. I followed the same procedure for the AppData database also. Lastly, I also removed “username” and “identifier” from the call JSON.

2.) Implementing client online/offline detection over the Internet

For implementing the client online/offline detection over the Internet, I needed to hold a persistent TCP/IP connection to a signalling server. So I started a thread at the start of the app and that thread opened a persistent TCP/IP socket for each SignalingServer object in the connection_data. The sockets were held open for as long as the app is running. I used a signalling server made on node.js and ran it on the laptop. Then after connecting the phone A and phone B to the laptop’s hotspot, I ran the app on the phone A and the server displayed that the user is online. After that, I checked for the client status by running the app on phone B while still keeping the app on phone A on. The result was displayed that the client was online and the client’s status was detected over the Internet.

Next Steps

The next phase i.e. the Final Phase of GSoC 2019, will be about achieving the call over the Internet, adding other features and some code polishing.

OpenWrt Firmware Wizard Update – 2nd phase completion

After 4 more weeks, there has been progress regarding the agenda. The agenda for the last phase was to create the web interface using which users could download appropriate images for their devices and build custom images too.

What has been achieved

A refined version of the web application has been achieved. The functionality of creating custom images has been added to the application.

The application has been moved to ReactJS. The finished application looks like this:

Note: There are minor bugs and issues in the app which will be rectified in the later versions.

You can look at the code for the interface here and can use the interface here (currently in beta).

Next Steps

In the next phase, an openwrt tool has to be engineered which can be used for upgrading OpenWrt automatically.
A interface for the tool has to be created for LuCI which will house all the settings and preferences of the user. The tool will periodically check if there is a new version of OpenWrt, if so, then it will download and apply the upgrade package automatically.

The foundation to check if there is a new version was laid during the first phase with the JSON metadata.

Retroshare for Android – Update 2

It’s been a month since the last post, so it’s time to summarize this period. In the previous post I showed the beginnings of my adventure with implementing the designed look of the application. That version looked as I intended, but it lacked interactivity, data management and connection to the main retroshare-service application.

The current version of the application has added animations for transitions between screens or tabs. Example animations (due to limited upload size, video is badly compressed 🙁 ):

Also, screens have been added to help various side activities such as creating a new identity or to make it easier to create an account, if it doesn’t already exist.:

And the next thing I spent some time on was the correct handling of queries for retroshare-service and data processing. Thanks to that, in the application we can already perform basic activities such as logging in or managing our identities.

In addition to the activities presented here, I devoted some time to just building a retroshare-service application, which exceeded my expectations about the ease of this task.

Next steps

In the application there are still a few minor modifications to be done. One of the key changes is to ensure proper storage and generation of the authorization token. Nevertheless, the main task of the upcoming period will be to add new functionalities and minor fixes to the Retroshare itself.

Due to the fact that visually the application is already very close to the final product, I would be happy to hear some criticism and hints what needs to be changed.

Konrad Dębiec

conTest – Wireless Testing Framework Second Update

During this coding period I added automatic processing of the data
collected by the wireless testing framework conTest, as well as the graphical
representation of the data.

While processing the data I found some issues in the controller software
as well as the physical testbed.

Most of the tests since the last Blog post were done with the attenuation values
you can see in in the lists below. I changed timing values between the experiments,
to validate the behavior.

Attenuator 1 uses the following values for its attenuation settings:

  • 10 s -> 0 dB
  • 10 s -> 60 dB
  • 10 s -> 0 dB
  • 10 s -> 60 dB

Attenuator 2:

  • 10 s -> 60 dB
  • 10 s -> 0 dB
  • 10 s -> 60 dB
  • 10 s -> 0 dB

My initial experiment to test functionality was not the best one to validate the
testbed (fig. 2). As both paths were basically set to the same attenuation
I only checked the signal in Wireshark as seen in figure 2, which matches mostly with
the black line in the closer look in figure 3.
The second figure was created with my evaluation scripts, while the first one was
created with wireshark during the first tests.

Figure 2: Signal strength as shown with wireshark from original testing
Figure 3: Separated signal strength curves of the original values with evaluation scripts

In the testbed I am using two analogous attenuator in addition to the programmable
attenuator. Figure 4 shows, that one path is stronger dampened. Without the
analogous blocks both paths are nearly equally attenuated, which could mean,
that one of them is broken, or not meant for the frequency range, while both of them
should be. It will need some further investigation, but as I had most of my exams
during this coding phase, I was a little short on time. For now I will continue
without these two devices.

Figure 4: Signal strength difference caused by problems with the analogous attenuator

In figure 4 you can see a section where the one of
the two paths is not following the values presented in the lists at the beginning of this post.

This is a problem in the control software of the digital attenuator. I was able to work around
it and fix two more problems in the software. The actual problem needs more time
researching putting into it, but more than I could afford at this time.

Figure 5: Signal strength curves without analogous attenuator and solved software problem

The evaluation script will check for our default files, filter out data, we want
to plot, like signal strength, selected MCS rate, throughout rate and packet
numbers. Afterwards the plots are constructed with python and matplotlib.

For most figures, places with more intense red and blue colour are values, which
were encountered more often. The black line represents the overall signal strength
provided by tcpdump.

Web Interface for Retroshare – Update 2

I Realized that the visual appearance of the application felt very bland and uninteresting, so I decided to shift some of my focus to the design and visual aspect of the UI. I did plenty of reading about UI/UX design principles and modern best practices during this time. And looks like it turned out pretty well, and is definitely a good improvement from the previous appearance. Also, since this is my first attempt at doing professional-level UX design, there is probably room for improvement, so feedback and suggestions are always welcome.

The general theme has been redone from scratch. I chose this soft blue color palette by taking inspiration from the main app’s look:

The home tab, along with displaying the user certificate, now also allows to add friends by using their certificates. It is possible to add friends by copying the certificate contents, dragging and dropping the file, or simply selecting it from the file manager.

Implemented modal messages within the browser that can be used as a popup dialogue box to display any kind of information (here showing information extracted from a Retroshare certificate):

As you can see, the navbar has also been revamped. And the best thing about it? Icons! I along with my mentors agreed on using the Font Awesome icon library, which is open source (licensed with a combination of MIT, CC 4.0 & OFL 1.1 licenses). I can now utilize icons across the whole app.

The downloads tab has also been redesigned. Now showing all downloads in a slightly different way. This layout was chosen with extensibility in mind, it can easily be extended to contain a additional file-related settings and chunk views by having an expandable options box for each file.

The config tab can now be used to change a lot of the setting options similar to the main app. Network, node, services, files and people sections from the app have been implemented. I will shortly finish the remaining sections too.

Also notice the tooltip icon. Which when hovered on, gives a brief description about the option. Just like in Retroshare:

Next steps

Now that the design is steadily making way for a more detailed and specialized variety of widgets and components, I am working on creating tabs for Network, People, Chats, Mail, Channels & Forums so that the Web Interface can finally become a fully usable alternative to the main client app.

You can try out the Web Interface by cloning it from the repository: https://github.com/RetroShare/RSNewWebUI, and my fork: https://github.com/rottencandy/RSNewWebUI. Again, I am always happy to receive feedback and suggestions for improving the Web Interface.

GSoC 2019 – Import public datasets to Retroshare network second evalutaion

Here again!

This evaluation I spend the work creating an automatically generated wrapper for the API. This wrapper is generated analyzing the Doxygen XML files generated when Retroshare is build. 

Creating the API wrapper

First of all, I modified the python script (made by @sehraf ) that generates the C++ API files, to create a python wrapper for the API. Analyzing the script and the XML files I get my script working generating a first version of the wrapper. Then I test the wrapper, giving support to async functions also. Some features of the wrapper are:

  • Document the code using DocString convention.
  • Parse also ‘manualwrappers’ like attempt login.
  • Requests with authentication and without.
  • Support basic authorization or token auth via ‘Authentication: basic bas64Token’ header.
  • Async methods support and callback implementation.

Here an example of the API wrapper generated: https://gitlab.com/snippets/1877207 . Some tests for the wrapper can be found here:

class TestMultiple(TestCase):
    def test_login(self):
        res = wrapper.RsLoginHelper.isLoggedIn()
        # Do login
        if not res['retval']:
            res = wrapper.RsLoginHelper.attemptLogin(ACCOUNT, PASSWORD)
            self.assertEqual(res['retval'], 0, "CANT LOG IN")
        self.assertEqual(res['retval'], True, "is not loged in")

    def test_authorizedMethod(self):
        res = wrapper.RsGxsChannels.getChannelsSummaries()
        self.assertEqual(res['retval'], True, "Can't get channel summaries")

class TestAsyncMethods(TestCase):
    def cb(self,res):
        print("cb", res)
    def test_asyncMeth(self):
        wrapper.RsGxsChannels.turtleSearchRequest("XRCB", 300, wrCallback=self.cb, wrTimeout=4)

Creating Retroshare Classes wrapper

After that, the problem was that a lot of functions need to have Retroshare classes as parameters. For example, to create a Retroshare forum, are needed classes like RsGxsForumGroup that at the same time need other inner classes like RsGroupMetaData. With the first version of the wrapper all this classes was passed in JSON format that was really annoying to assemble. 
So the next step was parse also this Retroshare classes recursively from the XML files to a Retroshare classes wrapper. On this step it was difficult to parse it correctly: differentiating the different types of classes, and class attributes, translating the types to python, if they are enums, primitive types etc… Finally I created this second class wrapper so when you need to pass a RsGxsForumGroup to the API wrapper you can just instantiate it and the wrapper do all the necessary to transform it to python and call the API. Some features:

  • Parse “compound” classes (structs on C++) recursively.
  • Parse “enums” and get their values.
  • Parse “typedef” and “using” classes and translate it to the appropriate type on Python .
  • Document it using Docstring convention .

Here an example for the class wrapper: https://gitlab.com/snippets/1875153 . Some tests can be found here:

    def test_createChannel(self):
        channelMetadata = RsClass.RsGroupMetaData(mGroupName="TestChdddannelCreation2", mGroupFlags=4, mSignFlags=520)
        channel = RsClass.RsGxsChannelGroup(mMeta=channelMetadata, mDescription="Channel Test")
        res = wrapper.RsGxsChannels.createChannel(channel)
        self.assertEqual(res['retval'], True, "Can't create channel")

For “v2” methods I opened an issue because I can’t communicate with the API. It was resolved as my “retroshare-service” wasn’t updated at all.

Next steps

This script will be adaptable to generate the wrappers for the language needed, for example for an OpenAPI format, TypeScript… Making much easy to other developers to start developing over Retroshare network.

Also it will be very easy to update when new feature is added to the API because it can be generated each time Retroshare is built.

Now will be time to apply the wrapper to the scripts that will import the public datasets!

Unittesting LibreMesh GSoC mid-term update

A few weeks passed and I want to share the progress of the project and what are the next steps 🙂

Unit testing tools and ecosystem

As one of the goals is that it must be easy for developers to write, modify and run the tests I created some simple tools to do this:

  • testing image -> Dockerfiles/Dockerfile.unittests
  • testing shell environment -> tools/dockertestshell
  • running the tests -> ./run_tests script

Testing image

In order to run the tests and have a reliable environment without the it’s working on my computer syndrome I created a simple and very small Docker image. This image is based on an image with Lua 5.1 and luarocks made by abaez. And then it just installs busted and luacov frameworks and bash.

FROM abaez/luarocks:lua5.1


RUN luarocks install luacov; \
    luarocks install busted

# TODO: move into a development dockerfile
RUN apk add --no-cache bash bash-completion

Nixio library

It would be good to have nixio available inside the docker image because this library is widely used in libremesh and also it could be very handy to have it available for the testing also.

I did an effort to add it to the image but many problems arised. The luarocks version of nixio 0.3-1 it is not working mainly because some compilation issues with newer versions of gcc. So I tried to work on a rockspec without this problem but I could not finish it because other problems arised I think that related to the Alpine/musl distribution and libc/linux headers. I will try help the author of nixio to publish a new version to luarocks as this will benefit others too.

Testing shell environment

To provide an easy way to develop or test things within the docker image I created a tool that opens a bash shell inside the docker image that has some features that allows easy development:

  • /home/$USER is mounted inside the docker image so each change you do to the code from inside is maintained when you close the docker container
  • the same applies to /tmp
  • you have the same user outside and inside
  • network access is garanted
  • and some goodies like bashrc, some useful ENV variables, PS1 modification, etc.

To enter the shell environment run:

[san@page lime-packages]$ ./tools/dockertestshell 
(docker) [san@page lime-packages]$

You can see that the prompt is changed adding (docker) in the left part so you can easily remember that you are inside the docker container.

This environment is also used by run_tests script.

Running the tests: run_tests bash script


This script is what you should be running each time you want to run the tests. As you can see in the image we currently have 19 tests and all are passing 🙂

For the sake of showing you what to expect when a test fails I modified a test condition to be false and here is the output:


now 18 tests are good, and there is one failure. The assertion that is failing is on line 11 and the test is Fake uci tests test simple get and set. Also it is shown that the expected result is the number 2 but the actual result is the number 1.

As it is expected, run_tests returns with 0 when all tests pass and != 0 when there is at least one failure.

The script in detail

The idea behind this script is simple:

  • sets the search path of the tests for buster (the unittesting framework)
  • sets the lua library paths, prepending the fake library and adding the paths to the libremesh packages with packages/lime-system/files/usr/lib/lua/?.lua. This doesn’t work automaticaly for every package if the paths does not use the files/path/to/final/destination. So if you want to test some package without the files convention maybe it would be good to move the package to this convention. Also it does not work if the lua module we want to test does not finish with .lua, in this case the path must be explicitly added (I wrote about this in a previous blog post).
  • runs the tests using the dockertestshell

run_tests also passes the first argument as an argument to busted so you can do things like this:

[san@page lime-packages]$ ./run_tests "--list --verbose"
packages/lime-system/tests/test_lime_config.lua:11: LiMe Config tests test empty get
packages/lime-system/tests/test_lime_config.lua:15: LiMe Config tests test simple get
packages/lime-system/tests/test_lime_config.lua:20: LiMe Config tests test get with fallback
packages/lime-system/tests/test_lime_config.lua:24: LiMe Config tests test get with lime-default
packages/lime-system/tests/test_lime_config.lua:30: LiMe Config tests test get precedence of fallback and lime-default
packages/lime-system/tests/test_lime_config.lua:36: LiMe Config tests test get with false value
packages/lime-system/tests/test_lime_config.lua:41: LiMe Config tests test get_bool
packages/lime-system/tests/test_lime_config.lua:54: LiMe Config tests test set
packages/lime-system/tests/test_lime_config.lua:64: LiMe Config tests test set nonstrings
packages/lime-system/tests/test_lime_config.lua:81: LiMe Config tests test get_all
packages/safe-upgrade/tests/test_safe_upgrade.lua:5: safe-upgrade tests test get current partition
tests/test_fake_uci.lua:4: Fake uci tests test simple get and set
tests/test_fake_uci.lua:14: Fake uci tests test multiple cursors
tests/test_fake_uci.lua:31: Fake uci tests test nested get and set
tests/test_fake_uci.lua:49: Fake uci tests test state not preserved between tests
tests/test_fake_uci.lua:54: Fake uci tests test save
tests/test_fake_uci.lua:59: Fake uci tests test delete
tests/test_fake_uci.lua:73: Fake uci tests test foreach
tests/test_fake_uci.lua:87: Fake uci tests test get_all

Here is the code:

$ cat run_tests 

TESTS_PATHS='packages/*/tests/test*.lua  tests/test*.lua'

./tools/dockertestshell "busted -v ${TESTS_PATHS} --lpath='${LIB_PATHS}'" ${1}

Integration of unittests with Travis CI

LibreMesh has already a github/Travis integration with two objetives:

  • test that the packages can be built (no Makefile errors, etc)
  • build and publish the packages of the master branch to an external server

The build pipeline of LibreMesh has been broken for a couple of months because the docker image that has been in use is not longer available. This is becaouse there is an ongoing effort by aparcar to create canonical docker images for OpenWrt.
So I did an atempt to fix the current LibreMesh build pipeline using the new infraestructure in this pull request. The build is still not passing but it seems it is something easy to fix as the build is passing but then the deploy is failing.

Travis unit testing

Beside fixing the current pipeline and to integrate the unittesting work I did a refactoring of the build steps to have a unittest stage and a build stage. To do this I installed the Github/Travis integration on my lime-packages fork. In the following image you can see that the two stages are green (tests are passing) 🙂


And here is the log of the unittests stage. You can see that it takes less than a minute to run the stage, with 15 seconds building the docker image and 0.011133 seconds to run the tests :100:

Next Steps

Now that the framework is in place and in continous integration we should be doing the following:

  • Add documentation on how to write tests
  • Integrate nixio in the docker image
  • Proofread the core LibreMesh code and inform about its testability
  • Provide some mocks for common functionality (uci already done!)

The first weeks of august I will move to Catalunya to work with a core developer of LibreMesh. So with my mentor NicoP we will adapt the schedule to take advantage of this.

BMX7 Wireguard Tunneling: 1st Coding Phase

It’s a wrap for phase one! We have managed to keep up with the goals we set for ourselves and along with my mentor Paul Spooren we have shaken up BMX7 development all around.

Documentation Refactor

One of this phase’s goals was to understand BMX7 functionality, usage and plugins. With a lot of reading (both in-project documentation and with external sources) this was achieved and I was much more synced. While doing so I refactored some pieces of docs to help me and I found a branch I had created with some generic changes that I made in the Community Bonding phase.

These acted as inspiration and I got together a big batch of changes commited and PR’d to the bmx7 upstream.

The PR can be found here and its purpose is to achieve generic changes to ease the introduction of new developers and users to the project, as well as ease the learning curve of usage.

More info one can found in the following blogpost that describes things in detail:

It’s worth to be noted that this was not a goal per-se of the phase and that changes did take place, but they sparked other changes that are still WIP on the PR.

Testing Infrastructure

Establish the following Testing setups for testing and later on continuous integration:

  • LXC running OpenWrt bridged mesh.
  • Qemu OpenWrt bridged mesh networks

The idea was to establish Linux Containers and Qemu infrastructures to do testing and experimentation. Along with aparcar my mentor “we salvaged from oblivion” a very interesting and well-set project that axn had created named Mesh Linux Containers (MLC) and which takes on its own the creation, configuration and command and control (CnC) of a virtualized mesh network on a Linux host, supporting an abundance of community mesh protocols. Paul took on him the modernization of this project producing the new generation of MLC, which switches mlc’s functionalities from the shell scripting era to LXC and distrobuilder to autocreate and populate an OpenWRT mesh mother and OpenWRT clients.

On the above I also based my testing infrastructure, but being a Qubes OS user and relatively confused with LXC versions (a newb), I kept coming across issues.

The situation was able to be relaxed by investing time on QEMU for love and support (as one may find here). Again though problems like libvirt on Qubes, multiple Qemu interfaces and tricky bridging tricks on a standalone VM didn’t allow me to have the results I was hoping for.

Hence, armboards were chosen. I borrowed boards from the hackerspace.gr common sharing stash of toys and I was able to interconnect a Raspberry Pi 1B, one Raspberry Pi 3B and a BeagleBone Black.

This approach is optimal for me to establish decent OpenWrt routers to test and play, that can painlessly run BMX7 (and Wireguard) and leave to the local community things to use like mesh boxes and on-the-go VPN-configured APs.

(The bmx7 luci app works like clockwork btw.)

BMX7 wg_tun Plugin

The initial goal was to implement wrapper functions to WG and establish a secure tunnel that way. This adds an overhead in the development phase, because making wg binary calls is both costly and requires to place code in places where no further improvements can be achieved.

For this reason, the embeddable wireguard implementation was chosen and we switched from addition(to the current tun src) to the creation of the wg_tun plugin earlier on than what was planned.

The idea is that adhering to the current implementation of the tunneling plugin of BMX7 we can reuse some minimum parts and establish:

  • The creation of a public and a private wg key associated with the current bmx7 session (or persist across sessions).
  • The advertisement of these keys and the network(IP) associated with our interface through descriptive updates for our peers to find us.
  • The establishment of connections with peers that have advertised their public keys and networks (and we’ve caught them), a la tunnel announcements style.

This goal is still WIP as more testing needs to take place and optimal ways and options for bmx7 node administrators to use it. In general, for this part and until further work has been put in, the paradigm of danrl for the luci-proto-wireguard package is being followed in the sense that we want the establishment of bmx7 wg tunnel to be that easy and the static configuration or the randomized UDP ports can help get there faster.

Progress can be found on the implementation’s branch on my fork (https://github.com/luserx0/bmx7/tree/wg_tun_plugin)

Developer Misc

My dotfiles repo has seen a lot of action this first period. The refactoring of my vimrc took place to help me in reading through code (a lot of code). The configs are managed through GNU Stow. If something catches your eye, clone, run the install script, tweak and share back.

My personal Blog saw also some pretty intense developments too to make progress report sharing and tutorial posting humane. It’s based on hexo and hexo-next, it’s static and hosted on gh-pages. Perfect combo for a GSoC student. Feel free to grab it from here and use it under CC.

If you have questions on how BMX7 operates and/or is different from other mesh routing protocols feel free to post them here.

Next Steps

  • Additions of features and options of the wg_plugin. Getting it merged on the upstream is a good milestone.
  • Cleanup and research on reusing cryptographic and networking primitives common to Wireguard and BMX7.
  • Creation of the bmx7 Debian Package.
  • Port mlc functionality to mlc-ng.
  • Finish the second phase of the documentation refactor.
  • Attending Battemesh V12 😉
  • Order hardware to play with