[Olsr-dev] LinkQualityMult problems in 0.5.6-r5

[Daniel Nitzpon]

hi!

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 
using. That's
 > a bad sollution for a problem that MUST be solved.

do you mean something like 
https://dev.leipzig.freifunk.net/trac/browser/firmware/packages/global/freifunk-gwtun
?
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 
the package.

>>> 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..

greetz,
daniel