Re: [Ninux-Wireless] Fwd: [Bologna] estate ninux - compere collettive
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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?
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
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
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
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
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
Re: [Ninux-Wireless] IRC Meeting 29 Gennaio 2018
Il 29/01/2018 16:43, Stefano De Carlo ha scritto: > Cari Ninuxer, questa sera dalle 21:00 alle 22:00 IRC Meeting Ninux Resconto del meetbot: http://86.119.33.5/ninux_org_irc_meeting_29_gennaio_2018/2018/ninux_org_irc_meeting_29_gennaio_2018.2018-01-29-20.05.html Log completi: http://86.119.33.5/ninux_org_irc_meeting_29_gennaio_2018/2018/ninux_org_irc_meeting_29_gennaio_2018.2018-01-29-20.05.log.html ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
[Ninux-Wireless] IRC Meeting 29 Gennaio 2018
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)
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)
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)
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)
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]
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
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
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
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
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
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
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
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
Il 23/10/2017 10:45, Claudio Pisa ha scritto: > Che succede? > E' intenzionale o accidentale? > http://wiki.ninux.org/GestioneIndirizzi?action=diff&rev2=1646&rev1=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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 l'hotsp
Re: [Ninux-Wireless] NodogSplash e Traffic Control
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
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
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
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§ion=3&subnetId=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
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
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)
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)
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
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
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
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
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] Fwd: Introducing the LEDE project
Il 07/05/2016 10:30, Massimiliano CARNEMOLLA ha scritto: > On 04/05/16 00:20, Ilario Gelmetti wrote: > >> Era davvero necessaria questa nuova frammentazione? > > Siamo in grado di coalizzarci tutti insieme per snobbare questa cosa rendendo > inutile tutto cio' ? Prima ancora: perchè dovremmo? hai dei dettagli per rispondere "No" alla domanda di Ilario? Forkare è pericoloso e delicato, può andar male in mille modi diversi ma non è il male in assoluto, e per le ragioni giuste e al momento giusto (specie quando si è provata ogni altra alternativa) può avere ricadute positive *persino per il progetto forkato*. 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
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 ?
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?
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
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
Il 28/02/2016 21:17, Elena ``of Valhalla'' ha scritto: > nel passaggio però c'è un not di troppo (anche se poi la frase perde > abbastanza senso): Aaaahi ragione, li avevo corretti mentalmente :-) Spererei che anche il "not" prima di USB sia di troppo. Hanno ragione, non è ragionevole, ma se l'FCC lockdown fa ripartire l'epoca d'oro del wireless/networking homebrew, non è una cosa troppo entusiasmante da leggere. Stefanauss. signature.asc Description: OpenPGP digital signature ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] [ninux-roma] 802.11ac in ambienti urbani densi
Il 25/02/2016 11:43, Claudio Pisa ha scritto: > Vi torna? Eccome. Sia da g a n, che da n ad ac, l'incremento di efficienza teorica a parità di singolo stream a 20 MHz è esattamente del 20%. Anche se si riflettesse sempre in pratica, da solo non giustifica uno switch e i relativi costi e/o imbarazzi logistici. Le vere killer feature del N sono state 2, una built-in e sistemica, l'altra circostanziale: MIMO e 5GHz/40 MHz. Il nuovo spettro aveva gli anni contati, quindi un nuovo standard che di base è un'evoluzione ma che per mantenere le promesse fa un uso ancora più scellerato dello spettro è un gigantesco "embè?". Il MU-MIMO è interessante per via dell'impatto reale del suo predecessore, ma onestamente aspetto di vederlo nella vita vissuta. Mi sembra lontanuccio dal diventare pratica comune. A me sembra che quasi tutto dell'hype sui prodotti AC sia erroneamente generato dallo standard, quando in realtà sarebbe da attribuirsi ai consistenti progressi nella progettazione dell'hardware, nelle estensioni, nei driver proprietari, nel range variegato di prodotti a disposizione. E questo solo discutendo meriti e demeriti dello standard. Fattorizzando anche che, ad esempio per Ubiquiti, un prodotto AC significa un prodotto completamente non standard, non interoperabile, e nemmeno forzabile ad esserlo (flash 3rd-party), 802.11ac è un totale no-go per me. A Cosenza cerco di spiegarlo a chiunque mi stia a sentire :-) Sono il primo sostenitore dell'opportunità di AirOS sull'antenna, ma solo perché ho (avevo) le scelte aperte dovessero cambiare le condizioni. Come considerazione a margine, la situazione di ath9k (il driver 802.11n di Atheros) in Linux, dove * il driver è tendente all'alto come qualità * il driver è opensource * il _firmware_ è open source (seriamente, nemmeno Intel) * l'azienda lavora tantissimo upstream è rarissima nel free software ed è unica nel sottosistema wireless, quindi personalmente ci rinuncerò solo quando costretto. 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
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)
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
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
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
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)
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
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
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)
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] Subnet 10.90.x.x - vecchia/nuova gestione indirizzi (was: Nuovo visualizer topologia)
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] Sperimentazione IPv6
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] presentazione
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] attivazione
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] Non passate da AirOS 5.6.X a OpenWRT!!
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!!
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