[Olsr-dev] LinkQualityMult problems in 0.5.6-r5
Sat Sep 5 14:44:09 CEST 2009
Henning Rogge schrieb:
> Am Samstag 05 September 2009 13:42:24 schrieb Mitar:
> One of these tools are plans for a "internet gateway tunnel daemon" we plan
> together with the openwrt crew. This way users will have a good way to
> whitelist/blacklist internet gateways and stop them from flapping without
> messing with link qualities.
> Some people use lqmult to control what internet gateway they are
> a bad sollution for a problem that MUST be solved.
do you mean something like
that has solved the issue of people messing with lqmult for gateway
selection here. i'm surprised that the openwrt folks don't know about
>>> Hmm... would be interesting to do lqmult in a way that it only works if
>>> both sides of the link agree to the change. That would allow "link
>>> management" without all this strange "zero-gain" games.
i've never heard of a situation of "escalating race towards ever lower
lqmult factors" between different neighbours that you seem to talk about
and can hardly imagine a topology where that might occur. have you
really experienced such situations?
just one example on where it might make sense to use lqmult: we have
quite a chaotic mix of firmare and olsrd versions here. only quite
recently we realized that only with a fixed multicast rate we will get
meaningfully comparable lq values. however we can neither enforce the
same setting everywhere as we might isolate nodes in doing so nor can we
force people to upgrade their firmwares to a version that has a fixed
default setting. so if we want to reflect the different relevance of lq
values without recompiling olsrd or writing a new metric plugin lqmult
is basically the only choice available.
now this is still a global issue that might be solvable on firmware
level, but our mesh is basically organized in the form that some people
have lots of nodes in one or two streets and keep an eye on them and
their settings. however we always have some node owners in between who
do not answer to attempts on contacting them, and if one of these has a
configuration that somehow yields good lq values but bad traffic
results, what do you expect us to do? discussing every case on a mailing
list or a meeting is not really an option, i'm afraid...
please don't try to make olsrd "better" by taking configuration options
away, this is exactly what the b.a.t.m.a.n. folks did and was the reason
why we switched from batman to bmx as secondary experimental protocol..
More information about the Olsr-dev