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