[Olsr-users] Looking for dev to make custom plug-in for our network
Thu Jan 10 21:21:13 CET 2013
Op 10 jan. 2013, om 18:27 heeft Michel Blais het volgende geschreven:
> I know it can be use by other network than adhoc. We use it with success over a fixed wirless network including wired part of the network.
Sure, OLSR runs over whatever link, as long as it supports IP.
> To explain a little we're a WISP covering rural area. Some of our main backhaul use 24 Ghz frequency heavilly affected by rain. When it happen, olsr will flap a lot between this link and backup link since without traffic on the link, when olsr route the traffic on a other link, it don't have any lost so will try back this link again.
Would the link be overloaded? Why is the link metric influenced by user traffic? I assume you use ETX.
> We need to disable those link manually for now so what we was thinking was to make a plug-in that would check link signal via SNMP, check more often if signal is over a first threshold and cut it if signal is over a second threshold. Since you can't remove a interface from olsr without restarting it, we we're thinking about blocking via iptables olsr paquet (in and out).
The trick is using link metrics, I think. You could try the old link-cost implementation (didn't made it in olsrd). Or use the new L2 link metric. This one uses wifi driver info. Adjusting for SNMP would be possible.
I'm pretty sure Henning would point to DLEP. Not available today. But yet, this is definitely the long term direction.
> The other thing was for QoS. What we was thinking was that OLSR could drop traffic shapping over a link until the're no lost on this link. With olsr paquet priorised, that would mean that every traffic priorised like VoIP would also don't have any lost and bulk taffic over traffic shapping could be drop by the router instead of send it via the wireless link and affecting latency. This plugin should also have a treshold that if traffic shapping goes lower than this treshold, link should be disable instead and a alert should be send.
So your radio doesn't support QoS packet scheduling? And you want the router to do it as front-end? The IETF DLEP proposal has some mechanisms for it. But the radio must provide the feedback, e.g. queue depth or flow control.
> I know Markus mentionned on this list that it's possible to priorise olsr paquet without using traffic shapping to have full throughput of the link but in our case, router and wireless link are not on the same device, it's impossible to change QoS rule on those wireless link and latency is more important than throughput.
If it is a fixed rate radio, it is easy to set up a shaper on your router. If rate is dynamic, but rather slow, you could set up some scripts for dynamic adjustments.
> If the community want to do it, we could send a donation to the project (even if I don't see any way to do it on the web page) instead of paying dev for those plug in.
> Le 2013-01-10 11:35, Ben West a écrit :
>> OLSRd can (and has been) used in media besides adhoc 802.11 wireless networks. Conceivably, one could use it on wired transport layers like a coaxial cable network, old-school "thick" Ethernet with vampire taps, and possibly even CAN.
>> (Meaning there may be segments of the OLSRd community who would find the plugins useful.)
>> Are there any details about the desired features of the plugins you are willing to share publicly?
>> On Thu, Jan 10, 2013 at 8:59 AM, Michel Blais <(spam-protected)> wrote:
>> Hi all,
>> We are looking for a dev that could make us 2 custom olsrd plug-in for our network.
>> Those plug-in would be useless for olsrd community since not for ad-hoc network.
>> Of course, we would pay for the work.
>> If somebody interessted, please contact me outside of the list.
>> Olsr-users mailing list
>> Ben West
> Olsr-users mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Olsr-users