Re: [Ninux-Wireless] NodogSplash e Traffic Control

2016-09-14 Per discussione Michele Salerno 
Il 14 settembre 2016 15:43, Matteo Pedani  ha scritto:
> TUTTO il traffico deve passare da un nodo, verso un altro nodo.
> In caso contrario non si è neutrali verso il contenuto.
>
Normale!


> Il traffico di un qualsiasi nodo deve essere completamente lasciato passare.
>
E' scritto anche nel Manifesto e condivido in pieno!


> Un altro caso è bloccare il traffico verso la propria rete privata.
> Oppure il traffico che proviene dalla propria rete privata.
>
Non condivido il pensiero, la mia LAN di Ninux è la LAN che uso in
casa, non ho altre LAN separate.
Se sul mio pc di casa metto in shared una cartella, tu sull'altro nodo
la vedi, se mi fai una scansione con nmap vedi tutti i miei device.
A me sta bene così in quanto come me altri nunuxer non credo abbiano
spasmi di cracker.


> Se voglio fare un HOTSpot pubblico dove e lo aggancio alla mia rete privata.
> OK posso filtrare e dire siete a casa mia potete vedere questo è quello. Ma
> ricordatevi non state usando un picopeering verso questa persona.
>
A casa mia con i ninuxer non ho nulla da nascondere ma condividere ogni cosa.


> Filtrare il traffico è BRUTTO, per il semplice motovo che vi prendete la
> responsabilità dei pacchetti che passano sul voltro nodo.
>
Sto concetto non mi è chiaro:
Se metto una Ubiquiti Bullet M2 con una antenna omnidirezionale da 150
cm sul mio tetto senza password, io sono SEMPRE responsabile di ogni
pacchetto che transita dal mio router verso Internet.
Se nel parco si siede alla panchina Mr. Bean e si collega al mio
hotspot totalmente libero e si va a vedere qualche sito
pedo-pornografico la Polizia Postale da chi va? ...dal tizio seduto
sulla panchina o da a casa di chi ha l'HotSpot?


> Oltretutto filtrare è oneroso in termini di risorse.
> Esistono delle librerie (opencv). che trovano facce in un immagine, o targe
> di auto, oppure GATTINI,  una volta riconosciute queste possono essere usate
> per filtrare.
> Con la stessa procedura (ma altre librerie) si può riconoscere praticamente
> tutto.
> Per filtrare i pacchetti in maniera efficente il vostro nodo deve girare su
> di un vero computer con prestazioni adeguate.
>
E' un discorso un po' eccessivo!


> Filtrare è oneroso in termini legali.
> Se per caso, il vostro vicino che si connette sul vostro HotSpot ma non
> ritiene utile condividere la filosofia ninux, ed è per caso un attivista che
> fa passare documenti di come si fanno attentati dentro delle innocenti foto
> di paesaggi. Voi non ve ne accorgereste. Ma vi prendereste la resposabilità.
> Solo per il fatto di esservi arrogato il diritto di controllare il traffico.
>
Qualsiasi cosa che transita sulla linea ADSL l'unico responsabile
SEMPRE è chi ha sottoscritto l'abbonamento ADSL.


> Un hot spot lo vedo invece così :
>
> Una persona che vede la rete aperta si connette, viene rediretta ad una
> pagina di accoglienza che spiega cosa è ninux la filisofia. Clicca ed
> accetta la filosofia.
>
> Dopo X tempo oppure X giga,  resetto il tutto, butto tutti i MAC che hanno i
> permessi, e le persone devono rifare la procedura.
>
> Una modalità del genere spinge la gente ad entrare in ninux, noin c'è
> bisogno di tracciare i pacchetti cosa indispensabile per effetture delle
> politiche di controllo del traffico.
>
> Matteo Pedani
>

Per fare un un SQL Injection, usare SET per fregare credenziali ed
alte attività illegali non ci vogliono Gbit di dati a disposizione.

Nel mio caso specifico:
Ho 3 antenne, una NanoBeam AC in modalità Client, 2 NanoStation M5
come AP. Il Traffico Ninux non è filtrato ne ha passwrod.
Le AP non hanno un DHCP attivo sulla BackBone e chi si collega tra
virgolette lo conosco in quanto un altro ninuxer.
Ed essendo un ninuxer come me, mi fido, e do a disposizione internet
in modo libero come lo è per me.

In fase di test sto usando l'antennina interna del mio WDR3600 ha una
interfaccia virtuale con una network totalmente diversa e che non ha
nulla a che fare con la rete Ninux.
Non è assolutamente consentito entrare ne nella LAN Ninux con un DROP secco.
Mr. XX (Bean lo conosco) seduto sulla panchina vede un sid aperto
"hotpost ninux", si collegasi apre il browser con una splashpage
che spiega in breve cosa è Ninux, dice che la navigazione è limitata
solo ed esclusivamente per la Posta e Web tradizionale (wikipedia,
facebook, google, etc...). Quando clicca su ACCETTA viene indirizzato
sul sito http://basilicata.ninux.org/
Dopo 30 min di inattività vieni disconnesso, dopo 2 ore di attività
idem...non devi "lavorare" con la mia ADSL...per modo di dire!

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à

[Ninux-Wireless] Fwd: [LEDE-DEV] OpenWrt Summit Session Announcements

2016-09-14 Per discussione Claudio Pisa 
FYI


 Forwarded Message 
Subject: [LEDE-DEV] OpenWrt Summit Session Announcements
Date: Tue, 13 Sep 2016 16:55:30 -0500
From: Eric Schultz 
To: lede-...@lists.infradead.org

All,

I wanted to let everyone know that the sessions for OpenWrt Summit have
been announced and are listed at http://openwrtsummit.org. We have a
really broad range of sessions this year that address both the technical
and industry sides of the OpenWrt/LEDE communities. I think I can speak
for the rest of the summit committee-members when I say that we're very
excited by our list of sessions. This will be great chance to meet in
person with others who are using or involved with OpenWrt or LEDE.

I encourage everyone to check out the session list and consider joining
us in Berlin on October 13. It's free to attend, we only ask that you
register ahead of time at http://openwrtsummit.org. I look forward to
seeing everyone there!

Eric Schultz, Chair, on behalf of the OpenWrt Summit Committee:

Abhijit Mahajani
Beda Kosata
Eric Schultz
Federico Capoano
Hans Dedecker
Hauke Mehrtens
Imre Kaloz
Kathy Giori
Luka Perkov
Paul Blay
Zoltan Herpai
-- 
Eric Schultz, Community Manager, prpl Foundation
http://www.prplfoundation.org
eschu...@prplfoundation.org
cell: 920-539-0404

___
Lede-dev mailing list
lede-...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Re: [Ninux-Wireless] NodogSplash e Traffic Control

2016-09-14 Per discussione Matteo Pedani 
TUTTO il traffico deve passare da un nodo, verso un altro nodo.
In caso contrario non si è neutrali verso il contenuto.

Il traffico di un qualsiasi nodo deve essere completamente lasciato
passare.

Un altro caso è bloccare il traffico verso la propria rete privata.
Oppure il traffico che proviene dalla propria rete privata.

Se voglio fare un HOTSpot pubblico dove e lo aggancio alla mia rete
privata. OK posso filtrare e dire siete a casa mia potete vedere questo è
quello. Ma ricordatevi non state usando un picopeering verso questa persona.

Filtrare il traffico è BRUTTO, per il semplice motovo che vi prendete la
responsabilità dei pacchetti che passano sul voltro nodo.

Oltretutto filtrare è oneroso in termini di risorse.
Esistono delle librerie (opencv). che trovano facce in un immagine, o targe
di auto, oppure GATTINI,  una volta riconosciute queste possono essere
usate per filtrare.
Con la stessa procedura (ma altre librerie) si può riconoscere praticamente
tutto.
Per filtrare i pacchetti in maniera efficente il vostro nodo deve girare su
di un vero computer con prestazioni adeguate.

Filtrare è oneroso in termini legali.
Se per caso, il vostro vicino che si connette sul vostro HotSpot ma non
ritiene utile condividere la filosofia ninux, ed è per caso un attivista
che fa passare documenti di come si fanno attentati dentro delle innocenti
foto di paesaggi. Voi non ve ne accorgereste. Ma vi prendereste la
resposabilità. Solo per il fatto di esservi arrogato il diritto di
controllare il traffico.

Un hot spot lo vedo invece così :

Una persona che vede la rete aperta si connette, viene rediretta ad una
pagina di accoglienza che spiega cosa è ninux la filisofia. Clicca ed
accetta la filosofia.

Dopo X tempo oppure X giga,  resetto il tutto, butto tutti i MAC che hanno
i permessi, e le persone devono rifare la procedura.

Una modalità del genere spinge la gente ad entrare in ninux, noin c'è
bisogno di tracciare i pacchetti cosa indispensabile per effetture delle
politiche di controllo del traffico.

Matteo Pedani

Il giorno 12 settembre 2016 23:17, Michele Salerno  ha
scritto:

> 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.
>
> Michele
> ___
> 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

[Ninux-Wireless] [LibreMesh] Release 16.07 "Community Chaos" officially out

2016-09-14 Per discussione Ilario 
Finalmente è stata rilasciata la versione 16.07 "Community Chaos" di LibreMesh!
Potete usare l'applicazione web Chef per compilare immagini personalizzate :)
Qui sotto trovate tutte le informazioni e i link.
Daje con la sperimentazione!!
Ciao!
Ilario


-- Forwarded message --
From: Gui Iribarren 
Date: 2016-09-13 16:44 GMT+02:00
Subject: [lime-dev] Release 16.07 "Community Chaos" officially out
To: lime-us...@lists.libremesh.org, lime-...@lists.libremesh.org


Thanks to everyone involved, finally we have an official release!

 * generic binaries, meant for testing or setting up temporary networks
   (i.e. when having the default AP SSID = LibreMesh.org is fine)

http://downloads.libremesh.org/community_chaos/16.07/

 * customized binaries with chef, meant for stable community networks
   (basically, you can preset a specific AP SSID and other settings
   common to the whole network, and then flash many routers in a row)
   can be generated at:

http://chef.libremesh.org/

Changelog since "BiggestBang" 15.09:

• Now based on OpenWrt Chaos Calmer 15.05.1
• Removed "firewall" package (which is included by default in vanilla
OpenWrt/LEDE), since it's not really being used in LibreMesh setup. It
can always be installed on a case-by-case basis using opkg.
  ∘ there's a new minimal system that runs /etc/firewall.lime on boot
(if "firewall" is not installed)
• Removed "odhcpd" since we're not using it at the moment (we use dnsmasq)
• Removed "odhcp6c" since we're not using it at the moment (we still
haven't solved how to deal with native IPv6 coming over WAN, i.e.
propagate a delegated prefix over the mesh in a reasonable way)
• New default packages: "lime-hwd-openwrt-wan" and "lime-proto-wan".
This checks if there's a WAN port, and automatically configures as "wan"
proto (lime-proto-wan). The "wan" proto let's you assign in
/etc/config/lime, for example, 802.1ad VLANs over the WAN port.
• New default package: "lime-hwd-ground-routing". Allows you to
configure 802.1q VLANs on embedded switches, so that you can separate
specific ports and put
• New default package: "bmx6-auto-gw-mode", so that when a node detects
(with watchping) it can ping 8.8.8.8 over WAN port, a bmx6 tunIn is
created on-the-fly, and Internet is shared to the rest of the clouds.
• Workaround for an spurious log message caused by BATMAN-Adv ("br-lan:
received packet on bat0 with own address as source address"): a "dummy0"
interface is created and added to bat0, with a slightly different MAC
address
  ∘ https://lists.open-mesh.org/pipermail/b.a.t.m.a.n/2014-March/011839.html
• New available packages: "lime-proto-bgp", allows to do BGP with bird
daemon; and "lime-proto-olsr", "-olsr2" and "-olsr6", which add support
for all versions of OLSR.
• Some new settings possible in /etc/config/lime-defaults
  ∘ wireless.htmode lets you preset the htmode for any wireless radio
(or htmode_2ghz and htmode_5ghz for specific bands)
  ∘ wireless.distance is the equivalent, for setting distance (and
distance_2ghz / _5ghz)
  ∘ system.domain for setting a cloud-wide domain name
• New "named AP" interface by default: in addition to the shared SSID
(where clients roam between nodes), there's a new AP with a different,
unique SSID (it includes the node hostname). This lets people easily
check with any stock smartphone (not only Android with a special app)
which nodes are online, nearby, and their respective signal strength.
Most importantly, it lets them connect to a specific AP and prevent
roaming, when they need it. Roaming is a nuisance if you're in the
middle of two nodes, with similar RSSI, but different performance
(bandwidth to Internet). Finally, it gives users a very easy way to
reliably access a specific (nearby) node webinterface, simply
associating to a specific AP and browsing to http://thisnode.info/
• Fixed all alfred facters (bat-hosts, dnsmasq-distributed-hosts,
dnsmasq-lease-share), so that they retry the "alfred -r" when it fails
(i.e. in slave mode)
• LiMe web interface received love:
  ∘ luci-app-lime-location (Simple Config -> Location) now works
  ∘ Simple Config -> Advanced

___
lime-dev mailing list
lime-...@lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-dev
___
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless