R5E4F gaps, R2CA8 missing on cloud, data client and spelling mistakes

Hello,

My rs4d (R5E4F) is online but since I connected another rs1d (R2CA8) on the same LAN (both DHCP) it seems to have many gaps. The logs of R5E4F are attached. I have v15 on both units. Looking at the manual, I suppose this will be fixed in firmware version 16? Is there a way to know when the auto-update will append?

Also, it says “Data client: disconnected” (could you explain why?) and I found a few mistakes in the french translation…

Finally, R2CA8 and R5E4F and undistinguishable on the station view, as they have the exact same location (one meter apart)…

Any help?

Cheers

Fred



RSH.R5E4F.2020-06-23T10_37_12.logs.tar (3.6 MB)

bonjour,

access to the interent for this unit seems to be very compromised. it is unable ping the data server, nor is it able to make contact with the ugprade servers, hence the reason it is stuck on version 0.15. as well, it is not being assinged an IP address using DHCP services.

which all points to the fact that the router it is connected to is not performing as it should. verify that your router is providing DHCP services, has access to the internet at large, and is permissioned to have all the necessary ports open for use by Shakes. firewall requirements can be found here.

cheers, hope this helps,

richard

Hello,

This is not very promising. The router is administered by my institute, lots of people use it and I would be the only one to complain. Both devices are accessible via their own IPs in the intranet of my office. I can ssh to them, and access some of the ports listed on https://manual.raspberryshake.org/firewallIssues.html, but I cannot try them all today, I will tomorrow when I’ll be in office.

Cheers

hi,

please try to confirm success with a different router, for example, try to see if you get different behavior when connecting to your home network.

regardless the unit’s location, the firewall requirements are absolute as laid out in the manual.

when these requirements are unable to be met due to restrictions implemented by local network security administrators, the only option left is to place the unit elsewhere: where the firewall requirements are able to be properly accommodated for.

good luck,

richard

Ok I have access to all required ports… and think I don’t have gaps today, so think everything is OK :slight_smile:

But I still have no idea of the meaning of “Data client: disconnected” :man_shrugging:

I guess I should do the system upgrade manually with https://gitlab.com/raspberryShake-public/raspshake-sd-img?

upgrading maually that shouldn’t be necessary. check the logfile upgrade.log, latest entries, to see what the problem could be. previous errors indicated accessing the upgrade server was failing. is this still the case?

same for disconnected, check log files odf_SL_plugin.err for relevant server connection messages.

that said, both your units are connected and transmitting data successfully to the server. if the units are not ugprading and are still claiming to be not connected to the server, please forward your log files for both units, i’d like to take a look at what the problem is.

cheers,

richard

I have:

myshake@raspberryshake:/opt $ tail /opt/log/upgrade.log
fatal: unable to access 'https://gitlab.com/raspberryshake-SW-public/rsh-SW-updater.git/': Failed to connect to gitlab.com port 443: Connection timed out
2020 168 05:13:14: Upgrading UPG to latest version
2020 168 05:13:15: Updating Docker image rsh-fe-config
Error response from daemon: Get https://registry.gitlab.com/v1/_ping: dial tcp 35.227.35.254:443: i/o timeout
2020 168 05:14:00: Updating Docker image rsh-data-producer
Error response from daemon: Get https://registry.gitlab.com/v1/_ping: dial tcp 35.227.35.254:443: i/o timeout
2020 168 05:14:45: Updating Docker image rsh-data-consumer
Error response from daemon: Get https://registry.gitlab.com/v1/_ping: dial tcp 35.227.35.254:443: i/o timeout
2020 168 05:15:30: Software updates complete.

But:

myshake@raspberryshake:/opt $ nc -vz gitlab.com 443
Connection to gitlab.com 443 port [tcp/https] succeeded!

day 168 was 9 days ago.

can you reboot the unit to force an upgrade attempt and see what happens when done more recently?

richard