Archive for September, 2015

Battlemesh V8: caldo, ciccia e wireless

Monday, September 7th, 2015

È appena finita l’edizione 2015 del Wireless Battle of the Mesh (WBMv8 o semplicemente Battlemesh), a Maribor in Slovenia, dove una nutrita pattuglia ninuxara proveniente da tutt’Italia ha gloriosamente tenuto alta la bandiera della nostra community network.

Per chi non lo sapesse, il WBM è l’incontro annuale degli attivisti delle reti comunitarie europee: c’erano comunità Greche, Tedesche, Iberiche, Balcaniche e in più quest’anno anche alcuni Statunitensi e due Indiani hanno volato fino a Maribor per partecipare!

L’ambiente del WBM è unico perche´ mette a contatto persone attiviste, ricercatrici interessate allo sviluppo di nuovi protocolli, sviluppatrici dei protocolli stessi, professioniste che partecipano alle attività di standardizzazione di IETF, o semplicemente curiose.

Quest’anno l’organizzazione è toccata alla comunità di Wlan-Slovenia, possiamo senz’altro affermare che hanno fatto un gran bel lavoro!

La sede in cui eravamo ospitati era spaziosa, attrezzata, ogni giorno un ottimo ed economico catering (tanta ciccia, ad esempio i tipici ćevapčići, ma in molti hanno optato per un menù vegetariano e altrettanto squisito) permetteva di pranzare senza dover andare in città. L’unico problema è stato il caldo afoso, affrontabile solo grazie al venticello di collina e al frigorifero ben rifornito di radler e bibite fresche. Probabilmente in futuro si eviterà il mese di agosto anticipando alla primavera, come nelle precedenti edizioni.

Ma cosa si fa al WBM? In primo luogo, si provano i protocolli di routing ossia i software che si occupano di calcolare il miglior instradamento possibile per i pacchetti di dati che devono attraversare una complessa rete di computer e router wireless. Durante la settimana si prepara un testbed, uno scenario composto da nodi wireless (una decina in questo caso) su cui far girare i vari protocolli di routing che parteciperanno alla “battle”.

Quest’anno questo processo s’è scontrato con diversi problemi e persino un bug del driver wifi, richiedendo diversi giorni di lavoro: per arrivare a dei risultati, gli sviluppatori hanno formato almeno due gruppi indipendenti che applicavano approcci differenti, molti dei nostri ninuxari hanno dato un contributo fondamentale in entrambi i gruppi.

manual testbed group

blackboard

wibed

Una volta che il testbed è funzionante si creano ad arte situazioni difficili su cui provare i protocolli di routing, ad esempio, si osserva come i protocolli reagiscono quando si incrementa il traffico totale sulla rete o si modifica improvvisamente la topologia della rete. Dunque si confrontano le performances ottenute, ad esempio in questo grafico è mostrato quanto traffico riescono a trasportare i vari protocolli di routing e con quali latenze:

rrul-box

Su un singolo flusso di traffico TCP con la rete già carica da 60Mbps di traffico di background si nota come le performance in termini di latenza e di banda dipendano dal protocollo usato.

Non è facile interpretare in modo univoco la massa di risultati: sono spesso apparentemente contraddittori e imprevedibili da non permettere mai di dichiarare un vincitore assoluto tra i protocolli provati nel WBM. Ma il WBM non è una battaglia con vincenti e perdenti, quello che conta è il confronto a pari condizioni dei software per studiarne le differenze, trovarne i difetti, e, insieme agli sviluppatori, migliorare i protocolli di routing e di conseguenza migliorare le nostre reti. I risultati ottenuti sono stati raccolti, documentati e pubblicati su docs.battlemesh.org.

Oltre alla battle, il WBM è ricco di presentazioni e discussioni che permettono a chi non sta partecipando ai test di formarsi ed aprirsi a nuovi temi, anche non specifici delle mesh networks. Ad esempio, molto interessante è stata la presentazione del progetto Alexandria che utilizza IPFS e blockchain florincoin per creare un repository distribuito di file multimediali liberi. Sono stati anche presentati la nuova versione e il nuovo sito web di KORUZA, un sistema open hardware per realizzare link ottici wireless a 1Gbps.

Ci sono anche state alcune presentazioni da appartenenti alla nostra community: sul formato di interscambio dati per reti NetJSON (vedi anche netjson.org), su come estendere nmap usando LUA e sulle VPN basate su Multipath-TCP. Le presentazioni sono anche state filmate.

talks

Ci sono state anche diverse interviste, tra cui anche una riguardante la nostra community.

Nei buchi di tempo alcuni ninuxari hanno scritto un modulo per il nuovo firmware Libre-Mesh di modo da avere il supporto per il protocollo di routing OLSRv1. Nelle sale del WBM una piccola rete wireless funzionava perfettamente con i moduli Libre-Mesh per OLSR e per il routing a terra!

libremesh

Ci sarebbe tanto da raccontare sulla nostra settimana al WBM, sia su quel che ha funzionato che su quel che si potrebbe migliorare, ma non c’è racconto migliore della partecipazione diretta, potete iniziare iscrivendovi alla mailing list, leggendo il wiki e venendo di persona al prossimo WBM!!

PS: si ringrazia BornAgain per le bellissime foto in bianco e nero.

La FCC contro i firmware open source: fai sentire la tua voce

Wednesday, September 2nd, 2015

fcc_vs_openwrt

La Commissione Federale per le Comunicazioni americana (FCC) sta seriamente pensando di approvare nuove norme per i dispositivi dotati di una radio wireless operante nella banda dei 5 GHz (U-NII). Se approvate, obbligheranno i produttori ad applicare meccanismi di protezione che impediranno di sostituire i firmware di questi dispositivi (router, ma non solo: smartphone, tablet, qualsiasi cosa con una radio WiFi 5GHz) con versioni non approvate dal produttore, inclusi i sistemi operativi open source e Linux-based come Android e OpenWrt.

Queste norme sarebbero un disastro per la sicurezza e per la riduzione dei costi di noi utenti, per la possibilità di sperimentare e innovare nel campo delle comunicazioni wireless. Ma soprattutto costituirebbero un macigno sullo sviluppo delle reti comunitarie come Ninux, che utilizzano router a basso costo modificati con versioni personalizzate di Linux.

I produttori quasi sempre abbandonano gli aggiornamenti ai dispositivi poco dopo la loro immissione sul mercato. Questo impedisce che i bug di sicurezza vengano corretti per tempo, lasciando dispositivi centrali come i router esposti su Internet con delle vulnerabilità facilmente sfruttabili. La possibilità di sostituire il software consente all’utente di allungare la vita utile (e sicura) dei dispositivi che acquista.

Inoltre le funzionalità disponibili sono pressoché identiche tra i produttori, quasi sempre quelle più necessarie (e quindi lucrative), ma senza la possibilità di espandere l’utilizzo ad altri scenari meno comuni ma non meno importanti. La ricerca e l’innovazione sulle comunicazioni wireless hanno accelerato grazie alle modifiche illimitate finora possibili su dispositivi a basso costo. Lo sviluppo e l’avanzamento dei protocolli di routing che rendono possibili reti wireless mesh come Ninux, avvengono anche grazie a queste sperimentazioni.

Con ogni probabilità questa decisione non impatterà solo gli Stati Uniti: per come funziona la produzione massiccia dei dispositivi elettronici, quasi ogni produttore sceglie i forti risparmi che derivano dallo sviluppare un’unica soluzione che vada bene per tutti i mercati. Il blocco ai firmware dei router diventerà quindi il nuovo minimo comun denominatore per quasi tutti i nuovi router sul mercato nel 2016, dunque anche qui in Europa/Italia.

C’è ancora la possibilità di impedire che questo accada: la FCC è in fase di consultazione pubblica su queste nuove norme fino al 9 Settembre. Visitate questa pagina e inviate i vostri commenti cliccando su Submit a Formal Comment. Se non avete dimestichezza con l’inglese o non avete molto tempo per elaborare un testo originale, potete copiaincollare e/o modificare il testo qui sotto.

Per approfondire le ramificazioni di questa decisione, potete consultare il wiki SaveWifi, e questi tre articoli.

I ask the FCC to refrain from implementing such measures on restricting the modification of U-NII devices. It will hamper security, commerce, and innovation.

* manufacturers are known for their terrible record in providing security fixes, most of the devices involved are *never* updated during their lifetime, instead preferring to just ignore current devices and iterate on a new product. This has come to its ultimate consequences recently, when a software bug affecting a *billion* of smartphones has been discovered and won’t be fixed for almost all of the affected devices. 3rd-party firmwares are the only safeguard against this kind of situations: manufactures are not and cannot be forced to provide security fixes.

* Without the ability to modify the software running on these devices, nothing more than the very limited, more lucrative use cases addressed by the manufacturer would be implemented. This leaves behind advanced and/or custom scenarios which businesses could integrate on their services/products with very small costs by replacing the software.

* Research and innovation in wireless communications, ranging from entirely new designs, models and protocols to software implementations, would basically come to an halt, severely harmed by the unavailability of low-cost, readily-available solutions upon which to experiment. Community Mesh Networks are entirely reliant on the ability to customize low-cost networking equipment.

* These rules are overreaching and not even helping in ensuring compliance. Virtually none of the FCC rule breaches is due to 3rd-party software modification. It is however *still* possible to trivially enable non-compliant modes on unmodified devices on major wireless equipment manufactures.

Thanks for listening.