ApolloX in WSL cannot see connected SoM

Probably this is a problem of WSL, and I don’t know how it can be fixed.
My Windows 10 machine has two ethernet interfaces:

  • one connected to the company LAN (DHCP, which gives internet acces, …)
  • one connected to to SoM (static IP, point to point)
    From the Win10 PC I can ping the SoM.

I see that WSL Ubuntu has only eth0, which is up and allows me to ping a web address (i.e. google.com), but cannot reach my SoM.
I don’t know if this is possible.
Since I cannot ping the SoM, ApolloX cannot see connected devices, and manually adding doesn’t work (the IP cannot be reached).

Is there any workaround?

I did other tests:
if I connect the SoM on the company LAN, WSL can ping its hostname.
But ApolloX cannot find the device on the network.
But in this case, I can manually connect to the IP.

Why ApolloX cannot find the device?

Hi @vix ,

Just to be sure, can you run the run-share-wsl-ports task, located here:

You will be asked to run a script as administrator: the script makes WSL2 services visible to an external network and it is necessary to make ApolloX work on Windows. If you accept it, click yes.

This task should be executed automatically when creating a new project. Maybe it didn’t work the first time?

Try doing that and see if it works for you.

Best regards,
Lucas Akira

Yes, the task has been run.
It asked me the administrator password to execute a powershell script.
Even if I re-run the task, it asks again for the password, then the powershell window opens and closes itself automatically.
I think it succedeed.
But I cannot see any connected device; or, better, it seems that “Scanning Torizon devices…” never ends.

EDIT:
I can add that I’m logged into Windows with an user that doesn’t have administrator rights (I can enter the credentials of an administrator user when prompted).

Hi @vix ,

The issue when connecting to the SoM on a static IP looks like something related to how WSL2 handles networking and its relation to the host. Maybe this link might be useful? Accessing network applications with WSL | Microsoft Learn

Best regards,
Lucas Akira

Hi @lucas_a.tx
I don’t think this is the case, because now that I connected the Verdin to my company LAN, the IP is assigned through DHCP.
I read one more time the explanation of @matheus.tx in this other topic related to issues of ApolloX in a Virtual Machine.

If I change the 192.168.0.0./24 by the IP range of my physical network interface (10.3.1.0/24), I can see the Verdin.

Is it possible that the “default network interface” is not the best approach in WSL?
If I run route, I get

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         my_pc_name      0.0.0.0         UG    0      0        0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.26.128.0    0.0.0.0         255.255.240.0   U     0      0        0 eth0

And cat /etc/resolv.conf returns

# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.26.128.1

where 172.26.128.1 is the ip of vEthernet (WSL) adapter in my Windows machine.

I suspect that ApolloX scanning feature in WSL needs some additional configuration to work (if possible).
What do you think @lucas_a.tx and @matheus.tx?

Hey @vix

for the WSL we list the interfaces from Windows side, because as you already know the interface that we have on WSL is only the vEthernet one.

Could you please in a WSL terminal run the follow?

ipconfig.exe | grep 'IPv4 Address. . . . . . . . . . . :'

Yeah I know, sound weird because is a Windows command, but WSL also make these weird integrations between Windows and Linux, and it’s should work.

This should return the IP addresses from the Windows side and then we use them as base, x.x.x.0/24, to make the search for network devices.

Let me know the return.

Best Regards,

Hi @matheus.tx

this is the return


   IPv4 Address. . . . . . . . . . . : 172.18.0.1
   IPv4 Address. . . . . . . . . . . : 192.168.56.1
   IPv4 Address. . . . . . . . . . . : 10.1.2.50
   IPv4 Address. . . . . . . . . . . : 10.10.10.79
   IPv4 Address. . . . . . . . . . . : 192.168.0.41
   IPv4 Address. . . . . . . . . . . : 192.168.1.41
   IPv4 Address. . . . . . . . . . . : 192.168.3.79
   IPv4 Address. . . . . . . . . . . : 192.168.20.1
   IPv4 Address. . . . . . . . . . . : 192.168.78.122
   IPv4 Address. . . . . . . . . . . : 172.27.208.1

But now I understood a little bit more what happens.
You wrote that you use a base x.x.x.0/24 but my Subnet masks are

   Subnet mask . . . . . . . . . . . . . : 255.255.240.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.0.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.255.0
   Subnet mask . . . . . . . . . . . . . : 255.255.240.0

And the Verdin is connected to the company LAN (IPv4 10.1.2.50 - mask 255.255.0.0).
I think that this explains what happens.
Not sure how easy is taking into account the proper mask.
Let me know if I can do something.

1 Like

Thanks a lot for the report.
I added this to our backlog, to get subnet mask for all the interfaces listed.
I will notify you here when we have a new version with this fix.

Best Regards,

1 Like

Hi @matheus.tx
I imagine you have no news on this topic, but in the meanwhile I’ve just found the same issue, but the mask is 255.255.255.0. So I’m not sure on what is the real origin fo this issue.
I try to explain what I did:

  • I use WSL on Windows 10
  • as suggested by @henrique.tx in a call, I enabled Internet Connection Sharing to give internet connection to the Verdin SoM
  • Internet Connection Sharing works as expected (I can ping google from the SoM through the internet connection given by my laptop)
  • ipconfig.exe from WSL returns 192.168.137.1 (mask 255.255.255.0) for the ethernet interface that connects my laptop to the Verdin SoM
  • ApolloX cannot see the Verdin, but if I “Manually Connect Device” to 192.168.137.1, everything is ok

Does this help you?

1 Like

Hi @vix

unfortunately, I don’t have any news about this feature. The team is focused now on the first MVP stable release, which should be next week. We believe this issue is not blocking, since there are other ways to connect directly to the board. We’ll check back on that in the next sprint.

By the way, thanks for the new information, indeed is relevant to us.

Best Regards,

Hey @vix

in the latest v2.1.1 we shipped a bunch of improvements on the device detection. Could you check if this works for you?

BR,

Hi @matheus.tx
the first release that works for me is v2.4.2