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).
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.
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).
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.castello 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:
# generateResolvConf = false
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.castello?
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.
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
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.