Fixed IP address not working


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


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, your gateway is probably:

static routers=

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=
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”, ping will accurately report the IP address of 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?



Install a linux program call mtr $sudo apt install mtr should do it. Then:


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” test worked as well, producing similar output as a traceroute to the same address.
If I try “traceroute” on the ailing RShake, the output is just:
traceroute to (, 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 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,



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

1 Like

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