<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Bene, ho passato ieri pomeriggio a rendere incontrovertibile che se c'è<br>
del lavoro da fare, preferisco vada in direzione dell'adeguamento di<br>
tutti i nodi ad OLSR piuttosto che al supporto di soluzioni legacy che<br>
non scalano.<br></blockquote><div><br></div><div>il lavoro da fare per l'adeguamento dei nodi è il seguente:</div><div><br></div><div>ARI dovrebbe "entrare" meglio nel funzionamento di Ninux e ecocasa dovrebbe giusto completare i lavori che stiamo rimandando da un mese.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Nell'ipotesi che si voglia effettivamente far convivere nodi OLSR e nodi<br>
non-OLSR, forse c'è un modo in cui possiamo implementarli<br>
- entrambi<br>
- contemporaneamente<br>
e progressivamente transizionare a comando verso la soluzione a nodi<br>
tutti-OLSR.<br></blockquote><div><br></div><div>LA via di mezzo per "affiancare" i nodi dumb potrebbe essere quella di annunciare le rotte anche per loro. Ma suona quasi inutile visti gli obiettivi.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Wireless VLAN Trunking/Passthrough?<br>
<br>
Ipotesi: un nuovo supernodo, simil-SPIG, con routing a terra (non la<br>
versione attuale, ma quella già pronta, riveduta e corretta, con le VLAN).<br>
Come descritto il mese scorso [1] il routing a terra prevede una doppia<br>
VLAN, una delle quali (eth0.3) di traffico OLSR che viene bridgiata<br>
(bridge0) con la WLAN. L'altra è di management (eth0.7)<br></blockquote><div><br></div><div>Ottimo</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Noi potremmo aggiungere una sovrastruttura così composta:<br>
<br>
1) Una ULTERIORE VLAN sulle interfacce dell'antenna (wlan0.99 e eth0.99)<br>
e router a terra (eth0.99)<br>
2) bridgiare (bridge1) wlan0.99 e eth0.99 sull'antenna.<br>
3) Associare il bridge1 alla VLAN (per il momento tralasciamo come).<br>
4) Sul router a terra assegnare a questa VLAN indirizzi <a href="http://10.87.254.0/24" target="_blank">10.87.254.0/24</a><br>
5) Si fanno collegare i nodi stupidi in DHCP al Virtual SSID associato a<br>
<a href="http://10.87.254.0/24" target="_blank">10.87.254.0/24</a>.<br>
6) Annunciare <a href="http://10.87.254.0/24" target="_blank">10.87.254.0/24</a> come HNA4 su OLSR.<br></blockquote><div><br></div><div>Mi piace il 99 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Elucubrazioni:<br>
<br>
La #1 e la #2 mirrorano quanto abbiamo fatto col routing a terra e le<br>
antenne in bridge, ma per una ulteriore VLAN. La presenza del .99 sulla<br>
WLAN è più che altro per identificare concettualmente la necessità di 2<br>
bridge che coinvolgono il wireless.<br>
<br>
La #3 è la parte decisiva. Se per il momento ipotizziamo che sia un<br>
bridge tutto wired, il bridge tagga-untagga a seconda delle porte che ne<br>
fanno parte e della direzione, come ben sappiamo.<br>
Ma nel wireless, da standard 802.11, di tag VLAN non ne possono passare<br>
(VLAN passthrough). A prescindere dal tag (vorremmo mantenere tutto<br>
untagged lato CPE, comunque), abbiamo bisogno di far si che il traffico<br>
in ingresso sul wifi dell'antenna venga inoltrato verso la corretta VLAN<br>
impostata negli ultimi 3 punti. Per far questo, in sostanza, l'antenna<br>
ha bisogno di un modo per agire da tipico bridge linux wired come sopra<br>
descritto.<br>
Credo si possa fare. Ci sono due modalità mooooolto diverse sul tavolo<br>
della sperimentazione:<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
A) Se AP e STA sono impostati in WDS transparent bridging (WDS-AP, WDS),<br>
in realtà iniettare tag vlan sul wireless è supportato, almeno da quasi<br>
tutte le implementazioni WDS. Si tratta di bridge L2 liscio liscio. In<br>
questa modalità, l'unica cosa da fare è impostare le VLAN desiderate su<br>
ambedue le interfacce e i bridge appositi, e chi s'è visto s'è visto.<br>
<br>
B) Senza il WDS, la cosa è per forza di cose più circonvoluta. Bisogna<br>
creare dei VirtualAP/SSID, uno per ogni VLAN, e associarli ai bridge<br>
descritti in #1 e #2 e di conseguenza alle VLAN. In pratica, le VLAN<br>
desiderate vengono create/ricreate dinamicamente dall'antenna in base al<br>
SSID di ricezione. Come se gli SSID virtuali corrispondessero ad una<br>
native VLAN di quella "porta wireless".<br></blockquote><div><br></div><div>Bello</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
La #4 #5 #6 realizzano quella che è, in sostanza, una HNA4 distribuita<br>
sul territorio. E come sappiamo le HNA4 sono l'unico posto dove non<br>
serve che si faccia parlare OLSR. Vi torna?<br></blockquote><div><br></div><div>Decisamente</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
La complessità dell'AP è ovvio che aumenterebbe, a tutto vantaggio dei<br>
nodi foglia che possono rimanere beceramente ignoranti (DHCP! Roba da<br>
figli unici).<br></blockquote><div><br></div><div>In questo caso la client isolation avrebbe lo stesso effetto senza vlan.</div><div>Sai, dal punto di vista della sicurezza non ha eguali e forza uno standard, è un ragionamento impeccabile. Pare che come la giri giri si torna sempre lì, e penso vada fatto.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Come vedete, per fare le cose per bene (scalabili, transizionabili), è<br>
tantissimo lavoro, tutt'altro che KISS.<br>
Lasciamo perdere * e abbracciamo OLSR ovunque,<br>
<br>
Stefanauss.<br>
<br>
[1] <a href="http://ml.ninux.org/pipermail/calabria/2013-December/002328.html" target="_blank">http://ml.ninux.org/pipermail/calabria/2013-December/002328.html</a><br>
[1] <a href="http://ml.ninux.org/pipermail/calabria/2013-December/002332.html" target="_blank">http://ml.ninux.org/pipermail/calabria/2013-December/002332.html</a><br>
[2]<br>
<a href="https://security.stackexchange.com/questions/16751/wireless-client-isolation-how-does-it-work-and-can-it-be-bypassed" target="_blank">https://security.stackexchange.com/questions/16751/wireless-client-isolation-how-does-it-work-and-can-it-be-bypassed</a><br>
<br>
<br></blockquote><div><br></div><div>Non lo sò cosa succederà, per questo penso ad una rete a 2 livelli. </div><div>Purtroppo, sul lungo periodo, risulterebbe più svantaggiosa per la gestione, mentre un'unico standard dovrebbe andare.</div>
<div><br></div><div>In questo caso il costo di installazione sarebbe circa 130€ incluso router da flashare.</div><div>Gigismi potrebbe compilare il firmware del Ninux start-kit e potremmo creare una pagina dove spiegare come fare il primo nodo di ninux. In questo caso eviteremmo totalmente i nodi dumb, perchè questi sin da principio verrebbero istruiti all'ingresso.</div>
<div><br></div><div>In questo caso passeremmo alla CI anche in questa settimana, tutte le antenne possono essere configurate da remoto e con un paio di telefonate potremmo coinvolgere qualcuno in più :)</div></div><br></div>
</div>