[Olsr-dev] Ninux GSoC 2012, ideas on olsrd
Ferry Huberts
(spam-protected)
Mon Mar 19 13:38:16 CET 2012
On 19-03-12 13:05, Henning Rogge wrote:
> On 03/19/2012 12:48 PM, ZioPRoTo (Saverio Proto) wrote:
>> Hello,
>>
>> Ninux was accepted for GSoC 2012 and I will be mentoring at least one
>> project on olsrd. We use it a lot, so the idea is to develop what is
>> missing for the Ninux network. Of course I am here because we want to
>> discuss our ideas with olsrd developers.
>>
>> here the list of stuff that we need. This things can be put in a
>> single project or we can split, depending on how many students we have
>> and their skills. Just we have to keep the Google rule: 1 student, 1
>> indipendent project.
>>
>> 2) Plugin to use manually specified metric (as in OSPF) because we
>> ended up that any automatic metric does not work in WiFi and we are
>> just messing around with LinkQualityMult all the time.
>> So, manual metric for links !
> Could you explain what is not working with automatic metrics on WiFi?
> Or is it just that the CURRENT metric cannot handle your usecase well?
>
> I think the easiest way to implement this feature would be a second
> parameter in the core that allows to SET (instead of multiply by
> factor) a link quality to a neighbor. I am still not sure this is a
> really good thing.
>
We are also working on this; we're developing a mechanism that utilizes
linux NL80211 to apply wireless link information in the link quality
calculation.
Related to this, we'd like to have a mechanism that allows us to
dynamically adjust smart gateway up/downlink values.
This, and more, we can (hopefully) discuss in Athens as I will also be
there (from Tuesday - Sunday)
>> 3) Permit by configuration to filter out some HNA advertised routes,
>> so that these ones are not installed in the kernel routing table.
>
> This would break the Mesh, because all other nodes rely on you to
> forward HNA traffic with this routes.
>
> A solution might be to put the filtered HNAs into a different routing
> table, so you can apply these routes only for traffic incoming from
> the mesh interface(s).
>
>> we are going to develop starting from stable git branch, because looks
>> like the two branches master and stable are very different now.
>
> The master branch will go (most likely) nowhere because I am working
> on a new codebase here (http://olsr.org/git/?p=framework.git;a=summary).
>
>> Thanks for feedback. We can also discuss this stuff in Athens for who
>> is there next week :)
>
> I will be there for the whole 7 days of the Battlemesh.
>
> Henning Rogge
>
>
>
--
Ferry Huberts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120319/c2cd0c2f/attachment.html>
More information about the Olsr-dev
mailing list