Hi Balena Forum,
i am currently running the current OpenBalena deployment and get a strange error when trying to reboot the device. I tried using different version or the CLIs, v5 and. v6 endpoints, but it does not work. Do you have any idea what might be the reason for the strange error?
balena device reboot UUID --debug
[debug] new argv=[/usr/local/lib/balena-cli/bin/node,/usr/local/lib/balena-cli/bin/run,device:reboot,25788f101ca940b12884d0ba20938c13] length=4
BalenaRequestError: Request error: tunneling socket could not be established, cause=connect ECONNREFUSED 10.164.0.6:3128
BalenaRequestError: Request error: tunneling socket could not be established, cause=connect ECONNREFUSED 10.164.0.6:3128
at Object.<anonymous> (/usr/local/lib/balena-cli/node_modules/balena-request/build/request.js:190:27)
at Generator.next (<anonymous>)
at fulfilled (/usr/local/lib/balena-cli/node_modules/tslib/tslib.js:111:62)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
For further help or support, visit:
https://www.balena.io/docs/reference/balena-cli/#support-faq-and-troubleshooting
Hi Frederic,
What version of openBalena are you using and what CLI version are you using?
The tunneling socket has been changed to port 443, however, I can remember that I saw a bug where the CLI still uses port 3128. I’ll check if I can find it.
1 Like
I tested this with REST calls to the balena backend using postman, but this still resulted in the same response error:
https://api.balena:443/supervisor/v1/reboot
Body:
{"uuid": ...}
incl. Bearertoken
Response 502 - bad gateway:
tunneling socket could not be established, cause=connect ECONNREFUSED 10.164.0.6:3128
@maggie0002 Have you come across this previously by chance? (Or happen to have any ideas?)
1 Like
(Thanks @bversluijs as well for the info above)
Haven’t come across it before. Not sure when you installed Open Balena but not too long ago there was a new CNAME requirement for tunnelling that you may not have included if you followed the install instructions a while ago: tunnel.mydomain.com. It’s now in the docs: https://www.balena.io/open/docs/getting-started
Not sure if it will be relevant though, as 10. IP address makes me think it could be an internal communication issue? 3128 was closed externally I believe, but is still used internally. Assuming you haven’t made any custom changes to the haproxy file, and that all the docker containers have come up ok?
Did you use the open balena script to start the process or did you flatten it into a docker-compose.yml file (by running ./scripts/compose config > docker-compose.yml)? If you flattened it you will need to run the command again after an open balena update to get the latest changes.
If you didn’t flatten it but use the script, could try a compose down and then compose back up again to ensure you have the latest containers:
./scripts/compose down
./scripts/compose pull
./scripts/compose up -d
Shouldn’t need all three but no harm in covering all the bases.
1 Like
Yes, this was what i missed 
. The tunnel.mydomain.com was something i must have skipped reading while upgrading my deployment.
Thank you for your quick support @bversluijs , @Maggie and @dtischler
2 Likes