You are here

3.16.1.1 Instability

10 posts / 0 new
Last post
kc0wkp
kc0wkp's picture
3.16.1.1 Instability

I did not see a post on this so sorry if it has already been addressed. I recently started getting all the nodes up to 3.16.1.1 from 3.16.1.0. However the nodes seem to be somewhat unstable now. Uptime never seems very long and it seems as if the node is constantly restarting. I have dumped my support file if that helps. Sometimes it take multiple attempts just to get to the local node.

kc0wkp
kc0wkp's picture
Here is the support file.
Here is the support file.
Support File Attachments: 
KG6JEI
It looks like this was taken
It looks like this was taken immediately after a node reboot, is that correct?  If so taking it after the issue has occurred for a while would be better to help.

​A number of issues are known since 3.16.1.0 that may be related or could be a different issue.  On a first glance based on what your reporting I'm thinking the slugbug fault and the fault where an unstable remote connection cycles olsr triggering the watchdog might be likely candidates for what you are describing.

​3.16.1.1 shouldn't be really any different than 3.16.1.0 as it introduced no new features and only changed some minor but exploitable areas of the GUI and SSH server.
kc0wkp
kc0wkp's picture
OLSR Restart
It appears to be OLSR restarting over and over again, sometimes every 60 seconds or so. Thinking of moving back to 3.16.1.0.
k1ky
k1ky's picture
3.16.1.1 Stability
We had some issues with under certain conditions. First, they like to have another RF connection connected - especially if running VTUN as a client or server with IP phones attached to  PBX.  They also don't like VTUN connections over "marginal" internet connections. Can you tell us a little more about your "system"?  Otherwise, this version is VERY statble.
w8awt
w8awt's picture
K1KY,
K1KY,

Just wondering what is considered "marginal"? I've been having stability problems on my ARHP that I think are connected to my tunnels. I have 3.6 down and .9 up internet.

Might this be a factor?

73,
Augustine
W8AWT

 
k1ky
k1ky's picture
Marginal
I have found that speed of the internet connection isn't as much of a factor as it has more to do with the stability of the actual connection - like if it is Wi-Fi or via Cellphone data which can sometimes be disrupted.  Also, if other Wi-Fi units are nearby, make sure as not to "overload" those units by locating them near MESH nodes.  I like to keep them at least 10 feet away from each other.  Vertical separation is also a good thing.  You can experiment with channel separation as well as use minimal power needed (but enough to keep good throughput). I find that some of the home AT&T internet connections are the poorer performers.  Are your "other" nodes running 3.16.1.1 or later?
kc0wkp
kc0wkp's picture
This particular node has

This particular node has three RF connections, one Client, and one server. Mesh chat is being offered via a pi. The node seems to lock up quite often while trying to move between pages. One RF link is on the weak side and through put is sometimes as low as .5 Mbps. I did not see any of these issues prior to upgrading from 3.16.1.0. One of the clients is also not very stable.

Internet is a stable 60/6 connection

Local Node - Nanostation 2.4
Remote Nodes - Bullets and Nanostation 

kc0wkp
kc0wkp's picture
All nodes are more then 50ft
All nodes are more then 50ft from the nearest 2.4 transmitter. All nodes have been upgraded to 3.16.1.1. 
kc0wkp
kc0wkp's picture
Things seem to have
Things seem to have stabilized now, I am wondering if all the adjusting we were doing and changing of neighboring nodes was causing the OLSR restarts.

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer