Torizon extension Visual Studio Code reboots module

Technical Support
, ,
1

Hi all,

After a certain time without having worked on the Linux application for my Colibri i.MX7 Dual module (working on the M4), I returned to Visual Studio Code to start a debug session of my existing project with my board.

The problem is that whenever I ask the Torizon extension to connect, it causes to module to reboot (message reboot: Restarting system on the console) and it does not succeed to connect (even after Linux has rebooted and shows the login prompt).

This reboot behavior is new to me and I never had it before (the Visual Studio Code install is some months old and I could always debug my application).
Looking at what could have been changed:

  • Visual Studio / Torizon plug-in => last time used did not show this problem. In the mean time, I did not start Visual Studio code
  • For my custom carrier board, I made some additional changes to the device tree.
  • I moved to Torizon version Tezi 5.7.0 build 17 while my last debugging was done with Tezi 5.6.0 build 13.

To be sure that my changes in the device tree did not interfere, I got my Aster carrier board with its separate Colibri Module and installed the plain “TorizonCore Upstream 5.7.0-build.17” version via the latest release of EasyInstaller.

But even with this plain installation, connecting the Torizon plugin to the board causes a reboot of the board.

I uninstalled Torizon from Visual Studiuo code and re-installed it, but still with the same result.

Some version info:

  • Ubuntu 22.04
  • Visual Studio Code 1.73.1
  • Torizon plugin:
    Published 4/9/2020, 08:27:36
    Last released 6/30/2022, 19:41:43
    Last updated 12/20/2022, 14:52:48 (today, after the uninstall and re-install)

This is, by the way, the output on the Torizon console in Visual Studio Code:

[11-20 13:55:17.150] Trying connect to Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3(06596549)
[11-20 14:26:56.229] Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3(06596549) not reached
[11-20 14:26:56.364] Torizon: unreachable devices
[11-20 14:26:56.364] Unreachable devices:

Toradex Colibri iMX7D 1GB (eMMC) on Colibri Evaluation Board V3(06596549)

Make sure the devices are turned on and connected to the network

It is not that unreachable because the plugin manages to reboot the module. Also, using e.g. ping to the module from the same PC works.

Does any of you have the same result or have an idea where this behavior comes from ?

Thanks a lot for any help.

Regards,
Jeroen

2

Greetings @ompie,

In terms of rebooting the module, the only reboot that is expected is when you initially add the device in the extension. When a device is added it will reboot once after being added. But after this the extension shouldn’t cause any further reboots.

From what I can gather it sounds like any attempt from the extension to connect to your device results in a reboot and then the extension also fails to connect, correct?

As for troubleshooting you’ve tried re-installing the extension, and you’ve tried removing and re-adding the device correct?

I notice you’re on Ubuntu 22.04, did you install the correct libssl version as we document here: Visual Studio Code Extension for Torizon | Toradex Developer Center

Since it’s been a while since you used the extension maybe you missed this.

Best Regards,
Jeremias

3

Hi @jeremias.tx
You probably just explained the reboot. Since connecting did not succeed, I tried several times to remove the device from the list and added it again.
While I can’t explain why I wouldn’t have the right version of libssl anymore, I’ll try to reinstall it next week when I’m back at work.

I’ll keep you i formed

Merry Christmas !

Jeroen

4

While I can’t explain why I wouldn’t have the right version of libssl anymore, I’ll try to reinstall it next week when I’m back at work.

Well the issue is not that you have the wrong version of libssl. It’s rather our extension requires an older version of libssl compared to the default version that comes with Ubuntu 22.04. So you probably have the right version for your distribution but the wrong one for our extension.

Since you said it’s been a while since last you worked with our extension there’s the possibility this version may have gotten updated since the last time. Seeing as you’re specifically having connection issues it’s at least worth checking to make sure you have the right version of libssl that our extension requires.

Best Regards,
Jeremias

5

Hi @jeremias.tx,

I did (re-)install libssl1.1_1.1.1f-1ubuntu2_amd64.deb on my PC but this did not change anything.
The ‘reboot issue’ is indeed what you described: the module only reboots once after you add it as a new device. The reboot and the fact that the ‘info’ part of the device shows the name, distroversion and other info about the module means that the PC can at least communicate with the module. So this part seems OK.

When looking around on the various output and terminal tabs in Visual Studio Code, I found a possible reason for the failing (SSL) connection. The Torizon IDE backend process terminal shows:

INFO:root:SSH - Creating tunnel to 07209920
2022-12-28 10:20:09,772| ERROR   | Could not connect to gateway 212.95.74.75:22 : Unable to connect to 212.95.74.75: [Errno 110] Connection timed out
ERROR:sshtunnel.SSHTunnelForwarder:Could not connect to gateway 212.95.74.75:22 : Unable to connect to 212.95.74.75: [Errno 110] Connection timed out
ERROR:root:Error: 539 SSH tunnel error. SSH tunnel error: Could not establish session to SSH gateway
ERROR:root:Exception: SSH tunnel error: Could not establish session to SSH gateway
ERROR:root:Could not establish session to SSH gateway
INFO:root:REST <- /api/devices/07209920/images - 539
INFO:root:REST -> /api/devices/07209920/images

The “wrong” thing I spotted in the ever-repeating log (retries of the connection
) is the IP address. It refers to 212.95.74.75 while my module has address 192.168.1.2 (this is also the IP address I specified when adding a new device).

Can you confirm that the IP address used for the SSH tunnel should be the address of the module ?
If so, do you have an idea where I have to change this ?

Thanks in advance,
Jeroen

6

Hi @ompie !

From this part of your error message, seems like the strange IP is not related to the module, but to some gateway.

Do you have any “special” configuration for your network? Could you check if you have any strange gateway configurations?

You can try to check it with the route command on your Ubuntu.

Best regards,

7

Hi @henrique.tx,

As far as I know, I do not have any ‘special’ configuration for my network. Using route, I get:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         _gateway        0.0.0.0         UG    600    0        0 wlp2s0
default         192.168.1.1     0.0.0.0         UG    20100  0        0 enp1s0
link-local      0.0.0.0         255.255.0.0     U     1000   0        0 wlp2s0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp2s0
192.168.1.0     0.0.0.0         255.255.255.0   U     100    0        0 enp1s0

The module, with IP address 192.168.1.2 is connected to the Ethernet interface enp1s0.
The command shows that the gateway for this interface is 192.168.1.1 which is correct.
And the other interfaces listed here don’t specify the 212.95.74.75 address either


Trying to open an ssh terminal to the module (by clicking on the ‘terminal icon’ of the board in the device list), I get the following error message box:
The terminal process "ssh '-q', '-i', '/home/torizon/.moses/devices/07209920/id_rsa', '-o', 'StrictHostKeyChecking=no', '-o', 'UserKnownHostsFile /dev/null', 'torizon@212.95.74.75'" terminated with exit code: 255.

Here as well, the strange IP address is used. Since it specifies torizon@212.95.74.75 as one of the arguments to ssh, it looks as if the address is considered the address of the module and not a gateway


Any additional ideas ?

Best regards,
Jeroen

8

Hi @ompie !

I must say that right now I don’t know where to look at


As a wild guess, does this location/company ring a bell to you: 212.95.74.75 IP Address Details - IPinfo.io?

Best regards,

9

Hi @henrique.tx,

No, the address is in France as where I am as well but at the complete opposite of the country. I checked my own public IP address and it’s completely different.

Hopefully someone else has a clue about this strange error


FYI, I also did a grep on all files in my home directory, searching for “212.95.74.75” but I did not find anything (I was hoping to find it in a Visual Studio Code config file 
)

Best regards and have a nice New Year’s Day if we don’t communicate for the next few days,
Jeroen

10

Hi @ompie !

Some other places to take a look:

  • Please check the VSCode Settings: Press F1 and select Preferences: Open User Settings (JSON)

    image
    image907×111 8.98 KB

  • Please perform the same grep you did before, but now in your project folder. Don’t forget to make sure that the search also looks inside the .vscode folder of your project.

  • If you start fresh with a new project, do you face the same issue with the same strange IP?

  • Could you also please check all the environment variables of your terminal for this strange IP? You can use the printenv command on the terminal of your computer for this.

Let us know if you find something.

And we wish you a nice New Year’s Eve as well :slight_smile:

Best regards,

11

Hi @henrique.tx,

Happy new year to all of you!

It’s been a while and I still have the problem.
I tried your suggestions but none of it helped. I totally removed the project and I still got the problem.

Meanwhile, I got a second Ubuntu 22.04 PC with a “virgin” installation. After installing docker, Visual Studio code (VSC) and the required extensions, I was able to create the 'hello world application (“Torizon/C-C++:Create C/C+₊ Application” using Cmake and « arm32v7-debian-no-ssh-bullseye ») and run it without any problems.

After that, on the “faulty PC”, I completely uninstalled Docker and also uninstalled the Docker and Torizon extensions in VSC
 After re-installation, I started VSC, re-installed the extensions and added my module as a device in the Torizon extension.
On this PC I also created a new application .The « Hello world » program is compiled and a container is made and the Dev Container is opened (not sure this is the right verb
).
At this stage, the VSC screen is cleared and everything is reinitialized, including the Torizon plugin.
And this is where it goes wrong: « could not connect to gateway 212.95.74.75:22 »
When reverting to the local folder (“Reopen Folder Locally”) the Toradex extension connects to the device.
And “Reopen in container” gets the problem back.

So it looks like it has something to do with the Container environment

I also once got the problem on the new PC with exactly the same message and the same IP address although I could not reproduce it.

I hope this will give you some good ideas :slight_smile:

Regards,
Jeroen

12

Hi @ompie !

Your issue is still strange :sweat_smile:

If you think this is related to some “container environment”, you can try to remove all the related Docker images that you have in the “faulty PC”.

You can go to your terminal and use the docker images (or docker image list) command to list all Docker images that you have and use the docker rmi command to remove images.

Then, you might need to go to VSCode and rebuild the necessary containers again:

image
image883×346 42.3 KB

I would try the following order:

  • Rebuild Dev Container
  • Rebuild SDK
  • Rebuild Application Container (the “Build debug container”)

Let us know how it goes :slight_smile:

Best regards,

1 Like
13

Hello @henrique.tx ,

Thanks again for your help. You guys really are very responsive!
Before being able to give you an answer on whether the strange IP address will disappear, I have another issue for which I opened a separate thread this weekend: Error opening remote remote window in VS Code with Torizon extensio
That problem, which I now have on both PCs, results in a build error.

Error response from daemon: pull access denied for api-terminal_arm32v7-debian-no-ssh_bullseye_debug_570c1fcc-4af2-407c-8c3d-0c0cc39686db_sdk_image, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

So when I try to rebuild the images as suggested (after deleting them), I stumble upon the same error.
So let’s hope someone has a solution for the one first 


Best regards,
Jeroen

1 Like
14

Hi @ompie !

Thanks for the compliment :smiley: We really take support very seriously :slight_smile:

Makes sense.

I saw that Lucas answered you there.

Please follow his instructions there and update us :slight_smile:

Best regards,

1 Like
15

Hi @henrique.tx,

As you saw, I closed the other thread. Reinstalling everything “fixed” those problems and I’m now back to the device not being found.
Meanwhile, I have two Linux PCs with the same installation, done in parallel,

When I added my ‘device’ to the Toradex extension, I specified the full name of the module: colibri-imx7-emmc-07209920.local.
On the first PC, let’s call it A, this worked well while in the “local folder”. On the other PC (B), it did not find the device (both PCs are connected via WiFi to the same network, no cables connected). No explanation for that but I retried with the IP address (192.168.0.27) and this worked.

Now the ‘funny’ thing : when trying to run the default application (“hello world”), this did succeed on PC B but NOT on PC A. So, on the PC where I used the full device name, I got the error I had before: could not connect to gateway 212.95.74.75:22 with the strange IP address.

Now the interesting part:
On PC B (the one that works, with the IP address), I did a ping to the device name without the “.local” extension:

ping colibri-imx7-emcc-07209920
PING nc-ass-vip.sdv.fr (212.95.74.75) 56(84) bytes of data.

=> the same unknown IP address shows up on PC B while PC A mentions this address in the Torizon Extension error message.
And doing the same ping on my windows PC gives the same error

So it looks like there is some problem with the routing on my network. But this does not explain everything:

  • why does the Toradex extension on PC A work with the “<device_name>.local” name while it does not on PC B?
  • Initially, at the start of this thread, I did not specify the device name . Instead, I entered the IP address. So it looks like after the initial connection, the extension uses the device name anyway (which makes sense)

Just to take things one step further, I turned off Wifi on PC A, rebooted and connected the PC to a separate router box which is only connected to PC A and the Colibri module (rebooted as well after the cable swap).
The Module is now on address 192.168.1.2 and doing a ping (on PC A) to the “<device_name>.local” succeeds while a ping to the name without .local prefix reports that the name cannot be resolved.

And surprise, opening the remote container, the Torizon extension did succeed to connect to the module and I could run the “Hello world” program. :slight_smile:

Then I reconnected Wifi. `ping colibri-imx7-emcc-07209920’ gives the strange IP again and when reopening VSC in remote container mode, the device connection error of the Torizon extension is back again!

Conclusion:

  • In remote container mode, the Torizon extension does not use the same mechanism to solve the IP address. To me, this looks like a bug but probably you can explain it because of the container
 (I’m still not a specialist on containers
)

Any thoughts on this ?

Best regards,
Jeroen

16

Hi @ompie

Seems like your computer is somewhat misconfigured related to your network.

This shows that ping tries to connect to the server at nc-ass-vip.sdv.fr to reach your module. This is not right. Can you ping using the .local at the end of the hostname of the module? (not to mention that you wrote emcc instead of emmc, but I assume that it was just a typo while writing here)

I just tested using 2 different computers on the same module and both could deploy and debug an application (even concurrently, but I don’t think that doing this concurrently is recommended)

17

Hi @henrique.tx

You got me doubting but I found the original ping command in the command history and it is indeed a typo in this post.

On a terminal on the “faulty” Linux PC, I can successfully ping colibri-imx7-emmc-07209920.local but colibri-imx7-emmc-07209920 gives the error with the “212.xx” address.

In VSC, to make it work, I used the plain IP address for the Colibri device. This means that in the config.yaml file under ~/.moses/devices/07209920, you can find hostname: 192.168.0.27

I did a short experiment by directly changing the hostname in the config.yaml file (with VSC not running
)

Both colibri-imx7-emmc-07209920.local and colibri-imx7-emmc-07209920' resulted in the Could not connect to gateway 212.95.74.75:22` error.

So there is a difference between the ping and the Torizon extension. I suspect the the Torizon extension silently adds the “.local” suffix and thus fails in both cases.

Anyway, since I do not have much time to dive into this routing mystery right now, I’ll stick to the IP address which works.

So I’ll mark this post as the solution.

Thanks for your help !

Jeroen

18

Hi @ompie !

Thanks a lot for the feedback.

If you face any issue, blocking or not, let us know.

The more feedback, the better :slight_smile:

Have a great day!

Best regards,