Some sort of update to VSC is causing it to lose my default device

Technical Support
, , , ,
1

I have 2 networks, once is a dhcp network, the other is a manual network. Both are 192.168.x.x networks. The manual (static IPs) network is between 2 boards (and my laptop), one being the imx8mp on a custom board. It has one network port. The 2 boards talk to each other using the network. My laptop runs VSCode talking to the verdin board on that network. It also has a 192.168.x.x network that it can get to the internet from and I am running windows 11 (unfortunately).

Windows 11, will only allow that manual network to be a public network, so the firewall rules are very strict. I don’t think this is the issue though.
VSC is losing the default device, by leaving it alone for even 10 minutes or so. And I am using insecure registries, so launching is a problem. I am running Ubuntu 24.04 on WSL and Docker Desktop, with the insecure registries containing all the IP’s, my laptop (2) and my device (1). It works fine for WSL, but for the verdin, everytime I setup the default device, it changes the insecure registries to the other network from my manual network. This was find until it started doing it by itself. It seems to continuously (every 10 or 15 minutes) recheck and reset the verdin’s insecure registry values and some of the settings, like the torizon login, and the host IP.

I am not sure what is causing this. But it has slowed me down having to remove the device and add it again and go into the daemon.json to add the registry values again and restart docker.

Steve

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Multi-NIC Environment Configuration Issues

Your issue appears to be related to a known limitation with the Torizon IDE Extension in multi-NIC environments. Based on the available documentation, here are the key solutions:

1. Manual Host IP Configuration

The Torizon IDE Extension can struggle with automatic IP detection when multiple network interfaces are present(1). You can manually configure the host IP in your project’s settings.json file(1):

"host_ip": "192.168.100.6",

(1)

2. Engineering Mode Configuration

When the Torizon IDE Extension connects to a device, it sets up Engineering Mode which includes configuring insecure registries(2). The extension automatically adds your development PC’s IP as an insecure container registry in /etc/docker/daemon.json(2):

{
	"insecure-registries" : ["<your development PC's IP>"]
}

(2)

3. Manual Registry Configuration

To prevent the extension from overwriting your registry settings, you may need to manually maintain the daemon.json file on your Verdin device(1):

{
   "insecure-registries" : ["192.168.100.6:5002"]
}

(1)

4. Network Connectivity Verification

Ensure proper network connectivity between your development machine and the Verdin board(3):

  • Verify both devices can communicate with each other
  • Check that port 2375 (Docker daemon) is accessible(3)
  • Confirm your local registry port (typically 5002) is accessible from the board(3)

5. Docker Configuration Considerations

Since you’re using Docker Desktop with WSL2, ensure you’re not running both Docker Desktop and Docker Engine simultaneously, as this can cause conflicts with the VSCode extension(3). The documentation recommends using Docker Engine in WSL2 rather than Docker Desktop when possible(4).

Known Limitation

The multi-NIC scenario you’re experiencing is a recognized limitation of the Torizon IDE Extension(1). The expected behavior should include per-subnet discovery and reachability checking, but this functionality is not currently implemented(1).

Workaround Summary

  1. Set the host_ip manually in your project’s settings.json
  2. Manually configure the insecure registries on your Verdin device
  3. Monitor and manually correct the daemon.json when the extension overwrites it
  4. Ensure consistent network connectivity between your development machine and target device

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

@ToradexAI

Yes, I recognize all of this. However, everything gets overwritten everytime I start up VSC. And I have had it overwrite the Docker daemon.json file just as it’s sitting there. And sometimes when I start VSC up with nothing changed, it connects with the device, but as soon as I try to debug, it says the device has a bad value in it and I must remove and re-add it. But I have to remove it and restart VSC before I can add it again. Otherwise, it sits there forever trying to “connect”.

Steve

4

Persistent Configuration Override Issue

Your issue with VS Code continuously overwriting your network settings is a more severe manifestation of the multi-NIC limitation. Here are specific steps to work around this persistent override behavior:

1. Override Host IP Detection

The extension may be detecting the wrong IP automatically. You can force it to use a specific IP by setting the torizon.overwriteHostIp setting in VS Code’s global settings(1). This prevents the extension from auto-detecting and changing the host IP:

  1. Open VS Code Settings (Ctrl+,)
  2. Search for torizon.overwriteHostIp
  3. Set it to your manual network IP (e.g., “192.168.100.6”)

This setting overrides the automatic IP detection that’s causing your configuration to reset(1).

2. Project-Level Settings Protection

In your project’s .vscode/settings.json, explicitly set these values to prevent overwrites(2):

{
    "torizon_ip": "192.168.x.x",
    "host_ip": "192.168.100.6",
    "torizon_debug_ssh_port": "2230",
    "containers.environment": {
        "DOCKER_HOST": "tcp://192.168.x.x:2375"
    }
}

(2)

3. Docker Daemon Configuration Lock

To prevent the daemon.json from being overwritten on your Verdin device, you can:

  1. Set the file as read-only after configuring it correctly
  2. Create a script that monitors and restores the correct configuration
  3. Ensure the insecure registries include your static IP

4. Connection State Reset

When you encounter the “bad value” error requiring device removal, this typically indicates the extension’s internal state has become corrupted(1). The requirement to restart VS Code suggests the extension isn’t properly cleaning up its connection state.

5. Engineering Mode Behavior

The extension automatically configures Engineering Mode settings each time it connects(3), which includes:

  • Setting up insecure registries
  • Configuring Docker daemon settings
  • Establishing SSH key sharing

This automatic reconfiguration is what’s overwriting your manual settings(3).

6. Workaround Strategy

Given the persistent nature of your issue:

  1. Use the global torizon.overwriteHostIp setting to lock the IP detection
  2. Monitor your daemon.json file and restore it when overwritten
  3. Keep backup copies of your working configuration
  4. Consider using a script to automatically restore correct settings after VS Code startup

Known Limitation Acknowledgment

This behavior represents a more severe case of the known multi-NIC limitation(2). The extension’s automatic reconfiguration is designed for simple network environments and doesn’t handle complex multi-network scenarios gracefully.

The persistent overwriting you’re experiencing suggests the extension is continuously re-detecting network changes and applying what it considers “correct” settings, which conflicts with your manual network setup.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Hey @EvetsMostel1,

How are you doing with this topic?

You may be able to change the torizon.autoScan property to false. I assume somewhere between Widows/docker/vscode/the extension and some idle time, something is being dropped and resigned to a default.

-Eric