Tag: GSoC2014

GSoC : Source-Sensitive Routing

Posted on by Olden Fabre

The first weeks of my Google Summer of Code project were a little complicated, as I still had exams at university, and I was not really aware of what mesh networks were about.  I also needed a little time to get to know network and routing better, both pratically and theorotically.

At the beginning, in order to understand quagga and babeld, Iread a lot of documentation on the routing topic including theoretical papers and some RFCs, while also browsing the code of both babeld and quagga.

On the other hand, I have been able to experiment mesh routing with the mesh network available at university.  In order to use that network from home, and being able to test my programs at all time, I also established a VPN connection between university and my home computer. By doing so, I can connect to the university’s babel network at any time. I have also been able to understand the functionning of quagga and zebra and to install source-sensitive static routes on a mesh network.

After having spent much time reading the codes of babel, quagga, and babel in quagga, I achieved to use the zebra’s API in babeld and began to add support for source-sensitive routing in babeld. Currently, my code runs and segfaults proudly ! I hope to see the first results of source-sensitive routing with my version of babel, in the worst case, at the end of the week.

At first, my goals were not really clear, but now, I have precise objectives on the short, middle, and long term.  In brief, my short term objectives would be to get a source-sensitive routing Babel running by the end of the week.  After getting a working version of Babel source sensitive, I will implement the same work in RIPng. RIPng is a quite simple protocol and Juliusz and Matthieu told
me it would be a good idea to offer it source-sensitive routing.  And finally, after everything will be tested and running fine, I will be implementing the source-sensitive commands in Babel.  Then, I will complete the documentation about my work. And in the end, the ultimate goal would be to be included in the official repository of Quagga.

If you want more details about the work I did, you can read my blog here : http://ariane.wifi.pps.univ-paris-diderot.fr/~olden/. I posted an entry every week to keep you informed of the progress on the short term. 

GSoC: Retroshare social network plugin compared with Retroshare forums

Posted on by Tillmann Gansky

In the last post i wrote about the decentralized structure of Retroshare. I said: similar features to Facebook are also possible in a decentralized manner. Now let’s have a closer look at those features.

Communication tools have the purpose to take a piece of information and transmit it. The question is who should receive it, when will it be received and to which next hop should the information be send.

Very simple forms of communcation are one to one messages. We have a clearly defined receiver which can be adresse by a RSA public key. This is very simple if we are directly connected to the receiver. If the receiver is not a direct neigbor, then Retroshare uses it’s distant tunnels. Current distant chat and distant messages only work when sender and receiver are online at the same time. Retroshare v0.6 will cache messages on neighbor nodes to deliver them when the receiver is online.

Retroshare can also do many to many communication. The Chatlobbies are for real time communication. If you don’t receive the message a few minutes after it was send you will never receive it. Messages are send to all neighbors in the chatlobby. RS keeps messages for a few minutes to prevent echos. Forums and channels offer persistant messages. This means messages are kept for a year in forums and a month in channels. The messages are not targeted at a person, but they belong to a context. This context is a chatlobby or a forum/channel. Users have to subscribe to the context.

Every message is bound to the context. It appears only at one place. In Retroshare forums and channels the context is a topic like “Developer’s Discussion” or “RetroShare Windows builds by Thunder”. In the social network plugin the posts are decoupled from a context. The context only stores a reference to the post. This allows posts to appear at different places. For example: a post can appear on the walls of user A and user B. And if i see the post and like it, i can forward it to my wall. Forwarding of specific posts only, increases the quality of the received content.

With forums and channels you first have to subscribe to them. Retroshare will then download the posts in it. The social network plugin automatically downloads the posts your friends like. And if your friends like it, then the probability is high that you also like it.

While forums are about a topic, a social network wall is about the user. It is a personal place where you can leave message for your friends, and your friends can leave messages for you. Still your are not limited to own content. If you want to share existing posts with your friends, just put it onto your wall.

Scope of the GSoC project
The goal of the GSoC project is to make a basic wall service. This includes the backend for message processing and the user interface. Chat and private messages are not planned for GSoC. But this is something that is very easy to add later.

Internally the social network plugin is based on the new Retroshare General Exchange System(GXS). GXS has two basic data structures: gxs-groups and gxs-messages. A gxs-message belongs to a gxs-group. If a gxs-group is marked as subscribed, then all messages in this group are downloaded. In the gxs-forums this mechanism is clearly visible to the user: gxs-groups are downloaded automatically, but the user has to subscribe to download the contained gxs-messages. The posts in the social network plugin should be independent. This requires that every root-post has its own gxs-group. The wall services automatically subscribes to interesting gxs-groups. Gxs-groups can be interesting because:
– the posts appears on a wall of a friend
– the user follows the author of the post or the user is friend with the author
– a friend made a comment on this post

So the interesting content is not defined by a forum title, but by the way friends interact with it.

GSoC 2014: Hardware Detection

Posted on by Francisco Jiménez González

Hi everyone!

Before  starting coding I have been studying Lua programming language I read  some tutorials and I did some practical examples. After that, I went to  the Libre-Mesh architecture to understand better how it is done. When I  understood the programming pattern of LiMe I started coding.

First of all, I started creating a plug-in module for ath9k-htc based hardware. This module has been tested using a TP-LINK WDR3600 and two TL-WN722N USB radios. While working I have included an hotplug hook so the usb radios can be dynamically plugged and removed from the system while it’s running. 

After  having the usbradio module almost done I have been working creating a  modular hardware detection plug-in for Libre-Mesh. This hardware  detection module have been completed with clean and configure functions. During the development of this part I have discovered some bugs in the file config.lua and I have solved it.

Currently, after doing some cleaning and debugging both modules are almost finished.

Obviously  all this work have been possible thank to the help of the community and  I hope to do my best during the rest of the coding period.

I will be happy to receive feedback or tips

Best Regards 😉

GSoC 2014 Updates – OpenWrt: IEEE 802.1ad VLAN support

Posted on by Gioacchino Mazzurco
As promised I have been working hard on the proposal. Thanks to community help I have already almost completed all deliverables and in fact some patches got merged in netifd [10-13] and OpenWrt [15] already and development branch of libre-mesh is already taking advantage of them [14] 🙂
 
Working on this project gave me more conviction that community collaboration is fundamental, community helped me to understand the problem and what to modify to fix it, moreover someone went beyond that submitting patches too [16-17] !
 
Here it goes a small resume of how I did it:
    – Talk multiple time with OpenWRT [0] folks via retroshare openwrt lobby, they gave me some indication on what I had to do
    – Get netifd code [18]
    – Create a vlandev netifd device
    – Implement routines to add and remove 802.1ad/802.1q vlan in Linux via netlink
    – Talk with OpenWRT folks for quality check and patch merging
    – Code cleaning and testing
    – Patches get merged in netifd and OpenWRT
 
Now who need to use 802.1ad is not unfortunately constrained to private software anymore, because it is now supported in OpenWRT [0] 😀
 
More updates [6] soon, and don’t forget the best is yet to come! 
 

GSoC: Social network plugin for Retroshare

Posted on by Tillmann Gansky

Retroshare is a communication tool build on two principles: decentralisation and privacy (Read more about the ideals behind Retroshare). Decentralisation means there is no central server. It also leads to privacy, because Retroshare runs on your own devices. Retroshare gives you the cryptographic tools to control who exactly can access your data. Privacy is enabled by encrypting all data which goes over the wire. Read Cryptography and Security in Retroshare for details.


Figure 1: Retroshare is a decentralized network.

Commercial social networks like Facebook have opposite properties: they are centralized and all data is visible to one company. The good news is: similar features to Facebook are also possible in a decentralized manner. The plan is to build this as a plugin for Retroshare. Always having decentralisation and privacy in mind, while offering a very similar interface with a similar feature set.


Figure 2: Sketch of the user interface.

Unlike other peer-to-peer software, Retroshare connects only to a set of trusted friends. This has some practical advantages, for example you don’t have to fear malicious peers. It still scales nicely, because friends tend to gather the same type of data.
But often you want to reach content that was not created by your direct friends. Or you want to contact someone because you are not friends yet. For this Retroshare offers another layer which i call the service layer. At first a service can send messages to direct neighbors only. But if it receives a data packet it can also forward it to a friend. This is how you can reach friends of friends. This philosophy has been applied to multiple information sharing algorithms within Retroshare. Read more about them in the following articles on the Retroshare team blog: Retroshare Forums, Distributed chat(a.k.a. Chat Lobbies), RetroShare’s anonymous routing model and Distant chat and messaging, using generic tunnels.


Figure 3: Retroshare forwards messages from friend to friend

On the neighbor Layer, you have to add your friends keys to your keyring by hand. But this is not a problem in practice, because the number of direct friends is small and Retroshare offers various options to get to know neighbor nodes one hop away. On the service layer you want to have the public keys of people many hops away. In Retroshare v0.6 there is a identity exchange system, which downloads public keys at the same time it receives a post from a unknown author. The identity exchange system can also work decoupled from the neighbor layer. This allows us to have pseudonymous identities. These identities can be used for different kinds of services like chat, mail, forums and the new social network plugin.

Retroshare is a steadily grown project, so the developers gained a lot of experience. Out of this they developed new systems to distribute messages in a Retroshare network (short name is gxs for General Exchange System). So all the complex code for doing the signing, verification, encryption and decryption of data is already done and avaliable. During the Summer of Code i will wrap this complex stuff in a nice webbased user interface. The RSWebUI Plugin is a starting point. It uses Wt, which is a library to create a webinterface with C++, without writing own code in web languages. You can watch the development in the git repository.

Read the next blog post to learn what features the social network plugin will have and how it will work in details.

Download Retroshare: http://retroshare.org

About me: i study electrical engineering. I first started programming to control hardware. I came to Retroshare because i wanted to chat securely without depending on a server. Then i started to dream about what else would be possible with a secured connection. So i started reading the code. Today i have enaugh knowlegde to contribute.

GSoC: Freifunk monitoring and administration panel

Posted on by Bagrat Ter-Akopyan

Trip to the Wireless Battle of the Mesh v7 Leipzig

Last week on Wednesday we took the bus from Weimar to Leipzig to the BattleMesh. An international convention with people working on wireless mesh routing protocols.

On late afternoon we arrived at Sublab. The hack-space in Weimar – ‘Maschinenraum’ – has a strong connection to the Sublab in Leipzig. One of the initiatiors of the Sublab was once part of the group of pioneers tinkering around with wireless technologies and free and open software years ago in Weimar.

So we know the Sublab from its early days on and tried to visit the space at least once a year. 

It was nice to see the space packed with so many international and very skilled people. Everybody was sharing ideas and answered a lot of questions we had regarding our google summer of code project.

About want we want to build and acomplished

Like many others we see the need for a remote monitoring and administration interface for WiFi nodes in a mesh network. A single person or a group have access (ssh keyring) to a nodes device statistics to monitor their health. The ‘admin’ can change config values or even re-flash a node or a group of nodes without the need to connect to every single router manually.

In a first draft we collected as many different device statistics as possible, like hostname, openwrt-version, hardware-model, uptime, memory etc. (Referred to as system data)
Configuration and statistics of network interfaces are another big blob of data we want to collect.
At the beginning we saw that many of our questions can be aswered via ‘uci’ calls, but some can not. We noticed that we can get native json output from network statistics, but for the rest of the data of interest we were unable to build proper json output. This was because of the missing support of json via jshn.sh / jshn and the complexity of Lua.

However while talking to the partitians of the BattleMash we were told about ubus. After discovering the abstraction caracteristic we decided to make as much ubus calls and avoid using community-specific shell scripts. All collected data will be processed by the monitoring-app writen in node.js which can run directly on supported routers or on a server or desktop pc.

We had a look at a lot of differnt software for monitoring a wireless community network, like http://www.weimarnetz.de/monitoring/, http://db.leipzig.freifunk.net/, http://blog.freifunk.net/tags/nodeshot
We also checked out some general network monitoring tools like rrdtool, bmon, vstat, mrtg and smokeping.

In the next couple of days we also want to take a look at the BattleMesh test scenarios – to see how to evaluate the health of the network.

Mockup freifunk Monitoring & Admin Panel

 

Right now we’re prototyping authification and establish data streams via ssh and ubus from monitoring server to 

destinated client. On the other hand we’re prototyping the interface of the app. It will be based around a visual representation of conneced nodes. Nodes with monitoring access provide additional data. Managed nodes allow for config changes and re-flashes directly from the apps interface. (check out the mockup)# Freifunk monitoring and administration panel.

GSoC: Freifunk API Query Client

Posted on by Martin Tippmann

Hi!

My GSoC Project for Freifunk is the development of a Query Client for the Freifunk API.

The Freifunk API is inspired by the so called “Space API” that is used by Hackerspaces all over the world.
It provides detailled information about every Freifunk Community and is intended to serve as a central place to aquire information and statistics about all Freifunk communities.

Freifunk communities can provide their data for the API using the generator.

The aim of my project is to provide a query browser for the API data to make the data for humans as well as machines more useful and accessible.

Possible usage examples are queries like:

– All contact mailinglists for all communities.
– Sum over all node numbers of all communites
– Show the name and webpage of all communities that use OLSR for routing.
– …

The API is defined using JSON-Schema. The current (0.3.0) version of the definition is here.

The query client will provide queries for the API data according to the specification.

It will be a JavaScript based web-application that loads the API files and returns results according to queries.

Besides that we plan to provide a server that provides results as JSON that can be used by routers or other machines or websites.

E.g. the current node count could be integrated in the website for the community via a simple Ajax-Request to the API.

A working prototype is planned to ready next week.

About Me: My name is Martin Tippmann. I’m a student at the Bauhaus Universität Weimar and I’m pursuing a degree in Computer Science for Media there.

 

 

Google Summer of Code – Source Sensitive Routing

Posted on by Olden Fabre

Hello everyone,

I am Olden, a master degree student at the Université Paris Diderot. After speaking with Juliusz Chroboczek, one of my teacher, he introduced me to his work on source sensitive routing and offered me to join the Freifunk community to implement it in Quagga. Under the direction of Matthieu Boutier, who has wrote the first implementation of source sensitive routing, I will be working on the integration of that procole in the next release of Quagga.

After discussing with David Lamparter, he informed me that he already implemented most of the necessary functions in Zebra and that the code will be pushed soon on their git repository. I will therefore be waiting a bit before modifying the Quagga code.

But my first aim will be to get used to the Quagga code and see how to include my modifications as easily as I can. I will therefore be waiting for the code of David Lamparter to be pushed on the git repository and then work on it.

During the time I will be waiting for that, I will read the code of Quagga and get used to it for around two weeks and then will be implementing source-sensitive routing into it. If my work is fully functioning, and if I get time afterwards, I will also be looking at the possibility of implementing the same algorithm in OSPF.

I don’t have for now a precise timeline concerning the work I will be doing on Quagga, but I will be posting on a regular basis the progress of my work on a blog. My git repository is not created yet, but I will be sharing its address with the one of my blog as soon as possible.

Thanks again Freifunk for taking me on this project, and see you soon for the beginning of my work !

Olden

GSoC2014 – BGP/Bird integration with OpenWRT and QMP

Posted on by Eloi Carbó Solé

This year, the Google Summer of Code and FreiFunk have given to Guifi.net and QMP communities the opportunity to develope a project in this event. This project is: BGP/Bird integration with OpenWRT and QMP.

 

A brief description of the project

Most of the community networks run dynamic routing protocols (OLSR, BMX6, BATMAN-ADV, etc.) with non-dynamic ones (BGP, OSPF, etc.). Guifi.net (BGP) and QMP (BMX6) are a scenario where this collision of metrics and routes happens. 

Furthermore, these communities are using Quagga for the BGP routing, which is a complex and oversized tool for the type of nodes that will work with it. For these kind of nodes, Bird is a really lightweight BGP daemon that is still not well supported to be used easily by the community (it does not have an easy and graphical configuration system yet).

 

This project will contribute with:

1st Block: Adapting Bird to fit into QMP firmware. (1 month)

  • Bird daemon improvements (3 weeks)
    • Give to Bird integration with OpenWRT: Add support for UCI configuration. Thus, will ease the configuring process and become closer to non-expert users.
    • Improve Bird UCI configuration adding LUCI support (web graphical interface). Adding a graphical user-friendly interface and the necessary tools to automate hardest processes of the configuration, non-expert community users could find this daemon as an easy to use routing tool.
  • Adapt Bird daemon to QMP (1 week)
    • Once working on OpenWRT and with an easy ‘to put on work’ configuration, add integration with the QMP firmware owing to replace Quagga’s routing functions in frontier nodes of the QMP network.

 

2n Block: Automate the translations of routes and metrics between a non-dynamic routing protocol and a dynamic one. (~2 months)

  • Creation of a routes and metrics exchange system (7 weeks)
    • Study and build an exchange system for metrics and routes between BGP (from Guifi.net) and BMX6 (from QMP).
    • Test and debug this solution in the real scenario (Guifi.net-QMP)

 

3rd Block: Project basic feedback and documentation (1 week)

  • Documentation, user support&feedback and results presentation.

 

About the author

I am Eloi Carbó, a Computer Science student specialized in Information Technology in the UPC of Barcelona. Currently I am working on my Final Degree dissertation: UPC CN-A testbed mesh network deployment, monitoring and validation. Using the Wibed Platform developed by the CONFINE Project [Link: https://wiki.confine-project.eu/wibed:start].

 

About the project collaborators

The project tutors are Roger Baig (fundació Guifi.net) and Axel Neumann (Freifunk and BMX6 support) and the special collaboration of Pau Escrich (fundació Guifi.net and QMP project).

OpenWrt: IEEE 802.1ad VLAN support

Posted on by Gioacchino Mazzurco

This is my first time as GSoC student and I am very glad to have been accepted in the Freifunk organization. I am a computer science student, therefore my life should be full of this kind of experiences, but unfortunately there are few possibilities to develop interesting applications and get a decent wage, due to the ever-increasing cuts in the sphere of research. The university offers several tedious unpaid apprenticeship with few learning value, generally works that machines are supposed to do instead of human beings. Moreover, the state of uncertainty that austerity politics ail people, kills their creativity. The GSoC wage, in addition to community help and fertile environment, will allow me to have some tranquillity and time to devote myself to think on creative ideas and implementing a long awaited feature in OpenWRT.

I have been hacktive in wireless community networks since years and I have seen a lot of situations where the use of the IEEE 802.1ad standard would make a drastic difference. Many times unlucky people were forced to use proprietary software because of the need for 802.1ad. An open implementation of this standard was not available in the past and only recently has it been implemented in the Linux kernel. What is still missing is an UCI standard way to configure 802.1ad interfaces, so at the moment this feature is still not usable by OpenWRT users.

OpenWRT is a Linux distribution primarly designed for embedded devices (e.g. routers) and we currently use it on our community network devices because it is the most suitable for our needs. Furthermore, the OpenWRT community and community networks have wide intersections both in thinking and in participants.

First of all I need to understand better the netifd (OpenWRT network manager) internals, then in agreement with OpenWRT developers I am going to define an 802.1ad UCI device configuration schema and implement its management inside netifd. I am going also to provide a new syntax for 802.1q devices but keeping retrocompatibility, then I am going to update the UCI documentation, do serveral testing and discuss with OpenWRT developers about how to merge the new code in the official repository.

I have already contacted OpenWRT developers and my mentors who seem pleased to help me, I will work hard on this project and I would like to see OpenWRT 802.1ad support rock-solid as soon as possible 🙂 I will push my day by day work on a netifd clone repository on Gitorious, so keep watching it.

More updates soon, and don’t forget the best is yet to come!