[Ninux-Wireless] Routing a valle (WAS: R: Nuove policy SDK AirOS)

[Alessio Caiazza]

2013/1/4 Michele Pietravalle <m.pietravalle a 4isp.it>

> > Detto questo io sarei comunque favorevole a cercare un'alternativa al
> firmware proprietario, magari spostando la logica di controllo del routing
> su un altro apparato e lasciare > alle antenne il solo compito di parlare
> tra di loro, ma questa è un'altra questione tra l'altro anche controversa...
>
>
> ****
>
> Mi inserisco al volo in questa discussione;****
>
> Per anni io ho fatto fare agli apparati sia la parte di interconnessione
> radio che di routing; col tempo però è saltato fuori che per mille motivi
> diversi non è la soluzione migliore..****
>
> di pro c'è la semplicità di manutenzione e la compatibilità con vari
> vendor;
>

Ciao Michele,
questo argomento mi interessa molto, al tempo dei miei primi esperimenti
con OLSR avevo provato a mettere dei bridge WIFI che non parlassero OLRS ma
poi ero finito con dei loop di routing che mi obbligavano a mettere o OLSR
o delle rotte statiche per spiegare cosa c'era dall'altra parte del bridge.

Potresti darmi una configurazione tipo per capire come realizzi 2 nodi con
routing a valle e N apparati sul tetto?


Grazie mille,
nolith



> ****
>
> difattti il 90% dei problemi hardware si verifica sulla parte radio, e non
> sulla parte di routing; di conseguenza un conto è cambiare solo l'antenna
> esterna, configurare due parametri al volo e fine, un conto è metter mano
> agli apparati di routing;****
>
> tra l'altro in caso di upgrade di apparati radio (altri vendor, altri
> bande di frequenza, etc) basta solo cambiare la parte radio lasciando
> immutate le logiche di routing..****
>
> ** **
>
> **
>



-- 
Alessio "nolith" Caiazza
il sapere umano appartiene al mondo.
GPG 440C5437
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/wireless/attachments/20130108/237d8c2a/attachment-0001.html>