I commissioned my new RS3D today - station R4FA0.
Initially all went well and the station briefly came up online, however, after changing the SSH password and setting a fixed IP address, the station has failed to reconnect to the server.
Please find attached log files:
RSH.R4FA0.2024-05-14T08 47 53.logs.tar (1.4 MB)
I tried the work around of toggling Data Forwarding given in other threads about the problem, but so far no change.
Thanks, Al.
Hello sheeny, and thank you for the logs!
The Shake boots up without issues, as you have seen, but it cannot seem to find a proper network connection:
2024 135 08:39:01: Network detection failed, unable to curl or ping common sites
2024 135 08:39:01: No internet connection found
2024 135 08:39:02: Network detection failed, unable to curl or ping common sites
Could I please ask you to SSH into the Shake, execute the following two commands:
cat /etc/dhcpcd.confcat /etc/resolv.confand post their output here? Thank you!
G’Day Stormchaser,
Thanks in advance for your help.
Last login: Mon May 15 17:37:19 2023 from 192.168.0.11 myshake@raspberryshake:/opt $ cat /etc/dhcpcd.conf interface eth0 static ip_address=192.168.0.117/ static routers= static domain_name_servers=192.168.0.1 static ip_address=192.168.0.117/ static routers= static domain_name_servers=192.168.0.1 static ip_address=192.168.0.117/ static routers= static domain_name_servers=192.168.0.1 # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. # Allow users of this group to interact with dhcpcd via the control socket. #controlgroup wheel # Inform the DHCP server of our hostname for DDNS. # Use the hardware address of the interface for the Client ID. clientid # or # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361. #duid # Persist interface configuration when dhcpcd exits. persistent # Rapid commit support. # Safe to enable by default because it requires the equivalent option set # on the server to actually work. option rapid_commit # A list of options to request from the DHCP server. option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes # Most distributions have NTP support. option ntp_servers # Respect the network MTU. # Some interface drivers reset when changing the MTU so disabled by default. #option interface_mtu # A ServerID is required by RFC2131. require dhcp_server_identifier # Generate Stable Private IPv6 Addresses instead of hardware based ones slaac private # A hook script is provided to lookup the hostname if not set by the DHCP # server, but it should not be run by default. #nohook loo denyinterfaces wlan0myshake@raspberryshake:/opt $ cat /etc/resolv.conf # Generated by resolvconf nameserver 192.168.0.1 nameserver 8.8.4.4 nameserver 180.76.76.76 myshake@raspberryshake:/opt $
I hope this helps. ;o)
Al.
Hello sheeny, it definitely does, thank you!
What you see (the many static lines, some with empty fields after the = symbol) is the result of a bug that will be fixed in the next Shake OS release and that we are actively working on. To solve your problem, please do the following:
Please open again the dhcpcd.conf file with
sudo nano /etc/dhcpcd.conf
Delete all the lines that start with static, thus leaving only interface eth0. After doing this, paste your latest configuration so that the first section of the file looks like this:
interface eth0
static ip_address=192.168.0.117
static routers=
static domain_name_servers=192.168.0.1
...rest of the file
Filling in the static routers field with your router’s IP address. Then save the file with the sequence Ctrl+X, Y, Enter. Now restart the service with :
sudo service dhcpcd restart
to make sure those changes took hold and then check the output file with
cat /etc/resolv.conf
Your Shake should now display a Static IP address (the one you set) and be able to connect to the internet.
If it doesn’t, please reboot it, then wait ~30 minutes and: 1) download the new logs, 2) print out again the dhcpcd.conf and resolv.conf files, sending all here to me.
Thank you very much for your collaboration, as usual.
This was the result of the last command (nano …):
It doesn’t look right… saying it’s unwritable.
Al.
My apologies, as the last command had to be cat... instead of nano... as you only needed to read the output and not edit it. I have modified the reply accordingly.
In any case, what the file is showing appears to be all right, with no empty lines. You can close this with Ctrl+X and if you haven’t already, could you try to reboot the Shake and see if the configuration you’ve set works?
Hmm… I think I’ve made a mess.
I rebooted the shake, and while waiting to see if it reconnected I noticed the IP address was 192.169.0.117 not 192.168.0.117 in rs-2.local.
When I tried to change pages to correct the IP address the shake shutdown. So it’s now unreachable on my network.
I assume that if I plug in a keyboard, mouse and screen I should be able to get in to correct this? I’d appreciate some guidance on this if it is possible. I’m not fluent with linux and R Pi.
Thanks,
Al.
Yes, having the incorrect IP address would make the Shake unreachable on your local network. It’s a bit unusual that the Shake shut down when you tried to change pages, but we’ll get to that later.
The Shake HDMI screen output is disabled by default to save resources, so the best thing you can do is the following:
With the Shake shut down, disconnect the LAN cable from your modem and connect it directly to your computer.
Then, you have to change your PC IP address to be in the same range as the Shake. In our manual, (Discovery IP) we usually go with 169.254.8.11.
Now, turn on the Shake, and after two-three minutes (the time to boot up), you should be able to connect via SSH with ssh [email protected].
Once in, you can edit the dhcpcd.conf as before, correct your IP address, then shut down the Shake with sudo shutdown.
Now disconnect the Shake LAN cable from your PC, reconnect it to your modem, revert your PC IP address change (in point 2), and when you turn the Shake ON again, it should now correctly appear on your network.
On the local PC IP change, if you are not familiar with it, I have selected some guides (not knowing your system):
Win10
Win11
Mac
If you require further assistance, just let me know.
Thanks Stormchaser!
It’s getting late here, so I’ll leave it till tomorrow, rather than risk more mistakes!
Thanks again.
Al.
Since I can’t access the shake, I can’t shut it down properly prior to switching it off.
My previous experience with this was the µSD card was corrupted and I had to reburn the card. I assume there’s no way to avoid this… if I’m lucky the card survives, if not we fix the problem by reburning?
Al.
Yes, a microSD card reburn would easily fix all this as it would revert the Shake configuration to factory settings.
In that case, you could simply disconnect the Shake’s power supply, extract the microSD card, re-burn it, and then re-configure the static IP address as per my message above (New RS3D (R4FA0) not comnnecting to server - #4 by Stormchaser)
If you need the Shake OS file to burn, you can find it here: microSD card topics
It is indeed a more straightforward solution, that’s for sure.
Good morning Stormchaser,
I reburned the SD card got the station going again, and made the changes as before (without the error in the IP address ;o) ) but still not connecting.
Here are the log files:
RSH.R4FA0.2024-05-14T21 10 02.logs.tar (81.5 KB)
Last login: Tue May 14 20:52:40 2024 from 192.168.0.118 myshake@raspberryshake:/opt $ cat /etc/dhcpcd.conf interface eth0 static ip_address=192.168.0.117 staic routers=192.168.0.1 static domain_name_servers=192.168.0.1 # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. # Allow users of this group to interact with dhcpcd via the control socket. #controlgroup wheel # Inform the DHCP server of our hostname for DDNS. # Use the hardware address of the interface for the Client ID. clientid # or # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361. #duid # Persist interface configuration when dhcpcd exits. persistent # Rapid commit support. # Safe to enable by default because it requires the equivalent option set # on the server to actually work. option rapid_commit # A list of options to request from the DHCP server. option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes # Most distributions have NTP support. option ntp_servers # Respect the network MTU. # Some interface drivers reset when changing the MTU so disabled by default. #option interface_mtu # A ServerID is required by RFC2131. require dhcp_server_identifier # Generate Stable Private IPv6 Addresses instead of hardware based ones slaac private # A hook script is provided to lookup the hostname if not set by the DHCP # server, but it should not be run by default. #nohook loo denyinterfaces wlan0 myshake@raspberryshake:/opt $ cat /etc/resolv.conf # Generated by resolvconf nameserver 192.168.0.1 nameserver 8.8.4.4 nameserver 180.76.76.76 myshake@raspberryshake:/opt $
Al.
Good evening from my side of the world sheeny!
Now dhcpcd.conf and resolv.conf look good from what I can see. Out of curiosity, is this the same configuration of your other Shake, or are we talking about two entirely different networks?
I ask this because the Shake cannot yet find a network:
2024 135 20:47:40: Network detection failed, unable to curl or ping common sites
2024 135 20:47:40: No internet connection found
2024 135 20:47:41: Network detection failed, unable to curl or ping common sites
And the two ports required for data transmissions appear to be blocked.
Can you SSH again into the Shake and execute these commands for me?
ping -c 5 8.8.8.8ping -c 5 144.91.66.87nc -zvw5 144.91.66.87 55555nc -zvw5 144.91.66.87 55556And also:
traceroute 8.8.8.8traceroute 144.91.66.87And post their output here? Thank you!
G’Day Stormchaser,
It should be the same as R21C0 - definitely the same network.
myshake@raspberryshake:/opt $ ping -c 5 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. From 169.254.210.251 icmp_seq=1 Destination Host Unreachable From 169.254.210.251 icmp_seq=2 Destination Host Unreachable From 169.254.210.251 icmp_seq=3 Destination Host Unreachable From 169.254.210.251 icmp_seq=4 Destination Host Unreachable From 169.254.210.251 icmp_seq=5 Destination Host Unreachable --- 8.8.8.8 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 28ms pipe 4 myshake@raspberryshake:/opt $ ping -c 5 144.91.66.87 PING 144.91.66.87 (144.91.66.87) 56(84) bytes of data. From 169.254.210.251 icmp_seq=1 Destination Host Unreachable From 169.254.210.251 icmp_seq=2 Destination Host Unreachable From 169.254.210.251 icmp_seq=3 Destination Host Unreachable From 169.254.210.251 icmp_seq=4 Destination Host Unreachable From 169.254.210.251 icmp_seq=5 Destination Host Unreachable --- 144.91.66.87 ping statistics --- 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 189ms pipe 4 myshake@raspberryshake:/opt $ nc -zvw5 144.91.66.87 55555 nc: connect to 144.91.66.87 port 55555 (tcp) failed: No route to host myshake@raspberryshake:/opt $ nc -zvw5 144.91.66.87 55556 nc: connect to 144.91.66.87 port 55556 (tcp) failed: No route to host myshake@raspberryshake:/opt $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 169.254.210.251 (169.254.210.251) 3141.082 ms !H 3140.931 ms !H 3140.902 ms !H myshake@raspberryshake:/opt $ traceroute 144.91.66.87 traceroute to 144.91.66.87 (144.91.66.87), 30 hops max, 60 byte packets 1 169.254.210.251 (169.254.210.251) 3145.181 ms !H 3145.024 ms !H 3144.996 ms !H myshake@raspberryshake:/opt $
Al.
Thank you for the output sheeny.
A question that may sound silly, but is the Shake currently connected to your PC or to your router?
Because I’m seeing this address 169.254.210.251 in front of all commands, traceroute included, and as that is the Discovery IP range of the Shake, it looks a bit unusual. It should report the IP address of your router as the first step:
myshake@raspberryshake:/opt $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.254 (192.168.1.254) 1.049 ms 0.886 ms 0.831 ms
...
Could you try to ping your router with ping -c 5 192.168.0.1?
The shake is connected to the router not my PC.
myshake@raspberryshake:/opt $ ping -c 5 192.168.0.1 PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data. 64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.719 ms 64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.678 ms 64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.715 ms 64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.669 ms 64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.692 ms --- 192.168.0.1 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 160ms rtt min/avg/max/mdev = 0.669/0.694/0.719/0.034 ms myshake@raspberryshake:/opt $
Al.
All right, thank you again.
The Shake can “chat” with the router all right. Could you please redo a sudo service dhcpcd restart followed by a sudo reboot?
If this doesn’t work, then we’ll explore other alternatives.
It’s rebooted, but not yet connected (only a few minutes so far),
Al.
That’s ok, while we wait, could you retrieve these two files
cat /etc/dhcpcd.confcat /etc/resolv.conffrom your other (the first) Shake? That is, if this unit has a static IP address too?
I would like to compare the two configurations to see if I have missed anything.
Thanks!
Yes R21C0 has a static address as well.
STATION: AM.R21C0.00 IP-ADDR: 192.168.0.106 myshake@raspberryshake:/opt $ cat /etc/dhcpcd.conf # A sample configuration for dhcpcd. # See dhcpcd.conf(5) for details. # Allow users of this group to interact with dhcpcd via the control socket. #controlgroup wheel # Inform the DHCP server of our hostname for DDNS. # Use the hardware address of the interface for the Client ID. clientid # or # Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361. #duid # Persist interface configuration when dhcpcd exits. persistent # Rapid commit support. # Safe to enable by default because it requires the equivalent option set # on the server to actually work. option rapid_commit # A list of options to request from the DHCP server. option domain_name_servers, domain_name, domain_search, host_name option classless_static_routes # Most distributions have NTP support. option ntp_servers # Respect the network MTU. # Some interface drivers reset when changing the MTU so disabled by default. #option interface_mtu # A ServerID is required by RFC2131. require dhcp_server_identifier # Generate Stable Private IPv6 Addresses instead of hardware based ones slaac private # A hook script is provided to lookup the hostname if not set by the DHCP # server, but it should not be run by default. #nohook loo denyinterfaces wlan0 myshake@raspberryshake:/opt $ cat /etc/resolv.conf # Generated by resolvconf nameserver 192.168.0.1 nameserver 8.8.4.4 nameserver 180.76.76.76 myshake@raspberryshake:/opt $
Al.