Re: [Ninux-Wireless] PicoPeering e peering obligation
> Il giorno 16/set/2016, alle ore 00:24, Elena ``of Valhalla''
> ha scritto:
>
> On 2016-09-15 at 19:17:58 +0200, Stefano De Carlo wrote:
>> * 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.
>
> 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?
“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]
In buona sostanza il PPA è un contratto. Come contratto deve essere stipulato
da *entrambe* le parti, tramite “un’interazione paritaria”. Non univocamente da
parte di chi si voglia agganciare.
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.
2- ‘Interazione paritaria’ .. io estenderei questo concetto anche al fatto di
connettere un nodo foglia a un supernodo . I nodi foglia non portano ad
un’estensione della rete e a meno di casi particolari non portano servizi alla
comunità .. quindi anche in questo caso, salvo le particolarità, un “supernodo”
potrebbe scegliere di non fare un PPA con un nodo foglia perchè l’interazione
non è paritaria, non ne riceve alcun beneficio, nemmeno in termini di
distribuzione del traffico che arriva sul suo nodo, se poi lo ritiene opportuno
fatti suoi .. rientra all’interno di un accordo tra i proprietari dei due nodi
[1] http://wiki.ninux.org/PicoPeer
BornAgain
bornagain [at] autoproduzioni.net
Nodi su rete wireless comunitaria Ninux.org
http://map.ninux.org/select/reggiocalbornagain/
http://map.ninux.org/select/romapandora/
ed altri ..
>
> ¹ e quindi non ha bisogno di modifiche di puntamento delle antenne
>
> --
> Elena ``of Valhalla''
> ___
> Wireless mailing list
> Wireless@ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/wireless
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] Massively distributed Openstack
On 09/15/2016 05:53 PM, Saverio Proto wrote: > devstack è come usare tutti i giorni Linux con il LiveCD per capirsi. > > openstack single node si fa solo a scuola per didattica, o per provare > una patch. Ma c'e' un vero motivo o e' "solo" la best practice, indotta anche dal fatto che i deployment di openstack nel mondo reale sono di ben altre dimensioni? > scrivo da cellulare. quando avrò una tastiera vera sottomano risponderò > piu decentwmente. sorry Ok. > ma vogliamo fare una serata a tema a Roma la prossima volta che scendo ? Magari! Clauz ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] PicoPeering e peering obligation
On 09/15/2016 07:17 PM, Stefano De Carlo wrote:
> 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.
Si' siamo arrivati (ahime') alla stessa conclusione anche a Roma dopo
che qualcuno ha iniziato ad usare le ACL.
Clauz
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
credo che sia errato promuovere mezzi di anonimizzazione. anzi ritengo giusto il comportamento opposto, la relazione tra ip e macchine é pubblico (anche x tribunali, polizia). Quindi risalire a chi sei é una bazzecola per la polizia postale. Certo é che se uno vuole anonimizzare il proprio traffico. le vpn e le reti x anoninizzare sono buone. ma da vecchio sistemista confido nella tecnologia che le persone. E molto piú facile usare le persone per farsi dire le pass che andare a crakkarle. idem vpn é molto piú facile creare una vpn free. ma secondo me non vi dovete nenche preoccupare di creare una vpn. oggi come oggi terroristi usano telegram per fare quello che vigliono. Il giorno 16/set/2016 02:37, "Stefano De Carlo" ha scritto: > > 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 > > > ___ > 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] NodogSplash e Traffic Control
https://relakks.com/faq leggi tutta la parte legal. ti protegge abbastanza bene. Saverio Il 16 set 2016 2:37 AM, "Stefano De Carlo" ha scritto: > 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 > > > ___ > 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] NodogSplash e Traffic Control
Rispondo dopo aver contato fino a 10. On 09/16/2016 11:36 AM, Matteo Pedani wrote: > credo che sia errato promuovere mezzi di anonimizzazione. E invece l'anonimizzazione permette la liberta' di parola in molti casi. Comunque qui non stiamo parlando veramente di anonimizzazione, IMO. Stiamo parlando di trasportare il traffico in Paesi in cui la legislazione e' diversa per quanto riguarda le responsabilita'. > anzi ritengo > giusto il comportamento opposto, la relazione tra ip e macchine é > pubblico (anche x tribunali, polizia). Quindi risalire a chi sei é una > bazzecola per la polizia postale. Certo é che se uno vuole anonimizzare > il proprio traffico. le vpn e le reti x anoninizzare sono buone. ma da > vecchio sistemista confido nella tecnologia che le persone. Bah. Se usi la VPN svedese esci con un IP associato alla macchina del provider svedese che non e' tenuto, per le leggi locali, a tenere traccia di chi stava usando la VPN in quel momento. > E molto piú > facile usare le persone per farsi dire le pass che andare a crakkarle. Quali password? E' scorrelato dal discorso sopra. > idem vpn é molto piú facile creare una vpn free. ma secondo me non vi > dovete nenche preoccupare di creare una vpn. oggi come oggi terroristi > usano telegram per fare quello che vigliono. ??? E comunque telegram e' sopravvalutato dal punto di vista della sicurezza. Clauz ___ 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 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] 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] PicoPeering e peering obligation
> Il giorno 16/set/2016, alle ore 13:51, Stefano De Carlo > ha scritto: > > 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". =sostanzialmente > 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. > Al termine “contratto” ho dato un’accezione un pò più estesa dell’ambito legale che arriva proprio al discorso convergenza di pensieri .. regole comuni, che stanno bene ad entrambi >> 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? no tu ne accetti però quello che è scritto dentro. quindi è comunque bilaterale. > >> 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). Esatto .. diciamo che il mio discorso “legale” sul contratto era riferito al fatto che, chiamiamolo come vogliamo, ma non può esistere l’obbligo per il proprietario di un nodo di far connettere sull’antenna chiunque perchè lo stabilisce il PPA (ho sentito fare diverse volte questo discorso in questi anni). > >> >> 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. > > ___ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless signature.asc Description: Message signed with OpenPGP using GPGMail ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] PicoPeering e peering obligation
Perché non promuovere il picopeering con le stesse modalitá della gpl? con testo e logo e link da mettere alle pag web. Il giorno 16/set/2016 13:51, "Stefano De Carlo" ha scritto: > 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. > > > ___ > 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] NodogSplash e Traffic Control
Capisco, anche io conto, ed in effettii ho cassato l'email di risposta che ti rissumo in due righe. ... Quello che volevo dire in sintesi, è meglio che sia l'utente finale a secgliere ed usare una tecnologia che rende anonima la rete. Il giorno 16 settembre 2016 12:52, Claudio Pisa ha scritto: > Rispondo dopo aver contato fino a 10. > > On 09/16/2016 11:36 AM, Matteo Pedani wrote: > > credo che sia errato promuovere mezzi di anonimizzazione. > > E invece l'anonimizzazione permette la liberta' di parola in molti casi. > > Comunque qui non stiamo parlando veramente di anonimizzazione, IMO. > Stiamo parlando di trasportare il traffico in Paesi in cui la > legislazione e' diversa per quanto riguarda le responsabilita'. > > > > anzi ritengo > > giusto il comportamento opposto, la relazione tra ip e macchine é > > pubblico (anche x tribunali, polizia). Quindi risalire a chi sei é una > > bazzecola per la polizia postale. Certo é che se uno vuole anonimizzare > > il proprio traffico. le vpn e le reti x anoninizzare sono buone. ma da > > vecchio sistemista confido nella tecnologia che le persone. > > Bah. Se usi la VPN svedese esci con un IP associato alla macchina del > provider svedese che non e' tenuto, per le leggi locali, a tenere > traccia di chi stava usando la VPN in quel momento. > > > > E molto piú > > facile usare le persone per farsi dire le pass che andare a crakkarle. > > Quali password? E' scorrelato dal discorso sopra. > > > > idem vpn é molto piú facile creare una vpn free. ma secondo me non vi > > dovete nenche preoccupare di creare una vpn. oggi come oggi terroristi > > usano telegram per fare quello che vigliono. > > ??? > > E comunque telegram e' sopravvalutato dal punto di vista della sicurezza. > > Clauz > > ___ > Wireless mailing list > Wireless@ml.ninux.org > http://ml.ninux.org/mailman/listinfo/wireless > -- *Matteo Pedani* www.pedani.it mobile +39 3343637690 phone +39 0699341466 phone +39 069415152 ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
Re: [Ninux-Wireless] NodogSplash e Traffic Control
Il 16 settembre 2016 02:13, Stefano De Carlo ha scritto: > 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. > Ormai sono quasi 2 anni che sono tra voi, quando ho tentato di usare pfsense avevo una intefaccia con il CaptivePortal di libero accesso. Quando passai a OpenWRT ho sempre avuto una antenna 2.4 libera senza pormi problemi. Claudio di Palermo mi aveva esposto questo problema tra i suoi nodi ed abbiamo iniziato a studiarci un po' le cose e stiamo ancora provando e riprovando varie configurazioni e soluzioni. > 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. > Il DROP messo da HOTPOST -> LAN e da HOTSPOT -> Backbone Ma questo non esclude che si possono aprire alcune porte per determinati servizi. Per promozione intendo invogliare, incuriosire l''ospite a documentarsi su cosa è Ninux andando a leggersi il Manifesto, le FAQ, farsi un giro sul sito della Basilicata etc... > 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é. > Concordo! > 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: > Chi si connette a te può scaricare torrent ed altro a manetta anche se piano? :) > * 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. > Per HotSpot intendo accesso con un cellullare, portatile, tablet etc..nessun setup se non cliccare su "Connetti" > * 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. > Mettere una regola di iptables su DROP generale ed aprire le porte sui servizi che vuoi abilitare non richiedere quantità di tempo irragionevole. E' chiaro, se uno vuole essere masochista della sicurezza il tempo non basta mai...ma non dobbiamo proteggere dati governativi! :) Ma dare una protezione a livello casalingo, non sulle reti Ninux, ma solo su quella di HotSpot. Se ho un serverino con un archivio di video su Matera, che viene visto dall'HotSpot ci sta! > * Limitare la banda e ripartirla equamente già da sola scoraggia la maggior > parte delle tentazioni di abusare del servizio. > Senza ombra
[Ninux-Wireless] Conclusione: NoDogSplash e Traffic Control
Dopo aver sollevato un polverone ritorno alla prima domanda: +++ Ciao raga, chiedo qui per vedere se altri hanno avuto problemi simili e se hanno trovato soluzioni. Con Claudio di Palermo stiamo cercando di capire come implementare un sistema per limitare la banda sull'interfaccia hotspot pubblica. Ho chiesto sulla ML dedicata e proprio oggi mi hanno detto che nelle ultime versioni di OpenWRT è stato rimosso il pacchetto IMQ in quanto sostituito da IFB e non è stato aggiornato il file tc.c Abbiamo installato QoS, ma se attivato sulla WAN ci tagliamo le XX anche per la LAN. Attivandolo sull'interfaccia di HOTSPOT funziona, ma Claudio ha notato che rallenta anche nell'apertura della splashpage anche mettendo una regola tipo: config classify 'cfg078143' option target 'Priority' option ports '2050' option comment 'NoDogSplash' di base usiamo Chaos, che soluzioni ci sono sencodo voi? Grazie. +++ Chiedevo una risposta swue swue...semplice semplice... - Il Traffic Controllo con nodogspash non funziona per via di IFB... - La configurazione di QoS che abbiamo usato rallenta anche la spash page... Ci sono suggerimenti? Thanks! Michele Salerno ___ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
