Chi siamo

Siamo un gruppo di appassionati di tecnologia, del fai da te e del software libero. Ispirati dal progetto Ninux di Roma vogliamo realizzare anche a Firenze (e dintorni) una rete wireless libera da censure e di proprietà delle persone.

Vuoi partecipare?

  • Vai sulla mappa e aggiungi un nodo potenziale
  • Iscriviti alla nostra mailing list
  • Vieni ad una riunione del gruppo: gli incontri avvengono il Lunedì ogni 2 settimane presso la sede all'exfila (via Monsignor Leto Casini, 11, Firenze, mappa) alle ore 21.00.

    Resoconto della riunione del 1° febbraio 2016

    C’erano diverse persone, tre del comitato mamme no inceneritore e 6 ninuxari ed abbiamo fatto due cose:

    • abbiamo discusso del progetto mamme no inceneritore, il cui scopo è quello di costruire una rete di sensori di PM10/PM2.5 nella zona della piana, per monitorare l’inquinamento ambientale dovuto a diverse fonti (macchine, fabbriche, aeroporto ecc…).

      Il comitato è molto attivo ed ha il supporto di persone molto preparate per mettere in piedi un sistema di monitoraggio complementare a quello di ARPAT, che in quella zona è molto carente.

      Marco ci ha fatto vedere alcuni sensori su cui stanno lavorando e potremmo collaborare mettendone alcuni sui nostri nodi.

      Il discorso è lungo, ci sono diverse variabili (prezzo, posizione, taratura…) ma ci è parsa un’idea molto bella, sia per loro, che possono mettere i sensori nei nostri nodi, sia per noi che possiamo mettere qualche nodo in più per collegare i loro sensori. Una volta fatto si dovrà trovare il modo di raccogliere questi dati e visualizzarli in modo facile.

      Tutti i dati, il codice, e l’hardware saranno open-data/source.

      Siamo rimasti che entro qualche settimana loro intendono fare dei test su alcuni modelli di sensori che hanno già comprato, cominceranno a lavorare col fablab per progettare un case da esterni ed a quel punto noi cominceremo a montarli nei nodi esistenti, in modo da cominciare a debuggare tutte le problematiche di installazione “in produzione”.

      Ci dobbiamo aggiornare entro qualche settimana.

    • Siamo saliti sul tetto e abbiamo tolto le due radio fritte (che ora sono nell’armadio) e orientato meglio le due radio funzionanti, una verso baldarn (che in realtà già andava bene) e una verso masaccio (che invece puntava a sud…).

      Il miglioramento è stato sensibile.

      Dobbiamo sempre risolvere il problema della VPN su tank che risucchia traffico anche quando ETX non è così male. E questo direi che è il punto della prossima riunione.

    Prove di collegamento con il nodo potenziale della Casa del Popolo di Osteria Nuova

    Sabato 31 ottobre 2015 abbiamo approntato gli apparati per effettuare le prove di collegamento con il nuovo nodo potenziale della Casa del Popolo di Osteria Nuova e la nostra sede.

    In mattinata abbiamo installato un apparato M5 sul tetto puntata nella direzione appropriata fissandola sul palo già presente ed usato per gli altri apparati e collegandola allo switch della scatola. Purtroppo non avevamo un altro injector per alimentare la nuova M5 e quindi abbiamo dovuto staccare quella puntata verso le Case Nuove di San Romolo: ovviamente ci siamo ripromessi di rimettere tutto a posto appena possibile.

    Scatola di Bellanzer2

    Dopo il lauto pranzo nella nostra solita pizzeria della zona siamo andati alla Casa del Popolo ed abbiamo fatto alcune prove di collegamento. Non siamo saliti sul tetto perché non è facilmente raggiungibile ma anche da posizioni piuttosto coperte abbiamo ottenuto collegamenti con valori di -78db piuttosto incoraggianti.

    Tetto della Casa del Popolo di Osteria Nuova

    NetPing - Progetto di monitoring e analisi della rete Ninux-Firenze

    Fare streaming delle nostre attività sulla rete Ninux ?

    Attivare servizi di archiviazione , sincronizzazione e Data base condivisi?

    Ascoltare musica e condividere contenuti ?

    Tutto è possibile e a questo stiamo pensando noi “ninuxari” del gruppo di Firenze.
    Per farlo ci vuole che la comunicazione tra i nodi sia affidabile , stabile e veloce.
    Ci siamo guardati in faccia e ci siamo chiesti :”Come sta la nostra rete?”.
    Dopo un imbarazzante silenzio abbiamo risposto : “Non lo so!”

    E’ da questa necessità che è venuta l’idea del progetto NetPing: un sistema per verificare la velocità di connessione tra un nodo ed un altro e di come questa varia nel tempo. Il sistema si basa sul concetto trasmettere pacchetti (TCP) di lunghezza nota al nodo vicino (1-hop). La velocità di comunicazione è calcolata in base al tempo necessario a trasmettere i pacchetti e quello di ricevere la risposta. Lo strumento adeguato a questo scopo è il comando di “ping” mediante il quale si possono trasmettere pacchetti in numero e lunghezza variabile, la risposta fornita contiene già informazioni sul tempo minimo medio e massimo di trasmissione. Se i pacchetti sono abbastanza lunghi si può affermare con buona approssimazione che il tempo di trasmissione è proporzionale alla velocità di comunicazione tra i nodi. Ad esempio : con

    #ping -c 10 -s 800 172.19.180.1
    #172.19.189.1 ping statistics
    #10 packets transmitted, 10 received, 0% packet loss, time 32ms
    #rtt min/avg/max/mdev = 2.209/3.298/5.260/0.981 ms, ipg/ewma 3.573/3.736 ms

    si calcola che la velocità media di comunicazione con il nodo 172.19.189.1 è di 1600*8/3.298) = 3381 kb/s

    Il sistema è così organizzato:

    Su ogni nodo sul cui apparato gira OLSR (OpenWrt , Debian ..) viene installato lo script:

    #check_neighs.sh

    questo viene attivato ogni ora con cron e aggiorna il file “ping.csv” che riporta i risultati del ping eseguito verso i nodi vicini 1-hop. E’ necessario che il nodo fornisca un servizo HTTP. Da qualche parte, nella rete, (nel nostro caso : 10.150.28.10) è presente un server che a cadenza di un ora interroga ogni nodo e scarica il file “ping.csv” attraverso

    #wget :http//indirizzo_del_nodo/ping

    ne esegue la differenza con quello scaricato durante la precedente scansione e archivia i dati nel data base (MySql) net_ping.

    Schema di Netping

    Al momento il sistema è attivo su sette nodi della rete e sta fornendo i primi risultati. Contiamo di poter installare lo script su tutti i nodi entro la prossima setimana. Stiamo lavorando ad un sistema di analisi e rappresentazione dei dati Web Based.
    Un esempio è qui.

    Il progetto è interamente scaricabile da: https://github.com/ninux-fi/monitoring_scripts.git

    Halloween Cyberpunk del gruppo Ninux Roma

    In occasione del prossimo halloween il gruppo Ninux Roma organizza una festa presso la propria sede del FusoLab di raccolta fondi.

    Questo è l’articolo per maggiori informazioni.

    ffmpeg questo s-conosciuto

    Durante gli ultimi incontri ci siamo concentrati sulla possibilità di sperimentare lo streaming audio-video sfruttando in parte la rete ninux.

    L’idea è stata quella di sfruttare l’occasione della festa dell’exfila degli scorsi 11-12-13 settembre come pretesto per mettere alla prova la rete e streammare qualche evento musicale e così abbiamo iniziato la sperimentazione.

    Per ridurre le variabili in gioco abbiamo scelto il canale di youtube come streamer finale verso l’utente, per ovvii motivi, così ci siamo concentrati sul software ffmpeg, per la cattura, l’encoding e la pubblicazione server-client per la trasmissione verso i server di youtube.

    La cattura è avvenuta sfruttando una banale web-cam usb rilevata su /dev/video0 di un portatile. La riga di comando per catturare dal dispositivo video e audio e stremmare su un server è simile alla seguente:

    ffmpeg -f v4l2 -i /dev/video0 -f alsa -ac 2 -i pulse -s 426x240 -vcodec libx264 -pix_fmt yuv420p -vb 1000k -profile:v auto -preset:v fast -g 60 -r 30 -acodec libmp3lame -ab 128k -f flv "rtmp://a.rtmp.youtube.com/live2/nome.utente.aaaa-bbbb-cccc-dddd"

    Descrizione di alcuni parametri:

    • -i = input

    • -ac = numero di canali audio

    • -s 426x240 = risoluzione del frame. I formati accettati da youtube sono: 426x240 854x480 1280x720

    • -vcodec libx264 = video codec suggerito da youtube

    • -pix_fmt yuv420p = formato del pixel richiesto da youtube

    • -vb = video bitrate adeguato alla risoluzione scelta.

    • -preset:v fast = è la qualità con cui viene effettuato l’encoding. Migliore è la qualità (slow), maggiore impegno per la cpu ma flusso più leggero sulla rete!

    • -g 60 = video gop size. È la quantità di fotogrammi tra un keyframe e l’altro. 60 significa un keyframe ogni 2 secondi (suggerito da youtube) se imposto il framerate a 30.

    • -r 30 = framerate (richiesto da youtube)

    • -acodec libmp3lame oppure aac è il codec di compressione audio richiesto da youtube.

    • -ab 128k = bitrate audio.

    La seconda parte della riga di comando -f flv “rtmp://a.rtmp.youtube.com/live2/nome.utente.aaaa-bbbb-cccc-dddd” produce l’output verso i server youtube, rispettando i requisiti severi di quest’ultimo.

    Qui sono sorti i primi problemi. La banda in upload da exfila non era sufficiente così abbiamo pensato di utilizzare un tool di ffmpeg, ffserver che si occupa di pubblicare una sorgente audio-video, dopo averla encodata nel formato adatto, nella nostra rete ninux.

    Questa la rigadi comando per ffserver:

    ffserver -f ffserver.conf

    Questo il file di configurazione:

    [ffserver.conf]

    HTTPPort 8091
    
    HTTPBindAddress 0.0.0.0
    
    MaxHTTPConnections 1000
    
    MaxClients 10
    
    MaxBandwidth 333000
    
    CustomLog -
    
    <Feed feed1.ffm>
    
    File /tmp/feed1.ffm
    
    FileMaxSize 400K
    
    ACL allow 127.0.0.1
    
    launch ffmpeg -f v4l2 -i /dev/video0 -f alsa -ac 2 -i pulse 
    
    </Feed>
    
    <stream live.flv>
    
    Format flv
    
    Feed feed1.ffm
    
    VideoCodec libx264
    
    VideoFrameRate 30
    
    VideoBitRate 800
    
    VideoSize 426x240 #854x480 #1280x720 #426x240
    
    VideoGopSize 30
    
    VideoBufferSize 1000
    
    AVOptionVideo crf 23
    
    AVOptionVideo preset fast profile auto
    
    PixelFormat yuv420p
    
    AVOptionVideo flags +global_header
    
    AudioCodec aac
    
    Strict -2
    
    AudioBitRate 128
    
    AudioChannels 2
    
    AudioSampleRate 44100
    
    AVOptionAudio flags +global_header
    
    </Stream>
    
    <Stream stat.html>
    
    Format status
    
    ACL allow localhost
    
    ACL allow 192.168.0.0 192.168.255.255
    
    </Stream>
    
    <Redirect index.html>
    
    URL http://www.ffmpeg.org/
    
    </Redirect>
    

    A questo punto è bastato utilizzare un’altra macchina su un nodo direttamente collegato alla fibra 30/3 con un ffmpeg che richiedeva al ffserver il flusso e lo “copiava” sui server youtube. Questa è la riga di comando locale:

    ffmpeg -i http://10.150.22.xxx:8091/live.flv -codec:copy -f flv "rtmp://a.rtmp.youtube.com/live2/nome.utente.aaaa-bbbb-cccc-dddd"
    

    Questa ci è sembrata la soluzione ideale, anche se perfezionabile, per sfruttare la rete ninux ad alta velocità e uscire da una fibra per l’upload.

    Anche se tecnicamente tutto ha funzionato, i risultati in termini di qualità non sono stati all’altezza delle aspettative a causa della rete attualmente non in perfetta efficienza, ma abbiamo già programmato una serie di test per individuare i nodi deboli da potenziare.