Unable to connect to devices

Yeah, It makes perfect sense, before using balena we had issues with our VPN range colliding with some local networks, so yeah, definitely the right way to do it. I think that we can still update applications just fine. Is the /mnt/boot/system-proxy/no-proxy accessible to containers? Or would this be in the docker-compose file?

For making the change from the application container programmatically I would look at either using the supervisor API or updating the iptables rules manually. Documentation for the supervisor API you need can be found here, or I can give you a hand if you’d rather deal with iptables directly.

That API looks like exactly what I need. I will do some experimentation with it and report back, thanks for the link.

Ok, so I am able to use the remote example to edit the configuration on a device that I have that has already been manually setup to work through the new VPN range. The remote example does not work on devices that are blocked (this was expected)

So, connected (locally) to a device that is blocked, Attempting to run the local version with PATCH and get the following error.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot PATCH /supervisor/v1/device/host-config</pre>
</body>
</html>

I am wondering if documentation is old? maybe I need to POST and put PATCH as method like in the remote example ?

The other thing that I am wondering about in the documentation is it says the following

The “noProxy” setting for the proxy is an optional array of IP addresses/subnets that should not be routed through the proxy. Keep in mind that local/reserved subnets are already excluded by balenaOS automatically.

And unfortunately the link goes 404. I am wondering if this feature was removed? I believe that if it worked as indicated then this issue would not have happened?

Just wondering if the docs are up to date, thanks

edit:
also interesting is this

# curl "$BALENA_SUPERVISOR_ADDRESS/v1/device/host-config?apikey=$BALENA_SUPERVISOR_API_KEY"
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /supervisor/v1/device/host-config</pre>
</body>
</html>

Hi @nleonardi,

If you are interacting with a local supervisor, you should patch the local URL provided in that example. Specifically, the request should be formed roughly as follows:

$ curl -X PATCH --header "Content-Type:application/json" \
    --data '{"network": {"hostname": "newhostname"}}' \
    "$BALENA_SUPERVISOR_ADDRESS/v1/device/host-config?apikey=$BALENA_SUPERVISOR_API_KEY"

From the looks of it, I think you are mixing the remote call with the local call.

I will look into that broken link, as we have recently updated the naming of some components in that repository. I suspect it is just an issue with that renaming.

Hi @xginn8
That is the form I was using, however the $BALENA_SUPERVISOR_ADDRESS env variable is not set in the container. I did an export BALENA_SUPERVISOR_ADDRESS=https://api.balena-cloud.com But It seems like you are saying that there is a local supervisor address that I should be using? In that case would it be just localhost ? or is it another container on the OS and I need it’s IP address?

If you have not already, you should take a look at how to communicate directly with the supervisor as that should explain all the configuration & setup that is necessary to interact locally. Please let us know how that goes for you!

Just as a further update, I have PRed a patch to our supervisor documentation as well. Thanks for reporting that issue!

Ah, I see now, The container is privileged and has host networking, but I had missed the supervisor label. The link you changed looks much more useful. I guess I am wondering if your team can also do a PR to that file https://github.com/balena-os/meta-balena/blob/master/meta-balena-common/recipes-connectivity/resin-proxy-config/resin-proxy-config/resin-proxy-config to add in the 100.64.0.0/16 subnet? It seems like that should be included as well, however I will leave it to your judgement whether that is the case. Thanks

edit: I can create an issue in github if that is helpful

Hi @nleonardi

I went to grab some dinner but I’ve just PR’d the appropriate changes to the proxy config in meta-balena, thanks for creating an issue! (I see I misread what you said, don’t worry about it, but thanks for the offer :slight_smile:).

EDIT: PR link.

@wrboyce Thank you!

We were able to get a fix deployed using the balena supervisor. Thanks for pointing us in that direction, we are working on other some features for our product that will benefit greatly by leveraging it, and now we know how to use.

Do you mind sending an update when that makes it’s way into the main release? It will be nice to take this patch out once it’s no longer necessary.

Thanks again for the quick responses, not the best way to spend a Monday lol :wink: but this was very helpful.

Sure thing! Since it has to go into the OS, then to the separate releases for the different device types, it will take a bit of time but we’ll try to keep you posted.

Glad you are sorted out! And yeah, would love to hear about the other features you mentioned, and whether or not you’re are getting along well with them too.

Cheers!

Hey @nleonardi, heard from our other team members, that you were asking:

I am wondering if the ip range that balena used to use changed? I seem to recall that it was a 172.x.x.x before,

The balena service currently uses 10.114.101.1/24, based on the systemd service file:

Is that what you are asking about?

@imrehg Thanks for the response, worked it out further up in the thread.