I am trying to work through the following guide, but I am not able to deploy/debug my sample application:
I am using Visual Studio Code on a Windows 10 machine and connecting to a Verdin iMX8M Mini through SSH. Inside Visual Code, when I am in the local container, I can connect to the device from the Torizon panel. However, once I create the C++ application and I am inside the Dev Container, I can no longer connect to the device and get an “Error (539) - SSH tunnel error”.
I am assuming that for some reason my Dev Container doesn’t have network access, but I haven’t been able to resolve the problem. I have not worked with containers before, so I am probably missing something simple. I am fairly stuck at this point and I would appreciate any troubleshooting guidance.
I was unable to reproduce this on my setup. Even inside the Dev Container environment I was able to deploy & debug a simple hello world application to my target device with no issue. I have some ideas though of what could be wrong. My first guess would be maybe a strict Windows firewall or such. The backend process for our IDE extension is called “Moses” could you check and see if maybe a firewall is blocking such a process? Or alternatively maybe the firewall is blocking Docker Desktop itself?
Furthermore just to have some additional information could you please provide the contents of the following logs:
- OUTPUT window > Torizon
- TERMINAL window > Torizon IDE backend
If you could provide these logs from the start of your IDE session up to the point the error occurs would be best. Preferably in plain text so we can parse it easier. Just want to make sure there’s nothing we’re missing.
Finally just to confirm what version of our IDE extension are you using?
Thanks for looking into this. Attached are the logs requested. I have included a log when outside the dev container showing successful connection to the Verdin.link text
I don’t have Windows Firewall or any local firewall running on my development PC. I’ve asked IT if there’s anything on our network that would prevent communication over port 5001, and they don’t see any reason traffic on port 5001 would be blocked.
I have tried a few things to figure out what may be wrong with my DevContainer config, and have a few observations that may help find a resolution:
When inside the Dev Container, if I try to SSH to the Verdin from the terminal I get the following error:
torizon@docker-desktop:/workspaces/HelloWorld$ ssh email@example.com
ssh: connect to host 172.17.2.199 port 22: No route to host
I found that the Dev Container is being connected to the “bridge” network and not the “host” network. Is this the expected behavior? The devcontainer.json file has the following, but it’s being ignored for some reason:
From the command line I tried manually disconnecting from the “bridge” network and connecting to the “host” network, but got the following error:
Error response from daemon: container cannot be disconnected from host network or connected to host network
The Toradex Torizon extension I am using is v1.3.95.
Thank you for your logs, based on the logs it really does seem like a standard connection issue.
I found that the Dev Container is
being connected to the “bridge”
network and not the “host” network. Is
this the expected behavior? The
devcontainer.json file has the
following, but it’s being ignored for
some reason: “runArgs”: [
This would definitely cause issue if the devcontainer wasn’t running on the host network. On my setup the devcontainer is running on the host network. Before we analyze this point more can you confirm that host networking isn’t being used by the devcontainer by doing the following:
- Open a terminal/command prompt in windows
- run “docker ps -a” and note the container ID of the devcontainer
- now run "docker container inspect "
- In the output of the last command look for the “NetworkMode”: field. What is the value of this field on your setup?
For reference in mine the field appears as follows:
"NetworkMode": "host",. If your devcontainer doesn’t match then this would definitely be the issue, the question is why is your devcontainer being brought up differently.
Perhaps after confirming all this as a sanity check try completely uninstalling then reinstalling the extension. Just to be safe and see if you can still reproduce this after a re-installation.
Thanks again for the response. I took your last suggestions and ended up down the rabbit hole. After learning all about managing containers and container networks I finally figured out my problem. It turns out our LAN subnet overlaps with the default Docker subnet of 172.17.0.0/16. I was able resolve the issue by specifying a new default subnet for Docker using the following in daemon.json:
After adding that and restarting, I can now SSH to the Verdin inside my Dev container in VSCode.
Glad you were able to resolve this. I will say that’s an interesting interaction with the Docker subnet. Good to note though.