<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">
<br>
entrare i suoi client direttamente in Ninux. Non l'avessi mai fatto:<br>
devo aver scatenato un bug immenso di LUCI (l'interfaccia web di<br>
OpenWRT) che per ragioni indebuggabili mi ha sbattuto fuori dal router,<br>
chiudendo interfacce che non erano interessate dalla modifica.<br></blockquote><div><br></div><div>Purtroppo è stato programmato con i piedi, per avere certezza della modifiche in network bisogna sempre:</div><div><br></div>
<div>/etc/init.d/network restart</div><div> </div><div>Il fatto che sbatta fuori è condizionato alla VLAN1, eth0 è occupato per il bridge e attivando lo switch releghiamo l'I/O delle porte ethernet alle VLAN configurate (VLAN1 di default). Le CPU untagged in VLAN1 solitamente oscurano tutto perchè untaggano la CPU per una specifica VLAN e di conseguenza oscurano la VLAN default (VLAN0), spiegato più in seguito.</div>
<div><br></div><div>però il ripristino della copia di backup funziona sempre :)</div><div><br></div><div>A Verde ho usato vlan1 e vlan2 in questa configurazione, riscrivendola in:</div><div><br></div><div><div> eth0.1 Link encap:Ethernet HWaddr 64:66:B3:41:3F:71 </div>
<div> inet addr:172.17.87.13 Bcast:172.17.255.255 Mask:255.255.0.0</div><div><br></div><div> eth0.2 Link encap:Ethernet HWaddr 64:66:B3:41:3F:71 </div><div> inet addr:192.168.1.33 Bcast:192.168.1.255 Mask:255.255.255.0</div>
</div><div><br></div><div><br></div></div></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><div>config switch_vlan</div></div></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>option device 'eth0'</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>option vlan '1'</div>
</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>option vid '1'</div></div></div></div><div class="gmail_extra"><div class="gmail_quote">
<div><div><span class="" style="white-space:pre"> </span>option ports '0t 2 4t'</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote">
<div><br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>config switch_vlan</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>option device 'eth0'</div>
</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>option vlan '2'</div></div></div></div><div class="gmail_extra"><div class="gmail_quote">
<div><div><span class="" style="white-space:pre"> </span>option vid '2'</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>option ports '0t 1 4t'</div>
</div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>La porta 4 è di trunking, un jolly.</div><div>Lasciando tutte le CPU delle VLAN come tagged, le porte restanti comunicano di default sulla VLAN0 come untagged e quì credo di capire che VLAN0 corrisponde ad eth0 (Vlan default, interfaccia che contiene sub-interfacce) che essendo bridgata in br-lan deve avere - per forza - la CPU untagged altrimenti blocca tutto.</div>
<div><br></div><div>se noi untagghiamo una CPU di una VLAN dobbiamo essere coscienti che stiamo a sottrarre l'untagged alla VLAN default !!!</div><div><br></div><div>swconfig sembra confermarcelo:</div><div><br></div>
</div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><div>root@VerdebinarioNinux:~# swconfig dev switch0 show</div></div></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div>Global attributes:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>enable_vlan: 1</div></div></div></div>
<div class="gmail_extra"><div class="gmail_quote"><div><div>Port 0:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>pvid: 0</div></div></div>
</div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>link: port:0 link:up speed:1000baseT full-duplex txflow rxflow </div></div></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div>Port 1:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>pvid: 2</div></div></div></div><div class="gmail_extra">
<div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>link: port:1 link:up speed:100baseT full-duplex auto</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>Port 2:</div>
</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>pvid: 1</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>link: port:2 link:up speed:100baseT full-duplex auto</div>
</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>Port 3:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>pvid: 0</div>
</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>link: port:3 link:down</div></div></div></div><div class="gmail_extra"><div class="gmail_quote">
<div><div>Port 4:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>pvid: 0</div></div></div></div><div class="gmail_extra"><div class="gmail_quote">
<div><div><span class="" style="white-space:pre"> </span>link: port:4 link:down</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>VLAN 0:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote">
<div><div><span class="" style="white-space:pre"> </span>vid: 0</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>ports: 0t 3 4t </div></div>
</div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>VLAN 1:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>vid: 1</div>
</div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>ports: 0t 2 4t </div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>
VLAN 2:</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div><span class="" style="white-space:pre"> </span>vid: 2</div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div>
<div><span class="" style="white-space:pre"> </span>ports: 0t 1 4t </div></div></div></div></blockquote><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>In questa configurazione abbiamo la porta 3 che comunica untagged sulla VLAN0 (ovvero br-lan, essendo eth0 impegnato) e la porta 4, di trunking, che comunica untagged sulla rete VLAN0/br-lan e tagged per tutte le VLAN.</div>
<div><br></div><div>La pratica conferma la regola, tagged non è esclusivo e possiamo crearne fino a 16 in openWRT mentre l'untagged riserva una porta per un link eth classico. </div><div><br></div><div>A verde il router ha la br-lan come 10.87.8.0 e due vlan, una per 172 e un'altra per 192.</div>
<div>se dovessi aggiungere un'antenna taggerei la porta 3 o userei as-is la porta 4.</div><div><br></div><div>Ad ogni modo la strategia di Stefano per risparmiare un indirizzo IP penso sia de facto la migliore soluzione per la rete.</div>
<div><br></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">
Una volta tornato a casa mi sono messo sul mio vecchio 1043ND (v1.8,<br>
firmware identico) e ho ripetuto la configurazione, questa volta<br>
utilizzando solo l'utility UCI a riga di comando per tutto, da zero,<br>
senza mai toccare la GUI. Roba che ti fa rimpiangere la sintassi a tre<br>
livelli di accesso dei Cisco.<br></blockquote><div><br></div><div>Se posti la sequenza di comandi possiamo scriptarlo in un wizard con semplici raw input bash.</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>
Due parole sulla VLAN di gestione. Le porte sono state tutte taggate, ma<br>
funzionalmente non sarebbe cambiato niente se avessimo deciso fare la<br>
VLAN 7 tutta untagged. La ragione principale per cui si è scelto di fare<br>
così è che questa accortezza è un modo semplice ed elegante di aggirare<br>
un bug noto presente in molti SoC presenti nei comuni router, di cui<br>
potete leggere meglio a <<a href="https://dev.openwrt.org/ticket/12181" target="_blank">https://dev.openwrt.org/ticket/12181</a>>. Questo<br>
bug impedisce che da una porta possa scaturire contemporaneamente<br>
traffico taggato e non taggato, ovvero che una porta faccia parte di 2<br>
VLAN, se in una delle quali essa risulta untagged. </blockquote><div><br></div><div><br></div><div>Considero che i comandi di UCI sono universali mentre i chip fanno più di testa loro. Che faccia dannare è cosa amara...</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>
<a href="http://imgur.com/zAQvvyu" target="_blank">http://imgur.com/zAQvvyu</a></blockquote><div><br></div><div>spettacolo.</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>
Due parole sugli ID delle VLAN: perché partiamo da 3? Semplice: AirOS<br>
non consente di utilizzare la VLAN con ID 1, mentre molto molto spesso<br>
OpenWRT ha già una VLAN 2 per l'interfaccia WAN, e ha poco senso<br>
mettersi a riordinarle.<br>
<br></blockquote><div><br></div><div>Sul TL-740N la WAN è sulla eth1. Se avesse più memoria sarebbe il top.</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">
A questo punto uno potrebbe avere la preoccupazione (e noi l'abbiamo<br>
avuta): ma se uso le VLAN sulle antenne di un supernodo, poi ogni nodo<br>
che si collegherà ad esso con le sue antenne dovrà utilizzare<br>
necessariamente le VLAN? Questo causerebbe molti problemi per i neofiti<br>
che vogliono entrare in Ninux, e per l'immediatezza di configurazione.<br>
La risposte è: NO. Come detto, l'interfaccia wireless e la VLAN di<br>
traffico (che viaggia, ovviamente, sulla porta eth0 dell'antenna) sono<br>
tra loro in bridge. </blockquote><div><br></div><div>Alla pari di una scoperta copernicana, la direzione dello switch tagga/untagga i frames, scriviamolo sui muri.</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">
root@OpenWrt:~# uci set firewall.@zone[0].network='LAN_NINUX ANTENNA1<br>
ANTENNA2 ANTENNA3 ANTENNA4'<br></blockquote><div><br></div><div><br></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">
Onestamente il firewall è l'unico aspetto che ha bisogno ancora di un<br>
test esteso. Non ho avuto tempo, modo e voglia di esaminare quali sono i<br>
default di OpenWRT e come possono influenzare il traffico<br>
multi-interfaccia che creiamo sul routing a terra. Sia io che Peppe<br>
abbiamo incontrato problemi che si è potuto risolvere semplicemente<br>
spegnendo il firewall (/etc/init.d/firewall stop), ma a dire il vero nel<br>
mio secondo giro di prove tutto è sembrato funzionare anche solo<br>
aggiungendo tutte le interfacce alla stessa zona LAN, come abbiamo fatto<br>
col comando appena visto. Spax mi informa che OpenWRT per default non<br>
forwarda il traffico tra le interfacce appartenenti ad una stessa zona,<br>
ma devo ancora capire in che modo ci affligge, se lo fa.<br></blockquote><div><br></div><div>La firewall può salire sù, va creata una zona per ogni rete, pertanto zona_172 e zona_10. Il Bug è che luci quando salva e "applica" include nel postrouting esclusivamente la vlan1 :)</div>
<div>Quindi un essere umano normale dovrebbe inserire le regole mancati a mano oppure ricreare da capo la firewall nell'eventualità di fare navigare i frames attraverso le reti delle interfaccie e non solo esclusivamente sulle interfacce (per il quale l'ip_forward basta )</div>
<div><br></div><div>Stè questa tua esperienza secondo me la puoi pubblicare di sana pianta sul blog :)</div><div> </div></div></div></div>