[Wien] ipv6 with olsrd2?

[Henning Rogge]

On Tue, Aug 15, 2017 at 4:52 PM, Erich N. Pekarek <(spam-protected)> wrote:
>> But the real solution should be to make sure Olsrd2 measures the link
>> cost right... so if there are good examples of links Olsrd2 classifies
>> "too good", a modification of the metric would be the right thing.
>
> I am still not really familiar with the way OLSRv2 measures this. Now that
> we are to be confronted with a rising number of locked firmwares as a result
> of the assimilation of FCC regulations in Europe, bridged setups will come
> to a renaissance.
> If you have advise on how to do that right, it'd be highly welcome.

Currently OLSRd2 uses DAT (Directional Airtime Metric)... which is a
"one way ETX similar to OLSRd1" combined with the link-speed of the
interface...

when running directly on the device with the wifi, Olsrd2 uses a
netlink socket to query the link-speed to each neighbor every second.

There are a few optional parameters for the metric that have not been
tested that much... one is a shaping parameter called
"ff_dat_exponent" for the link-loss (ETX) part of the metric, where
you can switch between linear link-loss (default), quadratic link-loss
(more similar to ETX) and cubic link-loss.

There is also the "mic_penalty" parameter, which allows you to
increase the cost of a link depending on the number of neighbors (the
idea is a link with many stations in the same collision domain is more
"expensive").

We have talked about ideas like integrating "link stability" or "link
uptime" into the metric, but this is still in the planning phase.

Henning Rogge