Firewall issues are fairly uncommon with Raspberry Shake’s installed at home. This is because the Shake is responsible for initiating ALL communication with the Raspberry Shake Community’s Server, not the other way around, where the Shake then pushes the data to the Server. Sometimes users have to install their Shake in settings like schools where the network has super-restrictive firewalls that prohibit any and all communication with the outside world. It is not uncommon in schools for even internal communication to be restricted/ blocked. Many schools allow for https communication and that is it.
If you are having problems communicating with your Shake using Swarm or do not see your Shake appearing on the StationView map and suspect this is because of firewall permission issues, please send this link to your system administrator and ask them to open to the following ports. They will often ask for your Shake’s IP and MAC address. These are displayed at rs.local.
These are the IP:port combinations that need to be open to use the Raspberry Shake:
rs.local:80 (http) [TCP] - the Raspberry Shake’s internal web configuration page
123 [UDP] - NTP, necessary for time-stamping seismic data
raspberryshakedata.com:55555 [TCP] - Continuous seismic data is sent to the Raspberry Shake Community Server through this port in packets 4 times per second over a continuously open socket with the server
raspberryshakedata.com:55556 [TCP] - Meta-Data is sent to the Raspberry Shake Community Server through this port once at system startup
These are the IP:port combinations that need to be open to use Swarm:
caps.raspberryshakedata.com:16022 [TCP] - For Swarm’s “RS Community” connection
Shake_Local_IP:16032 [TCP] - For Swarm’s local “myShake” connection
These are the ports that need to be open to use the web tools:
https://stationview.raspberryshake.org/:8079 - For displaying the waveforms
https://eqview.raspberryshake.org/:8079 - For displaying the waveforms
https://eqview.raspberryshake.org/:18082 - For displaying seismic event data
It has been found that there are some modem/routers that will automatically close a port if they detect too much traffic on it, like with the constant connection that the Raspberry Shake has. We recommend to not use them, if possible. A list can be found below:
AT&T Arris BGW201-700
(Only necessary for really restricted networks - like those that will only allow you to use their DNS server)
Edit /etc/resolvconf.conf and specify your name_server explicitly. For example,
# Configuration for resolvconf(8) # See resolvconf.conf(5) for details resolv_conf=/etc/resolv.conf # If you run a local name server, you should uncomment the below line and # configure your subscribers configuration files below. #name_servers=127.0.0.1 name_server=myawesome.dns.server # Mirror the Debian package defaults for the below resolvers # so that resolvconf integrates seemlessly. dnsmasq_resolv=/var/run/dnsmasq/resolv.conf pdnsd_conf=/etc/pdnsd.conf unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf
$ sudo reboot
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”
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.
(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.