<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
On 19-03-12 13:05, Henning Rogge wrote:
<blockquote cite="mid:4F672109.50200@fkie.fraunhofer.de" type="cite">On
03/19/2012 12:48 PM, ZioPRoTo (Saverio Proto) wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
Ninux was accepted for GSoC 2012 and I will be mentoring at
least one
<br>
project on olsrd. We use it a lot, so the idea is to develop
what is
<br>
missing for the Ninux network. Of course I am here because we
want to
<br>
discuss our ideas with olsrd developers.
<br>
<br>
here the list of stuff that we need. This things can be put in a
<br>
single project or we can split, depending on how many students
we have
<br>
and their skills. Just we have to keep the Google rule: 1
student, 1
<br>
indipendent project.
<br>
<br>
2) Plugin to use manually specified metric (as in OSPF) because
we
<br>
ended up that any automatic metric does not work in WiFi and we
are
<br>
just messing around with LinkQualityMult all the time.
<br>
So, manual metric for links !
<br>
</blockquote>
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?
<br>
<br>
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.
<br>
<br>
</blockquote>
<br>
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.<br>
Related to this, we'd like to have a mechanism that allows us to
dynamically adjust smart gateway up/downlink values.<br>
<br>
This, and more, we can (hopefully) discuss in Athens as I will also
be there (from Tuesday - Sunday)<br>
<br>
<br>
<br>
<blockquote cite="mid:4F672109.50200@fkie.fraunhofer.de" type="cite">
<blockquote type="cite">3) Permit by configuration to filter out
some HNA advertised routes,
<br>
so that these ones are not installed in the kernel routing
table.
<br>
</blockquote>
<br>
This would break the Mesh, because all other nodes rely on you to
forward HNA traffic with this routes.
<br>
<br>
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).
<br>
<br>
<blockquote type="cite">we are going to develop starting from
stable git branch, because looks
<br>
like the two branches master and stable are very different now.
<br>
</blockquote>
<br>
The master branch will go (most likely) nowhere because I am
working on a new codebase here
(<a class="moz-txt-link-freetext" href="http://olsr.org/git/?p=framework.git;a=summary">http://olsr.org/git/?p=framework.git;a=summary</a>).
<br>
<br>
<blockquote type="cite">Thanks for feedback. We can also discuss
this stuff in Athens for who
<br>
is there next week :)
<br>
</blockquote>
<br>
I will be there for the whole 7 days of the Battlemesh.
<br>
<br>
Henning Rogge
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ferry Huberts</pre>
</body>
</html>