Yeah, but I actually think the satellites are doing this already (external) for us by the ping-service. As soon as something with the routing of my nodes is wrong, I always get a lot of this errors like “ERROR contact:service ping satellite failed”. And .lastPinged remains null.
Since the dashboard is accessible from LAN, you can also access the api by http://[LAN-IP]:[DASHBOARD-PORT]/api/sno/ (although not accessible from WAN. No access tokens or wherever involved.
That actually never worked reliably for me. I would receive email about one satellite on one node only, in about 4 hours after it got offline. Those were absolutely useless. Maybe the fixed it in the last months? I don’t know.
I have a few nodes in remote locations. There is no site-to-site VPN. But in the lan, sure.
Ah, different garage. So many garages here in SCV…
This is only if you followed our recommendations and configured a DDNS client on your router rather on your host.
yes, sure. However, if your DDNS client is installed on your host, not on your internet facing router, it may update the DDNS domain to a private WAN IP of the router, either of the CGNAT router or the local IP of the internet facing router which is also a WAN IP for the second before the host.
I saw this many times. Perhaps not all DDNS clients so stupid. To avoid this problem entirely we recommend to configure a DDNS client directly on the internet facing router/modem instead.
yes, within a hour since the last check-in. I guess you would receive a notification email from the satellites around this time too.
I blocked the port forwarding rule for my node and I didn’t have these errors in the log, even when requested the storagenode API. However the lastPinged is stopped to refresh every call. So I guess it’s precise enough to conclude is your node online right now or not, if you have no option to use an external service/server.
This is only true after a restart. If your node was online, but then going to offline, the satellite will notice it depending on audit frequency for your node (then you will receive a notification email, but will not have these errors in the log) or within a hour after the last check-in, when the node would try to check-in automatically, only then you will see these errors.
The lastPinged property will keep a previous value in this case, until you bring it back online, and it’s null after the restart and if your node was not able to check-in (didn’t get a successful response on that attempt).
this depends on an audits frequency for your node from that satellite (they are asynchronous).