<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>hat gmx als spam eingestuft
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Mittwoch, 16. August 2017 um 08:03 Uhr<br/>
<b>Von:</b> "Henning Rogge" <hrogge@gmail.com><br/>
<b>An:</b> "Erich N. Pekarek" <erich@pekarek.at><br/>
<b>Cc:</b> "wien@lists.funkfeuer.at" <wien@lists.funkfeuer.at><br/>
<b>Betreff:</b> Re: [Wien] ipv6 with olsrd2?</div>
<div name="quoted-content">On Tue, Aug 15, 2017 at 4:52 PM, Erich N. Pekarek <erich@pekarek.at> wrote:<br/>
>> But the real solution should be to make sure Olsrd2 measures the link<br/>
>> cost right... so if there are good examples of links Olsrd2 classifies<br/>
>> "too good", a modification of the metric would be the right thing.<br/>
><br/>
> I am still not really familiar with the way OLSRv2 measures this. Now that<br/>
> we are to be confronted with a rising number of locked firmwares as a result<br/>
> of the assimilation of FCC regulations in Europe, bridged setups will come<br/>
> to a renaissance.<br/>
> If you have advise on how to do that right, it'd be highly welcome.<br/>
<br/>
Currently OLSRd2 uses DAT (Directional Airtime Metric)... which is a<br/>
"one way ETX similar to OLSRd1" combined with the link-speed of the<br/>
interface...<br/>
<br/>
when running directly on the device with the wifi, Olsrd2 uses a<br/>
netlink socket to query the link-speed to each neighbor every second.<br/>
<br/>
There are a few optional parameters for the metric that have not been<br/>
tested that much... one is a shaping parameter called<br/>
"ff_dat_exponent" for the link-loss (ETX) part of the metric, where<br/>
you can switch between linear link-loss (default), quadratic link-loss<br/>
(more similar to ETX) and cubic link-loss.<br/>
<br/>
There is also the "mic_penalty" parameter, which allows you to<br/>
increase the cost of a link depending on the number of neighbors (the<br/>
idea is a link with many stations in the same collision domain is more<br/>
"expensive").<br/>
<br/>
We have talked about ideas like integrating "link stability" or "link<br/>
uptime" into the metric, but this is still in the planning phase.<br/>
<br/>
Henning Rogge<br/>
<br/>
--<br/>
Wien mailing list<br/>
Wien@lists.funkfeuer.at<br/>
<a href="https://lists.funkfeuer.at/mailman/listinfo/wien" target="_blank">https://lists.funkfeuer.at/mailman/listinfo/wien</a></div>
</div>
</div>
</div></div></body></html>