Server Connection: Not Connected, and password issue

RSH.RBBE5.2021-04-26T11_16_43.logs.tar (4.7 MB)
Hi,

  1. After going through issues of similar nature in this forum I could still not figure out how to get my Raspberry device connected to the server. I tried burning the new Shake OS at a new micro SD card as well, but it did not work, so I re-inserted the old SD card. The green light kept blinking and did not glow solid as expected during the rebooting process.
  • Stand-alone is off.
    -Power supply seems to be working smoothly.
  • Device name: AM.RBBE5.00.E[HZ,NZ,NN,NE]
  1. To my knowledge, the default password of this device has not been changed (I am new to my organization here), but this password does not work. Is their any way to reset the password?

Thank you!
-RP

Hello RP_NS,

Thank you for adding your logs. Let’s tackle one problem before the other.

The station RBBE5 was blocked from transmission since, back in 2019, it rebooted very frequently, causing issues to our servers. Now, we have enabled it again, and we will wait to see if it start passing data to our data centre properly.

Can you verify that, in the next hours (tomorrow at maximum), the status has changed to “Connected?”

Thank you.

Hi Stormchaser,
Thank you for the prompt response.

The status is still “Not connected”.


RSH.RBBE5.2021-04-27T03_49_00.logs.tar (4.8 MB)

Here we have assigned a static IP to the Raspberry device instead of DHCP. Could this have anything to do with the frequent rebooting issue?
Do you have any ideas regarding what else could have caused it?

In addition to the current device RBBE5, we have 5 other inactive devices at different locations, whose logbooks I cannot currently access.
RE2B9
R2E9D
RBE19
RDF62
S16F7
Would it be possible for you to do a quick check on their status? Could they also have been blocked for similar reasons?

Hello RP_NS,

I’ll answer your last question first. I have checket every station in the list you have provided, and no one of them is blocked, so the issue has to be somewhere else.

Usually, frequent reboots can be caused by corruption of the ShakeOS on the microSD card (in this case, a wipe and re-burn of the OS are needed) or insufficient or unreliable power supply, which in 90% of the cases, is caused by a faulty or not appropriate adapter (and in this case, it is sufficient to find another one that works properly).

From the logs I can see this error:

|2021 116 01:00:25>>|odf_SL_plugin: Program Starting...|
|2021 116 01:00:25>>|Connection attempt #1 (raspberryshakedata.com:55556) failed with error code: Connection timed out|

It seems that the connection to our servers cannot be established from your network location. Static IP should not be the cause, I am using the same with my shakes, and there are no issues.

What I can advise you to do is the following:

Please shut down your Shake again first, then your modem/router. Wait for a couple of minutes, then restart your modem/router, and when it’s back online, please check again from your pc/laptop if the following ports are open (do not start the Shake now):

port 55555 [TCP]
port 55556 [TCP]
port 123 for TCP and UDP traffic in both directions

If they are still not open, please consult your modem/router manual on how to open them (port 123 in particular, since it is the one that regulates the time synchronisation). After they have been opened, start your Shake and wait for a bit (around one hour tops) to see if it manages to connect to our servers.

Thank you for the detailed response.

I did pull the plug and reconnect the device (but not the router) a few days ago, but it did not change anything.

Since the password of the device is currently not working (as mentioned in my first post), I cannot shut down the device. I can only pull the plug. Would it be necessary to fix the password issue before I attempt the step you have suggested?

It is no problem at all, you’re welcome.

Yes, let’s try to tackle the password issue first, and then move onwards.

The default setup, that you have every time you wipe/re-burn, or turn on, the Shake for the first time is the following:

Username myshake
Password shakeme

Can you confirm that using the indicated password, nothing happens when triggering the “Shutdown” command from the Actions button high on the right → Actions tab section?

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.