cancel
Showing results for 
Search instead for 
Did you mean: 
SOLVED

Communication between ctrlX CORE Virtual and external device in same network

Communication between ctrlX CORE Virtual and external device in same network

schoeffler
Member

Hi,

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.

8 REPLIES 8

schoeffler
Member

I think I just figured out the solution myself:

  1. Start virtual control with ctrlX Works and configure the IP address + gateway in "settings->connectivity"
  2. Shutdown virtual control and close ctrlX Works (important!)
  3. Go to your Windows network adapter options
  4. Bridge your Ethernet connection to the virtual TAP of ctrlX Core virtual (in my case VirtualControl-DE-AD-BE-00-00-01)
    1. Remark: ctrlX Works should be closed, as it (imho) tries to create a new TAP every time a virtual machine is started; This does interfere with the bridging mechanism of windows (if not intended -- possible bug?)
  5. Since we can not use ctrlX Works to start the virtual machine, we have to do it manually. You find the corresponding .bat file in your ProgramData
    1. In my case, the "fobjft4d.user.qcow2.tap.start.bat" (folder: C:\ProgramData\Rexroth\ctrlX WORKS\virtual-controls\images\1.2.3) starts a ctrlX Core Virtual. If started manually, a new virtual TAP is not recreated --> everything works fine
  6. If your network settings are entered correctly, you should be able to access the virtual control from another PC/device in the same network and the other way around

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.

 

Hi Schoeffler,

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.

Your CodeCaptain

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.

CodeShepherd
Community Moderator
Community Moderator

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:

ctrlX COREvirtual external accessctrlX COREvirtual external access

In the network setting also routes and gateways can be set:

ctrlX CORE WebUI routing settingctrlX CORE WebUI routing setting

Marc_Smaak
Long-established Member

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:

Marc_Smaak_0-1666703221091.png

I can access the webinterface via https://localhost:8443 and https://192.168.88.154:8443 however what I need is connectivity from the virtual core to atleast my local network.

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?

Hi Marc_Smaak,

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_0-1666713981067.png

 

Marc_Smaak
Long-established Member

@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?

Marc_Smaak
Long-established Member

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

Icon--AD-black-48x48Icon--address-consumer-data-black-48x48Icon--appointment-black-48x48Icon--back-left-black-48x48Icon--calendar-black-48x48Icon--center-alignedIcon--Checkbox-checkIcon--clock-black-48x48Icon--close-black-48x48Icon--compare-black-48x48Icon--confirmation-black-48x48Icon--dealer-details-black-48x48Icon--delete-black-48x48Icon--delivery-black-48x48Icon--down-black-48x48Icon--download-black-48x48Ic-OverlayAlertIcon--externallink-black-48x48Icon-Filledforward-right_adjustedIcon--grid-view-black-48x48IC_gd_Check-Circle170821_Icons_Community170823_Bosch_Icons170823_Bosch_Icons170821_Icons_CommunityIC-logout170821_Icons_Community170825_Bosch_Icons170821_Icons_CommunityIC-shopping-cart2170821_Icons_CommunityIC-upIC_UserIcon--imageIcon--info-i-black-48x48Icon--left-alignedIcon--Less-minimize-black-48x48Icon-FilledIcon--List-Check-grennIcon--List-Check-blackIcon--List-Cross-blackIcon--list-view-mobile-black-48x48Icon--list-view-black-48x48Icon--More-Maximize-black-48x48Icon--my-product-black-48x48Icon--newsletter-black-48x48Icon--payment-black-48x48Icon--print-black-48x48Icon--promotion-black-48x48Icon--registration-black-48x48Icon--Reset-black-48x48Icon--right-alignedshare-circle1Icon--share-black-48x48Icon--shopping-bag-black-48x48Icon-shopping-cartIcon--start-play-black-48x48Icon--store-locator-black-48x48Ic-OverlayAlertIcon--summary-black-48x48tumblrIcon-FilledvineIc-OverlayAlertwhishlist