Firewall issues?

Firewall issues are fairly uncommon with the Raspberry Shake since the requirement is only to allow out-going traffic. This is because the Shake is responsible for initiating communications with the Raspberry Shake community’s server, not the other way around, where it then pushes the data to the server. But sometimes users have super-closed firewalls that prohibit any and all communication with the outside world. So, if you do not see your station appearing on the StationView map and suspect this is because of firewall permission issues, inform your system administrator of these details:

  1. Your Raspberry Shake’s IP and MAC address (“Media Access Control address”)
  2. Raspberry Shake community server IP:
  3. NTP program requires port 123 (UDP)
  4. Meta-Data is sent to the Raspberry Shake community server through port 55556 (TCP), once at system start-up
  5. Continuous seismic data is sent to the Raspberry Shake community server through port 55555 (TCP), in one second packets over a continuously open socket with the server
  6. And, if you want to be able to use Swarm to see data from other Raspberry Shakes on the AM network, you will need access to port 16032 (TCP) to successfully communicate with the Raspberry Shake community server.

How to manually change DNS

(Only necessary for really restricted networks - like those that will only allow you to use their DNS server)

  1. Edit /etc/resolvconf.conf and specify your name_server explicitly. For example,

    # Configuration for resolvconf(8)
    # See resolvconf.conf(5) for details
    # If you run a local name server, you should uncomment the below line and
    # configure your subscribers configuration files below.
    # Mirror the Debian package defaults for the below resolvers
    # so that resolvconf integrates seemlessly.
  2. Reboot,

    $ sudo reboot
  3. Check that the new nameserver appears at /etc/resolv.conf


At /etc/resolvconf.conf the DNS is denoted by “name_server”, at /etc/resolv.conf is appears as “nameserver”

NTP timing issues

If you notice that your Raspberry Shake’s system UTC clock is showing the incorrect time, it is very likely that NTP is being blocked by your firewall or ISP. Here we explain how to confirm that NTP is, in fact, not working.

Start by executing ntpq:

$ ntpq -p

If you see refid = INIT, then the Raspberry Shake’s Raspberry Pi computer is not making contact with one or more of the NTP servers, and now you know why the time is wrong.

So, why no NTP connection to the servers?

You can try executing the following commands for additional insights: (anything in red is not good!)

$ sudo systemctl status ntpdate -l
$ sudo systemctl status ntpd -l

ntpdate and ntpd are the services that are responsible for a) setting the time at boot-up, and b) starting the NTP daemon to keep the clock in sync after the time has been set. If either is failing, system time will be wrong.

OK, nothing is working- now what?

The requirement for Linux NTP clients to be able to communicate with servers is that port 123 must be open in both directions, all along the chain of routers to the internet WAN. So the next step is to explore who or what (usually a firewall) is blocking the NTP communication.

How to manually change NTP Server

(Only necessary for really restricted networks - like those that will only allow you to use their NTP server)

You can set the NTP server(s) to use in the file /etc/ntp.conf, in the section specifying “server …” List them in order of preference to use. You generally want more than one.