Shake keeps losing network connection

#1

Hi

My Raspberry shake keeps losing its network connection . It will stay connected for a few hours and the drop out . I cant see a reason for this .

I have attached the log files

Any ideas would be much appreciated

GrahamRSH.R7BC1.2019-08-09T08_40_10.logs.tar (3.6 MB)

#2

Try monitoring the CPU temp on the config page. I had problems with drop outs when my CPU got over 68 C. The high temps were caused by monitoring the trace through Stream at the default high refresh rate of 1 sec. When I throttle the refresh rate down to 10 sec the temps settle down. That’s the monitor function, not the helicorder display, which works OK temp wise.
Jeff

#3

Hi Graham, from the logs it looks like you are having DNS issues, which are generally a router or ISP-specific issue. There are two ways around this: setting a manual IP and DNS in the http://rs.local web config, or adding a line to /etc/dhcpcd.conf in the Shake filesystem.

Each of these fixes is simple:

  1. The first doesn’t require logging in to the Shake at all. Simply navigate to http://rs.local/, make note of the Shake’s IP address, then click on the Config gear to go to http://rs.local/config.

    Click on NETWORK, then under ETHERNET SETTINGS, click on “Enable static IP”.

    Fill out the Static IP field with the address you copied from the front page.

    Fill out the DNS server field with a more reliable DNS service. I like to use OpenDNS, which is 208.67.222.222 but you can also use Cloudfare’s new DNS service by entering 1.1.1.1 or Google’s by entering 8.8.8.8.

The slightly more involved way, in which you can keep your Shake on a dynamic IP (assigned by your router):

  1. SSH into the Shake.

    Copy and paste these commands:

    sudo echo 'static domain_name_servers=1.1.1.1 1.0.0.1' >> /etc/dhcpcd.conf
    sudo service dhcpcd restart
    

    Now make sure those changes took hold:

    nano /etc/resolv.conf
    

    The file should look like the following:

    # Generated by resolvconf
    nameserver 1.1.1.1
    nameserver 1.0.0.1
    

    You should not need to restart, these changes will take effect immediately.

#4

It’s also possible that the problem is on the ISP (internet service provider) side of things, in which case the above fix will not have much effect.

In that case, you may need to call your ISP and tell them to stop disconnecting your router’s DNS every 12 hours. Let’s hope it doesn’t have to come to that! (but it’s a distinct possibility)

#5

HI Ian

Many thanks for the reply - I’ll give it a go and see how I get on

Kind Regards

Graham

#6

Sure thing. Let us know.

#7

Hi

I thought it was OK but its gone down again to day

Logs attached
RSH.R7BC1.2019-08-15T14_06_00.logs.tar (3.7 MB)

#8

hi,

not sure i understand. the unit was rebooted a few hours ago, connected to the server, and has stayed connected just fine. it did happen, however, that there were a few hard resets on the time-stamping, which implies that your unit was unable to communicate with the NTP servers for some period of time.

you can see this in the odf_SL_plugin.info log file near the bottom:

...
2019 227 12:30:38>>	Time adjustment M0: HARD RESET.  This will result in a one-time time-tear.
2019 227 12:30:38>>	5.0: NTP Time (Init): NTP:	1565872237.761822939
2019 227 12:30:38>>	5.2: NTP Sync (HARD): VEL Before: 1565871767.750000000	After: 1565872237.500999928	Diff: 469.750999928
2019 227 12:30:38>>	5.2: NTP Sync (HARD): IS Before: 1565871767.750000000	After: 1565872237.500999928	Diff: 469.750999928
...

and i can confirm that your unit is currently connected and delivering data.

cheers,

richard

#9

HI Ian

When you have time would you mind looking through my logs to see if the DNS issue has been resolved

Im not convinced it has

Many thanks

Graham

RSH.R7BC1.2019-08-18T08_38_22.logs.tar (3.7 MB)

#10

hi graham,

everything is looking fine: since your reboot a few days ago there have been no more hard time resets (indicating a connection loss to the NTP servers). there were, however, a couple of reconnections to the server, but this was a server-side issue that has been resolved.

you can verify no time-tears in your data using swarm and connecting to your local unit, and not to the data server itself; server reconnections issues will not be present on the local version of your data streams.

cheers,

richard