Tag: gsoc

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.

 

 

GSoC – nodewatcher v3 platform

Posted on by Jernej Kos

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

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!

Hardware Detection for Libre-Mesh [GSoC 2014]

Posted on by Francisco Jiménez González
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

Posted on by Alessandro Bucciarelli

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

Freifunk Google Summer of Code 2014

Posted on by Mario Behling

We are excited that Freifunk has been accepted as a Google Summer of Code Mentor organization again in 2014.

We are now looking for interesting student projects. Participating community networks and projects have already put up a list of ideas on the wiki.

Students can apply for example for projects developing packages for OpenWrt (the basis of the freifunk firmware) extending its functionality or other useful network tools such as management server tools, graphic interfaces for existing tools, map extensions, p2p tools that take routing into consideration, implementing wlan sleeping modes, routing protocols and more.

The deadline for student applications is 21 March: 19:00 UTC. We recommend to start your application now. You also need to add an enrolement form into the system.

 

Freifunk Google Summer of Code Timeline

21 March:

19:00 UTC

Student application deadline.

Interim Period:

Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant.

7 April:

Mentoring organizations should have requested slots via their profile in Melange by this point.

9 April:

Slot allocations published to mentoring organizations

Interim Period:

Slot allocation trades happen amongst organizations. Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant.

15 April:

First round of de-duplication checks happens; organizations work together to try to resolve as many duplicates as possible.

18 April:

  1. All mentors must be signed up and all student proposals matched with a mentor – 07:00 UTC

  2. Student acceptance choice deadline.

  3. IRC meeting to resolve any outstanding duplicate accepted students – 19:00 UTC #gsoc (organizations must send a delegate to represent them in this meeting regardless of if they are in a duplicate situation before the meeting.)

21 April:

19:00 UTC

Accepted student proposals announced on the Google Summer of Code 2014 site.

Community Bonding Period:

Students get to know mentors, read documentation, get up to speed to begin working on their projects.

19 May:

  1. Students begin coding for their Google Summer of Code projects;

  2. Google begins issuing initial student payments provided tax forms are on file and students are in good standing with their communities.

Work Period:

Mentors give students a helping hand and guidance on their projects.

23 June:

19:00 UTC

Mentors and students can begin submitting mid-term evaluations.

27 June:

19:00 UTC

  1. Mid-term evaluations deadline;

  2. Google begins issuing mid-term student payments provided passing student survey is on file.

Work Period:

Mentors give students a helping hand and guidance on their projects.

11 August:

Suggested ‘pencils down’ date. Take a week to scrub code, write tests, improve documentation, etc.

18 August:

19:00 UTC

Firm ‘pencils down’ date. Mentors, students and organization administrators can begin submitting final evaluations to Google.

22 August:

19:00 UTC

  1. Final evaluation deadline

  2. Google begins issuing student and mentoring organization payments provided forms and evaluations are on file.

22 August: 20:00 UTC

Students can begin submitting required code samples to Google

25 August:

Final results of Google Summer of Code 2014 announced

Links

* GSoC Page: https://www.google-melange.com/gsoc/org2/google/gsoc2014/freifunk

* Idea Page: http://wiki.freifunk.net/Ideas

Freifunk Google Summer of Code: Guifi.net and QMP

Posted on by Mario Behling

Hakais has put up some info about student projects that were accepted as Freifunk Google Summer of Code projects and which are taken care by Guifi.net. Two students involved in Guifi.net have been accepted for the Gsoc 2012.

Google Summer of Code is a global program that offers students stipends to write code for open source projects. We have worked with the open source community to identify and fund exciting projects for the upcoming summer. One of these projects is named Guifi.net integration for QMP system, which has been applied by Joel Espunya and mentored by Pau Escrich. The main objective of it is to provide an easy way to use the QMP Mesh firmware inside the Guifi.net community network. (http://guifi.net/en/node/47699)

More info on the projects:

State of the art

The main purpose of QMP (Quick Mesh Project) is to provide an open and free software solution for the quick deployment of a WiFi network based on Mesh/MANET technology. It is focused to be useful mainly in the wireless community network. It is based on OpenWRT Linux and it is completely OpenSource.

The QMP project was drafted by Guifi.net (http://guifi.net/en) active members during year 2010. It was started on the beginnings of 2011 thanks to the funding of a local fundation named puntCat (http://www.fundacio.cat/en_index.html). This funding was ended on december 2011. However the project development still alive by a volunteers team.

  • Mesh Network

Strictly speaking, a Mesh network is one where all nodes (participants) are routers, meaning that all the nodes accept and forward packets from other nodes according to the routing rules. Thanks to this property the physical topology of the network is only restricted by the need of all nodes to be connected through at least one link.

  • Community Network

A community network is a network made and maintained by the same participants. Unlike the model used by the global telecommunication companies (which are business-focused), each user is owner of his stretch following the philosophy make-it-yourself. Using some agreements and organizations (e.g web site) they are able to connect with neighbours, neighbours of the neighbours and so on.

Project description

  • Summary

The objective of the project is to provide a software solution to easy integrate the Guifi.net characteristics into the QMP system.

  • Why this is needed

Currently QMP is a working system, that can be used to easy deploy a Mesh Network but there are several missing features. One of them is the integration with the Guifi.net community. It can also be used as a template for the integration of other Network Communities like Freifunk, Funkfeuer, AWMN, etc.