Looking for dev to make custom plug-in for our network

[Michel Blais]

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.

Thanks

Michel

[Ben West]

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?

Post by Michel Blais
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.
Thanks
Michel
--
Olsr-users mailing list
https://lists.olsr.org/**mailman/listinfo/olsr-users<https://lists.olsr.org/mailman/listinfo/olsr-users>

[Michel Blais]

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.

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

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

Post by Ben West
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
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.
Thanks
Michel
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users
--
Ben West

[Teco Boot]

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.

Teco

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.

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?
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.
Thanks
Michel
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users
--
Ben West

--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users

[Michel Blais]

Post by Teco Boot

Post by Michel Blais
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.

Post by Michel Blais
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.

If signal become too low because of rain and the router try to pass the
traffic through it, yes it will be overload. Now, when olsr stop passing
traffic traffic through it, the link quality will be perfect.

Post by Teco Boot

Post by Michel Blais
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.

Post by Michel Blais
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.

From what I read, flow control broke TCP own flow control and create
more problems than it solves. For queue deep, any way I think of are not
real time. Maybe the're a protocole for it I'm unaware of.

I really think olsr message is the best way to monitor the link and
adjust traffic shaping if link quality drop. It would also be compatible
with any link regardless of fonction supported.

Post by Teco Boot

Post by Michel Blais
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.

Maybe it would be easy on private band without noise but on public band,
you never know how much bandwith you have. In peak hour, the noise go
higher because wireless spectrum is use more.

Yes I could use some script to fix my 2 problems but I think it would be
more effective to do it directly into olsr instead of doing 2 external
script that need to communicate with olsr.

Thanks

Michel

Post by Teco Boot
Teco

Post by Michel Blais
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.

Post by Ben West
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
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.
Thanks
Michel
--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users
--
Ben West

--
Olsr-users mailing list
https://lists.olsr.org/mailman/listinfo/olsr-users