GSoC: Social network plugin for Retroshare

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

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.

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!

Hardware Detection for Libre-Mesh [GSoC 2014]

Hi everyone!

I am Francisco Jiménez (Frank95) and since I heard about the Libre-Mesh community I have been interested in contributing to it. That’s why at the last time I have been participating in the installations of new nodes in Spain and I consider that the idea of Libre-Mesh: Hardware Detection would be very useful for installers. It will contribute to easier and faster installations. 

The Hardware Detection project consists on creating a module for Libre-Mesh in such a way that the system will detect and It will configure the external USB radios and other hardware units automatically. In particular, the creation of plug-in modules for ath9k-htc based hardware, hardware switch chip such as thoses present on the TL-WDRxxxx devices  series and  DIR-632 with 8 ports switch (RTL8309G).

I am excited of being part of the community and participate as a student for the first time in GSoC 2014. Since I met this community, apart from a warm reception,  I have learned a lot about Libre-Mesh firware and OpenWRT. In addition, developing this project is an opportunity for improving my coding knowledge and make my nodes installations simpler.

 
I’ll push my code while I am working here:
 
And finally the code would be merged here:
 
If anyone wants to contribute with tips and feedback (it’s always welcome) please contact me at: 

franciscojim95 [at] gmail [dot] com

 
 

 


 

Netengine Google Sumer of Code Project

Hi everyone, I’m Alessandro Bucciarelli and I am participating for the first time to Google Summer of Code.
I chose to apply to work on Netengine, a project by Freifunk/Ninux. Netengine is a Python abstraction layer thought to retrieve informations about network configurations, and not only, from multiple couples of network protocols/device firmware.

Actually the main network protocols we are working on are: SNMP, SSH; with HTTP which is an idea for the immediate future.
By the firmware side there are AirOS and OpenWRT which are the most used firmwares among network devices (antennas and other) deployed inside the Ninux network.

Many of the readers, if experienced in the network field, will agree with me in saying that the retrieval of network informations (e.g IP addresses of the interface/s, MAC addresses, routing configurations) is vital.

This aspect is more than vital when you are interacting with remote devices, geographically widespread and sometimes accessible by only unskilled persons, to have a timely diagnostics of the  deployed hardware.

The module we are developing tries to solve, and I am sure it will be so, the problem of having informations from the devices REMOTELY, without any kind of further configurations and without any kind of physical interaction with the device.

For further details and code please visit https://github.com/ninuxorg/netengine or email us at ninux-dev@ml.ninux.org

Your API file in only 6 steps

  1. Call up http://freifunk.net/api-generator/ 
  2. Fill in the information about your community in the form and press “OK – generate…”. Mandatory fields are marked with an asterisk. The more information you enter, the better. 
  3. Your results will be displayed on the right hand side. If information is missing or fields are incorrectly filled, you will see it marked under the text box. Fill in or correct the information and generate the API file again.
  4. Save the content of the text box to a text file on your computer or press the download button.
  5. Upload the file created under point 4. to the Internet on to your Web space, in your content management system or our freifunk wiki. You will need a link to that file.
  6. The link must be added to the API directory. If you trust yourself, create a pull request, or you can send the link via contact form. If you chose the later, select “question about the API” as subject.

Please note: If you want to update, download or edit your API file, you can choose to do so after the entering the API directory, in the drop-down menu on the top right. The file must however be resaved or downloaded and uploaded to the Web server again.  

Please also use the possibilities to update information such as the number of nodes or services automatically and regularly. Gluon developers have written an examplary script, and there is a solution for OLSR-based networks on Github

You can find background information on the API in the blog and on freifunk.net.  

The most recent changes are summarized here.

Translation by Karin Kuschel.

In 6 Schritten zum API-File

  1. Ruf http://freifunk.net/api-generator/ auf
  2. Trag die Informationen zu deiner Community in das Formular ein und drücke auf “OK – generate…”. Pflichtfelder sind mit einem Stern gekennzeichnet. Je mehr Informationen eingetragen werden, umso besser.
  3. Auf der rechten Seite werden dir die Ergebnisse angezeigt. Falls Informationen fehlen oder Felder falsch befüllt sind, steht es dort unter dem Textfeld. Ergänze oder berichtige die Informationen und generiere das API-File erneut
  4. Speicher die Inhalte des Textfeldes in einer Textdatei auf deinem Rechner oder drücke auf den Download-Button.
  5. Lade die unter 4. erstellte Datei hoch ins Internet auf einen Webspace, in euer Content Managementsystem oder in das Freifunk-Wiki. Als Ergebnis benötigst du einen Link zu der Datei, der aus dem Internet erreichbar ist
  6. Der Link muss noch in das API-Directory eingetragen werden. Wenn du es dir selbst zutraust erstelle einen Pull-Request, ansonsten schickst du den Link über das Kontaktformular an uns und wählst als Betreff ‘Frage zur API’
Hinweis: Wenn du dein API-File aktualisieren willst, kannst du es nach dem Eintrag ins API-Directory im Auswahlmenü oben rechts auswählen, laden und bearbeiten. Danach muss die Datei allerdings erneut gespeichert oder heruntergeladen und auf den Webserver hochgeladen werden.
 
Nutz bitte auch die Möglichkeiten, Informationen wie die Anzahl der Knoten oder Dienste automatisch und regelmäßig zu aktualisieren. Die Gluon-Entwickler haben ein Beispiel dafür ein Script geschrieben und für OLSR-basierte Netzwerke gibt es eine Lösung bei Github.

Hintergründe zur API findest du im Blog und auf freifunk.net.

Die letzten Änderungen sind hier zusammengefasst.