Archive for June, 2012

NazzaNode2 – perché cciù is megl’ che uan!

Tuesday, June 12th, 2012

Vista panoramica dal tetto

Come recitava il famoso spot, due è meglio di uno! Quindi se l’occasione c’è, e la voglia di fare pure, perché non mettere su un nuovo supernodo? Ed è così che nasce il NazzaNode2, il primo caso di due supernodi Ninux sullo stesso tetto! L’intenzione è estendere la nostra rete verso Roma Ovest, ricca di nodi potenziali ma senza nessun ponte diretto. Il supernode esistente (NazzaNode) purtroppo è troppo basso per scavalcare Monte Mario, quindi grazie anche alle due NanoBridgeM5 ricevute per il compleanno ho deciso di potenziare l’installazione e far crescere il nodo. Dopo una mattinata di acquisti in compagnia di Fish e Arkanet un mese fa, ci siamo trovati sabato mattina io e Fish ad avviare i lavori del nodo.

(more…)

Ninux Calabria è nata!

Thursday, June 7th, 2012
- Si vabbhè, ma 'ste latenze e 'ste deviazioni standard non esistono, c'è qualcosa che non quadra.
- No ti spiego, qua c'è di mezzo la rete universitaria a rompere i coglioni, a Catanzaro i parametri saranno normali.
- Ma io sono a Catanzaro!

La discussione in Aula Zenith, sede dell'Hacklab Cosenza presso l'Università della Calabria, prosegue più animata di prima, ma Geegeek non sta già più ascoltando. Invece, sorride. Se avete conosciuto Gigi, saprete bene che il suo sorriso diventa la sua faccia, ed è quindi pressoché impossibile da ignorare a lungo. Dopo averlo notato con le valigie in mano in direzione tangente, non è stato difficile capire cosa gli fosse preso, sintonizzare i nostri pensieri e sorridere anche noi.

La naturalezza con cui è uscita quella frase, pretendere di trovarsi a Catanzaro nel bel mezzo della Facoltà di Economia dell'Unical, racchiude in un attimo solo il risultato di tutti i 13 mesi di lavoro del team di Ninux Calabria. 13 mesi di lavoro su ogni fronte, pieno zeppo di passi spesso troppo piccoli, intangibili ma comunque inevitabili e quindi frustranti. Nelle prime due settimane di Maggio però tutti questi pezzi hanno cominciato ad incastrarsi in un per noi entusiasmante effetto domino e ora siamo qui a raccontarvi che Ninux Calabria è nata.

Quando siamo partiti nell'Aprile del 2011 sapevamo di aver di fronte un immenso lavoro di test da fare e, soprattutto, di know-how da costruire; sapevamo che avremmo impiegato mesi per fare cose che a quelli di Ninux.org occorre mezza giornata per completare. Può essere dura lavorare con così tanto da fare e poche soddisfazioni nell'immediato, ma dalla nostra avevamo un "milestone" che ci siamo fin dall'inizio prefissi di raggiungere durante la costruzione della rete Ninux calabrese: collegare le due sedi dell'HackLab Cosenza presso l'Università della Calabria e quindi dotarlo di una propria rete autonoma. Entro Ottobre però, con i progressi fatti a Catanzaro, l'idea si è fatta ancora più grande: collegare in un rete libera le sedi dei due Hacklab calabresi di Catanzaro (lo *Lab) e Cosenza (la Zenith).

E 13 mesi dopo, ci siamo. Chiediamo scusa ai ragazzi del corso di giapponese dell'aula gemella se questo ping

il portatile di Stefanauss in Zenith pinga uno dei server nell'armadio *Lab

è stato accolto da un nostro boato =)

Adesso segue un po' di cronistoria di questo link e poi, in fondo, una carrellata dei nostri prossimi obbiettivi.

Il Link

Il progetto originale del link secondo l'artista che c'è in geegeek.



Zenith-HPCC, ~250m
Quello che ci ha fatto dannare per mesi non è tanto la distanza, piuttosto ridotta, ma l'assenza di una visuale aperta tra i due punti: il nostro laboratorio si trova sul retro dell'edificio che ospita il Centro di Calcolo ad Alte Prestazioni (punto rosso), mentre il luogo dove ci riuniamo è l'Aula Zenith (punto verde), ed entrambi sono accessibili dal ponte carrabile dell'Unical.
Visuale dal middle point:
L'ultimo lampione in fondo è l'HPCC.


Dopo i primi sopralluoghi, abbiamo identificato come middle point il retro di un cubo nelle immediate vicinanze della Zenith e che ha visuale sgombra verso l'HPCC: il punto ideale per triangolare e ultimare il link.

Mentre arrivava il primo ordine di materiale e cominciavano le sperimentazioni software su firmware e protocolli coordinate da Spax, e le prime misurazioni ci rassicuravano, per il link tutto si è quindi trasformato in una sfida logistica: Come piazzare le antenne in modo sicuro? Come arrivare al tetto del middle point e garantirci quindi la visuale sulla Zenith?
Per 8 mesi (inclusa tutta l'Estate) un router flashato con OLSR è rimasto indisturbato e intatto in cima al middle point, a rispondere almeno parzialmente alla prima di queste domande. In HPCC si è rivelato tutto un po' più complicato: siamo riusciti ad ultimare due installazioni di test differenti, una a Maggio 2011 e una a Luglio 2011, che però si sono rivelate inadeguate in quanto a sicurezza. Ad ogni modo la soluzione finale e attuale non è dissimile da quelle precedenti, solo più raffinata. La strada HPCC-Middle Point era tracciata.

Eravamo però in piena frustrazione per l'ultimo, piccolo tratto. L'idea era facile a dirsi: una 50ina di metri di cavo Ethernet calati su per il tetto, fatti scorrere verso la parte frontale dell'edificio protetti da una canalina, e collegati ad un Access Point alimentato in power-over-Ethernet. Praticamente impossibile da realizzare invece: senza autorizzazione e senza attrezzatura adeguata non siamo neanche arrivati ad un vero e proprio sopralluogo del tetto. La naturale conseguenza è stata un po' di demotivazione e lo spostamento del nostro focus da Cosenza a Catanzaro, dove invece tutto procedeva a latenze bassissime e visuali sterminate. Ci eravamo rassegnati ad un approccio alla lontana, puntando a trasformare qualche nodo (molto) potenziale della vicina cittadina universitaria, Quattromiglia, in un nodo operativo e da lì triangolare con la Zenith, ma il tutto è rimasto fumoso nei dettagli. Fino a che, questo mese di Aprile, è arrivata

La svolta


Una foto artistica del Centro di Calcolo
ad Altre Prestazioni dell'UniCal, by Vin-San.

Sotto forma di una coppia di scoperte che richiamano valori tipici della mentalità hacker: l'esplorare ogni angolo di un problema e trovarne soluzioni la cui bellezza è insita nella loro non-ovvietà.

Innanzitutto, geegeek ha trovato il modo di montare in tutta sicurezza l'antenna lato HPCC sfruttando il supporto di una telecamera di sorveglianza: alta abbastanza da essere inaccessibile ad eventuali vandali pur rimandendo di facile accesso per le persone all'interno del Centro.

Stimolati da un problema del tutto separato dal progetto Ninux Calabria che concerneva il nostro bisogno di NATtare la WiUnical per consentire la connessione ad internet anche ai corsisti networking dell'Hacklab che non erano universitari, abbiamo indagato più a fondo la struttura delle rete universitaria che è stata rinnovata a Gennario 2012, e che ora prevede AP non protetti e accesso sicuro garantito da un tunnel VPN. Petruzzo e Vin-San si sono accorti che qualsiasi configurazione IP statica assegnata ai propri terminali, collegati ad un qualunque Access Point aperto tra quelli sparsi per l'università ma non loggati in VPN, consentiva loro di comunicare host-to-host con successo. Ad esempio, Il protocollo Bonjour, installato di default sulle maggiori distro Linux, consentiva ad esempio la chat out-of-the-box! A quanto pare, la WiUnical è una gigantesca LAN in cui tutti gli Access Point sono interconnessi tra di loro da una serie di switch. Il 2+2 è stato immediato: non avevamo più bisogno di collegare fisicamente il tratto che ci mancava, ma la Zenith e l'HPCC potevano essere uniti cavalcando l'autostrada sgombra della rete universitaria!

HPCC / Esterno

Eccola la nostra prima Ubiquiti Nanostation M5 nell'ufficio che geegeek le ha preparato con amore. Il montante è uno di quelli scelti col nostro secondo ordine di materiale: si è rivelato un pò troppo attillato al primo tentativo, ma dopo qualche settimana gigi ha riportato sul luogo del delitto una versione che era stata piegata (letteralmente) ai nostri scopi.



Come è alimentata? Il cavo LAN che fa anche da PoE scorre lungo la facciata dell'edificio, perfettamente mimetizzata da una canalina dipinta dal nostro tutto-man gigi, in versione pittore oltre che scultore.


HPCC / Interno


Come tutti i router coinvolti finora a Catanzaro e a Cosenza, quello presente in HPCC a interfacciarsi con la Nanostation all'esterno è un TP-Link economicissimo (WR-741ND, disponibile a meno di 20€!) nel quale il firmware di default ha abdicato in favore di un ben più potente e ben più libero OpenWrt trunk cucinato dal nostro Spax. Tra le personalizzazioni da noi scelte tra i tantissimi pacchetti opzionali forniti dal progetto open source c'è ovviamente il demone OSLR, il mattone fondamentale dell'architettura routing di Ninux; il supporto per il protocollo IPv6 (lo sapete che il 6 Giugno è la giornata del lancio ufficiale su scala mondiale?); Tinc per collegarsi in VPN con le altre isole che compongo la rete Ninux nazionale; nodogsplash, una pagina d'introduzione a Ninux che si presenterà in futuro a chiunque si connetta ad uno degli AP liberi della rete.


La rete in HPCC ha una gestione leggermente diversa dal resto della rete universitaria, ed è separata dalla WiUnical. Sistemare quest'anello mancante non si è però rivelato un problema: con una coppia di connettori Powerline abbiamo collegato il router nel nostro laboratorio con quest'altro sistemato accanto alla finestra dell'aula seminari dell'HPCC e che fa da AP per la WiUnical.
Questo AP in particolare ci sta facendo un pò dannare a causa della sua instabilità che ci costringe spesso a riavviarlo; ma sappiamo che è il prezzo da pagare alla nostra voglia di sperimentare che ci porta a compilare versioni ancora in sviluppo di OpenWRT. Quando arriverà il momento consolideremo il tutto adoperando build stabili e ufficiali su tutti i nostri dispositivi.


Middle Point / Esterno

Come l'altra Nanostation M5, anche questa Ubiquiti è stata flashata con l'ultima versione di AirOS personalizzata da alcuni pacchetti selezionati (OLSRd, IPv6). A differenza di OpenWRT, AirOS è un firmware proprietario che viene però preferito per le sue performance nettamente superiori. Ad ogni modo l'azienda produttrice ha messo a disposizione un SDK che permette a programmatori terzi di aumentare il potenziale del prodotto compilando software libero già disponibile per altre piattaforme in modo da farlo girare nativamente sull'hardware.

Questo montante è stato invece "ingrassato"
da gigi alla meno peggio: Just Works (TM).
Per l'alimentazione (PoE) ci siamo allacciati ad una vecchia luce di servizio dimenticata da tutti e non più funzionante. Il cavo passa sotto ad una trave, bloccato da alcune fascette, in modo da resistere alle intemperie.

Dentro la plastica trasparente, la 220 e il Power-over-Ethernet.


Ecco la visuale, perfettamente allineata, di cui gode quest'antenna verso la sua gemella in HPCC. Questa foto è la rappresentazione fisica del primo link operativo a Cosenza, come conferma la Ninux Map ufficiale.



Aula Zenith / Interno

Rappresentazione della rete attuale , by Spax.
Il tassello finale è rappresentato dai due device (sempre TP-Link) presenti nella nostra sede, "AP Zenith" e "Router Zenith" nella topologia logica accanto, e connessi tra di loro con l'interfaccia WAN. I Router sono comodamente alloggiati in una cassetta che contiene tutto il resto dei dispositivi che cablano l'aula. Il Router fa da client sulla WiUnical, mentre l'Access Point con SSID "HacklabCS" fornisce connettività (anche Internet) a tutta l'aula, rendendo possibile per la prima volta in 2 anni la presenza di una connessione libera nel luogo di riunione scelto dall'Hacklab Cosenza. Avremmo potuto usare un solo device, scegliendone uno o con doppia interfaccia radio o uno in grado di operare in dual mode mantenendo un buon livello di prestazioni. Abbiamo però scelto di sdoppiare i compiti per aumentare il numero di nostri dispositivi "di produzione" e quindi i terreni su cui sperimentare; inoltre questa soluzione è nettamente più economica, con un costo complessivo dei router di 35€!

Speriamo che questo sia solo il primo di una serie di AP che consentiranno accesso alla rete Ninux in tutta l'Unical...


What's Next?



Guardiamo lontano...
le visuali delle antenne toccano le cittadine universitarie.
Abbiamo affiancato la sperimentazione pura e semplice ad un obbiettivo reale e concreto, ed abbiamo portato a termine entrambi con successo. E adesso? Quali sono i prossimi passi per Ninux Calabria?

  • Continuare a sperimentare. Ci sono tantissimi dispositivi in inventario che non aspettano altro di essere unboxati e di ricevere un po' d'amore. Ce ne sono altrettanti che ancora non abbiamo mai avuto sotto mano ma che abbiamo identificato come intriganti e con cui non vediamo l'ora di esplorare nuovi settori della nostra base di conoscenze in perenne work-in-progress. A questo si aggiunge la sconfinata base software disponibile tra cui trovare i bit giusti per potenziare le performance, la stabilità e la sicurezza della rete.
  • Espandere la rete. I nostri primi segmenti funzionanti ci danno l'iniezione di fiducia di cui avevamo bisogno per cominciare a cercare altra gente volenterosa con la quale ampliare le nostre isole. Come si vede dalle foto il nostro link (entrambe le antenne) hanno una fantastica linea visiva verso la cittadina universitaria di Quattromiglia, dove speriamo di trovare terreno fertile per nuovi segmenti. La ricerca di nuovi nodi potenziali era già partita a Catanzaro e Reggio Calabria, ora anche Cosenza può cominciare.
  • Produrre documentazione. Dalla nostra prospettiva "from scratch", cominciando da zero assoluto ci troviamo spesso a desiderare che le conoscenze da acquisire e di cui abbiamo bisogno siano tutte quante organizzate e facili da reperire. Spesso invece la situazione è opposta, con informazioni che non sono disponibili in forma omogenea ma piuttosto di frammenti sparsi che richiedono un gran lavoro di raccolta. Vogliamo documentare passo passo il nostro bagaglio che cresce, non solo a nostro beneficio, ma anche per i prossimi avventurieri che ci seguiranno e per chi Ninux lo fa da un bel po' e non ha vita facile nell'illustrare ai neofiti le basi di questa rete comunitaria. Per questo abbiamo cominciato a lavorare per produrre documentazione, per esempio con le registrazioni video del 1° Workshop calabrese, e a ampliare in sinergia con Roma il wiki nazionale.
  • Dipanare i dubbi. Ovunque nel mondo, ma in maniera drammaticamente marcata in Italia, l'apparato normativo si è fatto lasciare particolarmente dietro dal progresso tecnologico, mantenendo in vigore norme pensate per un passato che adesso non esiste più e che lasciano nell'incertezza applicazioni di tecnologie moderne, come ad esempio Ninux. Ora che, per quanto piccola, la nostra Ninux Calabria si tocca con mano è ora di pensare al futuro: delineare e comprendere quale sia la situazione normativa attuale nella quale una rete posseduta da chiunque ne faccia parte si colloca, anticipare le problematiche e infine risolverle con tutti i mezzi a disposizione di un membro di una comunità partecipe e informato.
  • Dare sostanza alla rete. Ora che una piccola porzione dell'infrastruttura è in piedi, nell'attesa di espanderla vogliamo cominciare a farne uso: dal piccolo prurito (l'intera Wikipedia in modalità offline e autoaggiornante? Yeah, baby!) al grande progetto (ci pensate ad un server DNS interno a Ninux che risolva domini .ninux che chiunque può avere gratuitamente?), passando per file server, chiamate VoIP, streaming audio e video, un nuovo spazio didattico gestito interamente da studenti Unical dove scambiare materiale e appunti, messaggistica istantanea geo-based, e chissà che altro. Abbiamo appena cominciato a grattare la superficie dell'immaginazione. Con Internet, una volta che l'infrastruttura è stata accessibile a tutti è stata la forza propulsiva delle applicazioni pensate dai singoli a dare il valore sconfinato che le attribuiamo oggi. Con Ninux contiamo succeda lo stesso, con una rete che stavolta però appartiene a tutti.

Volete partecipare? Ci riuniamo tutti i Martedì dalle 19 all'aula Zenith (Cubo 13C) dell'Università della Calabria, e a Catanzaro presso lo *Lab ogni Sabato pomeriggio. Ninux Calabria si coordina a livello regionale sulla nostra Mailing List ufficiale. Iscrivetevi!

Getting ready to World IPv6 Day 2012

Wednesday, June 6th, 2012

Download this press release in pdf from here

Download here the Ninux Roma Routing Architecture -Version 0

Introduction

A few months ago we published a graph on our homepage that shows in real time the last 24 hours of the bandwidth usage of our main IPv6 peering link.

 

We started our IPv6 deployment in March 2011. Unidata, an ISP operating in the area of Rome (Italy), offered us the chance to make an IPv6 BGP peering providing to us free transit to the public Internet (IPv6 only).

We accepted immediately this chance to experiment with IPv6, as since the beginning of our community network, making experiments with new technology has been a leading factor.

We already had a private peering with Ydea.com, to route a few IPv4 addresses we used for mail servers and other lightweight services. To set up the second peering we started to think of the new network architecture and we faced how to pay the necessary resources.

In the early days of Ninux we started “playing” with wireless equipment together with Iacopo Iacarelli, the owner of Ydea.com. Our stories are different, because Ydea.com is a wireless ISP and we are a community network, but our relationship grew bigger and bigger over time, so he was very happy to help us out by giving us some useful tips to deal with the LIR, a required step to obtain the necessary resources.

We first upgraded our private peering with Ydea.com to a public peering, once our public AS number was registered at RIPE.

The 8th of April 2011 we installed our antenna on the roof of the Unidata PoP located in the eastern suburbs of Rome. We installed our second BGP router, a Linux Server running Quagga (the hardware was kindly offered by Unidata).

The 24th of May 2011 we had our IPv6 address block 2001:4c00:893b::/48 ready to use.

To make sure it all worked well we moved by little steps. At Ninux we don’t have a vendor that provides hardware and software upgrades, like it happens with large scale ISPs. We have a software team that builds firmware on top of devices. Firmware are open source like in Pisa (OpenWRT firmware) or based on some vendor product that has an available SDK, as in Rome where we use AirOS by Ubiquiti.

Because we were not sure that the new firmware was stable enough, at first we upgraded just a few nodes to connect the Ninux Farm to the BGP router at the edge of the network. The upgrade of this 4 nodes was not critical for the whole network, and it was a perfect test playground to generate enough traffic.

You can see the nodes involved in the first experiment on our mapserver at these links:

http://map.ninux.org/select/ninuxfarm/

http://map.ninux.org/select/tecnopolo/

http://map.ninux.org/select/fishsupernode/

Problems

We started working to provide native IPv6 access to the servers in the Ninux Server Farm, and we faced the first problems.

The hardest problem we faced was to have IPv6 support on our backbone devices. The Ninux.org backbone runs mostly on Ubiquiti devices of the M-Series. Running OpenWRT on these devices would give total IPv6 support, however the open source drivers coming with OpenWRT are not as stable as the proprietary ones embedded in the AirOS firmware, leading to poor performances when using OpenWRT.

Using the AirOS SDK we developed ourselves our own IPv6 solution, but we couldn’t get something really stable until  the end of september.

We had to face some problems, because Ubiquiti is very fast in releasing new firmware versions when there is a bug, but the SDK release is somehow delayed. So to speed up testing and development, in August we had to reverse engineer their latest firmware.

After a lot of work we have now a stable firmware 🙂

We published here the patches to apply on top of the Ubiquiti SDK to have a IPv6 OLSR router:

https://github.com/ninuxorg/UbntM5AirOsOLSR/tree/master/patches/AirOS5.3.3

Stateless addresses

When starting with IPv6 you have to give IPv6 addresses to the devices of your network. We had a /48 to be partitioned.

IPv6 gives enough room for messy address management without easily run into a collision of addresses. At first we used a wiki page, and everybody was taking note of the /64 used for his home.

The easier way to deliver an IP address to the end users was using radvd directly on the OLSR routers. However we had a lot of flaps because the routers were changing IP addresses. Soon we realized that we had to disable routing advertisements on routers that had already a manually configured IPv6 address.

echo 0 > /proc/sys/net/ipv6/conf/all/accept_ra

BGP and IGP

The Ninux network in Rome had just IPv4 private addresses. The routing protocol used is OLSR. Connecting to the big Internet we started to identify OLSR as our IGP protocol. We upgraded the network to run in dual stack IPv4 and IPv6, so running two instances of the OLSR protocol. After configuring some stuff without a real plan, we started to write a real routing architecture, that you can find now on our web site.

When you have only one peering point with a single upstream provider, it is enough to redistribute via BGP to your upstream a static route that matches all your address space. But if you have different peering points in your network, then you need to redistribute IGP routers to BGP to understand what is really reachable and should be announced.

This was not trivial, because we use OLSR as IGP routing protocol, and the integration with Quagga is still experimental. We are still testing Quagga version 0.99.21 with this patch https://dev.openwrt.org/browser/packages/net/quagga/patches/120-quagga_manet.patch

Public Services

We are very happy to run a network that is ready for IPv6. Our users are using IPv6 services since several months, and we expect this traffic to increase the 6th of June 2012.

In addition to normal IPv6 Internet access we also set up some IPv6 services for our community members and for the all Internet:

  • Jabber XMPP server: A Jabber server running ejabberd is available with both public ipv6 and ipv4 address at jabber.ninux.org. The server is federated with the rest of the XMPP network and has proven a useful service for our community.
    More information (in Italian) can be found here: http://wiki.ninux.org/Jabber.
  • Openarena: Openarena is a first person shooting game based on the open sourced quake3 engine. An Openarena server is available at cleopatra.ninux.org:27960.
    More information (in Italian) can be found here: http://wiki.ninux.org/openarena_it.
  • Mumble server: Mumble is an open source low latency voice chat software that is really useful for quick conferences.
    The server has public IPv6 2001:4c00:893b:f2::2 and is reachable at port 64738.
    More information (in Italian) can be found here: http://wiki.ninux.org/Mumble.
  • Owncloud: Owncloud is an open source web application built in php that offers dropbox-like functionalities, we use it successfully to store documentation of our activities, like photos taken while building nodes or videos recorded at our events. We don’t use it only internally, infact we also allow other people who are not yet connected to our network to send us data: we often ask newcomers to send us photos of their roof in order to understand if we can connect them to any of our nodes and we give them access to our owncloud server to upload the photos easily. It has proved to be an useful and reliable service for our community.The server is reachable at https://obelix.ninux.org/owncloud/ with public ipv6 2001:4c00:893b:fa:230:48ff:fe73:53d.

Conclusion

The Ninux network is now ready for IPv6. Once we fixed the problems described in this document we updated all the nodes of the network. We have now 139 prefixes of size /64 active in our network. To the best of our knowledge we are one of the first Italian networks to deliver native IPv6 access to the home of Internet users.

After 1 year of testing and developing we feel ready for the world IPv6 day, and we are very proud of our experimentation done in a completely no profit way in the spirit of free and open source software.

We hope to see our IPv6 traffic increase on June the 6th !

We want to thank our upstream providers, Unidata, Ydea and E4A. We are very happy to cooperate with experienced companies that have worked for many years in the field of networking, it is a fantastic example of how the open source community can create chances for cooperation and innovation.

Improve remote monitoring and managing of OpenWrt

Monday, June 4th, 2012

After the good news of being accepted for the Google Summer of Code 2012, I have started to work hard on my project; first of all I have learned a lot of things about git, the version control system used by the community around eigenNet firmware to collaborate on the development of the OpenWRT based firmware suitable for community mesh networks, then I have created my own clone of the master repository, I started editing the code and then requested to merge into master when a set of feature was complete and tested enough.

What is done:

  • Selectable custom community CRDA
  • Pointing GUI
  • Bandwidth test server and GUI
  • Conditional  IPv4 gateway announcing
  • ATH5K driver support
  • 5GHz device support

What is not done yet:

  • Node Shot integration schema/classes
  • Community broad testing
  • Final adjustment

More news and updates soon!