I have an Intel NUC that is imaged with a development mode image and fully provisioned (running the latest git hash from my repository) and I have another computer on the same local network.
Balena(resin) dashboard shows the device is online, router has handed out an ip address via DHCP. I have the resin cli installed and when I attempt to ssh to the device
$ sudo resin local ssh af1e49e.local
ECONNREFUSED: connect ECONNREFUSED 10.0.0.115:2375
or
$ ssh root@10.0.0.115 -p 2375
ssh: connect to host 10.0.0.115 port 2375: Connection refused
The network bandwidth the public network is only 2Mbps download and less than 1Mbps upload
Since I’m on the local network, how can I connect to the device given that the connection to the balena servers is essentially non-existent?
Also when I do use my cellphone to create a hotspot, and power off the wireless router that we install to avoid interference with the host network (the one with a really poor connection to the balena servers) I get this error when I try to restart the main service or restart or shutdown the device:
Request error: tunneling socket could not be established, cause=socket hang up
You should be able to connect directly using local IP or the avahi hostname. Something like ssh -p 22222 resin.local. By defaut the hostname is resin but that is configurable in config.json.
@jason10, ah, I see you’re literally using resin.local. I think resin there was intended as a placeholder, as the specific hostname will change depending on your device. For balenaCloud devices, it should be .local (the short uuid is the first 7 chars). Assuming your device uuid starts with af1e49e, I think you were actually already using that before above, so you should run:
ssh -p 22222 root@af1e49e.local
Could you try that, and let us know if it works for you?
Even given this, it is a little surprising that the previous commands didn’t work, as resin local ssh does something quite similar. In the output you posted, it looks like it’s having an issue in this case talking to the docker port on the device.
What actually happens here is that by default the CLI talks to Docker on the device over the local network, to get a list of containers that are running, and then gives you a list to log into one of those directly. If Docker isn’t accessible on that port, it normally means either it’s not running for some reason, or you’re using a production image instead of development.