[Ninux-Calabria] routing a terra

[Stefano De Carlo]

Ciao a tutti,

come appendice al resoconto di ieri, qualche breve appunto su cose che
ho appurato smanettando e che possono tornare utili "down the road".

====

Il TP-Link TL-WR1043ND si rifiuta assolutamente di comunicare su
qualsiasi VLAN se non è presente l'opzione

option enable_vlan_4k '1'

nella sezione config switch di /etc/config/network. L'opzione
enable_vlan, che pure è presente, non è sufficiente da sola per attivare
la magia.
Mi sa che se lo switch supporta up to 4096 VLANS, allora non ti è
disponibile la modalità legacy?

====

Normalmente nel routing il traffico di risposta viaggia sulla stessa
interfaccia su cui è giunto in ingresso, ma nella direzione opposta.
Tuttavia in alcune situazioni, soprattutto con protocolli di routing
come OLSR, può succedere che le risposte viaggino in maniera
asimmetrica, seguendo path diverse per il ritorno.
Il comportamento default del kernel Linux, però, è di DROPPARE il
pacchetti se le rotte richiedono un inoltro su un interfaccia diversa
rispetto all'ingresso.
Ovviamente le distribuzioni tipo OpenWRT hanno tutte le impostazioni
corrette e sensibili, ma se stiamo sperimentando sui nostri host, come
ho fatto io la settimana scorsa, non è sufficiente impostare l'IP
Forwarding ma bisogna anche occuparsi di gestire quello che si chiama il
Reverse Path Filtering <http://lartc.org/howto/lartc.kernel.html>

Le opzioni rilevanti stanno in /proc/sys/net/ipv4/conf/*/rp_filter

"1" è il comportamento di default.
"0" disabilità il RPF e dunque inoltra i pacchetti a prescindere
(default in OpenWRT e AirOS)
"2" è un filtraggio leggero: droppa se le reti di destinazione sono tra
quelle a 0 hop (directly connected).

Prima di scoprire questo stavo impazzendo e credevo che i bridge
droppassero il traffico tagged :=O

=====

Dopo ogni modifica da CLI, sia essa con uci o manual editing:

/etc/init.d/network restart

Se la modifica interessa il wireless, allora si dia anche

wifi

Una nota su LUCI: ogni modifica "Save & Apply" corrisponde ad un
/etc/init.d/network reload
che a sua volta corrisponde ad un restart completo, se la semplice
rilettura delle configurazioni fallisse per un qualche motivo.

====

Per bridgiare tra due interfacce ETHERNET (siano esse pure o VLAN) è
sufficiente impostare l'opzione

option type 'bridge'

nella sezione della relativa interfaccia in /etc/config/network e
listare le ethX (o ethX.n) interessate dal bridge nell'opzione

option ifname 'ethQualcosa ethQualcosaltro'

sempre nella stessa sezione.
Ma per bridgare una ETHERNET e la WLAN, bisogna stare attenti ad una
procedura diversa: si imposta sempre type bridge nella sezione apposita,
ma non si deve listare MAI la wlan0 (o comunque si chiami) in
/etc/config/network. Per bridgiare la wireless bisogna specificare
nell'opzione option network presente in /etc/config/wireless il nome
dell'interfaccia con cui bridgiare (ovvero l'etichetta della relativa
sezione di /etc/config/network)

====
 
La sintassi per aggiungere una sezione di configurazione da linea di
comando è

uci add <configurazione> <tipo-sezione>

e per aggiungere/modificare una delle opzioni in suddetta sezione

uci set <configurazione>.<tipo-sezione>.<opzione>=valore/i

Ma se la <tipo-sezione> si vuole (o è richiesto) che abbia un'etichetta
(tipo 'LAN_NINUX' o 'ANTENNA1') allora la sintassi richiesta è
* diversa dalle due sopra
* NON documentata, porco billgates.

nello specifico è

uci set <configurazione>.<label>=<tipo-sezione>

ad esempio, se voglio creare lo spazio per l'interfaccia LAN_NINUX in
/etc/network, devo dare

uci set network.LAN_NINUX=interface

e lui creerà l'instestazione

config interface 'LAN_NINUX'

in /etc/config/network

=====

uci e LUCI non sembrano, quando si rimuove un'interfaccia, eliminarle
anche dalle opzioni in cui compaiono come valori.
Non sembra creare problematiche, nel senso: se incontra un valore non
più corrente, lo ignora.
Ma non mi piace, è molto approssimativo, e potrebbe essere causa dei bug
dell'interfaccia di LUCI che abbiamo sperimentato.
Oltre a rendere i file di configurazione meno leggibili.

=====

uci sembra funzionare.
Ho portato a termine una configurazione completa affidandomi solo alla
CLI, senza nessun bug o incertezza del router.
A questo punto il sospetto numero 1 è il front-end web, che secondo me
in alcune situazioni limite ha problemi di parsing dei file, e quando li
ha rischia, alla successiva rilettura dei file, di non tirare più su le
interfacce.


Stefanauss.

-------------- parte successiva --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20131223/b559c1dd/attachment-0001.pgp>