[Olsr-dev] OLSRd Linux NL80211 extension

[Teco Boot]

I discussed with originators of the patch what we can do.
We came up with the following approach:

 - make a branch in our repository, not elsewhere

 - add a hysteresis mechanism, to be used in whatever metric plugin, 
   that filters jitter in LQ. Default config is not using hysteresis, 
   as we have right now. It is a local policy to use hysteresis, or 
   not: it is an adjustment on LQ calculation, not ETX calculation.

 - see if the mechanism can be made interoperable with our current
   link metric plugins. There would be no change in the wire format,
   if we use the nl80211 info next to loss ratio for LQ calculation.

If we have this, we can do some experiments in corners of our current
networks. If there is a gain (I guess so), further deployment is easy.

Opinions?

Teco 


Op 3 apr. 2012, om 22:35 heeft Teco Boot het volgende geschreven:

> 
> Op 3 apr. 2012, om 11:12 heeft Henning Rogge het volgende geschreven:
> 
>> On 03/21/2012 11:46 AM, Frank de Brabander wrote:
>>> Hello,
>>> 
>>> I would like to share the work done on OLSRd, which adds basic support for
>>> applying Linux NL80211 information into the link cost calculation. In
>>> short what this means is that wireless signal strength and bandwidth are
>>> added to the cost calculation. The more detailed description is in the
>>> attached file OLSRD_LINUX_NL80211_EXTENSION.txt.
>>> 
>>> The code is based on the stable branch and can be found in a branch called
>>> nl80211_support on GitHub
>>> (https://github.com/brabander/olsr/tree/nl80211-support).
>>> 
>>> I'm very interested in how the OLSR community thinks about the current
>>> status of extension and where to go next.
>> I looked over your code in the last week and I think its a very interesting work to start experimenting with Layer-2 based metrics.
>> 
>> The problem with it (similar to the problems we had with earlier layer-2 experiments) is that it has to break the message format.
> 
> I'll check. I think it should be possible to influence ETX with L2 info.
> 
>> 
>> A better solution will only be possible after we switched to OLSRv2. If you like, you can have a look at the DLEP-prototype I am working on, which will become a probing service to allow querying nl802.11 data from WLAN over UDP.
> 
> In a single box, let's not use DLEP.
> Or do you suggest DLEP as access method to get metrics into the routing daemon: DLEP client & server in a device?
> 
> Teco
> 
>> 
>> The interesting parts for you should be
>> /src-plugins/nl80211_listener (the nl80211 probe code)
>> /src/olsr_layer2.[ch] (a hardware independent storage for the date).
>> 
>> Henning Rogge
>> 
>> -- 
>> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
>> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
>> Kommunikationssysteme (KOM)
>> Neuenahrer Straße 20, 53343 Wachtberg, Germany
>> Telefon +49 228 9435-961,   Fax +49 228 9435 685
>> mailto:(spam-protected) http://www.fkie.fraunhofer.de
>> GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
>> 
>> -- 
>> Olsr-dev mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>