Firewall issues?#

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/.

Ports#

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

Note

If a DNS service is not being provided behind the firewall of your school, office, etc., then the following port has to be opened too.

  • 53 (DNS) - necessary for server communications

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:

Note

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

Example email for School System Administrators#

If you need to send an email to your System Administrator asking for the ports above to be opened, you can use the template below, adapting it to suit your needs.

Note

Subject: Request to Open Specific Ports for Raspberry Shake Device

Dear [System Administrator’s Name],

I hope this message finds you well. We are reaching out to request assistance with our Raspberry Shake device, a seismograph used for educational purposes at our school. We’ve encountered connectivity issues that seem to be related to our network’s firewall settings.

To ensure the device functions correctly, it requires open access to specific ports for communication with the Raspberry Shake Community Server and for other related services. The necessary ports include:

  • Port 80 in TCP to access the Raspberry Shake’s internal web configuration page

  • Port 123 in UDP, necessary for time-stamping seismic data

  • Ports 55555 and 55556 in TCP, so that the Shake can transmit live data to the Raspberry Shake servers

Furthermore, if a DNS service is not being provided behind our school’s firewall, then Port 53 needs to be opened too.

It may be also necessary to add the Raspberry Shake unit IP and MAC addresses to our firewall’s exception list.

Also, to use all the Raspberry Shake data tools suite the following IP:ports combinations require to be open. To use SWARM:

  • caps.raspberryshakedata.com:16022 [TCP]

  • Shake_Local_IP:16032 [TCP]

To use our web tools (StationView, DataView, and more):

These ports are essential for the device’s operation, allowing us to access seismic data effectively. We kindly ask for your help in ensuring these ports are open and accessible from the device’s network.

Thank you for your time and assistance. We look forward to your prompt response.

Best regards,

[Your Name][Your Position]

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

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

  2. Reboot,

    $ sudo reboot

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

Warning

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.