On 08/29/2012 03:53 PM, leonardo wrote:
> On 29/08/2012 14:20, Alessio Caiazza wrote:

Hello.

>> Mi è parso di capire però che olsr usato su ninux non è proprio
>> vanilla, ma che ci sono delle patch (almeno per quello di airOs)
>> giusto? C'è qualche riferimento per questo argomento qui?

AFAIK l'OLSR che usiamo sui nodi non e' patchato.
Trovi i sorgenti del firmware qui: [*]

>> batman invece richiede OpenWRT custom di eigennet.

BATMAN gira su qualunque cosa con Linux: e' gia' incluso nel kernel a
partire dalla versione 2.6.38 [^].

>> Ho cominciato a dare una lettura a come funziona olsr; interpolando
>> con quello che zio proto ha detto al MOCA mi pare di ricordare che
>> tutta la questione degli MPR non funzioni e che quindi ogni nodo si
>> comporta da tale generando "un monte" di traffico di segnazione.
>> Ricordo bene?

Si' il meccanismo degli MPR attualmente non funziona in olsrd e quindi
di fatto si fa flooding. AFAIK MPR e' stato abbandonato perche' non
funzionava bene su vere reti mesh (in particolare Freifunk Berlin).

> Ho guardato l'implementazione di OLSR, vi condivido un email che ho
> mandato a Saverio, che è in vacanza:

Provo a risponderti io...

> ===
> 
> L'implementazione della scelta degli MPR senza link-quality ha qualche
> bug, di cui un paio sono veniali, ed un paio potrebbero essere invece
> importanti, ma mi è difficile controllarli anche con netkit. In ogni
> caso, che tu sappia, qualcuno usa questa modalità?

Che io sappia non viene usata, soprattutto con olsrd. Ci stanno altre
implementazioni di olsr in giro, che probabilmente sono compliant.


> L'implementazione con link quality mi pare che sia un po' approssimata.
> Ovvero, da RFC (l'unica RFC che conosco sul tema è questa
> http://tools.ietf.org/html/draft-ietf-manet-olsrv2-13) ci vogliono due
> set di MPR, uno che serve a fare il broadcast dei pacchetti e viene
> scelto come nel caso precedente, un'altro per selezionare le rotte
> migliori che viene scelto in base alle metriche.

Mi mancava. Comunque gli sviluppatori di olsrd stanno gia' lavorando
all'implementazione di OLSRv2.

> Se si usa un solo set di MPR basati sulla metrica, è probabile che le
> metriche fluttuino e creino loops. Ho visto qualcosa
> del genere in batman, mo mi faccio passare qualche indicazione in più.

Facci sapere :)

> ripensavo anche al fatto che proponevate di settare le metriche
> staticamente. Perchè? Quale problema volevi risolvere in questo modo?
> 
> ===
> 
> in ogni caso, usando fisheye si dovrebbe poter diminuire la segnalazione
> anche senza cambiare la scelta degli MPR.

Si'. A Roma non l'abbiamo ancora abilitato il fish-eye.

>> Non sono riuscito a capire esattamente come si comporta oslr, credo
>> che provvederò ad una rapida lettura dell'RFC per avere le idee un po'
>> più chiare.
> 
> Cercati prima un paper introduttivo, ce ne sono molti, l'RFC è un po'
> ostica.

Confermo. Consiglio questa tesi: [%]

ciao!
Clauz

[*] https://github.com/ninuxorg/SDK.UBNT.v5.5
[^]
http://www.open-mesh.org/projects/open-mesh/wiki/2011-03-17-batman-adv-and-the-penguin
[%] http://www.olsr.org/docs/report.pdf


_______________________________________________
Wireless mailing list
Wireless@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/wireless

Rispondere a