GSoC: Retroshare social network plugin compared with Retroshare forums

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

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

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: nodewatcher v3 – data collector agent

Hello all!

A quick update on what is happening regarding my GSoC project with bringing nodewatcher v3 platform closer to reality. Version 2 of nodewatcher used its own simple key-value format and a bunch of shell scripts to provide monitoring data. In order to bring this into the modern era where JSON and ubus are available as compact libraries on OpenWrt by default, I have in the last few days created a new modular OpenWrt monitoring agent that can run on nodes and periodically obtain data from various sources (directly from procfs, from uci, from netifd via ubus, from nl80211 netlink API via OpenWrt’s libiwinfo, etc.).

The daemon is implemented in C and different data sources are implemented as loadable shared object modules, enabling simple extensibility. Nodewatcher agent then provides all of the collected data in two ways: a) it can directly output data to a JSON file that can be served via HTTP; and b) it also provides an ubus object called nodewatcher.agent that exposes a get_data method, so other applications can obtain the same structured data as an ubus blobmsg. The nodewatcher monitoring agent could perhaps also be reused by the proposed Freifunk Monitoring and Administration Panel.

The nodewatcher-agent repository is hosted on GitHub with a README file providing a quick description of the used format, the ubus API and the currently implemented modules:

https://github.com/wlanslovenija/nodewatcher-agent

I have also packaged the agent for OpenWrt so it can be installed together with its various data source modules via opkg. The packages are available in the nodewatcher firmware package repository:

https://github.com/wlanslovenija/firmware-packages-opkg/tree/master/util/nodewatcher-agent

The agent and its packages should be considered alpha and the schema is still subject to change.

GSoC: Freifunk monitoring and administration panel

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

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.

 

 

GSoC – nodewatcher v3 platform

Hello all!

My GSoC work focues on the next version of nodewatcher, an open source (GNU AGPL licensed) network planning, deployment, monitoring and maintenance platform for community wireless networks. Its main idea is to automate as much as possible in building and operating a community wireless network. It encompasses functionalities sometimes named “node database”, “network dashboard”, “network map”, but also a web-based firmware image generator, which allows easy generation of customized firmware images for each node individually.

The previous version (v2) that is currently deployed by wlan slovenia has most of the functionality hardcoded for the use in our network. With version 3 we are making nodewatcher into a fully modular platform that can be reused and adapted by various community wireless mesh networks around the world and this GSoC project will bring us closer to making this a reality. Development can be tracked on GitHub (https://github.com/wlanslovenija/nodewatcher, branch development) and on wlan slovenia development Trac (https://dev.wlan-si.net).

About the author

My name is Jernej Kos, a computer science researcher, software developer and network engineer with over nine years of experience. I enjoy working on interesting projects, specifically with backend architecture and low-level details. I have experience with scalable web application development, development of software for embedded devices, routing protocol internals and security protocols. I am currently involved with open source projects, the most prominent being wlan slovenia, where I have developed a modular platform for network monitoring and provisioning, an efficient L2TPv3 based VPN solution that runs on OpenWrt-supported devices, a big data time series processing library and a simple system for multiprocess serial communication. My current research interests include secure, Sybil-tolerant and privacy-aware decentralized services and novel location-independent compact routing protocols. To this end I have developed Boost.ASIO C++ bindings for CuveCP and in the course of my PhD thesis am working on a secure and scalable location-independent compact routing protocol that can be used in mesh networks and/or for building decentralized social networks.

Google Summer of Code – Source Sensitive Routing

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

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

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!