Re: [Ninux-Wireless] Fwd: [Bologna] estate ninux - compere collettive

[Stefano De Carlo]

Ciao Cris,

il doc è quello che ti ha linkato Luigi. Il fulcro essenziale è, come
detto, quello di introdurre la reciprocità.

Lo introducemmo in lista calabria (
https://ml.ninux.org/pipermail/calabria/2017-April/013047.html) spiegando
il rationale e il contesto dietro la prima bozza. La formattazione della
mail è ignobile e quindi meglio il pastebin (https://pastebin.com/S1AKnVnB).

È operativo, siamo contenti perché sta funzionando ma è sempre una bozza.
L'idea del doc è quella di un rolling, ne stiamo valutando l'impatto nel
mentre che ristrutturiamo profondamente il progetto. Ad esempio c'erano
delle limature discusse con Leo di Firenze che non abbiamo (ancora)
espresso a testo. Feedback is welcome!

Lo spirito è proprio quello del contratto sociale a-la Debian, e anche del
Code of Conduct. Nelle ricerche che abbiamo fatto abbiamo anche tradotto 2
doc simili, con l'idea che alcune delle cose confluiranno nei doc della
nostra rete

* Il FONN Compact di Guifi (http://wiki.ninux.org/FONNCompact)
* Memorandum of Understanding di Freifunk (
https://github.com/stefanauss/FreifunkMoU/blob/master/FreifunkMemorandumofUnderstanding_it.md
)

Un punto della situazione della nostra ricerca sui "Social Contract" per le
community network l'ho fatto in un talk alla traccia Ninux del Merge-it
2018. Le slide che ho usato sono qua:
https://drive.google.com/open?id=1ITfuej5pALDp1bDxSrUUCqUPrFK8LIhL

Spero tutto questa vi possa essere utile!

Stefanauss

Il giorno mer 19 giu 2019 alle ore 11:08 kiki 
ha scritto:

> Mi ricordo che i cosentini parlavano l'anno scorso di aver fatto delle
> "aggiunte locali" al pico peer agreement..
> non le trovo in internet... me le potete passare?
>
> che anche a bologna siamo in aria di fare "patti sociali" tra i componenti
> della rete.. e errori, suggerimenti, esperienze sono sempre gradite.
> ciao !
>
> Cris
>
>
___
Wireless mailing list
Wireless@ml.ninux.org
https://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] CORE Network tutorial

[Stefano De Carlo]

Molto ben composto, grazie Peppe

Il giorno dom 24 feb 2019 alle ore 00:34 Giuseppe De Marco <
demarco...@gmail.com> ha scritto:

> Scritto un tutorial per un giovane cugino che si sta cimentando nelle reti.
> Condivido così com'è,
> https://github.com/peppelinux/Common-Open-Research-Emulator-CORE-Tutorials
>
> buon week
> ___
> Wireless mailing list
> Wireless@ml.ninux.org
> https://ml.ninux.org/mailman/listinfo/wireless
>
___
Wireless mailing list
Wireless@ml.ninux.org
https://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] test

[Stefano De Carlo]

Il 22/02/19 10:33, nino ha scritto:
> Ora tutte le interfacce di gestione dovrebbero funzionare bene.
> Datemi feedback
> Ciao
> Nino

Ciao Nino,

ho provato e ora funziona. grazie mille

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
https://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] test

[Stefano De Carlo]

Ciao Nino,

non riusciamo a moderare i messaggi nella lista calabria.

nel pannello admin clicchiamo sulla decisione da prendere, ma il submit
redirige alla stessa pagina col messaggio ancora presente.

In alcuni casi dopo la mancata decisione arriva una nuova mail
riepilogativa con l'elenco dei messaggi in moderazione, quindi nei vari
tentativi ci sono arrivate una 20ina di mail di fila.

Inoltre la base URL di mailman è rimasto quello vecchio senza https,
quindi quando ad ogni submit compare un messaggio che mi avvisa che i
dati saranno inviati in chiaro.

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] test

[Stefano De Carlo]

Esattamente, riguarda la crittografia in transito

Il giorno mar 5 feb 2019 alle ore 10:50 Saverio Proto 
ha scritto:

> > Penso si riferisca al fatto che l'archivio web sia http.
>
> No, si riferisce al fatto che il mail server della mailing list non
> usa TLS per consegnare le email.
>
> Saverio
> ___
> Wireless mailing list
> Wireless@ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/wireless
>
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nodo IMPERIAL-OPPIDO

[Stefano De Carlo]

Il 21/11/18 22:50, Michele Salerno ha scritto:
> Ragazzi, non so perchè non ho più trovato il nodo...l'ho reinserito.
> Me lo passate a verde?
> http://map.ninux.org/select/imperial-oppido/
>
> Grazie.
> Michele


Attivato

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Telegram

[Stefano De Carlo]

Il 22/10/18 11:29, Fabio Casolari ha scritto:
> Immagino che sapere quale è il canale telegram   no vero?
>
> giusto perche la ML è piuttosto muta


Qui trovi tutto: http://wiki.ninux.org/telegram :)

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Telegram

[Stefano De Carlo]

Il 29/09/2018 20:50, Massimiliano ha scritto:
>
> Quindi secondo te qual e' la motivazione che il traffico ML e' quasi
> nullo ?

È una cosa semplice: l'aggregato dei vantaggi delle ML (alcuni dei quali
hai elencato) e degli svantaggi di Telegram (alcuni dei quali hai
elencato) non è sufficiente affinché la maggior parte delle persone
rinuncino a poter *comunicare col minor sforzo* e con *metodi più
familiari*, cosa che (evidenza empirica) è la loro priorità.

Quello di sopra è il fatto catalizzatore. Dopodiché subentra il network
effect che si tira dentro la minoranza che sarebbe, in linea di
principio, neutrale verso lo strumento.

> Se dovessi esprimere (nella peggiore delle ipotesi) in percentuale il
> non utilizzo di Telegram e altri nella comunicazione Ninux quanto
> riporterebbe in termini di traffico all'interno delle liste ?

Appena pochi giorni fa ho postato lo stesso messaggio riguardo a come
usare dei fondi che erano appena arrivati per Ninux, sia su Telegram che
sulla lista.
Quindi un argomento non dico "importante" ma comunque di interesse
comune, con uno scopo, ci sono degli sbattimenti di più persone dietro,
non una cazzatella insomma.
ZERO risposte sulla lista.
DECINE su Telegram (e non è stato nemmeno uno dei topic più partecipati).
Questa per me è la peggiore delle ipotesi.


> Avere diversi strumenti di comunicazione puo' essere funzionale ma
> ognuno di loro dovrebbe essere utilizzato per cio' verso cui riesce a
> rendere un buon risultato.
>
> Utilizzare Telegram indistintamente per ogni tipo di comunicazione
> potrebbe ridurlo nel ns caso ad un simil Facebook o Whatsapp.
>

Fin quando non ci sarà uno strumento (che mi pare evidente non sarà la
ML) dove l'aggregato dei vantaggi dello strumento e degli svantaggi di
Telegram, ridotto dell'attrito [1] dovuto ad un'eventuale transizione,
non sia tale da far rivalutare il bilancio delle priorità ad almeno una
parte di chi comunica su/di/con Ninux, temo che avremo "indistintamente
ogni tipo di comunicazione" su Telegram.

> Che siamo [...] me lo permetti ?

"""Ti permetto""" tutto questo e tutto il resto, ma essendo questioni
che, al di là del merito, sono completamente ortogonali al tema dello
strumento di comunicazione che si sta trattando, non entro nell'off-topic.

> Non volermene se ho utilizzato toni poco rispettosi nei tuoi confronti.

Mi sembravano toni normalissimi, no problem comunque :)

Stefanauss.

[1] Anche e soprattutto "politico", vedi lo sciagurato flame "serve un
forum" negli archivi ninux.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] problema di connessione internet tra router

[Stefano De Carlo]

Il 25/09/2018 00:14, Michele Salerno ha scritto:
> Ecco i file:
> Router B (senza internet)
>  - network: https://pastebin.com/0JD66LjX
>  - wireless: https://pastebin.com/eQq7cr4i
>  - firewall: https://pastebin.com/tq77JhES
> - olsrd2: https://pastebin.com/gmnt9DDv
>
> Router A (con internet)
>  - network: https://pastebin.com/JaXrm7sp
>  - wireless: https://pastebin.com/vgyEQRxS
>  - firewall: https://pastebin.com/95k98Sst
> - olsrd2: https://pastebin.com/0C4YGGnj
>
> Grazie

Nel router senza internet, prova a cambiare nella config firewall la
zona ninux

config zone 'cfg14dc81'
    option output 'ACCEPT'
    option name 'ninux'
    option input 'ACCEPT'
    option forward 'ACCEPT'
    option network 'ninux vpnbas Ant1 Ant2 Ant3 Ant4 ANT_1 ANT_2'
    option masq '1'
    option masq_src '192.168.20.0/24'

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] 580€ per Ninux, come spenderli?

[Stefano De Carlo]

Salve Ninuxers,

la settimana scorsa sono arrivate 580 € del compenso che Clauz e
Leobowski hanno recepito per aver scritto un articolo Giswatch su Ninux
pubblico da APC

Clauz e Leo (grazie!) li hanno messi a disposizione della community
Ninux, da utilizzare come ci piace.

Quindi ora siamo alla ricerca di idee su come spenderli :)

Chiaramente sarebbe preferibile

- Qualcosa i cui benefici siano possibilmente non limitati direttamente
ad una singola isola/nodo
- evitare di instaurare una spesa ricorrente

Ma niente è precluso, siamo aperti a tutte le buone idee.

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] problema di connessione internet tra router

[Stefano De Carlo]

Il 24/09/2018 18:05, Michele Salerno ha scritto:
> er spiegare meglio: sulla eth0.5 è collegata una bullet M2, sul
> router è impostato il dhcp su quella interfaccia etc.
> Un client, il mio tablet, prende l'ip, prende i dns prende tutto
> correttamente ma non va fuori da quella rete, come se il routing tra
> quelle interfacce non esistesse.

Ciao Michele,

qualsiasi cosa stai provando a troubleshootare, non puoi farlo
avvalendoti dell'opzione source interface di ping.

Busybox (che fornisce ping in wrt) non ha l'implementazione completa.
Persino sul mio PC linux con binario standalone, se forzo una
interfaccia diversa, il traffico avviene regolarmente ma il processo
ping che lo genera NON vede le risposte, segno che il kernel non lo
restituisce correttamente.
Inoltre, a seconda dei casi, potresti essere vittima dell'opzione
"reverse path filter", per cui un pacchetto che non dovrebbe uscire da
lì, viene droppato prima.

Ho capito giusto che:
- un client collegato in wireless alla bullet M2, che negozia un ip
192.168.20.0/24, poi non riesce ad uscire su internet?
- che la bullet è collegata su eth0.5

?

La cosa nettamente più probabile è che la rete 192.168.20.0/24 non viene
nattata correttamente da uno dei due router, a seconda della configurazione

/etc/config/network,wireless,firewall di entrambi i router?

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Telegram

[Stefano De Carlo]

Il 16/09/2018 20:44, Massimiliano CARNEMOLLA ha scritto:
> Da un po' di tempo a questa parte stiamo utilizzando Telegram e forse
> altri canali di comunicazione che stanno togliendo valore alle
> funzionalita' della Mailing List.
>
> Il risultato e' un traffico quasi nullo di quest'ultima, con perdita
> dello storico delle esperienze che condividiamo ogni giorno tra di
> noi, segnalando problemi, trovando soluzioni, proponendo idee,
> condividendo opinioni etc.

Ciao,

dal punto di vista prettamente pratico, la "perdita dello storico" non è
un dogma, esistono millemila modi raggiungibili di preservare lo storico
anche attraverso Telegram, basta prendersi la cetriolaggine di
implementarli.

L'intero ragionamento che fai si basa sull'assunto che, a levare
Telegram, quelle interazioni semplicemente si (ri)sposterebbero in lista.
Cosa che non sta ne in cielo nè in terra.

Il gruppo Telegram è nato come strumento supplementare (nemmeno
inventivato o particolarmente visibile!), ma si è rapidamente
trasformato nel principale strumento di comunicazione Ninux in maniera
naturale. Anche gli heavy-users della ML hanno privilegiato Telegram.
Evidentemente quel tipo di strumento è più vicino a quello di cui si
sentiva il bisogno tra i ninuxer.

La quantità di interazioni (condivisione di problemi, opinioni, idee,
soluzioni, ecc) prima e dopo l'apertura del canale è imparagonabile. Le
comunicazioni non strutturate e senza troppe formalità, la facilità di
contatto, la possibilità di parlare estemporaneamente, hanno incentivato
un sacco di nuove partecipazioni alle discussioni.
Personalmente non vedo che beneficio ci sia ad avere 3 interazioni al
mese tra i 4 soliti noti che si prendono la briga di aprire il client di
posta, PERFETTAMENTE DOCUMENTATE e A IMPERITURA MEMORIA, quando possiamo
averne 100 con almeno 10 che dicono la loro, senza sforzo, anche se
senza traccia scritta.

Chissenefregadegliarchivi (e se ce ne frega, si può fare!).

>
> Nonostante tutti i buoni propositi di questo mondo ogni giorno ci
> comportiamo come i granchi, facciamo un passo avanti e due indietro.

Per me è due passi avanti (aumento dei contenuti, aumento dei
partecipanti) e uno indietro (semi-open, semi-standard)

>
> Riusciamo tutti insieme a fare Comunita' e trovare un modello/metodo
> di lavoro che porti il progetto a raggiungere un buon livello in
> termini di risultati ? 

Un buon metodo di lavoro è saper riconoscere cosa sta funzionando e cosa
no e migliorarlo, senza prenderlo come scusa per stare fermi ma nemmeno
senza cercare per forza di ricondurlo ai propri preconcetti su come le
cose dovrebbero essere.

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] problema di connessione internet tra router

[Stefano De Carlo]

Il 22/09/2018 17:23, Michele Salerno ha scritto:
> Dal router B se faccio un ping verso google.it funziona, da una delle
> antenne se faccio un ping verso internet funziona.
> Ma se faccio ping -I eth0.3 google.it ottengo un "Destination Host 
> Unreachable"
> stessa cosa se cambio in eth0.4 o 5

Ciao Michele,

non ho capito perché dai questi ping specificando con l'interfaccia
sorgente.
Cosa stai cercando di dimostrare?
Qual'è il problema concreto che stai cercando di risolvere? Chi non ha
connettività con cosa?

Sulle antenne, hai impostato l'ip HNA del router come default gw?

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] problema con config ad-hoc

[Stefano De Carlo]

Il giorno sab 2 giu 2018 alle ore 20:28 Michele Salerno
 ha scritto:
>
> Vorrei avere 2 router connessi in modalità ad-hoc ma sembra non si
> connettono ne l'interfaccia sale su.
> Premessa: uno dei 2 router è un TP-Link C2600 che per come ho provato
> a problemi con le VLAN e mi viene il dubbio che sia un problema
> fisico.
>
> Avete qualche idea da suggerirmi?
>

Qualche log dove il problema si manifesta?

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] OpenWisp e Ansible NNXX 2 router nella stessa LAN

[Stefano De Carlo]

Il 05/04/2018 17:25, Michele Salerno ha scritto:
> Dal router (A) con router -n vedo tutti i router connessi al server OpenWisp.
> Dal router (B) vedo le 2 reti /25, la rete della VPN ma le altre no

Ciao Michele,

non ho capito esattamente quali voci della tabella di routing non ti
convincono.

Io vedo alcune rotte di servizio che servono a garantire che il
raggiungimento di alcuni host remoti passi sempre e comunque dal tunnel
e non da un eventuale default gw presente. Le aggiungono i software VPN
in automatico, tipicamente.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] WireGuard: Next Generation Kernel Network Tunnel

[Stefano De Carlo]

Il 10/01/2018 12:57, Germano Massullo ha scritto:
> Pull request approvata, ora WireGuard è disponibile in systemd-networkd

È interessante che Torvalds stesso spinge per avere Wireguard incluso in
Linux: https://lkml.org/lkml/2018/2/13/752

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] IRC meeting 26/03/18 (log) + anticipo prossimo?

[Stefano De Carlo]

Posto i log dell'ultimo IRC meeting per chi se lo fosse perso

http://86.119.33.5/ninux_org_irc_meeting_2018_03_26/2018/ninux_org_irc_meeting_2018_03_26.2018-03-26-19.20.html
http://86.119.33.5/ninux_org_irc_meeting_2018_03_26/2018/ninux_org_irc_meeting_2018_03_26.2018-03-26-19.20.log.html
http://86.119.33.5/ninux_org_irc_meeting_2018_03_26/2018/ninux_org_irc_meeting_2018_03_26.2018-03-26-19.20.txt

Il prossimo "ultimo lunedì del mese" è il 30 Aprile, ovvero giusto prima
del primo maggio, profumo di ponte in ogni dove.

Se non ci sono mozioni contrarie, in via eccezionale fisserei il
prossimo meeting per Lunedì 23 Aprile 2018.

Qui costruiamo l'ordine del giorno per il prossimo meeting:
https://pad.ingmg.com/p/ninux-org-irc-meeting-odg-od24us7 (pad sponsored
by Hispanico :)

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Punto su ninux @ merge-it 2018

[Stefano De Carlo]

Il 13/03/2018 09:22, Leonardo Maccari ha scritto:
> Ciao,
>
> scusate la latitanza.
> Io posso allungare un po' il mio talk e fare un'introduzione alle reti
> comunitarie e ninux, prima di parlare del progetto.

Update. Ho aggiunto al nostro programma l'intervento di SFSC e riempito
di un ODG il momento tavola rotonda, che è stato spostato al pomeriggio.
Ho anche avuto l'OK di Clauz per ridurre il suo talk a 30m, in modo da
incastrare tutto meglio. Il programma diventa questo e lo dovrebbero
pubblicare a breve sul sito, ho già mandato la pull request:

12:30 Il progetto netCommons
13:00 Licenza per reti libere e aperte

14:30 SFSC
15:00 Girantenna
15:30 Protocolli di routing
16:00 IoT comunitaria
16:30 Kiotlog
17:00 Tavola rotonda (1h)

Descrizione della Tavola Rotonda:

Momento di discussione libera con i relatori, la community Ninux, gli
esponenti delle altre community network italiane e il pubblico del
Merge-it sui temi presentati durante la sessione (ma non solo). In
particolare proponiamo all'ordine del giorno:

* Net Neutrality
* ISP Comunitari (Do-it-yourself ISP)
* Privacy
* Autoprovisioning di servizi
* Licenze e Accordi di peering nelle reti comunitarie
* Situazione normativa, #RadioLockdown europeo in particolare (RED)

Stando così le cose, abbastanza imbucate anche secondo i piani originali
se vogliamo, rinuncerei a fare il mini-momento divulgativo tanto per
averlo e lascerei eventuali (frammenti di) pippone ninux a margine, per
chi si avvicina per chiedere qualcosa in più, qualche menzione qua e là
che sicuramente si farà nei talk anche se sono complessivamente più tecnici.
Alla fine, guardando bene, anche le altre community sono andate sul
tecnico e non c'è un "talk di azzeramento".

Sta bene?

> Posso anche fare un secondo round di email per convincere qualcun'altro
> a venire degli altri ISP comunitari.
>
> ciao,
> leonardo.

Secondo me si può fare, ma solo in funzione di comunicare il programma
definitivo e proporre la partecipazione alla tavola rotonda, non più
call4talk.

Sto seguendo cosa intendo fare gli organizzatori per l'apericena del 23,
e dobbiamo organizzarci per il pranzo-lampo del 24.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Traduzione italiana del FONN Compact di Guifi

[Stefano De Carlo]

Ciao lista,

volevo segnalare che ho pubblicato sul wiki la mia traduzione in
italiano del FONN Compact, che per chi non lo sapesse è la Licenza di
Rete che tutti i partecipanti alla rete Guifi.net devono sottoscrivere.

http://wiki.ninux.org/FONNCompact

La traduzione è stata fatta anche e soprattutto in funzione del filone
"PicoPeering evoluto" di cui si è discusso al Ninux Day e che stiamo
portando avanti in Ninux Calabria da un po'.

Buona lettura per chi vorrà (servono 15min credo) e fatemi sapere se non
vi torna qualcosa.

Stefanauss

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Punto su ninux @ merge-it 2018

[Stefano De Carlo]

Il 07/03/2018 12:56, Claudio Pisa ha scritto:
> On 03/05/2018 02:31 AM, Stefano De Carlo wrote:
>> Il programma è grosso modo quello, ma è ancora provvisorio perché
>> mancano delle piccole grandi cose da valutare e decidere ed è apprezzato
>> il feedback di tutti (in particolare di chi effettivamente ci sarà):
>>
>> * in generale c'è il "problema" di avere 1h in più rispetto al solo
>> pomeriggio, un'opportunità da sfruttare :)
>>
>> * la cosa più importante è: faremo assemblea? e se la faremo, la
>> facciamo classica alla ninux day o qualche forma di tavola rotonda
>> diversa dal solito pensata ad-hoc per il merge-it? In ogni caso è bene
>> pensare ad un odg
> Per l'eventuale assemblea avremmo solo un'ora, giusto? In questo caso mi
> sembra poco tempo per un'assemblea. Forse sarebbe meglio avere una
> tavola rotonda tematica. Come temi mi vengono in mente net neutrality,
> privacy e autoprovisioning di servizi, licenze di peering o la RED.

Al momento si, 1h o giù di lì.
Ok, se <= 1h, tavola tematica.
Se confermata la presenza di SFSC io introdurrei sicuramente tra i temi
quello degli ISP comunitari.
Ed effettivamente, come dici dopo, anche se non ci saranno è un tema
interessante

>> * ricordo che ci sarà un'aula "lounge" con tavoli + ciabatte,
>> sfruttabile per attività a margine, smanettamenti, ecc
> Aula condivisa, non ninux-only, giusto?

Si, la lounge si, condivisa.

> Abbiamo gia' questo:
> https://blog.ninux.org/2018/01/17/ninux-merge-it-2018/
> Hai gia' in mente i contenuti del nuovo post?

* merge si avvicina
* programma definitivo
* perché partecipare (sia per i ninuxer che per gli esterni)

>> * spamming
>> * contarci per bene
>> * organizzare il pranzo del sabato (veloce perché c'è solo 1h di buco)
> Sai se c'e' una caffetteria o simili all'evento?

99% no, ci si basa sul circondario, che è stato verificato essere
comunque fornito anche se di Sabato.

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Punto su ninux @ merge-it 2018

[Stefano De Carlo]

Ciao a tutti,

Siamo a 19 giorni dal Merge-it 2018 del 24 Marzo, quindi colgo
l'occasione di fare il punto della situazione  anche in seguito all'IRC
meeting. Ho anche aggiornato la pagina del wiki:
http://wiki.ninux.org/mergeit2018

Come prima cosa invito tutti quelli che tra noi hanno intenzione di
esserci al Merge-it di aggiungersi nella lista pubblicata sul wiki.

È uscita la prima bozza di programma dell'evento, e quindi anche della
nostra sessione, la trovate qui:
https://merge-it.net/index.html#section-ajenda

Il programma è grosso modo quello, ma è ancora provvisorio perché
mancano delle piccole grandi cose da valutare e decidere ed è apprezzato
il feedback di tutti (in particolare di chi effettivamente ci sarà):

* in generale c'è il "problema" di avere 1h in più rispetto al solo
pomeriggio, un'opportunità da sfruttare :)

* la cosa più importante è: faremo assemblea? e se la faremo, la
facciamo classica alla ninux day o qualche forma di tavola rotonda
diversa dal solito pensata ad-hoc per il merge-it? In ogni caso è bene
pensare ad un odg

* ci saranno altre WCN? al momento sembra di no, perché chi abbiamo
contattato non ha manifestato interesse, tranne "Senza Fili Senza
Confini", un ISP comunitario di base a Torino che penso molti di voi
avranno sentito. Ancora non si sa se ci saranno, ma se fossero presenti
potremmo provare ad imbastire una tavola rotonda su temi comuni. Tanto
non mi pare che il tema "DIY ISP" è disdegnato da queste parti :)

* come discusso all'IRC meeting, se quanto sopra non si concretizza si è
comunque liberato uno slot per un intervento più divulgativo su Ninux da
mettere in testa alla nostra sessione. ovvero: cercasi candidato
dell'ultimo minuto per fare il talk "pippone Ninux" versione merge-it :-D

* ricordo che ci sarà un'aula "lounge" con tavoli + ciabatte,
sfruttabile per attività a margine, smanettamenti, ecc

Nella pagina del wiki ho messo in lista un po' di queste e altre cose da
fare, ma principalmente:

* feedback/decisioni di cui sopra e ultimazione del programma
* post sul blog
* spamming
* contarci per bene
* organizzare il pranzo del sabato (veloce perché c'è solo 1h di buco)

Fatevi sentire ;-),

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] IRC Meeting 29 Gennaio 2018

[Stefano De Carlo]

Cari Ninuxer, questa sera dalle 21:00 alle 22:00 IRC Meeting Ninux,
siete tutti invitati. Per partecipare:

* join del canale IRC #ninux.org su FreeNode alle 21
* stare su questo canale telegram alle 21 

L'Odg è povero ma contiene un punto che è lì da 1 mese, la preparazione
del Merge-it 2018  In ogni caso tutti possiamo aggiungere punti da
discutere stasera, basta editare qui

OdG:
https://docs.google.com/document/d/1LchF88VzQORooWkI_Dxu128rgVzt89jMy-cUu52b8Ms/edit

@ Ninux Google Calendar Admins

Ho creato il calendar del prossimo (Lunedì 26 Febbraio, sempre ultimo
lunedì del mese), ma in più ho messo notifiche rompicoglioni a 1, 3, 7,
14 giorni (che arrivano agli admin calendar) per poter fare reminder
progressivi sull'appuntamento e sul riempimento odg

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ninux @ Merge-it 2018 (Torino, 24 Marzo)

[Stefano De Carlo]

Il 30/12/2017 21:03, Leonardo Maccari ha scritto:
> Da Firenze veniamo io ed Edoardo di sicuro, forse altri, io propongo
> anche un talk su netCommons e potrei fare anche una presentazione
> introduttiva sulle reti comunitarie in un'altra sessione.
>
> Come avviene la selezione dei talk?

Non ne abbiamo parlato in maniera estensiva. La c4p è unica per tutti,
quindi in teoria un "esterno" potrebbe inviare un talk buono per la
sessione Ninux.
Devo ancora discutere con Roberto cosa si intende per "preferito taglio
tecnico piuttosto che divulgativo". Immagino il rationale dietro sia che
per le cose prettamente divulgative le varie community hanno i "propri"
eventi.

In pratica siamo rimasti che poi avremmo visionato assieme con Roberto
le submission, e finalizzato un programma che andasse bene sia a noi che
all'intento "merging" dell'evento.
L'impressione è che gli organizzatori sarebbero contenti se qualche talk
ninux "contaminasse" altre sessioni, e anche viceversa.

Anche io pensavo che sarebbe un ottimo scenario per presentare netCommons.
Io stavo pensando di proporre una trattazione ordinata delle "licenze"
delle reti comunitarie picopeering, network licenses & simili.

> Come gia' detto al ninuxday, vorrei invitare anche altre
> esperienze italiane a raccontarci cosa fanno. Conto di farlo
> presto la prossima settimana.

Hai già qualche idea su chi invitare?
Pensavo potremmo discuterne nell'IRC meeting straordinario.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ninux @ Merge-it 2018 (Torino, 24 Marzo)

[Stefano De Carlo]

Il 29/12/2017 18:06, Rugantio ha scritto:
> A Torino la lista locale è un po' moribonda e non credo ci siano link
> attivi, tuttavia credo che questa possa essere un'opportunità per
> stimolare gli smanettoni a iniziare a montare le antenne. Io
> sicuramente verrò all'evento e inviterò anche i compagni
> dell'underscore (hacklab del Gabrio) e di Radio BlackOut, sarebbe
> utile coinvolgere anche i valsusini considerato che gran parte di loro
> ha connettività solo grazie ad Eolo che va in giro a montare antenne
> (a pagamento si intende).

Ciao Rugantio,

sono d'accordissimo che è l'occasione ideale per un rebootstrap, ancora
di più se poi in effetti avremo la parte tavola rotonda/dibattito

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ninux @ Merge-it 2018 (Torino, 24 Marzo)

[Stefano De Carlo]

Il 28/12/2017 22:57, Claudio Pisa ha scritto:
> Proponi tu data e ora per l'IRC meeting straordinario o dobbiamo fare un
> poll?

Vorrei evitare l'overhead di un altro pool, reciclando al limite i
risultati del precedente.
Ad esempio, tra le date più vicine, Lunedì 1 alle 21/22 e Mercoledì 3
alle 21/22 avevano una preferenza praticamente identica alla scelta
vincitrice.

Domani è festa, facciamo Mercoledì 3 alle 21 o 22?

Stefanauss,
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Ninux @ Merge-it 2018 (Torino, 24 Marzo)

[Stefano De Carlo]

Ciao Ninuxers,

Quanto segue è già passato sul gruppo telegram già da parecchio,
purtroppo il delay è principalmente colpa mia. Sorry.

Durante l'assemblea del Ninux Day 2017 @ Bologna e discussioni fatte
durante l'evento è emerso consenso su due aspetti:

* Questa community ha bisogno di vedersi più spesso/dialogare più
intensamente
* Questa community ha bisogno di incontrare e coinvolgere altre
community (networks, ma non solo) per capire cosa/come fanno, aiutandoci
a capire in che direzione andare

È stato proposto che la prossima "scusa" ideale per incontrarci poteva
essere una nuova conferenza italiana la cui prima edizione di svolgerà a
Torino: il Merge-it [https://merge-it.net/]

Data: 24 Marzo, Location: Cittadella Politecnica
(http://www.cittadellapolitecnica.polito.it/)

In estrema sintesi il Merge-it vorrebbe essere a lungo termine il
"FOSDEM italiano", e a breve termine un super-hub di tutte le community
Open/Free $qualcosa, appunto "mergiate" tutte assieme nello stesso posto
per un giorno. L'organizzazione è curata da Roberto "madbob" Guido che è
quello che quasi-da-solo organizza il network dei Linux Day ogni anno.

Abbiamo fatto richiesta di far parte delle community di Merge-it 2018
con una nostra sessione, e siamo stati accettati :-) Abbiamo anche avuto
l'ok a invitare altre WCN italiane se vogliamo.

Quello che dobbiamo fare adesso è organizzare la nostra sessione di 3h e
la presenza ninuxara al Merge-it. Per noi si tratta di fatto di un Ninux
Day ma senza l'accollo della parte organizzativa seria, e un po' più
"esposto all'esterno".

Per il momento siamo stati assegnati ad una sessione pomeridiana, ma
parlando con Roberto è uscito che la preferenza degli organizzatori è
che ci sia una sessione di dibattito/tavola rotonda per ogni community,
cioè qualcosa che ricalca come noi effettivamente svolgiamo i Ninux Day.
In questo caso potremmo avere una sessione all-day-long.

La Call 4 Paper è unica per tutto l'evento, ed è online da un paio di
settimane e ha come scadenza 14 Gennaio: https://merge-it.net/c4p/

Noi possiamo preparare la sessione internamente, ma possiamo anche
"impollinare" con contenuti trasversali altre community e alcuni talks
finire in una sessione diversa dalla nostra. Dipenderà dalle nostre
proposte.

Queste sono le info fondamentali. Urgerebbe un IRC meeting straordinario
festivo per cominciare a pianificare il tutto :-)

Stefanauss

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Meeting IRC Ninux - risultati [was: Meeting IRC Ninux - poll fase 2]

[Stefano De Carlo]

Il 19/12/2017 22:51, Claudio Pisa ha scritto:
> A quanto pare l'opzione preferita per il meeting IRC ninux e' l'ultimo
> lunedi' del mese dalle 21 alle 22, con prossimo meeting IRC il 22
> gennaio prossimo.

Ciao Clauz,

ma l'ultimo lunedì del prossimo mese non è il 29?

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Meeting IRC Ninux

[Stefano De Carlo]

Il 14/12/2017 13:31, Claudio Pisa ha scritto:
> Pero' non riconoscere la legittimita' dell'assemblea del Ninux Day,
> ovvero una delle poche occasioni in cui ci si confronta di persona tra
> isole Ninux, mi sembrerebbe un po' estremo...

Non parlavo di legittimità (come ovvio, visto che sto azionandomi
direttamente sui miei accolli :-P) ma del fatto che non c'è chiarezza.

Sono stato a 2 Ninux Day, il terzo che ho perso ho passato i 12 mesi
dopo a scoprire poco a poco cose su cui si era "deciso".
Uno arriva ai Ninux Day e non si sa su cosa si "decide", i Pad sono vuoti.
A qualificarti a "decidere" è la presenza, e penso che pochi membri
sarebbero pronti a sostenere che la presenza al Ninux Day è una sintesi
affidabile di 12 mesi di attività comunitaria di un ninuxer.

Nessuno mette in dubbio che le assemblee dei Ninux day siano ideali per
prendere delle decisioni e direzioni strategiche come comunità, e
personalmente credo che dovrebbero effettivamente fare anche e
soprattutto questo.

Ma mica è chiaro che lo sono. E soffrono di un decisionismo "da presidio".
Per chiarezza di processo sono quasi più "di peso" le decisioni dei
pochi meeting IRC fatti.

È stata una considerazione en-passant, fatta senza animosità che
personalmente vedo come un semplice altro esempio delle contraddizioni e
"cose fatte a metà" che ci portiamo dietro come impostazione comunitaria
e di cui abbiamo discusso molto al Ninux Day.

Mo' vado a votare la seconda fase ;-)

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Meeting IRC Ninux

[Stefano De Carlo]

Il 13/12/2017 15:53, Claudio Pisa ha scritto:
> Ciao.
> Durante il Ninux Day si e' deciso di fare gli incontri su IRC in un
> giorno fisso.
>
> Clauz

Premesso che, detto da uno che ha sia presenze che assenze ai Ninux Day,
non è proprio ben chiaro se/perche i Ninux Days siano "decisionali". :-D

Comunque:

Abbiamo ragionato sul perché gli IRC meeting dopo un inizio promettente
sono scemati fino a cessare. Abbiamo identificato tanti perché
plausibili senza metterci a pensare troppo all'incidenza relativa, anche
perché sicuramente si tratta di un effetto composto

* Incertezza sulla cadenza, giorno e ora
* Data giorno ora del next meeting deciso durante previous meeting, una
ricetta per il disastro se previous meeting capita sia poco partecipato
* Poca o tardiva esposizione del next meeting nei canali social
* OdG scarsissimi o nulli causa poca esposizione della possibilità di
inserire dei punti
* Difficoltà di partecipazione intrinseca causa IRC

Da allora oltretutto abbiamo "risolto" o comunque minimizzato l'ultimo
punto perché adesso c'è il bridge Telegram-IRC. Il prossimo meeting IRC
avrà una potenziale audience già loggata di circa 140 utenti, ma "il
prossimo meeting" non c'è mai stato, ci siamo interrotti appena prima.

Si è tutti quanti riconosciuto che un appuntamento fisso potrebbe
precludere la tal persona ad una partecipazione, ma ci sono state le
seguenti considerazioni fatte da almeno 2 o più persone:
* È una coperta corta: cosa scegli scegli, qualcuno escluderai per forza
* È più importante che si stabilisca come appuntamento comunitario
piuttosto che si garantisca la partecipazione di $ninuxer.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Meeting IRC Ninux

[Stefano De Carlo]

Il 07/12/2017 23:09, Claudio Pisa ha scritto:
> Per decidere la cadenza possiamo usare questo:
> https://framadate.org/lqxRNMK811UlwxvY
> Tra una settimana chiuderei questo poll e creerei un nuovo poll per
> decidere giorno e ora.

Messa la mia (tra le opzioni, "ogni tre settimane" sarebbe stata la mia
preferita xD)

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] ninuxday

[Stefano De Carlo]

Il 16/11/2017 18:57, Leonardo Maccari ha scritto:
> Ciao gente,
>
> Che ne dite di aggiornarci sul ninuxday? quante persone pensano di
> venire? vedo al momento ben 5 iscritti! dai ragazzi facciamo la fatica
> di aggiungersi alla lista

Da Cosenza veniamo io e Luca (Lipos), che mancava alla lista dei
partecipanti, l'ho appena aggiunto.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [blog] Ninux Day 2017 - 25 e 26 Novembre a Bologna

[Stefano De Carlo]

Il 24/10/2017 11:01, Elena ``of Valhalla'' ha scritto:
> On 2017-10-24 at 10:32:14 +0200, Stefano De Carlo wrote:
>> La richiesta delle slide lato organizzatore solitamente serve due scopi:
>>
>> * permette di pubblicare del materiale post-evento, senza dover
>> rincorrere ognuno dei relatori per averle. Aneddoticamente dagli eventi
>> organizzati nel corso degli anni ti posso dire che se non chiedi le
>> slide prima scordati di avere il set completo a disposizione.
> Come citato nel link prima: l'utilità di un set di slide senza il
> relativo talk dovrebbe essere minimale, altrimenti sono il tipo di slide
> che distrae più che aiutare.

Il relatore produce le slide come ritiene opportuno, eventualmente
seguendo i giusti principi del bravo Mr. Have I Been Pwnd.

Però poi l'utilità che hanno la decide chi te le chiede (riferimenti,
traccia, rielaborazione, parole chiave, passaggi specifici, LINKS
soprattutto, tutte cose estrapolabili anche da slide minimali) e
*invariabilmente* c'è qualcuno che te le chiede quindi per gli
organizzatori subentra il discorso della mail precedente, premunirsi per
non ammattire dopo e/o non poter soddisfare le richieste.

>
>> * permette di fare prove tecniche di trasmissione col materiale "reale"
> Quindi niente laptop dei presentatori durante i talk e obbligo di slide
> in pdf per tutti?

Non lo so, non penso proprio e figurati se al Ninux Day ci mettiamo a
fare i formali su ste cose :-) parlavo in generale delle motivazioni
dietro la richiesta delle slide.
Anche con i portatili dei presentatori le prove tecniche servono spesso
(backup, non tutti usano il proprio

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [blog] Ninux Day 2017 - 25 e 26 Novembre a Bologna

[Stefano De Carlo]

Il 24/10/2017 09:12, Elena ``of Valhalla'' ha scritto:
> dove "chiedere le slide in anticipo, specie se settimane / mesi in
> anticipo" è una delle lamentele più comuni da parte degli speakers, per
> vari validi motivi (incluso il fatto che di solito la gente ben
> organizzata finisce di prepararle il giorno prima, gli altri la mattina
> stessai, ma anche il fatto che se le slide da sole danno sufficienti
> contenuti per essere utili, probabilmente non sono delle grandi slide
> per il talk (troppo testo, propense a distrarre)).

La richiesta delle slide lato organizzatore solitamente serve due scopi:

* permette di pubblicare del materiale post-evento, senza dover
rincorrere ognuno dei relatori per averle. Aneddoticamente dagli eventi
organizzati nel corso degli anni ti posso dire che se non chiedi le
slide prima scordati di avere il set completo a disposizione.
* permette di fare prove tecniche di trasmissione col materiale "reale"

che sono entrambe cose molto desiderabili.
Alla fine non viene richiesto nessun invio anticipato dell'ordine di
settimane e non penso sia intenzione.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] Corso Advanced Networking 2018 by Hacklab Cosenza

[Stefano De Carlo]

Ciao a tutti,

volevo segnalare che sta per partire l'edizione 2018 del corso di reti
di Hacklab Cosenza (tra i founder dell'isola ninux indigena).

Già da qualche anno lo abbiamo strutturato per poterlo seguire da remoto
(a parte 3-4 puntatine nel corso di un semestre in Calabria per gli
esami). Al di là della valenza professionale (certificazioni Cisco
CCENT/CCNA), è un corso ideale per chi parte da praticamente nulla per
acquisire le conoscenze tecniche necessarie in una wireless community
network, sia a gestire il proprio nodo che a contribuire alla rete nel
complesso.

Da qui lo shameless plug  ;-)

Info su: https://hlcs.it/advanced-networking/

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [ninux-roma] Cancellazione massiva su GestioneIndirizzi

[Stefano De Carlo]

Il 23/10/2017 10:45, Claudio Pisa ha scritto:
> Che succede?
> E' intenzionale o accidentale?
> http://wiki.ninux.org/GestioneIndirizzi?action=diff=1646=1645
>
> Clauz

Mi sembra un CTRL+A finito male.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Situazione LEDE / OpenWRT

[Stefano De Carlo]

Il 06/10/2017 02:14, Germano Massullo ha scritto:
> Attualmente quale è la situazione sviluppo LEDE vs OpenWRT?
> Dovrei mettere un firmware open su un TP-LINK AC1750 e vorrei che fosse
> il più possibile stabile

Il progetto più vicino in a come era "OpenWrt pre-split" in termini di
caratteristiche numero di contributor e ritmo di sviluppo è LEDE.
Per sapere quale è più stabile non c'è parlare, c'è provare.

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] questionario per progetto netcommons.eu

[Stefano De Carlo]

Il 04/10/2017 12:16, Ilario Gelmetti ha scritto:
> Il link corretto e` questo:
> https://d52netcommons.limequery.com

In realtà non credo sia questo, questa è semplicemente la landing page
dei survey pubblicati da netcommons.
Quello che al momento è visualizzato nell'elenco (attitude) non credo
sia quello della mail inoltrata (legal issues).

Ci dirà Leo.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] AMMBR.com

[Stefano De Carlo]

Il 03/09/2017 22:22, Leonardo Maccari ha scritto:
> Se non ci si arriva, chi vuole provare si esprime, e io gli dico che
> ci sono X persone in Y citta' che avrebbero voglia di provare i loro
> cosi quando ne hanno qualcuno da testare, e vediamo che succede.

Ciao,

come ho già detto per me è OK fare un plug (non un endorsement) a AMMBR
come "ninux"

anyway

io e Musk siamo interessati a testare a Cosenza, quindi puoi
incrementare X e Y.

Stefanauss
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Articolo su republica cita ninux.org a proposito di wifi italia

[Stefano De Carlo]

Il 19/07/2017 19:44, Matteo Pedani ha scritto:
> Possiamo aiutare il pubblico a prendere la strada "giusta" di una rete
> veramente comunitaria?

Io non credo, perchè

>
> [...], bisogna imparare a comunicare che cosa è una rete comunitaria,
> bisogna semplificare l'accesso alla rete ninux. 

queste due cose (che volevamo e dovevamo fare anche il giorno prima che
uscisse questo articolo) sono ancora abbastanza lontane in ninux.org,
perlomeno non al livello che occorrerebbe per avere qualche speranza di
instradare il pubblico verso la "strada giusta della WCN".

Ci sono ovviamente un sacco di altri fattori, ma quanto sopra basta IMO
per metterci una pietra sopra per ora.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] PSA: AirOS 6.0.6 implementa la verifica crittografica degli aggiornamenti

[Stefano De Carlo]

Il 11/07/2017 22:41, Stefano De Carlo ha scritto:
> Si parla [1] di rendere disponibili versioni firmate (e quindi
> downgradabili) di specifici firmware precedenti come il 5.6.15

Scusate, mi ero perso il link

[1]
https://community.ubnt.com/t5/airOS-Software-Configuration/New-6-0-6-firmware-locking-out-downgrade/td-p/1984722

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] PSA: AirOS 6.0.6 implementa la verifica crittografica degli aggiornamenti

[Stefano De Carlo]

Ciao,

se aggiornate ad AirOS 6.0.6 (serie AirMax M) perdete la possibilità di
flashare OpenWrt/LEDE o anche di downgradare a versioni precedenti di
AirOS non approvate da Ubiquiti via interfaccia grafica. Il flash via
TFTP è invece ancora privo di verifiche e quindi un'opzione valida per
flashare firmware di terze parti.

Note di Rilascio: https://dl.ubnt.com/firmwares/XW-fw/v6.0.6/changelog.txt

"- Signed firmware support (Users are not able to downgrade below v6.0.6
unless using TFTP)"

Si parla [1] di rendere disponibili versioni firmate (e quindi
downgradabili) di specifici firmware precedenti come il 5.6.15, ma
questa versione non è compatibile con il flash di OpenWrt/LEDE perché
non consente modifiche alla tabella delle partizioni. È necessaria la
serie 5.5.x per questo, ma con questa feature ne viene completamente
deprecato il downgrade via Web UI.

Ho testato un flashing via Web UI di una NanoBeam 16 a LEDE 17.0.2
"nano-m-xw-factory", ad upload completato compare il messaggio:

"""
This firmware is not trusted by airOS. To maintain security, it will not
be loaded. Please load trusted firmware.
"""

NON ho testato personalmente il flash TFTP dopo aggiornamento a AirOS
6.0.6, ma non ho letto di report che denunciavano un lockdown pure lì.

Stefanauss.

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] WR1043ND v4, LEDE e VLAN

[Stefano De Carlo]

Il 24/06/2017 16:07, Michele Salerno ha scritto:
> Raga a voi funziona regolarmente?
> Io come attivo le vlan mi butta fuori!
>
> Ovviamente ho provato a spegnerlo e riaccenderlonisba!

Nel v2/v3 si doveva operare così, non so se per il v4 è così: 
https://wiki.openwrt.org/toh/tp-link/tl-wr1043nd#use_eth1_vlan_id_interface_instead_of_eth0_vlan_id_for_additional_vlan-s_on_v2x_v3x_router_hardware

Qualche dettaglio in più su come operano v2/v3: 
http://ml.ninux.org/pipermail/wireless/2014-September/016302.html

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Meeting IRC stasera

[Stefano De Carlo]

Il 16/03/2017 15:00, Leonardo Maccari ha scritto:
> Ciao Gente,
>
> reminder che stasera c'e' il meeting IRC, alle 9.

Link ai minutes, dacci sotto lerrigatto:

 Meeting ended Thu Mar 16 21:35:47 2017 UTC.  Information about 
MeetBot at http://86.119.33.5 . (v 0.1.4)
 Minutes:
http://86.119.33.5/ninux_org_irc_meeting_2017_03_16/2017/ninux_org_irc_meeting_2017_03_16.2017-03-16-20.17.html
 Minutes (text): 
http://86.119.33.5/ninux_org_irc_meeting_2017_03_16/2017/ninux_org_irc_meeting_2017_03_16.2017-03-16-20.17.txt
 Log:
http://86.119.33.5/ninux_org_irc_meeting_2017_03_16/2017/ninux_org_irc_meeting_2017_03_16.2017-03-16-20.17.log.html

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] configurazione

[Stefano De Carlo]

Il 10/03/2017 09:58, Alessio Greggi ha scritto:
>
> Cosa intende per interfaccia client/ad-hoc?
>

Ciao Alessio,

"L'interfaccia client/ad hoc" non è altro che l'interfaccia wireless 
dell'antenna che opera in una di queste due modalità, che sono proprio le due 
modalità che non sono bridgiabili tradizionalmente e quindi richiedono trelay. 
config/trelay vuole il nome reale dell'interfaccia, NON quello OpenWrt che 
compare ad esempio nella GUI Network > Interfaces.

Ma tu l'antenna ce l'hai in modalità ad hoc o client (detta anche STA?)

Se hai ad-hoc, allora vai con trelay, è l'unico modo per bridgiare una wireless 
ad una ethernet.

Se hai client, la vera soluzione è un'altra, utilizzare WDS sia su client che 
sul relativo AP. Utilizzando WDS puoi creare un bridge tradizionale. Se le 
antenne sono entrambe OpenWrt, la soluzione è la preferibile e percorribile.

Purtroppo mi sa che questa variante ancora manca nella guida.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] configurazione

[Stefano De Carlo]

Il 09/03/2017 19:10, Alessio Greggi ha scritto:
> Ma non ho minimamente idea di come si configuri.

Qui trovi il sample di configurazione contenuta nel pacchetto, è veramente 
minimale come vedi

https://github.com/openwrt/openwrt/blob/5ce38c486c525b28d9784f83e839537aa0149123/package/kernel/trelay/files/trelay.config

Stefanauss

___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] resoconto meeting IRC

[Stefano De Carlo]

Il 01/03/2017 19:53, Leonardo Maccari ha scritto:
> (da ML-BO) "accettiamo la proposta del ninux day nazionale a novembre a 
> bologna" 
>
> GRANDI!!! ci vediamo tutti presto allora!

Non per raffreddare gli entusiasmi, però non era così netta. Oltretutto è 
successo in chiusura di meeting, quando molti avevano staccato quindi non si è 
approfondita la cosa.

Però è vero che abbiamo avuto il primo ack da Bologna, ne hanno parlato, con 
entusiasmo e il clima è buono per l'accollo, ma il ragazzo che era con noi su 
IRC ci ha detto che non erano abbastanza per una decisione conclusiva su un 
impegno così importante e che ne riparleranno, ma non era chiarissima la data 
(a BO sono in corso diverse attività sommando quelle dei gruppi smanettoni).

Spero che al prossimo meeting (16/03) magari si saranno già reincontrati, o 
almeno che ci sia qualche rappresentante da BO per riparlarne come primo topic.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] IRC log 8 febbraio

[Stefano De Carlo]

Il 09/02/2017 18:55, Nemesis ha scritto:
> Qualcuno può caricare i log dell'ultimo irc meeting su github?
>
> Nemesis

https://github.com/ninuxorg/meetbot-ninux-logs/commit/de2b39381b222d2816f6ba34723c326b7526a0b4

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Proposta: porte VPN su GestioneIndirizzi

[Stefano De Carlo]

Il 27/12/2016 15:21, Claudio Pisa ha scritto:
> Ciao.
> Dopo i discorsi durante e dopo il Ninux Day su reti overlay, credo che
> sarebbe il caso di coordinarsi sulle porte da allocare alle varie VPN,
> per evitare overlapping, e lo farei sulla pagina GestioneIndirizzi.
>
> Se c'e' consenso possiamo creare la tabella su GestioneIndirizzi e
> cercare di censire le VPN gia' esistenti.
>
> ciao,
> Clauz

Ok per fare questa particolare cosa su GestioneIndirizzi

Stefanauss.

P.S. L'unico sistema IPAM con gestione delle porte out-of-the-box, afaik, è 
Netbox, e comunque solo nella versione di sviluppo.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [domanda] gesire gw tramite metriche

[Stefano De Carlo]

Il 27/12/2016 23:14, Michele Salerno ha scritto:
> Avendo
> Router A -> Router B (wan) -> Router C (wan)
>
> come impostare una metrica per dire ad A di usare come GW C senza che
> OLSR cambia le cose?

Una volta che il tuo traffico arriva a B, decide B cosa farne.
Puoi fare source-based routing (policy routing) su B, se ne sei amministratore. 
Ma in linea generale dovresti poterlo fare su tutti i router intermedi tra te e 
il gw desiderato, affinché la cosa funzioni.

Se non è questo il caso, puoi selezionare uno specifico gw solo col tunneling.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Gestione connettivita' router/gateway

[Stefano De Carlo]

Il 18/12/2016 19:59, Massimiliano CARNEMOLLA ha scritto:
> Nel caso di un PC che funge da router/gateway prima erano necessarie due 
> schede di rete (una per gestire la connettivita' internet) ed una per la LAN.
>
> Adesso si possono usare le VLAN o creare schede di rete virtuali 
> sull'hypervisor in sostituzione di queste 2 o piu' schede ethernet ?

Si, è una pratica che si chiama routing-on-a-stick o anche one-armed-router.

"adesso" e "prima" saranno una quindicina d'anni ormai

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [post-ninux-day] Esempi di successo

[Stefano De Carlo]

Il 30/11/2016 14:01, Stefano De Carlo ha scritto:
> Aggiungo questo:

Bravoo-oh, ho scordato il link: 
http://blog.elementary.io/post/152626170946/switching-from-macos-the-basics

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [post-ninux-day] Esempi di successo

[Stefano De Carlo]

Il 29/11/2016 11:06, Nemesis ha scritto:
> - questi atteggiamenti hanno prodotto risultati positivi? Continuando su
> questa strada si arriverà dove si vuole o si cadrà gradualmente
> nell'obsolescenza e nell'oblio?
>
> - questi atteggiamenti corrispondono ad una mentalità aperta,
> pragmatica, agile, è propria di persone che vogliono uscire dalla
> propria comfort zone per crescere, o il contrario?
>
> Vi lascio alcuni spunti di approfondimento:

Aggiungo questo:

Di recente i nuovi prodotti laptop Apple hanno lasciato delusa una fetta grossa 
dell'utenza ("i pro", lasciamo perdere la definizione precisa).
Molti blog d'opinione hanno cominciato timidamente a proporre uno switch a 
Linux come possibile corso d'opera per i delusi, con l'idea di fondo "mantenere 
quanto più possibile MacOS ma svincolarlo dall'hardware". elementaryOS è stata 
la distribuzione più linkata in questi pezzi.

Il team di elementaryOS (che è veramente esiguo, ci sono molti meno attivi che 
in QUESTA community) ha avuto la prontezza di reagire prontamente sul lato 
comunicativo, iniziando immediatamente una serie di articoli "benvenuto" facili 
facili su come migrare esplicitamente da MacOS a elementary. Ha ottenuto un 
effetto valanga dal punto di vista del "purchè se ne parli"

Difficile avere i risultati reali in termini di effettivi switch, ma non 
importa tantissimo. L'importante è stato estrarre il massimo dall'opportunità 
reagendo agilmente.

Si può contrastare questo con quanto successo per noi all'epoca dell'articolo 
su Repubblica.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Materiale studio IPv6

[Stefano De Carlo]

Il 31/10/2016 23:06, Germano Massullo ha scritto:
> Conoscete qualche buona risorsa online per studiare la gestione degli
> indirizzi IPv6?

Che intendi per "gestione degli indirizzi"? Ti interessa qualche tematica 
precisa o deve anche essere un primer che parta dalle basi?

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Configurazione VLAN antenna

[Stefano De Carlo]

Il 30/10/2016 10:42, Germano Massullo ha scritto:
> Con quella configurazione di VLAN è stato elevato un caso particolare a
> caso generale.

È stato "elevato" un setup che funziona in qualsiasi scenario a unico setup 
proposto, per evitare di dover ramificare la guida in un'esplosione di 
precisazioni.

>> > Serve ancora. Su alcune piattaforme, anche moderne, la limitazione è *in 
>> > hardware*.
>> > Visto che non esiste una compatibility matrix affidabile tra SoC, 
>> > specifiche del datasheet e versione di openwrt, la guida segue un singolo 
>> > setup che funziona *sicuramente*, *sempre*, su tutti gli switch managed 
>> > (perché se non supporti la segmentazione attraverso VID non sei 
>> > 802.1q-compliant).
> A me risulta che a Roma, Fish ed Halino, abbiano installato una marea di
> impianti con OpenWRT senza mettere la doppia VLAN sull'antenna.
>

Sicuramente, ma "una marea" non mi sembra una compatibility matrix su cui 
impostare una guida.

Ripeto più dettagliatamente: in molti SoC "il bug della doppia VLAN" è una 
*limitazione hardware*. [1]
Non la aggiri con patch. Hai quel dato SoC? Doppia VLAN.

Mo', sicuramente ci sono alcuni SoC che su alcuni versioni di alcuni router a 
partire da qualche versione di OpenWrt, sono a posto.

Piuttosto che addentrarsi in (e doversi andare a ricercare) tutte queste 
precisazioni di, secondo me, limitatissimo valore per i "poco o niente addetti 
ai lavori" a cui si rivolge la guida, ho preferito tenerla compatta proponendo 
un singolo setup (da documentare in N sistemi).

Questo il rationale dietro, poi tutto è sempre abbondantemente migliorabile :-).

Stefanauss.

[1] https://lists.openwrt.org/pipermail/openwrt-devel/2014-March/024527.html



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Configurazione VLAN antenna

[Stefano De Carlo]

Il 29/10/2016 18:51, Germano Massullo ha scritto:
> Mi chiedevo come mai non è stato specificato

È stato specificato, pagina 18.

"Per quanto fastidioso, questo bug non è particolarmente bloccante: per 
aggirarlo basta utilizzare la doppia VLAN sull’antenna che abbiamo visto nella 
sezione “Configurazione Radio”, invece della singola che sarebbe stata 
necessaria se il nostro router non avesse questo bug"

> ma serv*IVA*

Serve ancora. Su alcune piattaforme, anche moderne, la limitazione è *in 
hardware*.
Visto che non esiste una compatibility matrix affidabile tra SoC, specifiche 
del datasheet e versione di openwrt, la guida segue un singolo setup che 
funziona *sicuramente*, *sempre*, su tutti gli switch managed (perché se non 
supporti la segmentazione attraverso VID non sei 802.1q-compliant).

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] R: Ottimizzare banda switch<->router

[Stefano De Carlo]

Il 21/10/2016 10:48, Germano Massullo ha scritto:
> Alessandro ieri mi ha mostrato il bonding livello 3+4. Sembrava una
> ottima soluzione, tuttavia ho appena scoperto che negli EdgeRouter non
> viene sfruttato l'offloading hardware, quindi si rischierebbe
> paradossalmente di avere dei rallentamenti

Io non credo proprio che tu stia nel dominio dell'offloading ubnt.
L'offloading in hardware accelera operazioni molto molto specifiche, tra cui, 
sicuramente, il NAT.
Da quel che ho capito, tu non ne fai.
Per tutte le operazioni che non possono risultare in un'accelerazione (perchè 
l'hardware non le supporta) avere l'offloading abilitato è in realtà un 
overhead.

Contronta: 
http://www.snbforums.com/threads/ubiquiti-edgemax-edgerouter-pro-reviewed.16929/

Ma per renderti conto davvero, devi fare un test con almeno 4 host gigabit, 
offloading abilitato e disabilitato, e fare LAN-to-WAN con/senza NAT (o solo 
senza se proprio non pensi ti servirà) e misurare.
Questo ti dovrebbe dare le capacità dell'EdgeRouter *in software*. Se ottieni 
dati che ti sono sufficienti, non dovrebbero variare inserendo il bonding 
(altro componente in-software) nel quadro.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Ottimizzare banda switch<->router

[Stefano De Carlo]

Il 19/10/2016 11:45, Germano Massullo ha scritto:
> Attualmente ho due opzioni
> - Link aggregation [1]: soluzione rischiosa perché non è detto che il
> router e lo switch dividano, come uno si aspetta, il traffico tra i vari
> cavi
> - VLAN per ogni antenna AC[2]: dato che queste antenne sono quelle che
> occupano più banda, assegnare a ciascuna di esse una VLAN come suggerito
> da Clauz, potrebbe essere una soluzione ideale.
> Avete altre idee?

A me sembra che ne hai solo una vera. Con le VLAN faresti una ripartizione a 
monte totalmente scollegata dalla quantità e tipologia del traffico realmente 
prodotto dai tuoi apparati. Per quanto te la puoi pensare bene prima, le 
condizioni cambiano, e sarebbe molto poco flessibile aggiungendo apparati.

Per quanto riguarda la link aggregation e da quello che leggo sul manuale 
EdgeSwitch, puoi evitare l'intera filiera "magari qualcosa non è 
802.3ad-compliant" usando semplicemente lo static port-channel. A me sembra che 
per il tuo setup non serve che il LAG sia di tipo 802.3ad o in qualsiasi modo 
automatico/dinamico.

La parte essenziale è l'algoritmo di hashing. Immagino che principalmente il 
traffico proveniente dalle antenne sarà inoltrato verso l'edgerouter. In questo 
scenario dovrebbe essere sufficiente evitare gli algo che includono il 
destination MAC per ripartire correttamente il traffico ed evitare colli di 
bottiglia. "Source MAC, VLAN, Ethertype, Incoming Port" sembra 
promettente-pur-se-semplice, ma in ogni caso devi fare delle prove perché senza 
avere accesso al codice [1] non sai a tavolino quanto sono efficienti i mapping.

Stefanauss.

[1] Che presumo sia proprietario, perlomeno lato backplane.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] [ot] - consiglio server assemblato per servizi in rete ninux

[Stefano De Carlo]

Il 24/09/2016 01:04, Michele Salerno ha scritto:
> Per chi è appassionato di hw, sa darmi qualche consiglio per
> assemblare un server di base senza spende una cifra?

Quale cifra?

Per far girare Proxmox hai essenzialmente bisogno solo delle estensioni per la 
virtualizzazione.

Prendi qualsiasi portatile della generazione Sandy Bridge o successive di cui 
trovi l'occasione, aumentagli la RAM, evita la sospensione col lid e hai 
risolto cost-effective, soprattutto fattorizzando i costi di gestione.
Oppure un Intel NUC.
Oppure un HP Microserver, se vuoi qualcosa che si avvicini al form-factor 
classico.

Questo se vuoi proprio rimanere sulla strada della virtualizzazione x86, cosa 
che io eviterei.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Consiglio acquisto materiale

[Stefano De Carlo]

Il 21/09/2016 18:53, leonardo ha scritto:
>  - TP-Link TL-WDR4300
>
> Qualcuno sa se quelli sul mercato di oggi si possono riflashare?

Il WDR3600/4300 è fuori produzione e fuori distribuzione da almeno un anno, 
credo anche di più.
All'inizio c'erano forti scorte, ma ormai è praticamente sparito.
A naso non la considererei, nel tuo caso, un'opzione percorribile, specie se 
sei limitato a determinati tipi di fornitore.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NodogSplash e Traffic Control

[Stefano De Carlo]

Il 16/09/2016 11:47, Saverio Proto ha scritto:
>
> https://relakks.com/faq
>
> leggi tutta la parte legal.
> ti protegge abbastanza bene.
>
> Saverio
>

Grazie.
A proposito di una comparison di parti legal, tecniche e quant'altro: 
https://thatoneprivacysite.net/

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NodogSplash e Traffic Control

[Stefano De Carlo]

Il 16/09/2016 11:36, Matteo Pedani ha scritto:
>
> credo che sia errato promuovere mezzi di anonimizzazione.
>

Pensa che altrove è (giustamente, IMO) un principio fondante: 
https://freifunk.net//en/what-is-it-about/our-vision/

> Certo é che se uno vuole anonimizzare il proprio traffico. le vpn e le reti x 
> anoninizzare sono buone.
>

Stai facendo un calderone che suggerisce come tu stia confondendo privacy, 
anonimato, e mitigazione delle responsabilità legali.

> oggi come oggi terroristi usano telegram per fare quello che vigliono.
>

Semplicemente fattualmente sbagliato.
Se sei interessato ad analisi serie della OpSec dei gruppi terroristici, ti 
suggerisco di spulciare a fondo: https://medium.com/@thegrugq

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] PicoPeering e peering obligation

[Stefano De Carlo]

Il 16/09/2016 09:20, BornAgain ha scritto:
>
> “Il PPA è un modo per formalizzare l'interazione paritaria tra i proprietari 
> di due nodi"
> “Il proprietario ha il diritto di formulare un ‘contratto di uso 
> accettabile’” [1]
>

Dario, uno dei brani che citi è una traduzione sbagliata. "Acceptable user 
policy" non può essere tradotta in "contratto d'uso accettabile". Una policy e 
un contratto sono cose diverse.

> In buona sostanza il PPA è un contratto.

Non so cosa intendi per "buona sostanza".
Il PPA è un Agreement, formalizzazione di una convergenza di pensieri e 
ragionamenti. In nessun caso, da solo, è legalmente vincolante. [1]
Un contratto è un documento legalmente vincolante. Niente può essere "in buona 
sostanza" un contratto se non è legalmente vincolante.

> Come contratto deve essere stipulato  da *entrambe* le parti, tramite 
> “un’interazione paritaria”. Non univocamente da parte di chi si voglia 
> agganciare. 
>

Non è così che funzionano i contratti.
Che i contratti richiedano bilateralità è una cosa che dipende dall'ordinamento 
giuridico, e nella quasi totalità di essi un contratto può tranquillamente 
essere unilaterale, e sono previsti meccanismi di accettazione o rifiuto ma in 
nessun caso di "interazione paritaria".
Hint: le licenze sono contratti. Ti risulta che tu stipuli "una" GPL prima di 
usare un software rilasciato in GPL?

> Questo per me significa che: 
> 1- non esiste il fatto che io, proprietario di un nodo, debba accettare *a 
> priori* la connessione di un nodo X. Dopo che l’accetto e la formalizziamo 
> non posso interferire naturalmente sul traffico in transito, ma questo è uno 
> step successivo. 
>

Infatti: *se* il peering avviene, avviene (vedi PPA). Instaurazione e revoca 
rimangono libere
(ma niente di tutto questo per via di un qualche vincolo legale, vedi sopra).

>
> 2- ‘Interazione paritaria’ .. io estenderei

Quello chje proponi lo puoi fare, nella clausole locali (punto 5).
Tra parentesi il principio che esponi trova alcuni ninuxer di qui perfettamente 
d'accordo e infatti stiamo valutando di inserirlo nei Local Amendments di una 
serie di nodi a Cosenza.

Stefanauss.

[1] Ecco perché in Guifi hanno riformulato (assieme a molto altro) i contenuti 
del Pico Peering *Agreement* in una NCL, Network Community *License*, il FONN 
Compact, che è legalmente vincolante, e altri _contratti_ relativi a specifici 
casi d'uso.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NodogSplash e Traffic Control

[Stefano De Carlo]

Il 15/09/2016 18:07, Saverio Proto ha scritto:
>
> ma usare:
> https://www.relakks.com/
>
> gia lo usavamo al Fusolab anni fa
>
> Saverio
>

puoi riassumere perché usare proprio questa (o comunque, perché fu scelta) 
rispetto ad altri provider VPN?
ho letto ma non sono riuscito a trovare nessun motivo ovvio.

Stefanauss



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] PicoPeering e peering obligation

[Stefano De Carlo]

Il 16/09/2016 00:24, Elena ``of Valhalla'' ha scritto:
> uhm, ma se le informazioni per il peering sono pubblicate, cosa
> impedisce tecnicamente ad una persona che si trova nel posto giusto¹ di
> collegarsi e peerare?
>
> ¹ e quindi non ha bisogno di modifiche di puntamento delle antenne

Le "informazioni per il peering" non devono per forza sottintendere ad una 
procedura gestibile in completa autonomia.
Ad esempio tra le informazioni pubblicate ci può essere l'istruzione di fornire 
il MAC address per l'inserimento nella whitelist dei client ammessi. O 
quant'altro. Il PPA non si addentra in specificità tecnologiche o procedurali.

In generale, l'assenza di impedimenti tecnici alla connessione autonoma non 
implica che il peering non possa essere rifiutato post-connessione.
Ovviamente il no-auth rimane sensato se, tra le altre cose, prevedo che il 
rifiuto di fare peering con un altro membro della free network sia sempre e 
solo una extrema ratio.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NodogSplash e Traffic Control

[Stefano De Carlo]

Il 14/09/2016 19:16, Michele Salerno ha scritto:
> Il discorso di mettere un hotspot è solo ed esclusivamente informativo
> per il passante sotto casa che non conosce ninux e darsi una lettura
> se interessato.
> Tanta gente comune non sa neanche che esiste. Io che ho un bagaglio di
> 15 anni nel settore informatico, solo 2 anni fa ho scoperto Ninux per
> caso su google ed è stato amore a prima lettura del Manifesto.
>
> Questa cosa diverrebbe anche proponibile ad amici che hanno attività
> commerciali come bar, pub, ristoranti etc
> Non gli vai a saturare la linea ADSL con tutti i clienti seduti ai
> tavoli, non dai accesso alla rete interna dove magari c'è il POS, il
> tablet delle ordinazioni etc... Dai informazioni ai clienti sulla rete
> Ninux, sulla spashpage puoi metterci il loghino del pub etc...
>
> Lo scopo è solo quello della promozione di Ninux dando un semplice,
> banale accesso ad internet ma prevenire e tutelare chi mette il
> servizio a disposizione di sconosciuti, negando al 100% l'accesso alla
> rete Ninux perchè deve essere tutelata anche quella da sconosciuti.
>
> Il discorso AP sulla backbone non ha nessun limite ed è aperta, non ha
> dhcpse non lo conosco, vado in gestione indirizzi di ninux.org e
> vedo chi è, chiedo in ML, chiedo in chat su telegram, chiedo al resto
> del gruppo nella mia zona, etc...
>
> Spero di aver spiegato meglio lo scopo di implementare un hotspot e di
> usare il Traffic Control.

Secondo me è un discorso anche condivisibile, ma c'è una grossa contraddizione 
tra la tua intenzione e l'implementazione che descrivi.
Ovvero: dici che la motivazione primaria è la promozione di Ninux, eppure nel 
processo blocchi completamente l'accesso alla rete libera che vuoi promuovere, 
con le risorse/servizi DIY e comunitarie che contiene, e invece l'unica cosa 
che consenti è l'accesso (pure non neutrale, nel tuo caso) ad una rete 
non-libera.

Non fila, IMO. Che modo migliore di promuovere Ninux ci può essere se non 
usarla e vedere com'è, chi ci sta, che ci sta, come si usa? La splash 
informativa ci può stare, ma come complemento. Come unico sbocco ninuxaro, 
quando c'è quell'alternativa, no.

Il peso dato al "proteggere la rete" mi sembra ampiamente eccessivo. Con un 
DROP a prescindere ti precludi la possibilità di cui sopra di usare la rete per 
promuoversi da sola [1], quando in realtà i singoli nodi Ninux sono in una 
posizione migliore della tua per scegliere (granularmente!) se 
privilegiare/come bilanciare la sicurezza o l'accesso. Conoscendo le 
informazioni tecniche del tuo hostpot ogni nodo può decidere se filtrare il 
traffico da essa proveniente oppure no.
Anche la definizione di "sconosciuto" dal quale proteggere mi sembra arbitraria.

Per il resto:

L'accesso a Internet direttamente tramite il proprio nodo non ricade nel 
dominio del free transit del PPA (non rientra nella definizione di "free 
network" e nemmeno di "additional service"). Averlo, non averlo, se e come 
consentirlo o limitarlo, non impatta la natura di Ninux come rete libera. E 
pertanto ogni singolo nodo può decidere per sé.

Detto questo io sul mio hotspot attivo la condivisione di Internet, non lo 
filtro, ma limito la banda. Il rationale della mia scelta, in ordine sparso, è 
questo:

* Un hotspot Ninux-only ha una pessima usabilità. Se creo un hotspot per 
consentire l'accesso a Ninux, voglio che le persone abbiano voglia di 
utilizzarlo, ma costringerle a setup complicati con doppia interfaccia wireless 
(una verso una qualche default) non è d'aiuto.

* Il principio di neutralità è un buon principio, e per quanto possibile mi ci 
attengo. In un hotspot però l'esaurimento della risorsa arriva prima e non è un 
problema trattabile, come almeno in potenza è sempre possibile in Ninux, 
mettendo banalmente a disposizione più risorse. Pertanto occorre un 
compromesso. Non filtrare ma tentare di suddividere equamente è quello che mi 
piace di più.

* Alla fine della fiera, filtrare a priori non è efficace, perché a meno di non 
spenderci quantità di tempo e risorse irragionevoli finirai per non bloccare 
qualcosa che vuoi bloccare, ma soprattutto bloccare qualcosa che vorresti 
permettere.

* Preferisco impiegare le stesse quantità di tempo (magari sempre 
irragionevoli) a monitorare e reagire ad eventuali abusi reali quando 
avvengono, piuttosto che cullarmi di aver eliminato abusi in potenza grazie a 
filtri che nemmeno revisionerò personalmente. Mi mantiene consapevole dei 
servizi che metto a disposizione ed è la stessa attitudine che penso dovrei 
comunque tenere per ogni risorsa che attivo in Ninux, perché "pubblicarne" una 
e lasciarla nell'incuria annulla l'effetto promozionale positivo che sto 
ricercando per la rete.

* Limitare la banda e ripartirla equamente già da sola scoraggia la maggior 
parte delle tentazioni di abusare del servizio.

* Sono d'accordo con quanto detto da Elena sul calderone del tutto ambiguo 
delle responsabilità. Alla fine è il nodo che offre 

Re: [Ninux-Wireless] NodogSplash e Traffic Control

[Stefano De Carlo]

Il 14/09/2016 00:18, Claudio Pisa ha scritto:
> Altre isole stanno usando splash page con successo?

Anche a Cosenza i risultati sono stati simili, ma onestamente il campione 
derivante dalla copertura o il tempo di uptime del servizio sono stati troppo 
poco ampi per estrapolare.
Anche l'usabilità era migliorabile.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] PicoPeering e peering obligation

[Stefano De Carlo]

Il 15/09/2016 16:26, Elena ``of Valhalla'' ha scritto:
> ma le antenne della
> rete ninux sono comunque aperte a chiunque senza nessuna autenticazione
> (vedi picopeering agreement)

* Non c'è nessun requisito di no-auth nel PPA, solo di "pubblicazione delle 
info necessarie ad instaurare il peering"
* L'obbligazione al peering ("chiunque") non fa parte del PPA. È la principale 
differenza tra il PPA e la Free Networks Definition [1]

Questa precisazione è secondo me importantissima perché c'è certamente una 
fetta di partecipanti a Ninux che ritiene che non dovrebbe essere, a priori, 
consentito rifiutare il peering anche solo in qualche caso. Ma è un errore 
considerare il PPA come sorgente di questo requisito o (di conseguenza) 
presumere che questo requisito sia già universalmente in essere in Ninux.

Stefanauss.

[1] https://sudoroom.org/pipermail/tmpcommonsnet/2013-October/08.html



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Freifunk Memorandum of Understanding

[Stefano De Carlo]

Il giorno sab 16 mag 2015 alle ore 19:13 Nemesis  ha
scritto:

> Community diverse, problemi simili.
>
> Vi consiglio di leggere questo:
>
> https://github.com/freifunk/MoU/blob/master/FreifunkMemorandumofUnderstanding_en.md
>
> Riporto per la felicità degli archivi.
>

Ciao,

@ Cosenza stiamo avendo un dibattito su PicoPeering e dintorni. Mi sono
ricordato di questo documento prodotto dalla community Freifunk e ho
pensato di tradurlo in italiano per aggiungerlo alla documentazione.

Lo trovate qui al momento:
https://github.com/stefanauss/FreifunkMoU/blob/master/FreifunkMemorandumofUnderstanding_it.md

Ovviamente se trovate errori di traduzione fatemi sapere. warning: tradotto
dall'inglese, quindi doppio layer di traduzione.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] info aggiunta subnet in gestione indirizzi

[Stefano De Carlo]

Il 12/09/2016 19:23, Michele Salerno ha scritto:
> La Backbone della Basilicata è 172.27.0.0/16
> Su tutti i router impostiamo la /16
> Altrimenti Matera (172.27.0.0) e Grassano (172.27.1.0) se non
> impostiamo la /16 non parleranno mai.
>
> Infatti, al seguente link
> http://ipam.ninux.org/?page=subnets=3=682
>
> Trovi sotto la 172.27.0.0/16 le 2 subnet per Matera e Grassano
> Matera 172.27.0.0/16
> Grassano 172.27.1.0/16
> Ne volevo aggiungere una come quellenulla di più.
>
> Michele

Michè, credo sia un bug del sistema.
È corretto che sia impossibile dire che hai una /16 all'interno di una /16.
La notazione CIDR dove l'ip non è di network è formalmente sbagliata, la usiamo 
noi colloquialmente per evidenziare che la subnet mask mesh reale da utilizzare 
è /16, anche se stiamo parlando di un range di 256 indirizzi (che quindi non è 
una vera /24). Anche questa è normale che non te la faccia utilizzare.
Quello che non capisco e non è normale, è perché te le abbia proprio fatte 
creare quelle che sono già esistenti. Che non te ne faccia creare di ulteriori, 
è normale.
Credo abbia a che fare con il fatto che dal changelog le due subnet risultano 
"ridimensionate le subnet mask" qualcosa come più di un anno fa.

Il modo corretto di procedere è quello che vedi anche altrove, se la tua 
intenzione è che la subnet emergenza abbia indirizzi da 172.27.254.0 a 
172.27.254.255, devi inserire una subnet 172.27.254.0/24.

Non so quale così su due piedi quale sarebbe il modo corretto di procedere per 
aggiustare quelle due già presenti senza cancellarle.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Nuovi nodi in zona Ortica a Milano

[Stefano De Carlo]

Il 26/08/2016 13:56, Claudio Pisa ha scritto:
> Ciao, Nicolas.
> Non ti nascondo che leggere il tuo messaggio e' stato molto faticoso,
> sia per il caldo che per la formattazione :P
>
> Ti rispondo sotto inline.

Peccato Nicolas non abbia risposto, poteva essere interessante per approfondire 
il tema del peering/transit con altre realtà simili, quando, come, perché farlo.

Si, questo è un bump spudorato, magari le ferie hanno fatto dimenticare il 
thread :-)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Per chi riserva sottoreti estese senza utilizzarle

[Stefano De Carlo]

Il 05/08/2016 19:10, Germano Massullo ha scritto:

Ciao Germano,

partendo dalla fine:

> - come già detto, nella bassa mantovana non c'è neanche un collegamento 
> attivo;
> chiedo a chi ha fatto tale prenotazione di ridimensionare fortemente
> l'ammontare di IP che ha riservato.

Questo nodo (http://map.ninux.org/select/ivan-casa/) risulta attivo dal 
10/08/2014 secondo gli archivi delle richieste di attivazioni sul map server. 
Non so così su due piedi perché compare ancora arancione e perché non ha gli 
apparati.
Ti consiglio di contattarlo, spiegarli la situazione e chiedere dei progressi 
sull'attivazione. Se non ce ne sono, concordate una riduzione, riassegnazione 
e/o cancellazione dello spazio ora assegnato a Ninux Bassa Mantovana.

Mi sembra la cosa più semplice e comunitaria da fare.
> Alla luce del fatto che in alcune organizzazioni / aziende/ ecc. si
> desidera evitare una sovrapposizione di indirizzi IP tra quelli
> utilizzati localmente e quelli di Ninux, anche se si usano tunnel vari
> per collegarsi a quest'ultima rete;

Noia forte, ma non è che è un criterio a cui possiamo sottostare quando 
scegliamo gli indirizzi IP, altrimenti non c'è una fine.
Lo siento por le orgs, ho anche io dovuto coordinare IP con Ninux, ma *in 
generale* trovo sia responsabilità delle org interoperare Ninux con la propria 
rete preesistente e il resto di Ninux.

> vorrei esprimere la mia netta contrarietà a questa consuetudine di
> riservare grandi sottoreti per aree geografiche dove non c'è neanche
> UN collegamento attivo e dove non c'è una previsione di grossa
> espansione immediata. Oltretutto consultando la mappa dell'area vedo
> che non c'è neanche una grande densità di nodi potenziali.

La suddivisione
* /16 "grande area geografica" mesh +
* /16 HNA da cui estrarre le
** /24 LAN per i singoli nodi
* altro /16 HNA all'esaurimento del primo.

da tempo proposta a tutti i nuovi ingressi a me francamente pare più che 
sufficiente in termini di ordine, logica, chiarezza e di essere alla portata di 
più o meno tutti i livelli di conoscenze.

Se Ninux partisse oggi con questa suddivisione, potremmo mappare tutta l'Italia 
e risolvere la questione dei blocchi di partenza dal momento zero, e tutti 
avrebbero indirizzi abbondantissimi per tutte le necessità dei primi 10 anni di 
isola, a prescindere da quando di preciso partono le installazioni in 
quell'area.
Pure in IPv4.

Il casino attuale non è figlio della suddivisione, ma della sua tardiva e 
inconstante applicazione, di ottimizzazioni precoci o del tutto inutili (tipo 
questa /17), di difficoltà procedurali, di pessima documentazione.

Potremmo parlare di 3mila modi diversi rispetto a quello sopra di suddividere e 
dimensionare, e andrebbero tutti bene.

Secondo me una zona con una 256 subnet che ne usa 3 da 2 anni NON è un 
problema, evitarlo non ha alcun valore; molto meglio la chiarezza iniziale che 
ti saresti creato.
Subnet pre-assegnate che sono pronte per un'isola che esisterà solo tra 3 anni, 
VA BENONE. La chiarezza fin dall'inizio invece c'ha valore.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] FCC condanna TP-Link.... all'open source? (RadioLockdown wtf)

[Stefano De Carlo]

Il 01/08/2016 22:16, Stefano De Carlo ha scritto:
> Ciao,
>
> ammetto che l'ho appena letto, al volo, e non ho tempo di verificare tutto 
> ora ma visto quanto ne abbiamo parlato, quando (mi pare) tutti reputiamo 
> importante la questione del Radio Lockdown, lo condiviso ASAP.

Sorry, ho scordato la fonte:

* http://lwn.net/Articles/695994/rss
* https://www.fcc.gov/document/fcc-settlement-tp-link

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] FCC condanna TP-Link.... all'open source? (RadioLockdown wtf)

[Stefano De Carlo]

Ciao,

ammetto che l'ho appena letto, al volo, e non ho tempo di verificare tutto ora 
ma visto quanto ne abbiamo parlato, quando (mi pare) tutti reputiamo importante 
la questione del Radio Lockdown, lo condiviso ASAP.

FCC si è accordata con tp-link per una multa di 200k $ per aver venduto 
dispositivi che permettevano potenze superiori. E fin qui, ci siamo. Ma poi nel 
brief si legge:

"""
TP-Link has also agreed to take steps to support innovation in third - party 
router firmware by committing to investigate security solutions
for certain 5 GHz band routers that would permit the use of third-party 
firmware while meeting the Commission’s security requirements and maintaining 
the integrity of critical radio parameters.
"""

Non ha senso.

FCC aveva già fatto marcia indietro sul blocco open, ma nei fatti aveva ormai 
fatto la frittata: le regole comportano un'unica soluzione economicamente 
sensata per il produttore, a prescindere dalle intenzioni del regolatore: il 
Radio Lockdown.

Il pezzo sopra non è frasato come se fosse un PR, ma come il resto del 
settlement ("the party has agreed", tipico linguaggio nel legalese americano), 
"ovvero ti multiamo 200k ma ora devi riaprire il *resto* dei device" (la radio 
è ancora off-limits).

O forse sono io che ci leggo quello che voglio io. Ovvero che con questo 
settlement, si chiarisce la regola stabilendo che il RadioLockdown è proprio 
tale, limitato solo alla radio.

Fatico proprio a trovare la ragione per cui FCC dovrebbe menzionare la cosa in 
un settlement se non è per enforce futuro.

Stefanauss.




signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Strumenti per benchmark di rete

[Stefano De Carlo]

Il 17/07/2016 21:51, Germano Massullo ha scritto:
> Avrei bisogno di un software per effettuare dei benchmark su Ubiquiti
> EdgeRouter Pro, come quelli che potete trovare al link [1]. Tali test
> sono stati effettuati con IxChariot[2], che tuttavia è un software
> commerciale. Facendo una breve ricerca su internet ho trovato dei
> software non a pagamento che tuttavia neanche si avvicinano alla qualità
> dei test della sopracitata suite: si limitano a fare delle misurazioni
> della banda passante, ma niente che riguardi ad esempio il massimo
> numero di connessioni aperte contemporaneamente.

Ovviamente scordati GUI ma puoi provare

* tcpdive - https://github.com/fastos/tcpdive
* Apache Benchmark, con l'approccio descritto qui 
http://arstechnica.com/gadgets/2016/01/numbers-dont-lie-its-time-to-build-your-own-router/

> Mi interessa scoprire se questi dispositivi, che vantano accelerazione
> hardware per la gestione dei pacchetti, soffrono di rallentamenti in
> caso di installazione di firmware non stock, come Lede/OpenWRT.
> Tale dubbio è venuto fuori ricordando che alcuni dispositivi Tp-Link
> hanno un NAT hardware che non viene sfruttato se non si usa il firmware
> originale[3]

Se è questo che devi verificare, puoi anche evitare la trafila. Nessun Network 
Accelerator "prosumer" ha supporto open source perché usano tutti custom-hack 
di netfilter, e i dev OpenWrt (presumo anche quelli LEDE), che li giudicano 
ignobili come qualità del codice, non si muoveranno finché non ci sarà un 
approccio general purpose nel kernel. Tutto questo in aggiunta ai soliti 
problemi sulla documentazione e reverse engineering dei chip.

Nei benchmark otterresti gli stessi risultati che se il chip non ci fosse, non 
è predisposto nessun offloading.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] L4-over-UDP

[Stefano De Carlo]

http://lwn.net/Articles/691887/

Un bel pezzo sulle conseguenze nello spostare protocolli di rete più ad alto 
livello dal kernel allo userspace.

Stefanauss.




signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

[Ninux-Wireless] RFC CLI & Offline Reader

[Stefano De Carlo]

Leggi le RFC come fossero man pages. Veramente carino!

https://github.com/monsieurh/rfc_reader

Stefanauss.




signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Router Vs. Raspberry P2

[Stefano De Carlo]

Il 08/05/2016 16:43, Michele Salerno ha scritto:
> Sul router ho
> config interface 'lan'
>  
>  option _orig_ifame 'eth0 radio0.network1'
>  option _orig_bridge 'true'
>  option ifname eth0 eth0.10'

option type 'bridge'
option ifname eth0 eth1.10

>
> config interface 'm2'
>  
>  option _orig_ifname 'eth1.3'
>  option ifname 'eth1.10 eth1.3'

option ifname eth1.3

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Bozza decreto attuazione direttiva EU

[Stefano De Carlo]

Il 30/04/2016 14:20, Nemesis ha scritto:
> E' disponibile una bozza del decreto per l'attuazione della normativa EU
> di cui abbiamo parlato sul blog:
>
> http://www.sviluppoeconomico.gov.it/images/stories/documenti/schema_di_decreto_di_attuazione_2014_53_UE.pdf

Ho aggiornato http://wiki.ninux.org/LeggiWireless con una sezione apposita.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Chaos Calmer: ping IPv6 multicast broken ?

[Stefano De Carlo]

Il 01/05/2016 20:11, Saverio Proto ha scritto:
> forse questo device ha un chip ethernet che butta via roba IPv6 ... possible ?

Yep, pare che butti via IPv6 multicast: https://dev.openwrt.org/ticket/20453

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] SuperNodo AIRMAX o AC?

[Stefano De Carlo]

Il 12/04/2016 13:30, Giuseppe Ferraiolo ha scritto:
> Ciao a tutti,
> avrei bisogno di un aiutino per la scelta dell’hw per un supernodo nel centro 
> storico di Napoli.
> Personalmente pensavo di partire con Rocket 5 + Settoriale 120 ma sono 
> indeciso se prendere o meno la versione AC.
> Non ho alcuna esperienza in merito e sto cercando di mettere sul piatto della 
> bilancia i benefici di maggiore banda contro la minor compatibilità ed il 
> prezzo.

L'incremento di banda dato da ac è del 20% rispetto ad n, @ SISO/MIMO 20 MHz.
Ogni incremento superiore è dettato da caratteristiche che sprecano lo spettro 
è che quindi sono circostanziali e non sostenibili a lungo termine. Io dei link 
a 80/160 di banda non li concepisco proprio, e quando devo mettere sul piatto 
della bilancia gli incrementi di throughput di 802.11ac, considero sempre e 
solo un +20% rispetto ad 802.11n perché è l'unico dato sostenibile e ripetibile.

Un +20% è sempre buono e in principio non si rifiuta di certo, ma nel caso di 
Ubiquiti, arriva al prezzo di totale incompatibilità.

Secondo me 802.11ac in salsa Ubiquiti non è adatto a Ninux, a parte qualche 
specifica backbone su cui si è singolarmente valutato l'impatto dell'upgrade.
Valuta il tuo bilancio delle priorità, ma ti consiglio di non pensare ai 
throughput peri-gigabit quando pensi alle performance di AC.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] proposta di usare 192.168/16 solo per uso locale

[Stefano De Carlo]

Il 15/03/2016 13:04, Matteo Pedani ha scritto:
> Propongo quindi di liberare la 192.168/16 e destinarla ad un uso privato e 
> non comunitario. E permetterne una gestione migliore.

Se l'obbiettivo comunitario è evitare problemi di interoperabilità tra routing 
domain ninux e privato, non è necessario dichiarare tutta la /16 non routabile 
su ninux. Bastano 5 subnet

* 192.168.0.0/24
* 192.168.1.0/24

E uno si potrebbe pure fermare qui e avrebbe risolto praticamente tutti i 
conflitti generati dagli indirizzamenti tipici di default. Quindi 
essenzialmente, si tratterebbe della 192.168.0.0/23. In modalità paranoia si 
aggiungerebbero:

* 192.168.2.0/24
* 192.168.100.0/24
* 192.168.200.0/24
* 192.168.254.0/24

Oltre queste la probabilità di trovarsi un conflitto tra indirizzamenti 
pre-esistenti e Ninux nelle tabelle è trascurabile e probabilmente risolvibile 
lato-nodo.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] 802.11ac in ambienti urbani densi

[Stefano De Carlo]

Il 28/02/2016 19:56, Massimiliano CARNEMOLLA ha scritto:
> Come devono essere connesse le radio internamente per andare bene allora ? 

C'è scritto nel passaggio che hai quotato, Max: PCI, PCIe.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Switch 10 Gbit/s (rame)

[Stefano De Carlo]

Il 11/02/2016 11:11, Germano Massullo ha scritto:
> Ciao Stefano, mi servirebbe sapere quanto li avete pagati.
> Grazie mille

Ciao Germano,

gli switch erano già del/dal cliente. Dammi qualche giorno e ti faccio sapere.

Il modello è XS712T.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Rapporto download - upload

[Stefano De Carlo]

Il 10/02/2016 13:43, Massimiliano CARNEMOLLA ha scritto:
> su connessioni UDP non dovrebbe comportare problemi.
>
> [snip]

Ciao Max,

Non c'è niente di intrinseco in TCP e UDP che impedisca loro di avere dl/ul 
simmetrici (rapporto 1:1).

Le caratteristiche del protocollo L3 (IPv4/IPv6) non hanno nessun impatto sulle 
performance del protocollo di L4 (UDP/TCP), al di fuori dell'MTU, che però è 
una caratteristica che deriva dal L2.

E difatti la totalità delle cose che hai accennato successivamente ha tutto a 
che fare con il mezzo di trasmissione e le caratteristiche dei protocolli a più 
basso livello, e assolutamente nulla con TCP e UDP.

Per capire meglio perché, devi approfondire

* TCP
* UDP
* "Frequency Plan"
* Half- vs Full- Duplex

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Acquisto apparati a 5 Ghz

[Stefano De Carlo]

Il 08/02/2016 20:57, Massimiliano CARNEMOLLA ha scritto:
> Nel caso scelga device 802.1ac come AP si possono collegare station di 
> diversa natura tipo AN o solo A senza pregiudicare le prestazioni di chi si 
> linka in AC ? 

No, non puoi evitare di intaccare. L'impatto può non essere necessariamente 
lineare o proporzionale, dipende dalla situazione specifica, ma c'è. rate più 
lenti -> air times più alti.
È il motivo per cui, per risolvere _tecnicamente_ il problema, esiste Airmax.

Puoi leggere cose molto antipatiche qui: 
http://www.smallnetbuilder.com/wireless/wireless-features/32284-how-well-do-ac-routers-handle-mixed-networks

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Acquisto apparati a 5 Ghz

[Stefano De Carlo]

Il 05/02/2016 12:44, Massimiliano CARNEMOLLA ha scritto:
> Posso utilizzare apparati Mikrotik - Ubiquiti con 802.11 AC o non si linkano 
> tra di loro (apparati di diverse marche) perche' non rispettano gli standard ?
>

Non so Mikrotik, ma Ubiquiti non utilizza 802.11ac, utilizza la sua versione 
chiamata Airmax AC (v7 o v8). Quindi no, non puoi.

> In alternativa posso considerare gli apparati Open Hardware consigliati da 
> Elena of Valhalla come valida alternativa ?
>

Prima menzioni apparati wireless a 5 GHz, poi un olino a 2.4 GHz, quindi ti 
rispondo di no.
Tieni sempre a mente che queste board "open hardware" hanno comunque chipset 
proprietari, quindi a seconda di quello che cerchi di raggiungere comprando OH 
la risposta varierà.
Se per "valida alternativa" intendi a livello tecnico, la risposta è 
incontrovertibilmente no, lo sono se cerchi di raggiungere un determinato 
compromesso al ribasso tra libertà personale e utilità pratica.
Ti suggerisco, finché non ne capirai di più e sarai in grado di fare tu le tue 
personali valutazioni sul compromesso in questione, di lasciar perdere 
"open/libre" come criterio per selezionare hw.

>
> Nel caso che AC non sia possibile sempre utilizzando apparati di marche 
> diverse vorrei prendere trasmettitori senza antenne e poi prendere antenne a 
> seconda il tipo di link.

La flessibilità massima che cerchi te la danno le Routerboard con slot 
mini-pci/pci-e supplementari.
Ma questo tipo di soluzione arriva, una volta implementata, a > 2x dei costi 
delle soluzioni integrate.

Scalando al ribasso le Rocket M5 e Le Bullet M2/5 sono ancora buonissime 
soluzioni per usare una stessa radio con scelte flessibili di antenna (alcune 
delle quali proposte da Ubiquiti stessa). In ogni caso anche qua avere la base 
station separata si traduce in costi supplemntari considerevoli in proporzione.

> Devo preferire MIMO?

Si (linea guida), ma senza stare a fissartici perché difficilmente nel mondo 
reale è il MIMO-si-MIMO-no che "va o spacca" un link. È una funzionalità che, 
se tutto il resto è in ordine, aumenta anche considerevolmente l'efficienza di 
una risorsa finita. Ma deve valere il "tutto il resto".

>
> Nel caso di omnidirezionale piu' di 500 metri non riesco a farci ?
>

È una "linea guida" che vale la maggior parte delle volte e a cui puoi 
attenerti, si.
Poi dipende dai dettagli.

> Es. con una 120 gradi quanti Km posso farci ?

(linea guida) i massimali hanno poco senso, con una 120 devi mantenerti sui 
10-12 km perché il limite vero è rappresentato dalla performance anomaly: vuoi 
che le STA mantengano segnali omogenei tra loro e tendenti all'alto. Riducendo 
quindi l'airtime, per quanto possibile.

(linea guida) il massimale per noi è stato 27km, link associato e traffico 
passante senza particolari problemi.

>
> Nel caso di trasmettitori con dual o triple chain significa per esempio che 
> (avendo 3 connettori) posso collegarci tre antenne a 120 e avere una 
> copertura a 360 gradi ?

No.
Le chain sono una proprietà della radio, non dell'antenna.
Le chain multiple lavorano sullo _stesso dataset_, ma codificato e trasmesso in 
stream spaziali multipli e diversificati, riassemblati alla destinazione.
Semplificando nel tuo esempio con quel setup capteresti solo uno degli stream 
spaziali in cui il segnale è ripartito dal MIMO, ma uno solo è spazzatura se 
non combinato con gli altri.

>
> Mi serve qualche linea guida per evitare di spendere soldi inutilmente o 
> ancora peggio di farli buttare agli altri che mi chiedono quale tipo di 
> materiale acquistare per realizzare link wireless.
>

Difficilmente si può sintetizzare tutto se non prendendola molto alla larga.
Dall'esperienza personale in anni di Ninux, ti posso dire che se:

* ti mantieni sempre e solo sotto i 5 km di link
* vuoi hw interoperabile e quindi potenzialmente longevo
* vuoi hw flessibile a tipo di link diversi
* il budget è un limite

praticamente non esiste una situazione dove la Nanostation M5 sia uno spreco in 
termini di tempo e/o soldi e features. È e rimane un jolly.

Se pretendi fin dal momento zero di beccare l'hw perfetto e calibrato per ogni 
dato tipo di link, specie con le limitate esperienze e conoscenze che al 
momento hai, non ti muoverai mai. Ne per definizione lo beccherai con "linea 
guida". Parti alla larga e poi migliora i link (_già funzionanti_) osservando 
sul campo.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Switch 10 Gbit/s (rame)

[Stefano De Carlo]

Il 24/01/2016 21:58, Germano Massullo ha scritto:
> Volevo segnalarvi che finalmente qualcuno sta iniziando a produrre
> switch 10 Gbit/s a costi tutto sommato umani
> http://www.netgear.it/landing/10gigabit.aspx

Ancora per qualche settimana avrò a disposizione due

http://www.netgear.com/business/products/switches/smart/XS712T.aspx#tab-techspecs

per un lavoro. Se serve sapere qualcosa, chiedete ;-)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Flash OpenWRT su Ubiquiti PowerBeam 400

[Stefano De Carlo]

Il giorno ven 15 gen 2016 alle ore 09:14 Alfredo Vania 
ha scritto:

>
> Buongiorno a tutti.
> Qualcuno ha mai provato a flashare una ubbiquiti PowerBeam400 con
> Scooreggione? O, più in generale, con OpenWRT?
>

Scorregione no di certo, OpenWrt pare di si:
https://wiki.openwrt.org/toh/ubiquiti/powerbeam

Wiki a parte, mi ricordo di aver letto fosse compatibile, ma non ho provato
personalmente.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Alimentatori delle Nanostation

[Stefano De Carlo]

Il giorno ven 8 gen 2016 alle ore 00:06 Andrea Grillini <
andrea.grill...@gmail.com> ha scritto:

> L'alimentatore di una Nanostation M5 è lo stesso di una Nanostation
> Loco M5?
>

Ciao Andrea,

si, è lo stesso.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Subnet 10.90.x.x - vecchia/nuova gestione indirizzi (was: Nuovo visualizer topologia)

[Stefano De Carlo]

Il giorno lun 4 gen 2016 alle ore 15:42 Giuliano G <
morpheo76.ni...@gmail.com> ha scritto:

> Solito problema della transizione da un sistema vecchio ad uno nuovo.
>
> Cambio nome al thread x dargli più visibilità, aggiungendo un esortazione
> a tutti ad aggiornare i propri dati.
>
> Giuliano
> aka
> Morpheo76
> Il 04/gen/2016 14:42, "Claudio"  ha scritto:
>
>> ok, nessun problema a cambiare la sottorete :)  ma quando ho inserito la
>> 10.90.0.0 nel nuovo database era libera.
>>
>>

Ciao Giuliano/Claudio,

scusa per il disguido, ho variato da Palermo a Crotone e in più aggiunto
Lamezia (10.92/16) nel nuovo database.

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Subnet 10.90.x.x - vecchia/nuova gestione indirizzi (was: Nuovo visualizer topologia)

[Stefano De Carlo]

Il giorno lun 4 gen 2016 alle ore 16:19 Claudio  ha
scritto:

> ok, nessun problema :) ...quindi mi sembra di capire che la necessità del
> CAP si attua dove è possibile?
>
>
No, del CAP e del metodo relativo non c'è più necessità (non c'è mai stata
necessità, in realtà), ed è deprecato perché nella sua forma era
controproducente ora che Ninux è una realtà estesa oltre Roma (ad esempio
renderà molto difficile fare summarization di rotte relative alle isole che
lo hanno usato).

Stefanauss.
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] attivazione

[Stefano De Carlo]

Il 30/12/2015 00:14, Claudio ha scritto:
> Buonasera, sono Claudio 
>
> vorrei attivare un altro nodo nella mappa ninux 
>
> il nodo vicino è: http://map.ninux.org/select/giuseppe/

Ciao Claudio,

ho attivato il nodo linkato, ora è verdizzato sulla mappa.
Non dimenticarti di completarlo inserendo
- Device installati
- Indirizzi configurati

Buon Ninux e buon link :)

Stefanauss.

P.S. Queste richieste di attivazione è meglio segnalarle a contatti [at] ninux 
[dot] org



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] presentazione

[Stefano De Carlo]

Il 30/12/2015 21:38, Vincenzo Quaranta ha scritto:
> Ciao a tutti,
> mi chiamo Vincenzo, sono un appassionato di informatica e sto seguendo il 
> corso Advanced Networking dell'Hacklab di Cosenza.
> Insieme ad altri amici di Taranto vorremmo creare dei nodi e sperimentare la 
> rete comunitaria.
> Spero di poter dare il migliore contributo alla rete e di fare una nuova 
> esperienza di conoscenza
>
> Grazie per l'accoglienza :D
>  
> Buon 2016 a tutti

Ehilà Vincenzo, benvenuto in Ninux.org :)

La prossima volta che passate da Cosenza se volete ci organizziamo per 
smanettare più attivamente ;-)

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Sperimentazione IPv6

[Stefano De Carlo]

Il 02/01/2016 10:57, Massimiliano CARNEMOLLA ha scritto:
> Come faccio a capire quale RFC al riguardo e' quella piu' aggiornata in modo 
> che possa studiarla senza perdere tempo ?
>
>
> Conoscete qualche libro cartaceo o guida su internet in italiano o inglese 
> complete sulle quali possa iniziare a studiare ?

Questa è moolto buona:

https://technet.microsoft.com/en-us/library/cc738109

Nelle sezioni "What is IPv6" e "How IPv6 Works".

È lunga e dettagliata, ma non è un libro. In 1-2 giorni ne sai molto di più. In 
più in fondo c'ha pure un elenco di un sacco di RFCs rilevanti.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Non passate da AirOS 5.6.X a OpenWRT!!

[Stefano De Carlo]

Il 31/12/2015 16:01, Ilario Gelmetti ha scritto:
> On 12/30/2015 08:58 PM, Luigi Porto wrote:
>> D'altronde abbiamo già previsto molto tempo fa questo comportamento
>> ovviando con la diffusione del routing a terra.
> Il che risulta in un vendor lock-in (le antenne di due nodi che fanno
> routing a terra devono avere lo stesso firmware per potersi collegare,
> se ho capito bene).

Al momento
- AirOS 5.x: Compatibile con 3rd party, basta disabilitare Airmax N; Non 
Compatibile con AirOS 7/8
- AirOS 6.x: Compatibile con 3rd party, basta disabilitare AirMax N; 
Compatibile Con AirOS 8, ma solo come STA.
- AirOS 7.x: Compatibile solo con AirOS 7.x e 8.x, non implementa nessuno 
standard 802.11
- AirOS 8.x: Compatibile con AirOS 7.x e 8.x, e con AirOS 6.x in sola modalità 
AP. Non implementa nessuno standard 802.11

Sembrerebbe  tracciata la strada, anche perché sono sempre molto evasivi 
sull'implementazione/abilitazione di 802.11n/ac puro sull'ultima linea di 
prodotti.

Che poi è il principale motivo per cui in molti a Cosenza non abbiamo proprio 
acquistato prodotti AC. È anche vero però che la situazione supporto in Linux a 
802.11ac non è rosea al momento a prescindere da Ubiquiti.

> Speriamo che questi simpatici giochetti (tipo controllo della firma
> dell'immagine) non li inizino a fare pure TP-Link e gli altri produttori
> che usiamo per i router a terra.

In realtà lo ha fatto, per fortuna per ora solo (afaik) sul TD-W8970/8980/9980, 
che però sarebbero ground router interessantissimi per Ninux per via della loro 
facile disponibilità, basso costo, e (cosa rarissima) supporto in 3rd party a 
modem ADSL/VDSL!

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Non passate da AirOS 5.6.X a OpenWRT!!

[Stefano De Carlo]

Il 30/12/2015 20:18, Luigi Porto ha scritto:
> Basta revertare da 5.6.x a 5.5.10 prima di effettuare qualsi 3rd party flash..

Leggi attentamente i link postati da Ilario.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Non passate da AirOS 5.6.X a OpenWRT!!

[Stefano De Carlo]

Il 30/12/2015 20:08, Ilario Gelmetti ha scritto:
> Per ora online non ho trovato una soluzione vera e completa, nei
> prossimi giorni farò delle prove.
> Ciao,
> Ilario

Ilà, non mi torna una cosa. I device XM che abbiamo passato da 5.5.6 a 5.6.3 
non hanno il layout delle partizioni che dicono sia associato all'upgrade e 
problematico, ma quello precedente:

XM.v5.6.3# cat /proc/mtd
dev:size   erasesize  name
mtd0: 0004 0001 "u-boot"
mtd1: 0001 0001 "u-boot-env"
mtd2: 0010 0001 "kernel"
mtd3: 0066 0001 "rootfs"
mtd4: 0004 0001 "cfg"
mtd5: 0001 0001 "EEPROM"

Provato con una NanoBridge M5 e una Bullet M2HP, ovviamente XM. Ovviamente non 
ho provato a flasharci OpenWrt, e non so come verificare la versione di uboot 
senza seriale. Ma l'output di /proc/mtd dovrebbe essere fedele.

Riesci a postare l'output di un device soft-briccato?

> PS urge abbandonare questi produttori di hardware infami per provare
> alternative più open e comunitarie, che non ci tendano simili trappole.
>
> [1] http://libertybsd.net/ubiquiti/
> [2] http://www.aredn.org/comment/849#comment-849
> [3] https://wiki.openwrt.org/toh/ubiquiti/airmaxm


Se ne possono dire di cose sulla Ubnt, ma questa è una roba normalissima.
Se tu controlli mezzo trunk di OpenWrt sono commit del mkfwimage per ovviare ai 
cambiamenti di layout uboot dei produttori.
Sul serio, lo fanno tutti, di continuo.
Manco avessero messo il controllo della firma crittografica alle immagini.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Non passate da AirOS 5.6.X a OpenWRT!!

[Stefano De Carlo]

Il 30/12/2015 22:01, Ilario Gelmetti ha scritto:
> On 12/30/2015 09:17 PM, Stefano De Carlo wrote:
> Non ho verificato ma avevo letto lo stesso commento da qualche parte:
> https://dev.openwrt.org/ticket/20982#comment:12

Ok, grazie.
Dicono che, anche a partizioni identiche, basta il nuovo uboot a sminchiare 
tutto.

>> Manco avessero messo il controllo della firma crittografica alle immagini.
> LOL, anzi, non fa tanto ridere... :/
> https://lists.openwrt.org/pipermail/openwrt-devel/2015-November/037572.html

Oh, well :(

Facci sapè,
Se ti serve poi un backup art dicci,
Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Due vlan su ogni antenna per il routing a terra

[Stefano De Carlo]

Il 26/12/2015 18:24, Ilario Gelmetti ha scritto:
> Ciao!
> Altra domanda sul routing a terra: perché creiamo una seconda vlan per
> il management sulle antenne invece di usare direttamente il bridge
> appena creato per il traffico dati?
> Lasciando l'interfaccia di management su, ad esempio, eth0.7 posso
> gestire le antenne solo collegandomi direttamente col portatile e
> impostandoci la vlan 7 di management.
> Invece impostando su AirOS come interfaccia di management il bridge0
> (che comprende wlan0 e eth0.6), ora posso raggiungere le antenne anche
> connettendomi al router a terra (che è configurato per comunicare sulla
> vlan 6 ma non sulla 7) senza dover configurare nulla sul pc.
> Ci sono controindicazioni?
> Grazie e ciao,
> Ilario


Ciao Ilario,

non ho ben capito il problema originario: da procedura secondo guida, non c'è 
alcun bisogno di impostare VLAN su nessun PC per collegarsi alle antenne 
_tramite ground router_. Diventa necessario solo se vuoi proprio collegare un 
pc direttamente ad un'antenna (impostata secondo HOWTO), ma non è che sia 
necessario, puoi passare dal GR.

Non ho capito che configurazione hai, nè su router nè su antenna. Tieni a mente 
che la guida è pensata per OLSR, quindi se stai usando il routing a terra con 
batman, ci sono probabilemente altre considerazioni da fare.

Una *possibile* (ma senza capire la configurazione esatta non ti so dire) 
controindicazione è che potresti star ricevendo traffico OLSR sulla LAN, o 
avere un bridge che dovrebbe lavorare a L2 che invece sta processando L3 (il 
che può portare ad ogni sorta di stranezza, pacchetti duplicati, overhead, etc).

Per la domanda originaria è semplice: la necessità della seconda VLAN *taggata* 
su AirOS esiste solo per retrocompatibilità con alcuni switch Atheros di 
OpenWrt che non digeriscono la ricezione di pacchetti taggati && non-taggati 
sulla stessa porta: droppano. È anche accennato nella guida.

Se uno non soffre di questi problemi sullo switch OpenWrt. potrebbe non creare 
la seconda VLAN su AirOS e usare LAN0 come management. I pacchetti di 
management sarebbero tutti untagged (quindi sempre parte di una seconda VLAN, 
solo "implicita" stavolta), il risultato identico, la configurazione un pelo 
più semplificata.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] Help: puntamento perfetto!

[Stefano De Carlo]

Il 09/12/2015 23:38, Michele Salerno ha scritto:
> Ma tra 2 supernodi con 2 antenne NanoBeam 5AC 19 configurate PtP se
> salgo di MHz non credo di fare chissà quale danno.
> Ho notato un incremento notevole passando da 20Mhz a 80Mhz.
> A 20MHz avevo TX e RX tra 90 e 100Mb.
> A 80Mhz TX e RX oscillano tra 250-300 Mb.
>
> Per le antenne normali fose è meglio lasciare a 20Mhz
>
> Cosa ne dite?

Lascia perdere il TX/RX negoziato, non è probante. Fai test di throughput reale 
(iperf), latenze (mtr).

Molto, molto spesso il guadagno (se c'è) è *modesto*. Fai prove reali e sulla 
base di quelle valuti il compromesso per te e verso gli altri.

Stefanauss.



signature.asc
Description: OpenPGP digital signature
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless