Server Connection: Not Connected, and password issue

When using the default password ‘shakeme’, I receive an “authentication failed” message, and therefore unable to shut down or reboot.

I am not able to change the password either, as the authentication fails for the old password.

Can the microSD be replaced with a new one? When I tried to do that according to gitlab website instructions, for some reason it did not seem to work. I simply unzipped the image to a new microSD, and did not use a tool like Etcher. Maybe I should try that if password access is not possible?

Then this seems to be a bug that needs to be examined and corrected. I will open a ticket for our software team so that they will take a look at it.

Changing the microSD card can be the next step, yes. Or formatting the old one from scratch following this procedure:

I followed the numbered list points to burn the files on my SD cards, and I have not used Etcher or similar software.

More details on which microSD cards to use (MLC is fine): https://manual.raspberryshake.org/burnSD.html#microsd-card-facts

Please try this solution, and check if the standard password will allow you to reboot or shutdown the Shake properly.

Thank you.

Thank you for further examining the issue.

I did try installing a new microSD card (as I did not want to risk damaging the old one which seems to be fine) by following the exact instructions in the above link. I even did a full format instead of quick format.

The unpacking task mentioned in step 5 did not seem to work. The R & B lights did glow solid, but the G light did not glow solid upon inserting the microSD card and kept on blinking, for an entire hour. The Raspberry device did not work after that, so I re-inserted the old microSD card. Any suggestions regarding this?

Hello RP_NS,

This is quite strange since the Raspberry Pi board and the Shake board seem to be working fine with the old card, albeit with the problems that we have already discussed. So, there should be no reason for it to not work with a new microSD card.

Do you have the chance to try with another microSD, a third one. just to erase this variable from the equation?

Hello,
I can try it out with another microSD card. Unfortunately our city is under 2-week long Covid lockdown since yesterday, and I am not able to travel to the device location. I will update as soon as I get the opportunity.
Thank you!

Hello,

There is no problem. I hope your situation with COVID improves and that you can resume work/travel safely.

A post was split to a new topic: Server connection unable to connect

Hi Stormchaser,

I finally got to work on the device after the Covid lockdowns, and wanted to give recent updates.

The issue discussed above (for RBBE5) is finally resolved, with the following steps:

  1. I took the device to a different location to rule out any network or power issues.

  2. Since the root cause seems to be corrupted microSD card, I took a new microSD card and fully formatted (not quick format) it to FAT32 using “USB disk Storage Format Tool”, since default windows format did not always work.

  3. I then obtained a microSD card from another functional raspberry shake device and cloned it to the newly formatted microSD card as described in step 4. I had to resort to cloning since the gitlab instructions for installing new Raspberry OS image did not work (is it due to version incompatibility?). Using Raspberry Pi imager also did not work.

  4. Using “AOMEI Partition Assistant” I cloned the functional microSD directly to the new microSD. This step failed at the first 2 attempts, and I had to fully format the new microSD before each new attempt. It took almost 4 hours to complete the process (including failed attempts), so patience was very necessary here.

  5. Finally, I inserted the newly cloned microSD into the raspberry shake device, and in about 10 minutes, the device was functional, as shown by Fing Desktop app. After about an hour or so, the station was also visible in the RS Station View.

  6. The password issue was automatically resolved after the above steps.

The device has been working smoothly for the last five days; so I shut it down and have now brought it to the original installation location. It remains to be seen if it works smoothly here as well. I will update further later.

Hello RP_NS,

Firstly, thank you for getting back with new information! And secondly, wow, that was one of the most detailed reports that I have read, thank you again!

I am sure that these points will be very useful to other people who are in a similar situation and want to solve it.

Could you please expand on this sentence

I had to resort to cloning since the gitlab instructions for installing new Raspberry OS image did not work (is it due to version incompatibility?)

in your point 3? Which error, in particular, was met when you tried to follow the instructions on our page? Because if there is some kind of miscommunication we naturally want to correct it.

Yes, cloning can be a long thing, I remember a similar experience when I cloned an old Win7 installation years ago, and it took a good part of the day. The 10 minutes wait is compatible with what we know after a first start, with the Shake OS communicating with our servers and downloading all the updates we have implemented.

I’m really happy to hear that your Shake is now working properly, and thank you for your patience and feedback. I’ll wait for further reports, if needed.

Enjoy Shaking!

Hi Stormchaser, you’re welcome.

To further clarify the point regarding the image burning instructions, I did not encounter any error messages and the image appeared to be extracted correctly to the microSD, but when I put the microSD into the Raspberry Shake , the unpacking task did not happen as described in steps 5.1 to 5.3 (of raspishake-microSD-card-software-Instructions.txt · master · raspberryShake-public / raspShake-SD-img · GitLab).

The Green light never glowed solid as described in 5.2, and only blinked occasionally. So I tried using Raspberry Pi imager to burn the image, but that did not work either. (I fully formatted the 8GB microSD before each attempt, which took about an hour.)

Could this be due to incompatibility between the image file version and the device? I couldn’t figure this out, so, I tried cloning from another functional device which was purchased at about the same time as the device being repaired.

I am now trying to install RBBE5 at the intended location and I will probably post another update some time next week.

1 Like

Thank you for the extendend information RP_NS, they are very welcome!

I understand the situation better, and yes, it could be due to an error in the imaging process, or some kind of corruption along the way that prevented the unpacking phase.

Good idea to clone the existing image into the new microSD.

Hi Stormchaser,
Today I tried installing the device at the original location. First I corrected the location information (which had been set to that of the device I cloned from).
However, the Server Connection still shows ‘Not Connected’ status. Here are the new log files:
RSH.RBBE5.2021-07-29T07_43_12.logs.tar (2.2 MB)
Does this indicate any new problems? Could it be that the device is still blocked by RS server?

PS. The ports that you previously suggested are open: port 55555 [TCP]
port 55556 [TCP]
port 123 for TCP and UDP traffic in both directions

Hello,

Thank you for the logs. From them, it appears that there are still issues with the data transmission to our servers, but after checking, the station is not blocked by us.

Could you please login into the Shake (instructions here: How to access your Raspberry Shake’s computer via ssh — Instructions on Setting Up Your Raspberry Shake) and execute the following command from the command line:

nc -zv raspberryshakedata.com 55555; nc -zv raspberryshakedata.com 55556

This will return ‘success’ or ‘connection refused’, which will at least be a direct indication if the unit can see the server and ports it needs to or not. If we have a refused status, then you should crosscheck if the ports are effectively open or not.

If we have a success status instead, maybe the used DNS server has problems in allowing transmission to our servers (it has happened in the past). You can then try to change it to one more widely used with the following instructions:

There are two possible ways: setting a manual DNS in the http://rs.local web config, or adding a line to /etc/dhcpcd.conf in the Shake filesystem.

  1. The first doesn’t require logging into the Shake. Navigate to rs.local, make note of the Shake’s IP address, then click on the Settings gear icon (high on the left) to access the configuration menu.Click on NETWORK, then under ETHERNET SETTINGS, click on “Enable static IP”.Fill out the Static IP field with the address you copied from the front page.Fill out the DNS server field with a more reliable DNS service. OpenDNS, which is 208.67.222.222, is a good choice. You can also use Cloudflare DNS service by entering 1.1.1.1 or Google by entering 8.8.8.8.

The second way, a bit more complex, in which you can keep your Shake on a dynamic IP (assigned by your modem/router):

  1. SSH into the Shake and, once you’re in, copy and paste these commands (this example is for Cloudflare DNS but, as stated, you can use others too):
sudo echo 'static domain_name_servers=1.1.1.1 1.0.0.1' >> /etc/dhcpcd.conf

Now make sure those changes took hold:

sudo service dhcpcd restart

And see if they took hold. The file should look like the following:

# Generated by resolvconf
nameserver 1.1.1.1
nameserver 1.0.0.1

You should not need to restart, these changes will take effect immediately, but if you want, you can still do it. If there is no connectivity change after a while, then you can retry with a different DNS server.

Thank you for the detailed instructions.

The device is installed in a fairly large office building with many networks and a firewall. Since I am not authorized to access the firewall settings, I am working with the IT admin.

Using PuTTY, I entered the command you suggested but it returned a syntax error. So, I tried the following instead:


(192.168.1.100 is the IP of the raspberry device)


Did I enter the commands correctly?
Since the command returns “connection refused”, does this mean that the firewall is blocking connection to the necessary ports?
The admin insists that the ports are open, so I am not sure what to do next.

Hello RP_NS,

You are right, the command was incorrect, and the following is instead the correct one:

nc -zv raspberryshakedata.com 55555; nc -zv raspberryshakedata.com 55556

which is the second that you have executed in any case.

This second one has provided a “connection timed out” result, so that confirms that the Shake cannot communicate with our servers via the two ports.

It is possible that the ports are open, but the firewall and/or the networks are configured in such a way that the IP or MAC address of the Shake have to be added to the exceptions for it to connect.

I advise you to bring the Shake to your home and connect it to your local network. If it connects as it should, then the issue is in your office network, otherwise, we can see what to do from this side.

The device is working fine and it connects at other locations. The issue does seem to be with the office network firewall.

The firewall in the office (where the problem is happening) is managed using FortiGate. The IT admin opened the three ports (55555, 55556, 123), but the device could not connect. So, he tried opening all ports, and then the device worked there as well, indicating that more ports besides the three might need to be open. However, due to security reasons, he suggested that it would be unsafe to keep all ports open all the time.

So, the question is, besides those three ports, are there any other ports that need to be opened? The objective is to open exactly those ports, and not all the ports.

Hello RP_NS,

A complete list of the ports that need to be opened is available here on our manual: Firewall issues? — Instructions on Setting Up Your Raspberry Shake

Usually, the suggested three are what is necessary for the Shake to be connected to our servers and to acquire a stable time synchronization service. But you can crosscheck with your IT manager and see if there is a port missing in our list!

If this is the case, please communicate it to us, so that we can update the information in our documentation.

Hi Stormchaser,
The device (RBBE5) is fully functional now after opening port 53, Our IT admin figured this out after a thorough examination of the firewall settings.

The manual does not mention port 53, which is used by DNS. I believe this is usually open in most devices, so it was not mentioned.

In summary, the device was made functional in this case after following these two steps:

  1. Repairing corrupted microSD by cloning the OS image from another functional Raspberry Shake.
  2. Opening ports 55555, 55556, 123 and 53, among others.

I believe this issue is fully resolved now. Stormchaser, thank you once again for all the detailed instructions!
In the coming months we will deploy 10 devices in different parts of the country, and I hope this experience will help us complete the process smoothly.

2 Likes

Hello RP_NS,

Thank you for getting back to me with this new information, and again, you’re welcome, it was a pleasure to collaborate with you and get everything ready to work! We will run a couple of tests and then modify our documentation accordingly.

We will be eagerly waiting for the data from these new Shakes, which, hopefully, will present fewer connections issues than this one. In any case, as you rightly stated, this experience will definitely be of help.

If anything else will be needed in the coming weeks/months, you know where to contact me!

P.s. Could you please attach the logs from the fully working and connected Shake? So that we will have some technical elements to validate our tests? Thank you!

Hi, here are the log files after the issues were solved:
RSH.RBBE5.2021-08-06T12_14_37.logs.tar (3.0 MB)

1 Like