Year: 2017

GSoC 2017 – Final Milestone

Posted on by ArneKappen

tl;dr:
If you are looking for the work I have done for GSoC 2017, here are the principal repositories containing the source code and documentation:
– [1] ONOS
– [2] SDWN controller
– [3] SDWN agent

Also, check out the website that Johannes and I created to document how our two GSoC projects can be combined.

August Progress

In my last blog post I wrote that during the final coding phase I wanted to focus on applications for my controller platform – mainly an app that integrates my controller with Johannes’ OpenWifi server. While I was programming it, I noticed that I was getting tangled in unstructured dependencies between the different parts of my code. I realized that the controller needed a refactoring to better define its main application-facing interfaces. So I decided to modularize it into 4 separate pieces:

    the SDWN core API,
    its core implementation,
    a command-line interface,
    and a REST API.

With the refactoring done, I built two applications: the aforementioned OpenWifi integration and a simple client hearing map. Unfortunately I ran out of time just when adding features was fun again. The basics are all in place and working but I did not finish the more advanced applications such as the client load balancer or client authenticator that I mentioned in my last blog post.

On the more positive side, I really like how the newly structured controller behaves when adding features as well as how the OpenWifi integration turned out. A combined SDWN/OpenWifi setup is shaping up to become a neat management tool to operate a large deployment of LEDE nodes in which most of the initial configuration is automated. Nodes discover the OpenWifi server, download a configuration which makes them initiate a connection to the SDWN controller which gathers information about the nodes’ wireless capabilities and running access points. Throw in the hearing map and the nodes start reporting clients in their vicinity to the controller which makes that information available via its various APIs. Seeing it in action felt rewarding and dampened my initial disappointment of not getting everything done.
Johannes and I have put together a small website using GitHub pages which explains how to set up and use a combined SDWN/OpenWifi system.

Also during the past month, I have reached out to the ONOS developers about my work on the compatibility of ONOS’ fork of Loxigen and its upstream version. ONOS recently moved to a much more recent version of the loxigen-generated Java library for its OpenFlow subsystem which should make it easier for me to merge with it my modified ONOS. I want to explore if I can completely separate my code from the controller and have it provide the same functionality as external modules. This would of course greatly simplify future maintenance of the work I did.

The SDWN System

The following sections document the structure of the system that I have built and list possible applications.

The Controller

The SDWN controller that I have written comes as an OSGi bundle that gets deployed as an ONOS application. It relies on ONOS’ OpenFlow subsystem which manages the connection to the wireless switches in the network. Since I am using a custom OpenFlow protocol extension, I have added a corresponding protocol driver into ONOS’ south-bound interface which is responsible for the handshake with the SDWN agent. The SDWN controller’s core interacts with that driver and ONOS’ OpenFlow controller to create its abstraction of the network elements. It maintains so-called SDWN entities to represent the relevant wireless network resources and their relationships. For example, an access point is running on a network interface card which supports a certain set of transmission frequencies and rates. The controller would represent this state in the form of Java objects for the network interface card, its capabilities as well as the access points and set the references between them appropriately. This information is stored and made accessible through different APIs. If clients associate with the access point, the agent on the node notifies the controller which learns the client’s properties and stores the relationship with the AP. SDWN applications need not communicate with the wireless hardware directly but only work with the abstractions provided by the controller. There are also means for applications to subscribe to certain events such as the association of a new client or the reception of a probe request frame by an access point.

SDWN Applications

Applications can provide their services without having to interact directly with the network, they can leave communication details to the controller. For instance, the simple hearing map that I wrote subscribes to 802.11 management frame events. Every time the controller gets notified about such a frame by one of its APs, it informs the hearing map service. The service in turn stores the information about which AP on which switch received the frame on which frequency at what time and with how strong a signal.

Although I did not get to implement it, all the interfaces necessary to implement a blacklist of banned clients are in place. Simply register with the SDWN controller, hook into the stream of authentication and association request events, and deny unwanted clients based on their MAC address.

Or you could automatically push clients towards certain frequency bands: Query the hearing map for clients in the vicinity of an AP broadcasting at the desired frequency and check if they are currently associated with an access point on an unfavored channel. If yes, instruct that AP to disassociate and ban the clients for some time and grant their association request at the chosen target AP.

The Agent

To manage the network elements from the central controller, each of them needs to run an agent that maintains the connection, responds to queries, and executes commands. The SDWN agent is called wlanflow and it is built with the indigo OpenFow agent framework by the Floodlight project. It is available as a feed to integrate with the LEDE build system and uses UCI for configuration. Please refer to the instructions in the repository at GitHub (REPO LINK) about installation and configuration.
Wlanflow interacts with different other programs and services on the same machine. For example, it learns about most wireless capabilities through Linux’ netlink interface and subscribes to the standard Linux wifi soft-mac daemon hostapd via LEDE’s ubus IPC bus to receive notifications about incoming wifi management frames.

The Protocol

The SDWN controller and agent talk using an extended version of OpenFlow 1.3. The libraries for both the Java controller and the C agent are generated using a modified version of Loxigen.

Deploying the SDWN System

Like I said in the beginning of this blog post, I did not manage to realize all the ideas I had for this system. For this reason, the final product is a bit bare and lacks finish. Nonetheless, I encourage you to build a small installation and try out its features if you have spare wireless LEDE nodes lying around. I would appreciate your feedback and suggestions for improvements or new features.

You can find instructions on how to build and deploy the components of the SDWN system in their respective repositories which are listed at the top of this page.

Acknowledgments

Finally, I would like to thank Freifunk for letting me participate in GSoC again. Thanks to Andreas for organizing everything on Freifunk’s side and to my mentor, Julius.

GSoC 2017 – Attended Sysupgrade – Final evaluation update

Posted on by Paul Spooren

Hi Freifunk,

This is my last post within this years GSoC. I’ll cover the progress, challenges and future of the project.

tl;dr:
Direct links to the work I’ve done this GSoC:

First a small reminder what the project is about: Enable end-users to update their routers to new releases or bulk update installed packages via a simple click in the Luci web interface. The magic lies in a server producing sysupgrade images with the same packages preinstalled as installed on the router. That happens on demand when triggered via the web interface.The image is downloaded securely via encrypted HTTP as the used browser has all certificates installed. The router does neither need certificates nor a correct running clock.

Progress

Server

At this point I’m very happy to announce a test (and usable) version of the attended sysupgrade setup. All created package recipes were accepted into the official repository and are compiled within the daily build cycle. The server runs fine obeying the described API at the Github page. Images are build within a few seconds if the request appears for the first time. The server stores previous requests and forwards to existing images instead of building it again. This reduces significantly the amount of build images due to the likely case of identical images being requested again. In addition some basic information are offered via the web servers status pages.

The server is implemented in Python3 using flask for request routing and template rendering. While that’s only the tip of the iceberg behind the server lays a rather complex PostgreSQL database validating requests, checking for package changes or transforming packages when updating to another main release. More on the transformations later.

Images created on the server. A click on manifest shows all installed packages with version. All snapshot builds are deleted midnight UTC.

To try the the server at https://betaupdate.libremesh.org have a look at the demos I prepared. Continue reading “GSoC 2017 – Attended Sysupgrade – Final evaluation update” →

GSoC 2017 – RetroShare mobile improvements – Final evaluation update

Posted on by Angela Mazzurco

Hi Freifunk and GSoC communities!

Finally we arrive at the end of the summer and also at this third final evaluation of GSoC!
I’m proud I have participated to this edition of GSoC and I am thankful for this opportunity.

This past month I did lot of new work and lot of interesting improvements.

One of the funniest and visible things are the implementation of the 8biticon library that provides a reliable avatar face generated using GXS id as input, it is reliable in the sense that having the same GXS id as input will generate always the same avatar.

The nice thing about this is that it can be used as an user friendly way to verify identities, the user doesn’t need anymore to check long fingerprints but she can do a quick verification just by looking at the generated face.

Another interesting thing I have implemented is sending little files and images via chat using data URL. This works encoding a file to base64 and send it with a header specifying the mime type. The maximum file size is 60KB, and for images, if it’s bigger than that or if it’s size is more than 160×160 pixel, the program resizes it to fit.

This branch results very interesting for me because it uses all the things that I learned this summer: call C++ code from QML, call Android Java code from C++ interact with Android OS, create custom QML components from C++ code…

 

Of course, a big part of work has been to find and fix bugs, on Android and on desktop. At the moment the last commit has little known bugs that I’m going to solve as soon as possible.

One of this bugs causes program crash on some Android devices when send or receive an emoji. This happen because I implement an alternative emoji font if no native compatible emoji font is found. On Android, the Android Emoji font is who provides the typography of emojis, but in some devices its not shown. So I decided to integrate the OpenSansEmoji project. That way, when the program doesn’t detect a compatible emoji font, it uses the OpenSansEmoji.

But the implementation of that is not working as good as expected and causes the crash mentioned above.


Another typical work has been to improve the UI aesthetics in little things: correct a height in one place, change the color somewhere else, draw a line separating the contacts. I create a custom button component with animation and the possibility to attach to them an icon. This is done thinking about to also centralize the application style sheets.

And thinking about the end user, I tried to improve how the user share or import the nodes identities. I put a shortcut on the menu to share identity, and also refactor a little bit the import/export trusted nodes view, making an informative popup that shows you a little bit of information about each option.

 

Also I have done some little attempt to implement key exchange using the device sound card using libquiet available in C, Java, JavaScript and more languages.

This is a very interesting functionality that would improve the key exchange process and make it user friendly.

The functionality is not implemented yet as I believe it would take more time then the GSoC as it seemed more difficult than we thought initially, but I would like to continue working on this topic in the future.

In latest days I have been working with my mentors to do the final polishing and integrate most of the code in RetroShare official repository master branch, most of the code have already been merged as you can see in this commit e06bffdb by one of my mentors.

As always you can find all the code and activity track on my gitlab repository, I also suggest to take a look to the detailed technical report and if you are eager to test the results on your phone you can download the Android Package too.

Finally I want to say goodbye, and again appreciate the opportunity to participate to this exciting GSoC!

Implementing Pop-Routing in OSPF – July Updates

Posted on by Gabriele Gemmi

In the last months some issues emerged with the original plan of my project.
After implementing topology export in NetJSON format for BIRD, I started investigating how to modify the timers of OSPF, and finally found that OSPF has a limitation regarding the timers, which states that all the routers on the same network must have the same timers. This is surprising, since the RFC supports specifying the timer in the messages, and thus it would be trivial to have nodes with differentiated timers (as OLSR and other protocols do, for instance). Actually somewhere else in the RFC it is stated that even if the timers could be diversified, they must be used as a network-wide parameter, otherwise routers wont pair as neighbor. This issue is not easy to solve, and would break the compatibility with other OSPF implementations, thus, together with my mentor we decided to change the project on something that we could accomplish in the remaining time and that was still helpful for Wireless Communities.

Since many WCNs in Europe are still using OLSRv1 we’ve decided to implement PopRouting on it. The NetJSON plugin[1] is already available so we only had to implement the Timer’s plugin and the PRINCE plugin to communicate with it.

During this mont I’ve implemented and alpha version of the Pop-Routing plugin[2] for OLSRd. This plugin is quite simple, it listens to a specified port and it parse two commands : “/HelloTimer=xx.yy” and “/TcTimer=xx.yy”, where xx.yy are floating point numbers.

I’ve also implemented the Prince plugin[3] that communicate with OLSRd. It fetches the topology from the NetJSON plugin and it pushes the updated timers to the PopRouting Plugin.

The next month I am going to fix all the bugs I found, document the plugins and test Pop-Routing with NEPA test.

Despite those problems the implementation of NetJSON for OSPF is working and we hope it will be merged in the BIRD codebase soon.

Cheers, Gabriel

[1]: https://github.com/OLSR/olsrd/tree/master/lib/netjson
[2]: https://github.com/AdvancedNetworkingSystems/olsrd/tree/poprouting/lib/poprouting
[3]: https://github.com/AdvancedNetworkingSystems/poprouting/blob/refactor_ospf/prince/src/olsr/olsr.c

GSoC: Improving nodewatcher data representation capability (update 3)

Posted on by rasovica

I have been working on improving the wlan-slo main page. This page has not been updated in a long time and it is crucial at introducing new people to mesh networking.

Continue reading “GSoC: Improving nodewatcher data representation capability (update 3)” →

GSoC 2017-netjsongraph.js milestone 2

Posted on by GeekPlux

After a month of efforts, netjsongraph.js has been greatly improved.
First, I added some API and options are compatible with previous versions, except those that can not be added to the WebGL element. Followed by updating the documentation and some examples so that users can better understand and try out our projects. Finally, I have optimized interaction and performance.

netjsongraph dark theme
netjsongraph dark theme

Interaction

  • added highlight effect on nodes and links when hovered.
  • added tooltips with node information
  • added pan and zoom interaction
  • added node and link information panel when clicked
  • adjust the size of the canvas when the window resized

Performance

The large part of the performance of force-directed layout is consumed in each element position calculation in every tick. So if the position calculation of the elements is before canvas rendering, it is effective to reduce the performance loss.
So I made a static layout https://github.com/netjson/netjsongraph.js/issues/44, there is no animation when rendering, directly render a static force-directed layout in the page.

Other

Besides, I have refactored the event controller, in order to make zoom and pan or other events added easily.
But now the overall rendering results are not good as our expected. There is a little lag in animation, I currently have no idea about the reason, perhaps because this is not best practice of three.js. In the next stage, I will focus on solving performance problems and improving the visual effect.

Next Plan

The links below may be useful:

  • http://taligarsiel.com/Projects/howbrowserswork1.htm
  • http://igoro.com/archive/what-really-happens-when-you-navigate-to-a-url/
  • https://github.com/alex/what-happens-when
  • https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
​

GSoC 2017 – Add MPTCP support in LEDE/OpenWRT trunk – July progress

Posted on by Fejes Ferenc

What we have so far

After lots of experiments, I figured out the way which enables the transparent MPTCP operation for both the client and the server (with the regular kernel).
I tested the configurations at my virtualized environment, check the video below. For configuration infos, please read the video description. (the post continues)

Continue reading “GSoC 2017 – Add MPTCP support in LEDE/OpenWRT trunk – July progress” →

geolocator-software-defined-gps-second-evaluation

Posted on by buttjantarek@googlemail.com
Hi everyone,

 

I am now taking you over my second evaluation. A German version of this blog post can be found here [0]. For people who did not read over the geolocator (Software defined GPS) project before, here is a link to the project introducing (english)[1] and (german)[2]. The first evaluation from last month can be found here (english)[3] and (german)[4]. First of all I would like to tell you about the web backend:

 

Web Backend

As I said it in the blogpost before, the new web backend should replace the old one.
The current openwifi.su web backend consists of a collection of different programs in different programlanguages. The new one is written in Golang it has a fully backward compatibility. The new web backend is more secure.  It checks all requested strings at the end of the url that they contain only comma separated macaddresses with 12 hex characters, as a validation check.

 

Also the new web backend fix an issue by calculating the requested position. The method before just adds all latitude values and devides them over the amount of positions. Same for longitude. The new way is a geographic midpoint calculation. First the lat/lon values will be converted into radius and then the radius will be converted into a Cartesian coordinate system, after that the midpoint calculation will be done and will gave us a lat/lon in the form of radius and the values will be converted back into degrees, that is all.

 

The web backend has a new feature which should help to enhance the position quality. If there are BSSIDs unknown in the database of openwifi.su, the new backend sends an extra request for the unknown BSSIDs to Moziller location service [5] and brings that information into the calculation of the response.

 

At the moment the new web backend is being tested. In the next few days a first version of the new web backend will be released. The current code can be found here [6].

 

LEDE Package

The last project is to build packages for LEDE and send merge requests to Gluon. The idea behind that is, for WiFi routers and other WiFi devices to be able to automatically receive their own position. This could be a nice feature for mobile Freifunk Routers. It could also provide a good alternative instead of setting positions by hand. A first version of that package is here [7].

 

For the integration in Gluon I plan 4 new packages. The first one is the gluon-geolocator, which depends on gluon-node-info and provides the programme with the capability of receiving geopositions based on surrounding WiFis.

 

The next 3 packages are just for the Gluon configmode. The configmode is a state that begins at the initial start of a Gluon router and the owner of that router can configure it over a LAN connection.
I would like to integrate the following 3 packages within the gluon-config-mode-geo-location.
They are named:
gluon-config-mode-geo-location-with-geloc-map,
gluon-config-mode-geo-location-with-geloc,
gluon-config-mode-geo-location-with-map

 

As their names indicate, the package gluon-config-mode-geo-location-with-geloc-map should integrate the options of the geolocator and an OSM map into the configmode. The other 2 packages, gluon-config-mode-geo-location-with-map and gluon-config-mode-geo-location-with-geloc should either integrate only an OSM map or just the configuration options of the geolocator. Also the package gluon-config-mode-geo-location should be able to and will show the current location interface without any map or geolocator.

 

A merge request of the above new packages will follow soon. Some of the gluon-config-mode-geo-location extensions are currently not finish yet.

 

In the next few weeks I would like to finish the integration into Gluon, as well as continuing to develop the new web backend and releasing the first version of it. There are many ToDo points currently open e.g. Multicore functionality, optionally other geographic midpoint calculations. At the beginning of August there is the SHA2017[8], which I will use for a marathon session.

 

With best wishes
Jan-Tarek Butt

 

GSoC 2017 – Milestone 2

Posted on by ArneKappen

Following the rather stark change of direction after the last milestone (see my last post), I have worked on the integration of my project with Johannes Wegener’s: OpenWifi.

July Progress

For my software-defined networking (SDN) agent, I have added support for configuration through a UCI config file as well as process management through procd. This ties the daemon in neatly with the LEDE/OpenWRT system. Now, parameters such as the SDN controller’s address are read from this file and the configuration can be reloaded at runtime without stopping the agent.
Using the UCI system also exposes the configuration parameters to Johannes’ OpenWifi system. He and I discussed the bootstrapping process with our mentor and we have come up with the following idea: When a newly installed LEDE/OpenWRT access point first boots, it discovers the OpenWifi server via mDNS and fetches its configuration from it. With the address contained in the configuration, my SDN agent on the access point is able to connect to the SDN controller and thus integrate automatically with an existing centrally managed deployment. In the event of a configuration parameter change (e.g. a switch to a different SDN controller), OpenWifi can trigger a configuration reload to quickly update all access points in the network.

On the controller side, I have implemented a REST client to interface with OpenWifi. Through it, the controller can register with the OpenWifi server. During the registration, it installs its address and OpenFlow listening port in the UCI configuration which later gets sent to access points.
I have also begun writing a REST interface for my controller to offer more comfortable management of SDN applications and the network state. Right now, I can query the controller about its resources: access points, switches and clients. With the basics in place, expanding the interface to expose more SDN functionality should be pretty straightforward.

Next Steps

During the final part of this year’s GSoC, I want to focus on adding functionality, testing and documentation. I will spend the remaining weeks of the project like this:
1) write an SDN application
2) expose the app’s functionality via the controller’s command-line and REST interfaces
3) test it on the university department’s testbed
4) document its usage
5) goto 1)

Since the foundation for the SDN applications is in place and running, I am optimistic about getting a lot done during August. I will start with a client hearing map that keeps track of associated and unassociated clients in the vicinity of the deployment’s access points. Leveraging the hearing map, I want to implement a client load balancer that distributes associated clients evenly across available access points. I will also look into automated channel selection to avoid interference between neighbouring access points.
Finally, I would like to wrap up the controller in a docker image for easy deployment.

Luci2 on Libremesh – July

Posted on by Marcos Gutierrez

At the moment the development of luci2 is found rethinking some decisions and advancing in others. The thread of the discussion can be seen in
https://github.com/jow-/luci-ng/pull/42 mainly pushed by @ianchi and commented on by @jow.
For my part I started looking for a mid-point between the LiMe App (developed in preact for LibreMesh) and Luci2. At this moment LiMe App uses orangerpcd in the backend and the same api is being migrated to be consumed from ubus.
The plug-in test for “luci2” in preact can be seen at https://github.com/gmarcos87/preact-luci, although the main development will continue from now on in Agular, but trying to maintain an aprouch where views/apps are Completely defined in json.
I hope to get to the next post with the libremesh api on ubus ready to be consumed by Luci2, whatever their final destination.