I have an issue with a Raspberry Shake that was set to use a fixed IP address. It now is accessible on the LAN from a PC via the web control panel and SSH via PuTTY, however it is not able to access the external web. Oddly, I also have a Raspberry Boom, on the same network with a fixed IP address and it works OK. Browsing on the Raspberry Pi forums I find lots of things about issues with the original Jessie release where trying to set a fixed IP address breaks things, but I thought this had been resolved. When I look at the /etc/network/interfaces file, and /etc/dhcpcd.conf file on the Shake and Boom they were somewhat different at first, but changing the ones on the Shake to agree with the ones on the Boom, except for the specific IP addresses, has not helped. When I try to do the “Download Log Files” on the Shake it dies with a 504 Gateway timeout error on the page that opens up, and the main control page freezes for awhile with a machine offline message. Are there other files I should be looking at, or is time to try building a fresh sd card?
Thanks, Richard Browning
Fixed IP address not working
One cause of the symptom you are seeing is an incorrect gateway. Are you sure the your shake and boom agree on this line?
For example, if your static IP is 192.168.1.100, your gateway is probably:
static routers=192.168.1.1
If this line doesn’t agree in both files, change your shake to agree with the working boom.
Yes, in my case it is:
static routers=192.168.0.1
The line is towards the top of /etc/dhcpcd.conv just after the static ip_address line. I have also tried putting the added lines at the bottom of the file with no obvious difference in behavior. The service dhcpcd is running.
It does seem to be an issue with the gateway setting, but I am not sure where exactly it gets set. When running “ping website.com”, ping will accurately report the IP address of website.com so the nameserver setting is ok, but then cannot reach it so no packets are returned. However ping does work going to 192.168.0.x addresses.
Running ifconfig on the Shake and Boom gives very similar results, with neither one reporting a gateway setting for eth0 . The route command also gives essentially the same information on the Shake and Boom, but maybe I don’t know how to spot the gateway setting in the output. Is there some way to display and change the gateway address on a running system?
Hi,
Install a linux program call mtr $sudo apt install mtr should do it. Then:
$mtr google.com
and it should let you see where things get stuck
Installing mtr on the RShake doesn’t work because it has no WAN internet access at all. I did try installing mtr on the RBoom that is working. The install failed though. It looked like mtr itself might have downloaded, but apt found maybe 100 or more other libraries that needed to be installed as well and most of these failed with a 404 error message. I do have a pi-top running the basic Raspbian distribution I tried installing mtr on the pi-top and it worked very nicely. Doing the “mtr google.com” test worked as well, producing similar output as a traceroute to the same address.
If I try “traceroute google.com” on the ailing RShake, the output is just:
traceroute to google.com (172.217.12.14), 30 hops max, 60 bytes packets
1 * * *
2 * * *
3 * * *
… and so forth. Essentially there are no returned packets as the system cannot find the gateway. If I do the same thing on the RBoom that works, then the first return is from the gateway 192.168.0.1. Any other ideas on how to examine or tinker with the gateway settings on the RShake?
hi richard,
going back to the beginning, you don’t say whether you used the front-end configuration interface to set the fixed IP or if you did this yourself on the command line. i ask because if you did this from the front-end interface, then we need to look at this from the standpoint that our software might have a bug for your use-case details.
if you did not use the front-end interface, then you might want to try to set the fixed IP via the front-end config, perhaps the results will be different.
and can you send along your log files for both units?; perhaps something might be there that could help us diganose what could be going on.
thanks in advance,
richard
OK,here is an attempt at the log files. The RBoom works normally, so here is the standard set of log files. RSH.R5456.2019-08-29T21_38_26.logs.tar (2.1 MB)
The RShake that cannot access the internet was more challenging for me. Trying to use the log file save on the web control panel doesn’t work, not clear to me what the issue is, but instead of getting a file to save the new web page just dies. Using ssh access I found log files in /opt/log and also in /var/log. I made tar files for these directories as separate items, then moved these files to my PC using psftp. So here are the two separate tar files - hopefully the names are reasonably clear.RSH.RE046_optlog_20190829.tar (4.4 MB)
Well I tried on the var/log tar file, but the file is too big. So, I am unpacking the file and just copying over the syslog file. I still have all the other files but don’t know which ones you might be interested in. syslog (369.3 KB)
The history of the RShake is a little vague to me at this point. It has been running at least since July 2017. I believe the fixed IP change was originally done using the option on the browser interface. However, a few months ago I had some hardware failures at the cable modem and a separate router as well as some reconfiguring of the local area network hardware connections. At some point in the repair/reconfiguration process the RShake lost connectivity. I then tried tinkering with the standard configuration files but it never seemed to make a difference. Perhaps it would easiest for all if I just make a new microSD card and start fresh.
Thanks, Richard Browning
I purchased a new industrial grade microSD card then downloaded and installed the latest version of the Shake software. Installed this in the RShake and booted it up. It came up able to access the local area network, but is not able to access the outside internet. This is essentially the same issue as before. I did go ahead and enter the settings changes, including the request for a fixed IP address, then pushed save and reboot button. It did seem to save the settings, but not clear if it did actually reboot. The time on the RShake is set to a default in Mar 2019 because it cannot get to the network time server. Otherwise it seems to be operational, just cannot get to the outside world. I did make a tar file of the files in /opt/log and am including it here: RSH_201909072010.tar (150 KB)
Any suggestions on how to fix the network situation will be very much appreciated.
Thanks, Richard Browning
I am experiencing the same issue with a R3 I just received today. I cannot get the front end to change to the DNS that I enter. It just returns to 8.8.4.4 as the DNS. I am able to set a static IP, but it does not appear to connect to the internet. I also received a R Shake Boom and got it configured and online without any issue. I set a static IP and DNS and it is now online working fine. I am uploading the log files from the R3. RSH.R985F.2019-03-16T02_42_32.logs.tar (790 KB) RSH.R985F.2019-03-16T02_44_47.logs.tar (771 KB)
Thanks Tom Warner
Hi Tom, I got your email as well but responding here. This is a bug that I believe will be fixed in the next release. To set a DNS server manually, you can edit the file /etc/resolv.conf and add the line
nameserver 1.1.1.1
Or simply append the server to the file from the command line like so:
echo "nameserver 1.1.1.1" >> /etc/resolv.conf
If you have any further questions let me know.
Ian
Ian,
I was able to use nano to change the nameserver to match my other unit which is connected, however, the unit still does not connect. The front end confirms the correct DNS that I changed with nano. When I reboot or shutdown and restart, the network nameserver returns to 8.8.4.4 and the resolv.conf reverts to nameserver 8.8.4.4 even though I checked that it was changed and written prior to the restart. Any suggestions on what might be going on?
Tom W.
Hi Tom, I’m so sorry, I always get this backwards. resolv.conf gets overwritten by dhcpcd. To make the changes stick, edit the file /etc/dhcpcd.conf and add the following line to the end of the file:
static domain_name_servers=1.1.1.1 1.0.0.1
Then restart dhcpcd:
sudo service dhcpcd restart
If everything goes well you should end up with two new nameserver lines in resolv.conf, which will stick on reboot.
Ian,
I was able to accomplish the tasks you laid out and the unit now boots up with the correct DNS, however, it is still not connecting to the Raspberry Shake like my Shake Boom did. I got the following from the boot log file if this helps. It appears everything is correctly configured but the network adapter is just not connecting to the internet (no server contact or NTP contact).
Job for rsh-data-consumer.service failed because the control process exited with error code.
See “systemctl status rsh-data-consumer.service” and “journalctl -xe” for details.
2019 076 07:43:15: R-Shake System boot-up sequence completed
2019 076 07:44:02: Network detection failed, unable to curl or ping common sites
2019 076 07:45:02: Network detection failed, unable to curl or ping common sites
2019 076 07:46:01: Network detection failed, unable to curl or ping common sites
2019 076 07:47:02: Network detection failed, unable to curl or ping common sites
Tom W.
Ok. Something is definitely up here. Can you reboot the unit, wait 10 minutes, and then download and send the logs again?
Also, is the subnet of your local network 192.168.1.x? If so, the network mask should read 255.255.255.0 instead of 255.255.0.0 as it does now. When you set a static IP, did you play around with the DHCP settings at all?
Ian. I have included the logs as requested. The subnet of my local network is 192.168.1.x and yes the subnet mask should be 255.255.255.0 but I do not see any place that I can verify it or set that manually in the front end interface or confirm it in the logs. You stated that it is showing 255.255.0.0 now. How can I check this and change it to 255.255.255.0. RSH.R985F.2019-11-17T20_37_24.logs.tar (1.7 MB)