I’m attempting to deploy a docker image for debugging on my Toradex device from the Torizon IDE (OS Major version 7). The build and deploy process outputs a connectivity error unless my development PC and Toradex device have the same subnet (matching the first three octets). This isn’t guaranteed on my company’s network and I’m hoping to broaden the allowable subnet mask for deployment from 255.255.255.0 to 255.255.0.0. I am able to ssh into and connect across through the Torizon IDE when the third octet doesn’t match, I expect this is an issue with the local docker registry. Can this wider subnet range be used for the Torizon IDE for deploying and debugging code?
Development Laptop:
Windows 11 Pro
OS build 22621.4317
Running Torizon OS Major 7 in a WSL remote on VS code
Output from tdx-info on the board shown below:
Software summary
Bootloader: U-Boot
Kernel version: 6.6.54-rt44-7.2.0-devel-ga6d7d8cae6f6 #1-Torizon SMP P REEMPT_RT Thu Jan 1 00:00:00 UTC 1970
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo v t.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ost ree=/ostree/boot.1/torizon/4d473d306b471f1e59fa09ccbd010569882f052b87e8bf5823e4e a71d5bb29f3/0
Distro name: NAME=“Torizon OS with PREEMPT_RT”
Distro version: VERSION_ID=7.2.0-devel-202502-build.5
Distro variant: VARIANT=“Docker”
Hardware info
HW model: Toradex Verdin iMX8M Plus WB on Ivy
Toradex version: 0070 V1.1A
Processor arch: aarch64
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello, and thank you for your detailed description of the issue.
You are correct in your assessment: the deployment limitation is due to how the Torizon IDE extension uses a local Docker registry on your development machine, which the target device must access during deployment and debugging. The documentation and community discussions confirm that the extension is designed with the expectation that both the development PC and the Toradex device are on the same subnet (matching the first three octets), typically within a 255.255.255.0 (or /24) network mask(1)(2). There is currently no documented or configurable option in the IDE or extension to relax this requirement to use a broader subnet mask like 255.255.0.0 (or /16).
Why this limitation exists:
The target device needs to reach the Docker registry on your workstation. With split or routed subnets, automatic discovery or accessibility can break due to:
Docker registry bindings that default to only listening on local addresses.
Workstation firewalls or Windows network policies that block cross-subnet requests.
Lack of explicit network routing between the subnets.
What you can do:
Ensure Network Routing Exists:
Double-check that the subnets on your corporate network are fully routable between your development PC and device, without restrictions or NAT between them.
Check Firewalls:
Make sure that firewalls on both the PC (including Windows Firewall) and any corporate network appliances allow incoming connections to the Docker registry port (typically 5000 TCP) across your intended subnets(2).
Manually Set Docker Registry Host:
You might try setting the Docker registry to listen on all available interfaces (0.0.0.0) rather than just localhost on your workstation, ensuring the Toradex device can reach it directly via IP address. This can require manual adjustments to your Docker configuration and registry setup outside the default Torizon IDE flow. See the following general guide on using Docker registries: Add Dependencies and Tools to an Existing Project.
Consider DNS/Hosts File Adjustments:
If you encounter name resolution issues, ensure that your device can resolve the hostname or FQDN of your workstation hosting the registry.
Summary:
The Torizon IDE is not currently designed or documented for deployment across routed or non-local subnets without network-level workarounds. The easiest and most reliable workflow is to ensure that both endpoints are within the same /24 subnet as per the documentation. Any other configuration will require in-depth knowledge of Docker, Windows networking, and host/container connectivity troubleshooting. For now, the IDE does not support modifying the subnet mask requirement directly.
If you want to attempt a more advanced network configuration, the steps above may help, but be aware this is not officially supported in the current IDE release.
Well, a few hours ago I had the “opposite issue” - the Torizon IDE discovery bound the socket to an IP address from a different subnet, below is my post:
Can you share some outputs from commands like netstat or lsof, to be able to identify the registry socket binding?
Also, from my observations, it binds to a specific IP address, without checking the subnet mask. So, changing from /24 to /16 or whatever else should be absolutely transparent from software point of view, as long as you have OSI Layer 3 reachability between the endpoints.
Can you share the error message that you receive when you are attempting the deploy the docker image? As well as what which specific task runner you are attempting to run.
Actually, in the above post I was replying to @belangen with the idea that I doubt that the Torizon IDE won’t work with lower subnet mask, because from software perspective it only sees IP addresses (/32). Please correct me if my observations are wrong…
I then gave an example with the issue that I faced on my PC with multiple NICs, which confirms my theory that the Torizon IDE is not network-aware in the sense of detecting and/or prioritising subnets.
