I have recently installed 3 shakes (3D, 4D and RSBoom). As per instructions these were powered up in order and were able to be accessed via rs.local, rs-1.local and rs-2.local. However, at some time during the day the access changed to rs.local, rs-2.local and rs-4.local.
This morning the access is rs.local, rs-16.local and rs-24.local.
As far as I am aware the devices have remained on line and powered up continuously.
I did try restarting them via software but that did not change the name.
However, if the units are powered down and then powered up again in the original order the names were
rs.local, rs-4.local and rs-5.local.
Is this normal behaviour?
The work around is to assign fixed IP addresses and then access each machine using its IP address.
I would welcome others experiences.
1 Like
The 'shakes do not define their .local names. The announce their existence using the Apple Bonjour protocol (https://developer.apple.com/bonjour/). Clients receive these notifications, which include a tag (e.g. “rs”) and IP address. The client adds that to it’s local DNS resolve in the .local domain.
If the client receives a second notification, from a different IP, it will add the name with a numerical index, e.g. rs-1.local if it is notified of a third, it adds it as rs-2.local etc.
Each device broadcasts its notification at fixed intervals so that clients newly connected to the network can detect them.
It appears that whatever computer you are using is not recognizing that these are the same devices already added to it’s DNS, and adding them again, with a new increment.
My guess is that you may be using a Windows system?
Microsoft has a spotty history of support for this protocol (Not Invented Here, Can’t make money from it). Other operating systems have supported it cleanly for quite a while. With Windows a lot is going to depend on version and patch level. It might be worth just trying a re-boot?
Whatever the problem, it is virtually certain that it is at the client level, not the 'shake.
One other remote possibility is that your DHCP server is handing out IPs with very short expiration times, and upon renewal is issuing a different IP, so that over a few hours, the 'shake ends up having multiple IP addresses - that would cause the .local address to increment each time. I think it unlikely that a DHCP server would be that unusually configured (or broken).
2 Likes
Thanks for the reply. that all makes sense. I therefore chose to change to static IP addresses and I have now created a problem…
I set a static IP address and then did a Save and Reboot. It took a while but eventually the units came back on line and I could access then using rs.local etc.
However, none of them will connect to the server. I have checked the Myshake.out files and all three are failing with the error message of not being able to create socket on eth0.
I have tried powering off, restarting but nothing works.
Do you have any suggestions?
thanks
RSH.R8F7A.2023-12-09T09 47 08.logs.tar (2.4 MB)
RSH.R9A1F.2023-12-09T09 54 16.logs.tar (2.0 MB)
RSH.R9ABA.2023-12-09T09 56 16.logs.tar (2.2 MB)
I tried reverting to DHCP but that did not help. I still get the error message and none are connecting.
1 Like
You may have to wait for @Stormchaser to come back online (Monday) to get a proper analysis of your logs. But what I can see is (looking just at the first one):
The error messages about eth0 are probably a red herring, you have an IPv4 address configures on eth0, but both an IPv4 and an IPv6 address configures for ntp servers, so we see:
unable to create socket on eth0 (12) for 2407:7000:8771:bf00:d635:1dff:0:1d8#123
Which is correct, there is no connectivity on IPv6 so that will fail. However, it does establish an IPv4 connection to an ntp server, so that is ok.
I also see this:
Station Info
------------
Data-Sharing Mode : ON
Data Server Conn : OFF
Save Data Days : 7
Heli Scale : 0.5
Station Name : AM.R8F7A.00.EH[Z,N,E]
Geophone : OSOP
Whereas my shake has:
Station Info
------------
Data-Sharing Mode : ON
Data Server Conn : ON
Save Data Days : 7
Heli Scale : 0.5
Station Name : AM.R309F.00.[EHZ][HDF]
Geophone : OSOP
I think data sharing needs to be ON:
Maybe try that?
1 Like
thanks for the reply.
I agree. I too believed this was the problem, but the GUI is showing data sharing is on. The devices are not establishing a connection to the server.
It is strange that all three devices behave the same way.
Ian
1 Like
In case you miss it, I have posted an article on why the “no connection to server” error is happening and how to fix it. It requires editing the file DHCPCD.CONF which is being incorrectly written by the operating system. It puts an entry into the file pointing static router = to a blank. Edit this line by adding the router address and connection is restored.
4 Likes
