I want to use a ctrlX Core Virtual to exchange data with another device in a local network. I have the following setup:
- Windows PC with ctrlX Works running a virtual control (network mode = Network Adapter). IP address of Windows PC is 192.168.1.10.
- Device is in the same network and has the IP address 192.168.1.11.
Per default, the virtual control is not connect to the local network as it comes with an "unconnected" virtual network adapter (TAP-Windows Adapter). In this state it's not possible to, e.g. ping the device x.x.x.11 from the virtual control. My goal is to at least be able to ping the device from the virtual control.
My guess is that I have to give the virtual control a static IP address in the same network, e.g. 192.168.1.12 + maybe bridge one of the TAP adapters (e.g. "VirtualControl-DE-AD-BE-00-00-03") to the physical Ethernet adapter of the Windows PC.
I'm not sure if this is the right approach. Therefore, I would be glad if someone could point me into the right direction.
Solved! Go to Solution.
I think I just figured out the solution myself:
Further remark: QEMU is used for virtualization; If I'm not mistaken, ICMP/"ping" does not work for testing*. Imho the best test is to use another PC, enter the IP address of the virtual control into a browser, and then check whether the ctrlX Core Virtual login screen appears.
*"if you are using the (default) SLiRP user networking, then ping (ICMP) will not work, though TCP and UDP will. Don't try to use ping to test your QEMU network configuration! " Source: https://wiki.qemu.org/Documentation/Networking
I'm not very familar with QEMU, therefore, I might be wrong.
first of all thanks for your effort, thats a nice workaround.
We know about this behavior and a solution is planned for later this year.
Has there been any update here? I am trying to establish OPC UA connection between ctrlX Virtual Core as client and a physical core as the server.
Depending on how your ctrlX COREvirtual is running. In port forwarding mode you can, from ctrlX WORKS version 1.12 on, open it for external access:
In the network setting also routes and gateways can be set:
I am confused what to do exactly using the most recent virtual core 1.12.9
I am running the virtual core in my Windows virtual machine which has direct internet access via a BTIA router.
I have configurred external access and see this in ctrlX works:
since I use port forwarding I do not get a virtual TAp adapter to bridge.
I did assign a fixed IP address to my core in my local network range and the default gateway 192.168.88.1 but this does not help. I can ping this fixed IP address from the SSH shell of the virtual core. I cannot ping the host IP address which is in the same subnet
What am I missing here?
I assume you need to add the route in the Virtual ctrlX core if you want connectivity from your local network into the virtual core. Is this the right assumtion so routing 10.0.2.0/24 via gateway 10.0.2.2 Correct?
in the "Port forwarding" mode QEMU is doing automatically a NAT.
However ping is not working by default, see this link, chapter "User Networking (SLIRP). https://wiki.qemu.org/Documentation/Networking
To test your internet connecting you can use my Node-RED test flow, doing a http request and connecting to a public MQTT Broker.
See attached zip file.
@TheCodeCaptain Thank you for your answer. Good to know the core is connected trough NAT I did not realize this but I guess it is obvious since we need port forwarding. As said I can connect to the core with the host IP address from the host (192.168.88.154) This works both for the web-interface and ssh using the fowarded ports. However if I try to connect to the core from another device in my network using this same IP address I get no response. I suspect this is the firwall at my IDE WIn10 VM 😣
Hover if I try to connect to another server on my network through ssh from the Virtual core controller shell it also does not work With pure NAT I do expect this works???
I tried you nodered flow too and it does not connect to the public server so it still seems there is a problem.
Would it be better to use the Tap Adapter setting?
Sorry by bad, I still had a fixed IP configured in my network range for the Virtula core. After removing the inside out does work so I can connct for the virtual core shell to a local server on my network. Also the Node-Red flow does connect to the public MQTT server so indeed Internet connectivity is in place