A module for OLSRv2 to throughput estimation of 2-hop wireless links

Hi to community members!

This project aims to develop a module for the throughput estimation in OLSRv2 based networks. The basic idea is to evaluate the throughput of 1-hop and 2-hop network paths and to expose the measures to the user by visualizing them on the netjson graph.

The community bonding period had the goals to improve my knowledge of OLSRv2, to study OONF and its basic modules, then start approaching netjson. Now we are designing how to realize the throughput measures between the nodes. Basically, we are considering two approaches: the implementation of probe-based measure in OONF by using its reader/writer objects, or an alternative approach that realizes a daemon which reuses iperf based measures.

In the next weeks, we will update you with the initial results!

GSoC 2018 – RetroShare Web Interface Modifications/Improvements

Project Introduction

RetroShare, the encrypted peer-to-peer social networking system, has a web interface which makes it easier to use from multiple devices without running multiple nodes. The web interface works, but it is in need of improvements in its API, appearance, and user friendliness.

The web interface is particularly important to those who wish to use RetroShare heedlessly on a server, so they especially will benefit from improvements to it.

This project will mainly involve building on and redesigning the web interface API, libresapi.

Who I am

My name is Kevin Froman, I am a 19 year old American computer science student. I am passionate about online privacy, information security, and decentralized networking. I mainly have worked in web and mobile development, however I have some experience in standard desktop development as well.

More info about me, as well as a mirror of blog posts written here, is available at my website.

Project Overview

As with all projects, mine is made up of several main goals:

  • Switching the RetroShare web server library to Restbed (https://github.com/corvusoft/restbed)
  • Properly serializing all data in and out of the API as JSON
  • Refactoring and/or migrating existing code where applicable
  • Maintain existing supported RetroShare features in the UI (do not lose any in migration)
  • Add authentication (likely sha256-HMAC) to the interface to protect against certain browser attacks
  • Re-designing the front end, both style and functionality, likely using VueJS.
    • I am not a web designer, however I can definitely improve the appearance

Bonus goals include:

  • Adding more RetroShare features to the UI (the features the web UI supports is incomplete)
  • Making the web interface easier to setup on headless servers
  • External HTTP API mechanism with CORS (Cross Origin Resource Sharing)
The web interface’s appearance is currently not a work of art.

 

Bonding Period Experiences

Leading up to and during the Community Bonding Period, I got to know my mentors Cyril and Gio better and explored the RetroShare code base, especially libretroshare and libresapi. We discussed details about the project and the way project goals will be implemented.

As a way to dive into RetroShare, I worked on a backup system for RetroShare profile data to XML files. Unfortunately, I did not get a lot done on this, mainly do to final exams and projects for my classes which overlapped with most of the bonding period, but also due to roadblocks I ran into involving my development environment, personal issues, and less than optimal time management on my part. I felt I needed to spend time looking at libresapi and studying the code base in general, in order to be better prepared for the main coding period. The issues I had have been resolved.

At first, I found diving into this a large, multi-author code base intimidating, but I learned more of its structure and feel more confident for the main project.

First Goal/Milestone

My first project milestone is to fully analyze libresapi and to look for any code that should be kept/refactored and to finalize exact details of the new API system (white-boarding, prototyping, writing unittests). If all goes as planned, the first milestone will be done before May 28th.

I expect this goal to be accomplished early, so I will likely also be starting on the second milestone during this time, which is to get the base API system setup (both for the front-end and back-end).

 

I look forward to a summer working on RetroShare, and I believe my project will be a valuable contribution.

I wish the best of luck to fellow Freifunk GSoC students!

The Turnantenna

Intro

This year the “Battle of the Mesh” was hosted by the c-base community in Berlin. It was an awesome event, with amazing people coming from everywhere. I was able to present my project here, and it was exciting because many people was interested in. I also met some other students involved in the actual Google Summer of Code.

Unfortunately the week is over, and so is the bonding period.

Description of the project

Now it’s time to code, so let me introduce my project: The Turnantenna.

As its name suggests, the Turnantenna is a directional antenna paired with an engine that should be remotely controlled.

The advantages of having such a system are:

  • It could allow rapid changes of the mesh of the network;
  • It can make easy to dotests and optimization of the network;
  • It provides security as you don’t have to climb onto the roof (or pole, or pylon …) everytime, saving time and reducing dangerous operations.

Think about all the times that you had to reach the antenna to change it’s orientation. Now you can cut down this practice!

The Turnantenna was designed from and idea of Salvatore Moretti, another member of the Ninux community. With the other Ninuxers we made a working prototype of the Turnantenna, but now all the project should be improved.

The electrical scheme and a render are shown below.

The goal in the next month is to write down a new driver for the two engines, and to make them work through HTTP APIs. The orientation of the antenna will be changed interacting from a dedicated web page (that will be shaped in the next month) or sending HTTP requests; in the last month I’ll publish all the documentation and packaging the application with PIP.

Thanks

I wish to thank all the Freifunk members for the reception, and for giving me  the opportunity of being part of the Google Summer of Code this year.

I’d like to express my sincere thanks to all of the Ninuxers that helped and are still helping me in this adventure. I love you guys!

GSoC 2018 – Kernel-space SOCKS proxy for Linux

Background

Welcome! I’m Ferenc Fejes from University of Debrecen, Hungary. In 2017 I did my first GSoC project with my mentors Benjamin Henrion and Claudio Pisa. You can find all of my post from the project on this link here: https://blog.freifunk.net/tag/mptcp+lede/
In a nutshell it was an experiment to create a test-bed for aggregating the speed of multiple Wi-Fi links in transport layer with MPTCP. We succeeded, I also provided a detailed tutorial with the method for reproducing the experiment in home. I did not expected too much enquiry about the project but after the blogposts and an OpenWRT summit workshop, I received lots of emails and messages – many experimenter interested about the project which is a great honor of me. In China, where the router proxyfication is necessary because of the great firewall, many people applied the method of my GSoC 2017 project outcome. (Cont.) Continue reading “GSoC 2018 – Kernel-space SOCKS proxy for Linux”

Our Projects for GSoC 2018

GSoC Logo

In 2018 Freifunk applied again as umbrella organization for Google Summer of Code. That’s the third year in a row and our 8th Summer of Code in total. Finally we got 14 slots for student projects.

Partner Organisations

As in the years before we act as umbrella organisation. Our partner organisations for this year are:

GSoC 2018 Projects

You can find our organisation’s profile and more information on our projects at the GSoC 2018 organisation’s page. This is just a list of our projects. More information will be added later when the coding period starts.

Titel Student
Kernel space SOCKS proxy for Linux 4.x Fejes Ferenc
Realizing a decentralized WiFi Controller nick.power
Local Phone App Daniel Dakhno
Easily Expandable Wireless Intrusion Detection System Alexander Paetzelt
A module for OLSRv2 to throughput estimation of 2-hop wireless links Pasquale Imputato
Design network agnostic communication protocol Katharina Sabel
LibreNet6 Paul Spooren
nodewatcher: Build system rework and package upstreaming Robert Marko
VRConfig – Visual Router Config for OpenWrt Asco
LibreMesh ground routing user friendly interface Marcos Gutierrez
RetroShare Web UI API Changes Proposal Kevin Froman
Re-write the Turnantenna code Marco Musumeci
Better map for nodewatcher Marin Stević
OpenWLANMap App Thi Huyen (Lilli) Cao

We’re looking forward for all these projects. Following the timeline we have the Community Bonding Period now. All students will be introduced to their organisation and their specific project. The projects will start latest at May 14. That’s when the coding period starts. There are several evaluations and the last Coding Period will end on August 6. After submitting the final evalulations by mentors and students the final results will be announced on August 22.

Stay tuned, all of the students will write about their project at this place. There will also be talks on events like the Wireless Meshup, Chaos Communcation Congress and other related events.

GSoC: Improving nodewatcher data representation capability(final report)

Introduction

This summer was really exciting because it was my first Google Summer of Code! I worked for Freifunk, a non-commercial initiative for free wireless networks. I would like to thank them for the opportunity to expand my programming skills and a great summer. I am excited that I got around to use Git on a serious multi-developer project and even create my first pull request. I developed a strong affection for Docker, which I now use for personal projects as well. After 5 years of programming in Python I am happy to add Django to my programming skill set. Continue reading “GSoC: Improving nodewatcher data representation capability(final report)”

GSoC: Libremesh Spectrum Analyzer – summary

Hello everybody!
This is my final report for GSoC 2017.
I have enjoyed this GSoC a lot. Having the chance to get involved with the LibreMesh development community has been a blessing, thank you Freifunk and GSoC for giving me this opportunity!
This months of coding for LibreMesh have allowed me to learn many new skills while being able to contribute to the common project and getting more involved in the governance and community of the project.
I have been working on many features and most of them have been merged to the LibreMesh main branch, so in the following pages you can find all the technical details of the work done.

Principal contributions

https://github.com/libremesh/spectrum-analyzer-packages

This repository contains all the code related to the spectrum analyzer.

It is also an OpenWRT/LEDE feed, so it can be added to a feeds.conf file to be used as a source of packages.

In this repository you can find:

  • Spectral Scan Manager: It manages ath9k states, recovers i/q data from the atheros modules and hands them over through ubus
  • Spectral Scan Decoder: FFT_eval wrapper that will receive Spectral Scan Manager i/q data and turn it into JSON
  • Spectral Analysis Collector: A configurable daemon that will collect the Spectral Scan Decoder data for further analysis. This collection could be kept in memory or sent to a secondary server (like the OpenPAWS server)
  • Visualization Module: Access the information handed by the Decoder or the Collector (depending which information we would like to access) and visualize it in a Waterfall graph.
  • OpenPAWS Server: OpenPAWS is an open implementation of the PAWS protocol, TVWS Database. The Spectrum Analyzer can talk to it to inform on the usage of TVWS frequencies.

https://github.com/libremesh/lime-packages

I had the chance to contribute some changes to the LibreMesh core, namely:

  • Adding the first steps of Continuous Integration and Continuous Deployment
  • Enhancing LibreMesh LuCI web interface

Outreach activities

As part of my involvement on the LibreMesh team, I got the chance to be part of many outreach activities to spread the word:

Things I had to learn

This were the things that I had to got deep into to get things done during the GSoC:

  • OpenWRT/LEDE Build pipeline
  • ath9k module functionality
  • LuCI module creation
  • Data visualization and D3.js Visualization tool

Reports on Freifunk blog

During my GSoC I did some articles about the life of a GSoC and LibreMesh/OpenWRT/LEDE programmer:

Things done

Things to be done

  • Proper packaging: right now the packages are not ready yet, so manual installation is required. I’m getting into this in the upcoming weeks.

    Variable frequencies: right now the Visualization Module only shows frequencies in the 5Ghz range. Refactor the code to be able to display all frequencies.

    Integration with LuCI: A LuCI module would be much more practical for integration with the rest of the architecture.

Future enhancements

  • Support for frequency shifters: there is a device that allows to do frequency shifting between 2.4Ghz and TVWS frequencies by connecting it to the radio conector.. Allow the system to be able to support it, namely, configure that there is one connected in a specific interface, and shift frequencies detected accordingly.
  • Add Support as an OpenPAWS agent: The scans done by this module could be used as an input for the OpenPAWS Server to monitor TVWS frequencies use and be able to handover frequencies based on current usage. For that, an agent needs to be developed that consumes the Spectral Analysis Collector data and sends it to the OpenPAWS Server.

Final Thoughts

The project has been very successful for me to get more deeply involved with the LibreMesh community.

Also, it helped me understand the complexity and diversity of knowledge required to engage with FLOSS projects.

Moving forward, I commit to continue working with the LibreMesh project.

Will continue mantaining the packages I produced and learning from the community to better serve it.

GSoC 2017 – wlan slovenija – Final report

What’s been done

The first blog post that describes the idea and goals can be read here, the first update here and the second one here.

So the Google Summer of Code came to a close. It was an interesting journey of learning, adapting and frustration. First I struggled with setting up the work space to work on LEDE platform. It was in the end successful and the whole process well documented, from setting up the virtual machines for running nodewatcher and nodewatcher-agent to actually coding, compiling and updating the agent with new packages. The end product is working HMAC signing of agent’s report messages that are sent to the nodewatcher. It can be used as a lightweight alternative to SSL certificates.

After that I tackled the task of improving the Tunneldigger, but was again met with deprecated documentation that wasn’t helpful at setting things up. After much struggle and digging around Slack I managed to get things going. Unfortunately my health disagreed and prevented me from finishing the task fully.

 

What’s next

If possible, I intend to finish the last task anyway so my contribution to wlan-si and Google Summer of Code is complete.

I am contributing using my github account.

Thank you for the great opportunity and good luck!

geolocator (Software defined GPS) final evaluation

Hi everyone,

with this blog post I would like to explain the full Google Summer of Code Project as a final post. For people who haven’t read over the geolocator (Software defined GPS) project before, it might be interesting to read these three blog posts at first:

– geolocator (Software defined GPS) (english)[1] and (german)[2]

– geolocator (Software defined GPS) first evaluation (english)[3] and (german)[4]

– geolocator-software-defined-GPS-second-evaluation (english)[5] and (german)[6]

Otherwise I will give in the following a short overview about the project structure to remind you of it. I structured the Google Summer of Code project into 3 main subprojects:

web backend,

– The web backend named sgps-core is a service, which should give requested clients their geo position.

gps-share,

– The idea of gps-share is to create an udev device, which provides NEMA-formata protocols over tty addicted on information, which is received from the above mentioned backend.

LEDE Package,

– The intention behind this subproject is to develop a new package for LEDE called geolocator, which should provide the geo position of LEDE devices.

Now I would like to give you a full state of each above mentioned subproject. Firstly I will explain about the web backend and finally a peroration including my valediction as a Student by Google Summer of Code.

web backend

Generally the backend service receives over the OpenWLANMap[7] App from mobile phones the mac addresses of surrounding wireless networks linked to GPS positions. This information will be stored into a database. If a device like a WiFi router requests its position, it will send surrounding Wireless mac addresses to the backend and get back a geo position, which is calculated from these information in the database.

The new web backend called sgps-core[8] is an API-core, which should replace the old openwifi.su backend. The old one consists of a collection of different programs in different program languages. sgps-core includes a fully backwards compatibility to the old openwifi API[9] for requesting a position. sgps-core is written in Golang, which processes a lot faster than the old API, which is written in Ruby. sgps-core is more secure because it checks and take only requested strings, which contain only comma separated macaddresses with 12 hex characters.

As a fallback feature, sgps-core is able to receive coordinates from unknown WIFIs by requesting them on Mozilla Location Service (MLS)[10] if there are no db entries for that WIFIs. The position for clients will be returned in form of latitude and longitude. As a quick reminder, here is the schemata from the first post, which represented the the functionality of sgps-core:

The sgps-core solved a problem about calculating the position. The old method counts the average of all latitude values. Analogous for longitude. The new method calls geographic midpoint calculation and needs 4 parameters lat0, lon0, lat1, lon1 (give two take one) which will be explained in detail in following:

deg have to be replace with latitude or longitude value.

rad = deg *π / 180 <- Generally conversion from degrees to radiant.

dlon = (lon1 – lon0) * pi / 180

lat0 = lat0 * π / 180 <- lat0 from degrees to radiant.

lat1 = lat1 * π / 180 <- lat1 from degrees to radiant.

lon0 = lon0 * π / 180 <- lon0 from degrees to radiant.

Converting into Cartesian coordinate system.

Bx = cos(lat1) * cos(dlon)

By = cos(lat1) * sin(dlon)

Calculate new position reference to sphere and Converting back from Cartesian coordinate system into new latitude and longitude:

lat2 = atan2(sin(lat0) + sin(lat1), (cos(lat0) + Bx)² + By²)^(1/2))

lon2 = lon0 + atan2(By, cos(lat0) + Bx)

On this point it is also possible to use a ellipsoid to increase the accuracy of positions. This may be interesting for long distances. For short ones like from seen wireless networks, it is not really relevant.

Converting back to degrees:

deg = rad / pi * 180 <- Generally conversion from radiant to degrees.

lat2 = lat2 / pi * 180 <- lat2 from radiant to degrees .

lon2 = lon2 / pi * 180 <- lon2 from radiant to degrees.

In the last few weeks, I spent a lot of time on discussing with the current server administrator of openwifi.su to deploy the sgps-core on the server for a test environment. But he did not have much time, so we decided to migrate the openwifi.su to our Nordwest Freifunk infrastructure to make the administration more accessible for other people. In my last report I wrote “I will release in the next few days a first version”. This could not be done because of the above mentioned discussion. After the migration I can test that backend on huge databases and compatibility to the DBS. The current code can be found here [11]. For people who want to try the sgps-core please check out the following URL[12].

gps-share

The Idea at the beginning of GSoC17 was to write a program to provide GPS NEMA-formats over a tty udev device. The information for the GPS NEMA-formats should come from the above mentioned sgps-core. As I told in the first blog post I discussed with some people from the Mozilla Location Service Malinglist and it turned out that something similar was already exist called geoclue. To avoid developing redundant software I decided to drop this idea. Instead of it the new plan was to build support for native GPS in gps-share[13], which is an add-on for geoclue. But during the Google Summer of code I had to focus more on the both other subprojects because they are more important, especially for Freifunk. In my peroration I will tell about the future plans, especially for gps-share.

LEDE Packages

The third subproject was to create some opkg packages for LEDE[14] and similar Frameworks. The main package called geolocator provides the geo position of the device via UCI[15]. Positions should be received from the above explained sgps-core. The 4 other packages are only for Gluon[16], which add the configuration options of the geolocator to the Web-interface.

This month I mainly worked on the LEDE Packeges. At the beginning of the august I sent a merge request to Gluon for integrating the Gluon-geolocator[17]. The containing geolocator program was written in ash shell code. While reviewing and discussing about the merge request, I realized that I had to rewrite the program from shell to lua code because Gluon mainly work with in lua written programs. You can find the shell code here[18] and the Lua version here[19]. At the moment I am waiting here for another review and subsequently merging.

The other packages for the Gluon Web-interface are also already in process. The first idea was to create a detection of installed packages to show related configuration options on the Web-interface. This idea was dropped because I found a better solution. The problem is detecting packages on runtime, which means many extra code on Routers, which only have 4MB Flash for example. So I decided to generate the package with their options on compile time. These packages are:

gluon-config-mode-geo-location,

gluon-config-mode-geo-location-with-geloc-map,

gluon-config-mode-geo-location-with-geloc,

gluon-config-mode-geo-location-with-map

The main package is gluon-config-mode-geo-location, which is already exist in gluon, but with a difference Web-interface. Each package should either integrate an open street map or the geolocator options. Integrating both are also possible. For communities which would like to stay on the currently variety of functionalities, it is also no problem not integrate any of these extra options.

Here is how the new packages look like:

I wrote some C++ programs, which generate me the Lua code for the Gluon Web-interface, which is written in Lua. Base on preprocessor variables, the amount of options for each package will be included into the Lua output from the C++ program. These preprocessor variables will be set by selecting one of the above packages. Also PO files for the translation will be generated in the same way. A merge request of the above new packages can be found here[20] I am still working on it.

Peroration and Future plans

Now I am coming to my peroration.The last 3 months were really awesome, just like last year as a student on the Google Summer of Code. I would love to recommend this great opportunity for not only students but also for open source organizations. Students can not only learn a lot of new things but also meet new great people, make new friends and take part in many events. For example: at the beginning of august I was on the SHA2017[21] (Still Hacking Anyway) and had a meetup with some Freifunk communities there. We had a great discussion about a lot of technical stuffs and a nice time for socializing. The SHA2017 took place in Netherland nearby Amsterdam. Another example is : this week I flew to Spain to start my exchange semester. Coincidentally a student from Germany who I met at the beginning of the GSoC17 in Berlin on the WCW[22] (Wireless Community Weekend) is also doing an exchange semester in Spain. We have already emailed each other and planned to meet up in the next months, probly in Barcelona or any other places. As I said above, this is my second time as a student on the GSoC, which means this is also my last time and sadly I have to say goodbye to GSoC as a student now. But maybe next year I can work as mentor to support other students in their great opportunities.

Back to the projects, as i said I’m still working on it. I will finish the Integration into Gluon and LEDE and continue developing sgps-core integrate new features and migrate the infrastructure to a better server. I would like to contact Zeeshan Ali, the maintainer of gps-share and try to help on this project as well. Also I am still working on the hoodselector which is my Google Summer of Code project from the last yeah. You can read about it here[23]. The hoodselector should also integrated into Gluon but it requires for sure a few weeks of work to integrate VXLAN on it. A merge request for can be found here[24].

Also I would like to say thank you to my Mentors Clemens John from the Google Summer of code 2016 and Johannes Rudolph from 2017 and especially to Andreas Bräu who works so hard on the Freifunk Org for many years to give students these opportunities to be a part of the Freifunk Community.

[1] https://blog.freifunk.net/2017/05/29/geolocator-software-defined-gps/

[2] https://ffnw.de/geolocator-software-defined-gps/

[3] https://blog.freifunk.net/2017/06/28/geolocator-software-defined-gps-first-evaluation/

[4] https://ffnw.de/geolocator-software-defined-gps-erste-evaluation/

[5] https://blog.freifunk.net/2017/07/26/geolocator-software-defined-gps-second-evaluation/

[6] https://ffnw.de/geolocator-software-defined-gps-zweite-evaluation/

[7] https://f-droid.org/packages/com.vwp.owmap/

[8] https://github.com/openwifi-su/sgps-core/blob/master/README.md

[9] https://sourceforge.net/p/libwlocate/code/ci/master/tree/master/

[10] https://location.services.mozilla.com/

[11] https://github.com/openwifi-su/sgps-core

[12] http://runner01.ffnw.de:8082/api/v1/bssids/64700274945A,0018E7DC21BB,30FC681F37A6,F81A673626E8,EC086BA8ED18,8416F9A8E2FA,E894F6A230E4,98DED020D00A,EC086B3349B2,F81A677F5CD8,A0F3C1654BA6http://runner02.ffnw.de/64700274945A,0018E7DC21BB,30FC681F37A6,F81A673626E8,EC086BA8ED18,8416F9A8E2FA,E894F6A230E4,98DED020D00A,EC086B3349B2,F81A677F5CD8,A0F3C1654BA6

[13] https://github.com/zeenix/gps-share

[14] https://lede-project.org/

[15] https://wiki.openwrt.org/doc/uci

[16] https://gluon.readthedocs.io/en/latest/

[17] https://github.com/freifunk-gluon/gluon/pull/1201

[18] https://git.ffnw.de/ffnw-firmware/packages/blob/ba8007e5a6b99306068847ba98f2bb72b7fb2745/ffnw-node-info/files/lib/ffnw/geolocator/geolocator.sh

[19] https://github.com/2tata/gluon/blob/fa935d83a64c27dd23f133bd8cecf5d72ef9281b/package/gluon-geolocator/luasrc/lib/gluon/geolocator/geolocator

[20] https://github.com/freifunk-gluon/gluon/pull/1211

[21] https://sha2017.org/

[22] https://wiki.freifunk.net/Wireless_Community_Weekend_2017

[23] https://blog.freifunk.net/2016/08/22/monitoring-and-quality-assurance-open-wifi-networks-out-client-view-final-evaluation/

[24] https://github.com/freifunk-gluon/gluon/pull/997

 

Implementing Pop-Routing in OSPF – Final evaluation updates

Hello again, since last updates I worked hard to finish my project and to reach the final milestone for this project.

As I explained in my previous post[1], due to some issues, we’ve decided to change the topic of the project to Implementing Pop-Routing in OLSRd instead of OSPF.

In this last month I completed the code for the OLSRd plugin[2], which I hope will be merged soon [3].In order to allow PRINCE to interact with OLSRd I had to modify the PRINCE source code[4] and create a new plugin[5].

The last part of my GSOC was testing the functionalities of my project.
To perform this tests I used a tool developed by the University of Trento, called “NePA TesT”[6]. NePA allowed me to simulate a mesh network in my laptop and to perform tests on it. The network topology was defined using NetJSON, but for my purpose modified it to use graph generators[7]

To ensure that PRINCE was working correctly on this virtual network I measured the centrality and the tuned timer for each node. Then I compared these values to the ones calculated by the original algorithm. Since the simulated network was real, and it needed a bit of time to converge, I took the last 10 values to avoid to measure errors. This are the maximum errors for each size and each kind of graph:

Maximum of percentage errors calculating nodes centrality

I also measured the “hello” messages’ rate to check if it was being calculated correctly by PRINCE. As I did for the centrality I took the mean of the last 10 values for each node and I compared them against the ones calculated using the python Pop-Routing algorithm.

Maximum of percentage errors calculating “Hello” messages’ emission rate

Hence, as we can see from these tables, PRINCE is calculating the Centrality, and the timer’s value, with a really small error. This test also highlighted a bug (*) in the c_graph_parser library with very that particular kind of graph [8].

The last test I performed was to check whether the message to update the timers’ emission rate was actually modifying the emission rate of the messages.
I used a simple graph: 2 nodes connected by one link. And I captured the traffic with tcpdump, before and after the update message.
After 30 seconds I sent a message to the OLSRd poprouting plugin to update the hello timer to 5s. As you can see from the graph below it is working correctly!

Hello messages measured emission rate

I can conclude that PRINCE is working correctly with OLSRd and now it can be used to enhance the Wireless Community Networks that are still using it.
I would like to thank Freifunk, Ninux and Google for giving me the opportunity to participate in GSoC.

Cheers, Gabriele Gemmi

[1]: https://blog.freifunk.net/2017/07/27/implementing-pop-routing-ospf-july-updates/
[2]: https://github.com/AdvancedNetworkingSystems/olsrd/tree/poprouting
[3]: https://github.com/OLSR/olsrd/pull/38
[4]: https://github.com/AdvancedNetworkingSystems/poprouting/tree/refactor_ospf
[5]: https://github.com/AdvancedNetworkingSystems/poprouting/tree/refactor_ospf/prince/lib/olsrd
[6]: https://ans.disi.unitn.it/redmine/projects/community-newtork-emulator/wiki
[7]: https://github.com/AdvancedNetworkingSystems/wcn_emulator
[8]: https://github.com/AdvancedNetworkingSystems/poprouting/issues/23