3.16.1.1 Instability

10 posts / 0 new

Sat, 03/10/2018 - 11:21

kc0wkp

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.

Sat, 03/10/2018 - 11:35

kc0wkp

Here is the support file.

Support File Attachments:

supportdata-KC0WKP-1-201803070612.tgz

Sun, 03/11/2018 - 15:20

(Reply to #2) #3

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.

Sat, 03/10/2018 - 19:58

kc0wkp

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.

Sat, 03/10/2018 - 21:13

k1ky

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.

Sat, 03/10/2018 - 21:47

(Reply to #5) #6

w8awt

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

Sat, 03/10/2018 - 23:20

(Reply to #6) #7

k1ky

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?

Sat, 03/10/2018 - 21:47

kc0wkp

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

Sat, 03/10/2018 - 23:59

kc0wkp

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.

Fri, 03/16/2018 - 21:29

#10

kc0wkp

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.

Amateur Radio Emergency Data Network

Menu SF

You are here

3.16.1.1 Instability

Amateur Radio Emergency Data Network

Search form

Menu SF

You are here

3.16.1.1 Instability