You are here

OSLR, LQ and RF based DTDLinks

5 posts / 0 new
Last post
VA7NIC
VA7NIC's picture
OSLR, LQ and RF based DTDLinks
We have the beginning of a mesh environment and are running into an issue where our RF based DTDlink drops out when LQ drops below 95% I believe.

I found a message from awhile ago from Joe AE6XE (https://www.aredn.org/content/tunnel-and-olsr-behavior) in regards to tunnel issues, and wondered if the suggested fix #2  of commenting out MODE ether in the dtdlink sections of olsrd.conf files does the same thing as it apparently does to tunnels?

Am I looking in the right spot?    Are there other variables that could be tuned or inserted?

The RF link (5.8ghz, perhaps 4km) is almost rock solid, but whatever condition occurs and it drops the connection when as stated above the LQ drops below 95%.

The difference of that link going up and down is the ability to connect or not connect to a winlink post office service.

Thanks for any help!
 
KG6JEI
AREDN does not support
AREDN does not support changing the config files.  Any such change will result in a loss of support from the AREDN team.  There is currently no user tuneable supported method for changing this

This is expected behavior for DTDLinks, they are specifically designed that if the link drops on quality that they drop out. If you are backhauling them over some from of non hardwire link this would be expected to occur from time to time as the design for the DTDLink interface is a 100% perfect interface.

There has been talk about adding a feature that would allow for connections similar to DTDLink but without the high reliability requirement, I can't currently find a ticket for this however and I recall it was original scheduled to be in 3.17.1.0rc1 but wasn't brought to completion before RC feature freeze.  Now that were back in develop (where features can be added) I haven't heard of anyone working on it.  I've been dealing with some major bug tickets so I haven't had time to look at it myself.

You might want to create a feature ticket for this in bloodhound http://bloodhound.aredn.org so you can be added to a notification for it and to create a 'me too' type request for it to increase the chances and probabilities of it being handled sooner.  I see a lot of features users talk about but very few get put into Bloodhound which means the Dev team generally doesn't consider them or take any action on them while new issues in bloodhound are suppose to be discussed by the group on the ticket and presented by the project manager on the weekly conference call.
VA7NIC
VA7NIC's picture
I have created a ticket on
I have created a ticket on bloodhound... hoping its worded nicely enough to make sense of what I am thinking about.  

If someone has a better way of wording it, I can make changes.
 
AE6XE
AE6XE's picture
I observed recently, a
I observed recently, a dtdlink across a cat5, with the 0.1 ETX.   When the LQ drops below the threshold, it had reverted to an ETX reference of 1.0 and behaves similar to an RF link.   I think we have been assuming it would drop, but I saw it fallback to the RF thresholds and ETX settings.    Check to see if the traffic is getting lost elsewhere, say less than 20% success and would be dropping the link regardless.    Can you confirm my prior observation?

Joe AE6XE
VA7NIC
VA7NIC's picture
I can't say I've seen the
I can't say I've seen the observations you described above.  The non-hardwired (RF) dtdlink is good when the LQ is above 95%. When it goes to 94% it drops the link, and doesn't come back until it goes above 95% again.  If I am running a traceroute, it will stop or timeout at the last good side of the dtdlink, and then the mesh tries to re-direct it elsewhere.   A ping session will just stop completely and show timeouts until the link comes back online.

 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer