Ninux.org Wireless Community

Sta nascendo un nuovo python user group a Roma!

Ci vedremo Martedì 8 Luglio alle 19:00 al Fusolab 2.0 in Via della Bella Villa 94 (potete parcheggiare tranquillamente al parcheggione della coop).

Per coordinarci abbiamo tirato su una mailing list.

C’è anche un evento su G+.

Essendo il sottoscritto (Nemesis) uno dei promotori di questa iniziativa, invito tutti i ragazzi di Ninux-Roma a partecipare agli incontri al fine di alzare il livello delle skills della nostra comunità.

Ciao a tutti,

sono Alessandro Bucciarelli (a.k.a butch) e quest’anno partecipo per la prima volta al GSOC con Freifunk/Ninux con un progetto che si chiama Netengine.

Netengine è una libreria scritta in Python, sviluppata inizialmente come parte della nuova versione di Nodeshot (la nuova versione della mappa di Ninux attualmente in sviluppo) che è stata poi spostata in un progetto separato che può essere utilizzato indipendentemente da Nodeshot e Django.

Netengine è un livello di astrazione che mira ad offrire un unica API in python per recuperare le informazioni da diversi device  di rete su cui sono installati firmware differenti, ovvero astrae i device trattandoli come veri e propri oggetti con degli attributi e dei metodi da poter invocare.

A cosa serve Netengine e cosa fa?

Netengine serve innanzitutto per recuperare tutte le informazioni possibili da un determinato apparato. Ci sarà molto utile inoltre ad effettuare tutte quelle operazioni di diagnostica e di troubleshooting di apparati di rete (antenne ma non solo) da remota, ovvero senza la necessità di un contatto fisico con il device.

In un contesto come quello di Ninux, dove abbiamo un infinità di apparati distribuiti sul territorio gestiti da persone differenti con modi di lavorare differenti e con possibilità di intervento spesso ridotta, Netengine aspira ad alleviare il task di tenere aggiornati manualmente i dati che abbiamo nel nostro database. Grazie ad un unica API sarà più facile estrarre le informazioni dai device della rete ninux ed automare l’aggiornamento delle informazioni che sono presenti nel nostro DB.

Attualmente Netengine, lavora con diverse coppie di firmware/protocolli di rete tra cui AirOS, OpenWRT ed SSH, SNMP.

Un’idea per il futuro sarebbe quella di includere anche un backend HTTP a supporto di quelli SSH ed SNMP.

Entrando più nel dettaglio quello che fa questo modulo è inviare query SNMP al device che si sta analizzando, oppure avviare una connessione SSH in maniera trasparente all’utente che, sfruttando le chiamate di sistema, ritorna all’utilizzatore le informazioni richieste.

Quindi ogni device apparirà all’utente semplicemente come un’istanza dello specifico backend che vuole utilizzare (compatibilmente con il device), sul quale potrà invocare metodi e recuperare proprietà relativi al device.

Vi invito quindi ad analizzare e provare voi stessi il codice che potete trovare qui: https://github.com/ninuxorg/netengine.

Se volete contribuire alla discussione con suggerimenti e feedback potete farlo sulla lista ninux-dev.

Last Thursday, for the “Giovedì nerd” (i.e. “Nerd Thursday”) held every week at the Fusolab in Rome we had a Google Summer of Code Meetup.

Ninux.org is participating in the Google Summer of Code program thanks to Freifunk, that is acting as an umbrella organization for us.

We talked with many people from all around Rome about the GSoC projects that we had completed in the last years and about our new project proposals, which can be found here, and distributed the gadgets (big and small notebooks with the GSoC logos and some Google-pens) sent to us from Mountain View!

The Google Summer of Code 2010 is going to end.

Also this year, we have participated with a Freifunk project on the Freimap Software.

Freimap is an Open Source visualization and analysis framework for (mostly) mesh networks, such as for example Freifunk.net. It can read many a different data source and display them as different layers in a map. The network can be browsed and queried in real time, and a time bar allows to trace back to past events. Some statistics of the topology and network traffic may also be generated. From the last Google Summer of Code 2009, Service Discovery is a new feature.

The software itself runs in Java, and smoothly at that. It reads data from various sources in the network, a database, a file or from a Live Stream (OLSR Routing Protocol, B.A.T.M.A.N., etc).

This year I’ve added this feature: the ability of Freimap to store all visualized data in a MySQL Database.

HOW IT WORKS

In the current version, Freimap can take data from different datasource:

1. a file for a simple visualization: js, xml, txt files (static)
2. a MySQL database (static)
3. Live stream from an OLSR Daemon (dynamic)

If you want to store Live stream with the new “Database output for Freimap” feature you have to follow 2 simple steps. These steps are been simplified with a wizard that appear when you make a choice in the main GUI page.

The first step is a simple Wizard in which you have to insert some basics information such as:

1. MySQL Database information: IP/Hostname and port
2. MySQL Database credentials of an user that have a rw permission
3. Position of the OLSRd config file
4. Position of the LatLon.js file of the NameService Plugin
5. The port of the dotDraw plugin

Once you have entered all the information you can choose a previous “Freimap” Database or to “Create a new Freimap Database”. When you choose a database from a list of available database the application automatically detect if the selected schema contains Freimap data.  This choice read the data from the selected database and continue to store new live data in the same tables. With the second choice you can create a new database. This choice means that you can destroy an old database or you can create a completely new one.

ISSUES AND …TO DO

There is a lot of work to do to improve Freimap Software.

For example, as discussed in the OLSR-Dev Mailing List, there is a needs to make a simple web interface for the config file (now an xml file) in which you can change the base settings of the “Database output for Freimap” feature.

Another thing to do is to find a method to update and generate in a the fastest way a new “layer id” for the recovery of the correct layer when requested.

We have to add the possibility to read and store live data from and in two or more database (also schemas). This can be useful when you want to simulate in the same environment two networks with two different routing protocol (BATMAN and OLSR)

Actually the database information crosses the network in plain text. This means that we have to find a method to encrypt Freimap network data.

You can find more info here: http://wiki.freifunk.net/freimap

Mercurial Repository is here: http://code.google.com/p/freimap/

Freimap is a virtualization and visualization software for mesh networks. Currently this software does not have the ability to store information transmitted by individual nodes (data routing, position, connected clients, etc.) so the user cannot have a clear idea of network behavior over the time.

After gathering information and needs of various communities in Berlin during the international event WCW2010 we have written the basics for the job of this summer for the Google Summer of Code 2010. With the project “Database output for Freimap” we want to create a plug-in that can store all information and data, not only of individual clients but also of the entire mesh network (SNMP data, syslog data, etc …). In this way Freimap can be used as a veritable tool for troubleshooting and reference. The needs identified during the WCW2010 were:

• Define of a common node schema: communities have different schemas of nodes (due to the different types of networks used)
• Possibility to redrawing the map at a given time
• Ability to find a particular information (eg client connected at a given time)
• Need to manage the entire network from anywhere in the world with a Web Interface

The new Freimap is organized by level, unlike the previous version (written by Thomas Hirsch). These levels are:

1) Layer Datasource

2) Data Layer

3) Main Layer

The first layer is responsible for collecting data from all DataSources (NameService Plugins, OlsrDataSource, Files, MySqlDataScource, etc …)

The second layer is responsible for organizing and storing data in the database. This level contains all necessary information for the “rebuilding” of the map and then the regeneration of the situation at a given time. In addition to the data passed from the “DataSource Layer” at this level are added some basic information such as timestamps and information on the nodes (translated xy positions on the map, lat / lon, etc. ..)

The third level is responsible of the generation of the GUI from the data of previous levels. The project’s aim is therefore to find a way to store data of the second level, where there are all necessary data for the rebuilding  of the level at the given time.

This first step that must be followed, is surely a definition of a common  node schema. Project already started by the Ljubljana Community with some fundamental results.

Now, only for testing, the structure of the database tables is reduced at:

Node Table:

Layer Table:

Link Table:

After this first design phase, the second part of the program will be dedicated entirely to the coding in which will be defined the procedures for storing data in the database. With the first commit have been implemented the automatic generation of the database structure (local and/or remotely) and the ability to select an existing external/internal database from which to get the information and updates in real time .

Other updates will be announced shortly before the Mid-term evaluations deadline;

Changelog and updates about the development process can be found at: https://code.google.com/p/freimap/

Stefano Pilla