[edit: the Starlink router does not open the required ports]
A new issue, at least for me:
I am attempting to install the v.20 software on a RPi 2B+, headless with an Ethernet connection. This is for an older Shake 1D with a v4 board.
Following either of the two SD card instructions (raspberryShake-public / Raspshake Sd Img · GitLab), the shake software seems to start the install and blinks the green r/w LED for 10-15 minutes. At this point the two LEDs on the Ethernet jack turn off, and after a few more minutes the Pi’s green LED also stops blinking, and that’s the final state. The shake never appears on the local network, and can’t be discovered (e.g. with Fing).
I’ve verified that the latest Raspian Bullseye installs fine, and has Ethernet connectivity; hence the computer, network connection, and the SD card are fine. The Shake board’s blue LED is lit.
Any ideas as to what’s happening, and how I can get the Raspberry Shake software to complete its installation?
On further investigation, it may be that I’m trying to connect to a Starlink router, which uses CGNET and hence the ports the Raspberry Shake needs aren’t open.
Remembering that I own the router, I did an nmap scan:
only two ports are open:
PORT STATE SERVICE
80/tcp open http
53/udp open domain
This means that NTP isn’t available (port 123/UDP) and the ports the Shake uses to stream data to the server aren’t available, and there seems to be no way to open them.
I think there are only two options to use a Raspberry Shake with a Starlink router: either run in stand-alone mode with GPS for the time signal, or run a separate network server that can supply the Shake with open ports. Corrections welcome!
Bill
I think you are misunderstanding what nmap does. It list ports which have listeners on them.
Your router should not have many (ideally none) ports with listeners on the Internet side.
An Internet connection not allowing NTP, or any other port, would be pretty useless.
ISPs do typically block a couple of ports - ones used by broken Microsoft software - that facilitate virus and botnet attacks.
You have tested the hardware, the fact that you are not getting an IP really seems to indicate that the card may be bad, or maybe there was a problem in burning the image.
Thank you @PhilipPeake. A little bit of knowledge is dangerous. No wonder nmap use is forbidden at the University.
I was wrong: Using Raspian Bullseye I installed ntp and verified that it could reach the time servers (after first disabling systemd-timesyncd).
So, NTP works; with a terminal program I verified that the Shake digitizing board is sending the binary data from the geophone, so it works too.
Yet installing the latest Shake software image results in the same behavior: after 10-15 minutes the ethernet jack lights and the green SD card access LED off. It’s not the SD card as it’s the same one that boots Bullseye fine.
Reading the SD card after the failed install, using ext4fuse on a Mac, I can see that all the directories have been installed. Nothing is written into /opt/log
I persist in thinking that it’s the Starling router somehow. I’m out of ideas to try…
Why would it be the router if Raspbian OS works ok?
The fact that you are not getting any logs at all generated sounds like some sort of permissions problem… Log data is written before any network access at all takes place.
After rebooting the router and several more attempts with different permutations, I was able to get a postboot.log file created. It contained the message: Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
The Starlink router has the Google (8.8.8.8) DNS server coded into firmware, and this can not be changed.
From another Starlink connected computer, a traceroute to 8.8.8.8 takes over 16 seconds:
prompt$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 starlinkrouter (192.168.1.1) 4.752 ms 2.759 ms 1.792 ms
2 100.64.0.1 (100.64.0.1) 53.591 ms 87.076 ms 74.828 ms
3 172.16.249.0 (172.16.249.0) 68.357 ms 47.719 ms 58.042 ms
4 149.19.108.45 (149.19.108.45) 56.927 ms 47.613 ms 49.801 ms
5 undefined.hostname.localhost (206.224.64.63) 64.224 ms 49.324 ms 58.335 ms
6 * * *
7 dns.google (8.8.8.8) 52.999 ms 54.107 ms 56.544 ms
A similar traceroute to the Cloudflare DNS server (1.1.1.1) takes just over a second.
So what seems to be happening is that the Shake software is timing out when it tries to resolve a hostname address.
I’m able to see the postboot.log file on the Linux ext4 partition, after the fact, by installing the ext4fuse software on my Macintosh -but this does not allow writes to the filesystem, so I can not change the DNS server that the Shake software is using. Since this was to be a headless installation, I do not have access to an HDMI monitor and keyboard.
The solution (other than changing routers) seems to be to install the Shake software using a landline connection, change the DNS Server, and then install it at the Starlink location.
I’ve had help from Jeff Geerling on this; thank you! He’s made a good video about this initial Raspberry Shake experiences:
He also has a number of videos documenting his experiences with both Starlink and with Raspberry Pis (and other topics too). Check out his Youtube channel at: https://www.youtube.com/c/JeffGeerling/videos
Poking around the Linux ext4 partition from the failed install. The generated file: resolv.conf
contains the fallback nameservers used by the Shake software. In addition to Google (8.8.4.4), the first two on the list are from the cs2.cableonda.net provider in Panama (200.75.200.3 and 200.75.200.2) and public-dns-a.baidu.com (180.76.76.76) in China.
None of these can be found by the Shake software, resulting in multiple Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available
errors in the postboot.log file.
Thank you for this insightful and detailed recount of your experience with a Starlink router. If I’m not wrong, this is the first time that our Shakes are being used with this relatively new technology, and I am sure that your post will be very useful to other Shakers that may find themselves in the same situation.
As you have correctly thought, the Shake OS tests for connection, and if it doesn’t find any, it timeouts and prepares to test it repeatedly until a stable link to the internet is found. That is why you saw all the Unable to resolve hostname 'raspberryshake.net', most likely no DNS server available messages in the postboot.log file.
Just read this thread in detail.
One comment on this:
The times are times from the source to that particular host, not times from one host to the next.
So the time to 8.8.8.8 is ~55ms NOT 16 seconds.
You say that 8.8.8.8 is the hard-wired value in the StarLink system (Seems odd, I would have expected at least two to be listed, but ok …) But the resolv.conf file lists:
At least it does on my 'shake. It will try each of those in turn, timing out if they can’t be contacted and moving on to the next. Those timeouts can take some time. Probably enough to time out. The first two, 10.0.0.21 and 1.1.1.1 are those set by my DHCP server.
Since you have two listed at the top of the list which I doubt came from the Starlink DHCP (Panama and China servers) my guess is that at some point you tried out the 'shake connecting it to your normal Internet connection and received these addresses from the DHCP server there.
I would suggest trying editing the resolv.conf file and removing all the servers (addresses) before 8.8.8.8 then try again. My guess is that it will now find the DHCP server very quickly.
