Cannot connect to ctrlx datalayer from Linux host

[pjbonestroo]

Question: How can I connect to a ctrlx COREvirtual (running on a Windows guest), from a Linux host, using python package ctrlx-datalayer?

I have a Linux host and a Windows 10 Guest (using VirtualBox). Inside the Guest I succesfully installed ctrlx Works, PLC, etc. I added a VirtualControl (ctrlx COREvirtual) and it is online, including port forwarding, also to external. I disabled the firewall on my Guest.

From my (Linux) host, I am able to browse to the VirtualControl, using the IP from my Guest: https://192.168.1.104:8443. See screenshot attached.

I installed the python package 'ctrlx-datalayer', and also installed the `ctrlx-datalayer-2.2.7.deb` from https://github.com/boschrexroth/ctrlx-automation-sdk/releases.

I copied the script from https://github.com/boschrexroth/ctrlx-automation-sdk/tree/main/samples-python/datalayer.client.brows... but (adapting) and running it I got the error:

ERROR Connecting tcp://boschrexroth:boschrexroth@192.168.1.104?sslport=8443 failed.

What am I doing wrong? I think my approach is valid, right? Any suggestion would be great.

[CodeShepherd]

The Main question is how is the network settings of your host and virtual OS? As your issue is related to general network communication.

Please have a look to "Communicate between a ctrlX COREvirtual and other applications [DOCU]" if it can help you.

When I am using VirtualBox I normally start the ctrlX COREvirtual in network adapter mode on host OS and add a bridge the adapter to my virtual OS.

[pjbonestroo]

Thanks a lot. I will study the documentation and maybe come back here soon.

Regarding your comment: the difference is that I (must) start the ctrlX COREvirtual on guest OS. In VirtualBox I choose for "Bridged adapter" so that I indeed can reach my guest from the host. I can reach it using the browser, but not using the ctrlx-datalayer package/library.

[pjbonestroo]

As far as I can see my network settings of host and virtual OS are correct, since I can browse from my host to the COREvirtual on my guest.

So the question is: why can't the ctrlx-datalayer connect to it? It uses the same port (8443) right? Or is this a non-intended use of the library, since I use it on my own Linux installation, without QEMU/SDK, etc?

Is there a way to get a more specific error when the dataclient cannot be created?

[CodeShepherd]

Could you confirm your current configuration is:

Ubuntu20 OS (as there are many different Linux) -> VirtualBox running Windows 10 -> QEMU running ctrlX COREvirtual 1.20.x in port forwarding mode

Possible is to open a browser on Ubuntu OS and reach web UI of ctrlX COREvirtual via "<IP of guest OS>:<forwarded ssl port>"

Could you add your code here or at least the connection command parts so we can have a look to it? You can also send me a private message if code should not be shared in the forum.

[pjbonestroo]

Yes, I can confirm the configuration as you describe. My host is a Xubuntu installation, which is Ubuntu 22:

> cat /etc/os-release
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"

Summary: Ubuntu OS (see above) -> VirtualBox running Windows 10 Pro 64bit -> ctrlX WORKS (1.12.10) running QEMU ctrlx COREvirtual

It is indeed possible to open browser on Ubuntu OS and reach web UI of ctrlX COREvirtual via ip "<IP of guest OS>:<forwarded ssl port>"

The code running on Ubuntu is basically the same as https://github.com/boschrexroth/ctrlx-automation-sdk/blob/main/samples-python/datalayer.client.brows...

I made the changes for the IP-address and port, see `code-main.png`

While thinking about it, could it be related to the TLS certificate needed for the connection. In the browser, I continue by accepting an unsafe / unsighed certificate. How does ctrlx-datalayer lib handle this?

[CodeShepherd]

The certificates are not unsafe/unsigned. The communication is encrypted and the certificate is self signed by the ctrlX CORE. The browser in standard shows tells you that this kind of certificates could be unsafe. This is a web server mechanism that data layer is not using. So certificate handling is not necessary.

Please keep in mind that ctrlX CORE 1.20 is based on Ubuntu core20 and also the SDK and wheels for this version are needed to fit to the corresponding interfaces.

Which version of the Python wheel did you install? And which version of the SDK did you use?

[pjbonestroo]

Thanks for your ongoing support on this!

On my Linux host I only installed the python wheel for ctrlx-datalayer and the binary ctrlx-datalayer-2.2.7.deb. I did not install any additional things like the SDK.

The python wheel is installed in a python virtual environment by 'pip install ctrlx-datalayer' which gave me these versions:

pip install ctrlx-datalayer
Requirement already satisfied: ctrlx-datalayer in ./pyenv/lib/python3.10/site-packages (3.0.1)
Requirement already satisfied: ctrlx-fbs in ./pyenv/lib/python3.10/site-packages (from ctrlx-datalayer) (2.0.0)
Requirement already satisfied: flatbuffers in ./pyenv/lib/python3.10/site-packages (from ctrlx-datalayer) (23.5.26)

About certificates: does the datalayer not use the certificate (meaning that the traffic is not encrypted) or does it use the certificate without complaining about unsafety (like the browser does)?

I'm thinking about doing some network traffic analysis using Wireshark or something. Maybe I can find out what is going wrong.

[pjbonestroo]

As I already mentioned in my last reply, I now sniff the network traffic in order to get some insights.

On my Linux host I captured the network traffic between host (192.168.1.41) and Windows guest (192.168.1.104). The Windows guest has port forwarding to the COREvirtual. See the attached printscreen from wireshark.

Before starting capturing I tested if the browser connection still worked. So I navigated to 192.168.1.104:8443 using the browser, and I can confirm this still works.

As you can see in the printscreen there is communication between host and guest, and using TLSv1.3 the "Client hello"  and "Server hello"  messages are visisble. But, at some point I see a reset, and again the "Client hello" and "Server hello" messages. Note that all this traffic takes place in lets say less than a (few) second(s).

I'm not an expert at this, but someone who knows about this protocol and how the ctrlx-datalayer library handles this, might be able te understand and see the problem.

[CodeShepherd]

As we do not have this setup we need some time to do tests for this.

[pjbonestroo]

Hereby I add an extra wireshark printscreen, only showing 9 packets, which makes it easier to analyze.

Up to packet 5 I do not see anything strange. With packet 4 the client (linux host, 192.168.1.41, python script using ctrlx-datalayer) says hello, and with packet 5 the server (COREvirtual on windows guest) responds with an ACK.

Packet 6 I do not understand, as the clients sends an FIN ACK. But maybe this is normal, as I do not have enough knowledge about it.

Packet 7 and 8 give me some hope, as the server (COREvirtual) sends an 'Server hello' message.

But then packet 9 shows that the client sends a RST, which means the connection is resetted, I guess.

[pjbonestroo · Accepted solution]

My problem is solved! Today I installed version ctrlx WORKS 1.20 (instead of 1.12). Now it all works well 🙂

My python script running from Linux host connects to the COREvirtual and browses the datalayer successfully.

Since I downloaded ctrlX WORKS from the https://www.boschrexroth.com/nl/nl/ ... I did not see version 1.20! But someone gave me the link to https://www.boschrexroth.com/de/de/ ... and there also the 1.20 version is shown. So the nl site is not updated I guess, at moment of writing.

Thanks a lot for all your support!

[CodeShepherd]

We are working on the missing files on the collaboration room.

[CodeShepherd]

All files should now be available in the collaboration room for not German languages.