Ninux.org Wireless Community

In questi giorni si stanno moltiplicando gli appelli per tenere aperte le connessioni Wi-Fi ad Internet nelle zone colpite dal terremoto.

Essendo Ninux.org una community di esperti in tecnologie che riguardano le reti wireless ci sentiamo in dovere di aiutare le popolazioni colpite dal terremoto.

Cominciamo con il condividere alcune informazioni molto importanti.

Condividere la connessione è legale

Il terribile decreto Pisanu, che obbligava coloro che volessero condividere la propria connessione ad internet a richiedere una licenza, non è più in vigore dal Dicembre del 2010.

Condividere la propria connessione ad internet attraverso una rete wifi non è illegale. In alcuni casi gli operatori che forniscono accesso ad internet fanno firmare dei contratti in cui è vietato espressamente la condivisione dell’accesso ad internet attraverso reti locali, in quel caso il massimo che può succedere è che l’operatore recida il contratto, ma questo va contro l’interesse dell’operatore stesso dato che il cliente può facilmente rivolgersi ad un operatore più permissivo.

Sono anni che noi di Ninux consigliamo di lasciare dei punti di accesso liberi ed aperti e in queste situazioni di emergenza questo consiglio diventa un dovere.

Condividere la connessione è facile

Quasi tutti abbiamo un router wifi a casa. Disabilitare la password di accesso è facile: basta accedere al pannello di controllo web del router, cercare la sezione “wifi” o “wireless”, quindi cercare la sezione “sicurezza” disabilitare la password quindi salvare le modifiche. La procedura potrebbe differire leggermente da router a router, se incontrate problemi non esitate a contattarci via email a contatti@ninux.org.

Estendere il raggio della propria connessione

Montando apparati omnidirezionali come le Ubiquiti PicoStation al di fuori della propria finestra o del proprio balcone è possibile estendere enormemente la copertura della propria rete wifi.

Se non potete comprare le PicoStation potete sempre montare il vostro router attuale nei pressi della vostra finestra o fuori al balcone, l’unico problema è che solitamente i router casalinghi non sono stati progettati per essere posti all’esterno e quindi potrebbero essere sensibili alle condizioni atmosferiche.

Se avete la possibilità di mettere un’antenna omnidirezionale sul vostro tetto è ancora meglio.

Costruire una rete wireless è possibile

Questo è il nostro argomento preferito: costruire reti wireless su territori vasti, dove ci siano molti punti d’accesso. Collegando queste reti wireless a più punti di uscita verso internet è possibile dare connettività ad aree molto vaste, non c’è un limite teorico, gli unici limiti sono la disponibilità di volontari e di fondi per comprare i materiali.  Le reti wireless sono molto adatte per le situazioni di emergenza perchè rispetto alle reti di telecomunicazione tradizionali richiedono molto meno tempo per essere costruite ed hanno un costo molto più basso.

Il costo di un nodo della rete Ninux solitamente si aggira tra i 150€ ed i 300€ ma credo che in casi di emergenza come questo si possano montare nodi temporanei con un budget tra i 100€  ed i 200€.

I volontari di Ninux possono dare una mano

Se volete più informazioni, supporto su uno o tutti i punti elencati precedentemente non esitate a contattarci a contatti@ninux.org, saremo ben lieti di darvi una mano.

In un variabile giorno di fine Maggio diamo il benvenuto a Matteo nella Grande Rete Ninux!

Iniziando puntuali come sempre alle 9.30 sotto un sole cocente la squadra si piazza sul tetto e monta in meno di mezz’ora staffe e palo; Fabio, Leo e Matteo scendono nell’appartamento tre metri sotto per preparare l’ingresso in guaina in casa, mentre Fish, Halino, Nazza e Dario finiscono di montare scatola, tiranti e antenne. Sistemato il tutto in tempi da record e con Hispanico e Torquato passati a fare un saluto il team chiude i lavori hardware alle 14,00 con lauto pranzo e caffettino contornato da scherzi telefonici!

(more…)

E’ stato gia’ scritto sul blog di Ninux ma non poteva mancare un post alla nuova casa del Fusolab sul mio blog.

Infatti nel passare da Marzo ad Aprile del 2012, il Fusolab è passato da Via Giorgio Pitacco 29, a Viale della Bella Villa 94. Un cambiamento di quelli che contano, di quelli che cambiano le abitudini quotidiane, di quelli che creano ricordi nostalgici. Cosi ora il martedi ed il giovedi, invece di andare al Fusolab, vado al Fusolab 2.0. Il video propone la prima riunione di gestione del Fusolab 2.0 che si è tenuta martedi 3 Aprile. E’ passato ormai un mese, e via Pitacco sembra già un ricordo di un posto lontano nel tempo :O

Dopo la felicità e l’eccitazione per l’accettazione al Google Summer of Code mi sono rimboccato le maniche e ho incominciato a prepararmi sul lavoro da fare.

Dietro consigli di Saverio ho studiato diversi documenti e libri sulla struttura di socket e la gestione della rete in ambiente unix, all’inizio tutti quei socket(), connect() e send() mi hanno lasciato spiazzato, ma con calma è pazienza ho assimilato i concetti di base.

Dovendo lavorare su un progetto in complesso e continuo mutamento come olsr si è presentata la necessità di utilizzare uno strumento per la gestione del codice scritto e organizzazione delle modifiche. L’utilizzo di git era quindi d’obbligo, ed essendo uno strumento potente anche qui bisognava cercarne di capire il funzionamento basilare prima di poterlo usare.

Dopo qualche ultima breve guida sull’utilizzo di vim e cscope ho potuto dare ufficialmente il via alle danze, ho fatto un fork della branch stable di olsr e da li si è potuto incominciare a lavorare direttamente sul plugin di mdns. Il problema attuale del plugin è che non distingueva se un pacchetto mdns presente nella rete locale era stato ricevuto dalla rete olsr oppure era stato generato localmente, per ovviare al problema ho dovuto modificare il Time to Live (o Hop Limit per l’ipv6) dei pacchetti mdns provenienti dalla rete olsr impostandolo ad 1, poi ho anche fatto in modo che il plugin scartasse i pacchetti mdns presenti nella rete locale con time to live uguale a 1. In questo modo i pacchetti generati da dispositivi presenti nella rete interna sarebbero tranquillamente passati nella rete olsr mentre quelli provenienti dalla rete olsr sarebbero stati comunque fruibili ai device sulla rete interna.

Dopo qualche piccolo problema per la gestione delle struct dei pacchetti ipv6 una prima versione del codice è ora pronta per il testing, utilizzando netkit ora mi aspettano le prove e se necessario il relativo debug.

Vi porto notizie relative a quello che sto implementando per quanto riguarda il progetto di Android Mobile Application orientato alla rete di Ninux .

Per chi non conoscesse la natura della mia APP si tratta in sostanza di visualizzazione dei nodi di una rete(nel nostro caso Ninux) e connessione ai medesimi.

L’obbiettivo è di arrivare al 21 maggio (la data di inizio del Coding) con qualcosa in mano. Le idee ci sono, la voglia di fare idem, per questo non ho perso tempo e dopo due incontri di Fusolab già c’è un prototipo funzionante.

Sono state implementate fino ad adesso le seguenti funzionalità:

– parser xml
– parser Json
– se il database dell’app contiene nodi e se non è scaduto il termine massimo per l’auto-refresh dei nodi (settabile in linea teorica dall’utente) allora (1), altrimenti (2)

• (1) recupero i nodi dal database
• (2) mi connetto al MapServer

tramite JAVA faccio richiesta HTTP di tipo GET verso http://map.ninux.org/nodes.json e recupero la struttura JSON ( sfruttando archittettura REST ).
tramite parser JSON recupero i nodi con relative info.
salvo nodi nel database interno all’APP ( se vuoto ) o sovrascrivo i precedenti.

• visualizzo una cartina di google centrata su centro desiderato.
• creo un marker per ogni nodo aggiunto in lista e lo sovrappongo alla mappa.
• al click del marker visualizzo tutte le info del nodo.

Ovviamente tutto OO oriented in linguaggio nativo Java.

Matteo