SWOON: Simultaneous Wireless Organic Optimization within Nodewatcher

Hi everyone,

I will contribute to one of the Freifunk projects; nodewatcher, via Google Summer of Code this summer and I wanted to keep you updated on my progress as well as exchange thoughts about my ideas.

First of all, nodewatcher is an open source, modular community oriented platform used for network planning, node deployment, node monitoring and maintenance. nodewatcher was initially developed to be primarily used by the wlan slovenija project. With 1336 nodes, it’s really successful and a great example for community networks. As nodewatcher gets deployed elsewhere with even more nodes, it’s natural to ask ourselves if we can be smarter about allocating spectrum to our wireless nodes – these nodes are mostly inexpensive wireless routers but it’s natural to extend the meaning of the term to dedicated wireless access points (i.e. Unifi AP).

The theoretical foundation for this problem is fascinating by itself: Each node has a different amount of noise in each channel (the 2.4GHz band allows 3 non-overlapping channels where each channel is 20MHz wide) and each node wants to maximize its SNR (signal-to-noise ratio). I will term this as the greedy approach, which is already used in enterprise level devices. However, in an urban setting, nodes are close enough to each other for their signal to act as noise to other nodes. The greedy approach is no longer optimal as it bears a high price of anarchy. Instead, our goal is now to maximize the sum of channel capacities (under a power constraint). I will have to devise an algorithm to solve this problem and the algorithm does not seem trivial since the number of combinations is increasing exponentially with the number of nodes in the system. Even with only 10 nodes, we haveover 59000 possible allocations on 2.4GHz band and over 95 trillion on the 5GHz band.

Traditional networking literature tackles this optimization problem with Lagrange multipliers. An alternative is to look at approximate graph coloring schemes and compute chromatic numbers. I hope to experiment across various settings and approaches.
Over the course of the project, I hope to experiment with a real network which consists of at least 10 nodes and measure the improvements. One exciting thing about real life experiments is that nodewatcher was mostly used inside wlan slovenija’s network and I get to run it independently! This will probably allow me to fix some bugs on the way and contribute to nodewatcher in this aspect as well.

The algorithm will initally be developed as a nodewatcher module, but I hope to eventually port it to openwrt (possibly after the summer ends). The main difficulty is that nodewatcher can act as a central level planner, whereas the openwrt scenario requires negotiation among nodes. So it’s harder to convince a node to decrease its TX power to benefit other users. But imagine a network where nodes can communicate and achieve a socially optimal point of spectrum allocation! A glorious future awaits us.

Provide a cryptographic implementation for Qaul.net

Hey there,

my name is Katharina (aka spacekookie) and I am one of the Google Summer of Code participants for Freifunk projects; qaul.net in particular.

I wanted to write up a short article on what it is I will be doing this summer, how I will do it and what I hope to achieve. This will be one of three articles published on this blog.

Qaul.net provides a mesh-wifi network for people to connect and share information to other people on the network. Like freifunk it uses the OLSR mesh routing library. But unlike freifunk it’s main goal isn’t to connect to the www-internet but rather create a network of it’s own on which people can communicate, share data and come together. No centralised infrastructure required.

Currently all traffic on qaul.net is sent in the clear which is…suboptimal. For one nothing said on the network is in any sense of the word “private”. On the other there is no way to verify identities. And that’s what my Summer of Code project is about.

The changes to the qaul.net code base required are quite extensive but with a bit of clever planning shouldn’t break too many things. The core thing required is an abstraction layer between user and network.

Currently a user gives their node a nickname and that’s then them. “Identify verification” (if you want to call it that Tongue Out) is done by checking IP addresses against nick-names. Man in the middle attacks are very easy in such a network and the only defense is the benevolence of its users.

What I thus plan to do is introduce an abstraction layer between a node, routing and what a user sees. A “user identity” which can be shared between different nodes (but doesn’t have to be), something that can be written to an addressbook and is later on verifiably the same and will make users aware if their are being man-in-the-middled, which is now much easier to verify.

In addition to that I plan to introduce asymmetric encryted messages, completely transparent to the user. While qaul.net can flood a message acress the network that should be seen by as many people as possible, there should be the ability for two people on the network to talk to each other without anybody else knowing what they’re talking about.

What’s planned is something that resembles PGP. A users identify will be their master-private key fingerprint. From that each node gets a subkey-pair (public and private). The public key will be flooded into the network for people to use to write messages to that node. The private will be unique to the node. And when sending messages to another person people can either choose “all” which means that the messages is encrypted against all (non-revoked) public keys of the target identity or choose a specific node to talk to. This implementation also allows for mailing list style group discussions.

 

Through Google Summer of Code I hope to become a regular contributer to qaul.net as I am a big fan of the project ideas. I also hope that my contributions will make it a much safer place to communicate and share information on.

As already mentioned I will be updating this blog two more times: one around the half-way point of the project and one as a wrap-up of how it all went.

If you’re interested in reading more of my insane ramblings about the project, maybe micro updates and what not, check out my personal blog https://spacekookie.de or go directly to the GSOC category.

 

Until another day,

Katharina/ spacekookie

 

Freifunk beim Google Summer of Code

Google nutzt für viele seiner Dienste OpenSource-Software. Mit dem Google Summer of Code möchte sich Google bei der OpenSource-Gemeinde bedanken und fördert Studenten für ein von Mai bis August laufendes Projekt mit 5500 US$ – in diesem Jahr über 1100 Studenten aus aller Welt.

Im Jahr 2014 nahm Freifunk wieder am Google Summer of Code teil. Freifunk integriert dabei als Dachorganisation weltweit Initiativen wie guifi.net, ninux.org, wlan slovenija und LibreMesh aus Argentinien. Wir bekamen in diesem Jahr 9 Slots für Projekte, die Studenten in Deutschland, Frankreich, Italien, Spanien und Slowenien bearbeiteten. Die Projekte beschäftigten sich u.a. mit der Freifunk-API, Netzwerkprotokollen und Software zum Communitymanagement. Im Freifunkblog können Details zu den Projekten nachgelesen werden.

Den Abschluss des diesjährigen Google Summer of Code bildete der Mentors Summit, zu dem jede Organisation zwei Mentoren entsenden darf. Zur Feier des 10-jährige Bestehens waren auch Teilnehmer aus den vergangegen Jahren eingeladen und der Summit wurde um einen Tag verlängert.

Freifunk fun in USA

Auf dem Programm stand auch ein Ausflug, wo wir das echte Amerika kennenlernten und gemeinsam mit Teilnehmern aus China und Vietnam Basketball trainierten.

Mehr als 600 Teilnehmer aus aller Welt trafen sich in San Jose, Kalifornien, und wir hatten die Chance uns über unsere Projekte auszutauschen, neue Kontakte zu knüpfen und nicht zuletzt den 10. Google Summer of Code zu feiern. Als Überraschungsgast zum Jubiläumsempfang war Linus Torvalds geladen. In einem Treffen hatten wir die Gelegenheit, mit ihm über Freifunk zu sprechen.

Ideen für Projekte im Jahr 2015 können schon jetzt im Wiki eingetragen werden. Falls ihr Kontakte zu Universitäten oder Fachhochschulen habt, sprecht mit Dozenten, Studenten oder Lehrstuhlinhabern, um Unterstützung für Projekte im Sommersemester 2015 zu bekommen.

Links

Projektideen http://wiki.freifunk.net/Ideas

Fotos zum Mentor Summit: https://www.flickr.com/search/?tags=gsoc14

Linus Torvalds and Dirk Hohndel meetup with Freifunk Community at Google Reunion

Freifunk attendees had the chance to discuss Community Networks with Linus Torvalds and Dirk Hohndel from Intel at the Google Mentor Summit. Linus said, it was impressive to see the growth of community networks around the world and it is exciting to see so many people working on Linux for embedded devices.

Linus Torvalds, Mario Behling, Federico Capoano, Freifunk, Google Summer of Code

GSoC: Work on Freifunk API Query Client will go on

This is the final blogpost for my GSoC project for the Freifunk-API Query Client.

Goals
 
We want a comfortable tool to query all the Freifunk API files as there are nearly 100 communities all over Germany providing their data. There are already several applications like our community map, a common calendar, our feed aggrator or the community podcast collector. But it’s still hard to find communities by properties like routing protocols or focus topics.
 
Challenges
 
When we began this project we only planned to query the generated JSON data for the community in a browser and additionally provide query results via a webservice. But then we talked to several people and we heard about DeepaMehta with features like connectors to OpenStreetmap. So we did something what you don’t do normally: We changed our project goals before the midterm evaluations.
 
DeepaMehta is not just another database product, it provides a different way to store and handle data. It uses a graph to store connections between items and allows to modex complex datatypes and associations between them. We had to change our mind and had to learn a new kind of thinking. The API data is constantly evolving and changing and there a lot of cross-references in the data e.g. links to various nodemaps. We think the switch to DeepaMehta is useful because we can query the graph and add new relations and data without problems.

 
It’s difficult to handle different spec versions if you want to query all API files, because some fields changed, other fields were added to the specs or got another meaning. In an ideal world all communities update their files as soon as possible. But we all know, it will never happen like that. As a workaround we first focused on less fields, available in all versions.
 
What we got
 
We’re able to import communities from the API directory as a base entity. We also tried some different ways to import and store the specs, but we need some improvements here. By using the summarized API file, the import of our payload can be done via the DeepaMehta REST API.

The switch to DeepaMehta brought a lot of complexity to the project and I’m personally not happy my results at this point because I had trouble to spend enough time for the project. Additionally some basic problems like dealing with changing schema and data import are not really solved well at this point. The data is in DeepaMehta and can be queries with the included client but it’s not in a state where it’s usable for the community.

Overall the GSoC was an interesting experience for me. Through I’ve failed to set aside enough time for the tasks. The timely overlap with university lectures does not make it easier. So I can only recommend to know beforehand that you’ll have enough time to accomplish your goals. But the support from the Freifunk community was always great and helpful! As the project is not a state that can be considered ‘ready’ I’m continuing working on it.
 
Future Plans

I definitly want to finish the work at least to point where it can be used by the wider Freifunk community.

The default DeepaMehta client isn’t designated to query a lot of fields like our API provides. Here we need a new web based client to provide users an interface to select fields and get a proper response.

Work will continue on integrating the API data and DeepaMehta.

Repository: https://github.com/freifunk/query.api.freifunk.net

Final Blog Post: Netengine

Hi everybody, this is going to be my last blog post as a participant of GSOC2014. I’m very sad about this, those have been very hard worked months but very formative.

I improved both my coding skills but above all I have earned a work methodology thanks to my mentor Federico, who said to me to be more reflexive and to be more precise in what I do.

I have learnt some aspect of versioning (Git) I ignored before and learned much more on Python than I did by myself.

This is the “change log” of the last time period of the program: we developed a new backend, the HTTP backend. It aims to retrieve informations from the web admin interface of AirOS devices, that’s why we called it HTTP.

We wrote documentation about all the project, describing all the things an user should do both to contribute or use Netengine, trying to be as much more clear and to make it simpler as we could.

Unfortunately this is my last year as a student, no PhD on my way (for now), so I will not be eligible at all for next editions coming.

Greetings and thanks: I would like to thank Ninux , the community network I’ve worked with. I’ve had the possibility of joining their meetings, to talk a lot with every member and to be supported every time I had some problem about what I was doing.
Obviously my mentor Federico Capoano, Mario Behling from Freifunk who supervised projects.

For further questions on the project please visit https://github.com/ninuxorg/netengine or email us at ninuxdev@ml.ninux.org or read the docs!

GSoC 2014 Final – OpenWrt: IEEE 802.1ad VLAN support

Hi all!

Because I have worked very hard in the first part of GSoC, the implementation was almost done already for mid term, in the second part I have been mostly testing the code, and taking advantage of it in a lot of setups 🙂

The GSoC experience have been very formative to me and I would like to repeat it next year either as student or mentor 🙂

Moreover I’ll suggests to apply to GSoC to a lot of friends!

Many thanks to Freifunk to chose my proposal I hope you will take advantage of 802.1ad too 🙂

Cheers!

GSoC 2014: Hardware Detection [ Final ]

 

Hi everyone!

I am very happy to have participated do GSoC 2014, this experience have permitted to me to learn a lot about opensorce comminity and programming, i have learned also Lua programming language, while it seemed a little ugly  to me in the firsts times I ended up loving it.

This GSoC project permits to people installing Libre-Mesh on their devices and have device specific quirks already solved by the hardware detection module, without user intervention, while it permits to developers to write little modules to easly supports new hardwares and solve their quirks.

In particular in the second part of my GSoC I have improved hardware detection, in particular I have created a module to autoconfigure TL-WDR3600 and a module that permits to Libre-Mesh to detect wan port of a lot of routers taking advantage of the OpenWRT infrastructure.

While creating those new modules I have also realized how to improve general Libre-Mesh infrastructure and committed various improvement to the hardware-detection branch, that is now in the official repository ready for merging in develop branch.

Futhermore, during the last phase of this project I have optimized the code including modules I have written in the first period like usbradio detection module. 

Obviously all this work have been possible thank to the help of the community that helped me in the whole coding period.

Best Regards 😉

GSoC: nodewatcher v3

Hello all!

Thanks to this year’s GSoC, a lot of work has been done on nodewatcher v3 platform. It now has a better, modular monitoring agent that can run on OpenWrt-supported devices, with a new JSON-based output format that can be easily reused by other projects as well. The platform has been ported to the latest stable version of Django (1.6) together with all migrations and dependencies. Development environment setup now uses Docker and fig in order to make it very easy to dive into the code without having to battle with various dependencies.

The API for access to node configuration and monitoring data (registry API) has been much improved, with better, more usable querying capabilities and performance. During development we have discovered a bug with cascade deletions and  polymorphic models in Django. Node configuration editor based on the registry API now supports references between form models that have not yet been saved — this functionality enables configuration of bridge interfaces which are now also supported by the firmware generator. I have implemented type support in the datastream library for long-term monitoring data storage with a new type for storing graphs as datapoints. This enables nodewatcher v3 to use datastream to store how the network topology evolves over time.

All the code is available on GitHub in several repositories:

GSoC: Retroshare social network plugin review and future

During Google Summer of Code i did these things:
– learn what users expect from a social network. Figure out who should receive which messages.
– map social network functions on the existing Retroshare General Exchange System
– build a backend with basic features
– build a frontend with basic features
– started a new programming interface on top of libretroshare: a JSON over http interface

The Secushare homepage says: “RetroShare should provide more social functionality” Indeed! Every country is spying on their citizens. Storage, computing power and bandwidth became cheap. These are good conditions to build a distributed social network. The first step was already started a while ago with the General Exchange System for Retroshare v0.6. This project is the second step in this direction. One thing is missing: a release for normal users.

The backend and frontend made during GSoC can display a wall with avatar image and profile text. It is possible to create posts and reference them on walls. Posts can be commented. Read more details in the previous blog post. Still it is not suitable for daily use. There was not enough time to implement a scalable user interface architecture. The web interface can’t handle more than 100 posts, because pagination is missing. Whats more the UI is filled iterative. This causes many updates to the html tree with high cpu load. It would be better to send all information to the browser in one piece. The browser would then only have to update the HTML tree once. The design and layout should be improved to highlight the content and to get the date label out the way. (See the this screenshot.)

Future

Wt is nice because it allows to make a web interface without touching HTML JavaScript and CSS. But this is only the half truth. There where issues:
– completely destroyed layout by setting the image size
– menu bar was horizontal instead of vertical, this required to manual set a style class from C++
– WTimer stops working. I had to build my own server side timer

These issues where solvable. A real pain with Wt is the layout and UI design testing. You first have to go through the complete compile and start cycle to see changes. What if you missed a closing tag in a HTML template? You have to recompile and restart. Now i saw that with real web technologies you can see a live preview while you type. I think when doing layout and design it is important to immediately see the result. This is not possible with Wt. Conclusion: you can build a web interface with C++. But hard coding CSS class names and embedding HTML snippets in C++ is a pain that should be avoided.

On the other hand there exist advanced tools and frameworks for web development. AngularJS is a very nice JavaScript library. It offers data binding from JavaScript to HTML: you update a JavaScript object, and Angular updates the HTML. JavaScript objects are more flexible than C++ objects. You can even make a JavaScript object out of a JSON file. Angular makes handling of button clicks easy. AngularJS makes  Bootstrap offers a set of widgets with HTML example code and style sheets. Now i want to use other web frameworks instead of Wt.

I did not know about these web technologies when starting the project. This is some sort of a chicken-egg problem: Retroshare does not have web developers, because it doesn’t have a web interface. And there will be no web interface until a web developer can show how it can be done. Gladly there is now a web developer who can teach me how to make a web interface.

The new idea: make a web interface using web technologies

The next goal is to make a clean and easy to use JSON over HTTP api for Retroshare. Then web developers are free to make a nice web interface using their favorite frameworks. This api is not only useful for web interfaces, but also for scripting. You could then send a chat message from a shell script using curl:

curl -X PUT -d ‘{“msg”:”hi all<br/>(send from bash)”}’ http://localhost:9090/api/chatlobbies/<id>

What i will do now
I will do more research for a JSON over HTTP interface for Retroshare and rssocialnet. If this stays a good idea i want to implements it. Maybe i will try to start a new web interface. But i hope someone else is faster than me. I prefer to work on the rssocialnet backend and libretroshare. Whats more a web interface is a perfect place for new contributors. If i would make a clearly documented JSON over HTTP api, then a web developer would not need C++ knowledge or experience with libretroshare.

A dream is to bring Retroshare to Android. This is possible, but we have to make a new touch-friendly user interface and we have to optimize Retroshare to make it more battery friendly. I currently see two ways to build a GUI for Android: with QML/QtQuick or HTML based with the Ionic Framework. There is already a QML prototype.

To get rssocialnet ready for daily use, i need your help. Unfortunately I’m again in a research/planning phase. This means I’m not sure how the JSON over HTTP interface will look at the end. It also means if you tell me “i want to help coding”, i have to disappoint you because i don’t know what we have to code and how to code it. Anyway, here are some things you can think about:

– which features are important for a social network? read some ideas
– can you make a better gui mockup than me?
– which frontend technologie should be used? QML/QtQuick or Bootstrap and AngularJS?
– what are the requirements for a first release?
– how can you use your skills to help?

Thank you Freifunk and other mesh network communities for donating one GSoC slot to Retroshare. This was a good decision, it made it possible to start a mesh friendly social network application.