FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
Dear Community User! We have started the migration process.
This community is now in READ ONLY mode.
Read more: Important
information on the platform change.
05-27-2021 02:33 PM - edited 05-27-2021 02:39 PM
Hello
I have some issues with setting up TCP connections between an IPC and ctrlX Core. I want to create sample snaps as TCP Servers and Clients in C#, C++ and Python. I don’t want to access the datalayer, I only want a TCP connection sending and receiving data.
Therefore, I created a few samples to execute tests and got the following result: The connection with TCP works if the ctrlX is the TCP server. In the case that the ctrlX Core is the TCP client sending data to the host machine, it won’t work. I’ve tested having both the TCP Server and Client on the host machine as well as accessing the TCP Server (on host device) from another machine in the network without any problems. I’ve also looked up the network traffic with wireshark and saw that the package was sent to the host machine, but no answer is sent back, but with any other device, the answer will be sent. If the server isn’t started, the host machine sends an answer/ack so that the ctrlX Core logs that no one is listening on the socket. The ports on the host machine are opened.
I’ve also look at the firewall app on the ctrlX, but neither with or without the app installed and the ports opened, I cannot receive the messages of the TCP client on the ctrlX Core.
After I installed the TCP Client App on the ctrlX core, I get several errors of apparmor, but I don’t know how to solve them or if they are the reason why the example app doesn’t work. If I stop the server on the host machine, the application logs the expected socket exception (Connection timed out). After I start the server the network package is sent but no answer/ack is send back.
The TCP Client and Server are just the Microsoft Documentation examples (Server, Client) with changed ports and addresses. I’ve provided also screenshots of the ctrlX log, as well as the wireshark insights. I can provide the specific source code or other details if necessary.
The Problem is exactly the same with C++. Server on ctrlX works fine, but client on ctrlX with server on the host machine doesn’t work. I’ve also tested the case having the TCP server and client on the ctrlX with C# and C++, communicating with each other. In this case, there were no problems.
Sincerly,
Kai-Uwe
Solved! Go to Solution.
06-01-2021 11:24 AM
Hi KaiUwe,
can you also provide the snapcraft.yaml files? So we can reproduce the issue.
Did you face the same problems if you create the snaps with python for example?
Kind Regards
Johannes
06-01-2021 12:02 PM
Hi Johannes,
thank you for your answer. I've included the snapcraft files of the C++ and C# client. I've tested the C# Client also in devmode, but without success. Because the problem exists in both the C++ and the C# application, I've not tested the python example, yet.
Thank you for your help, if you need anything else just let me know.
Kind Regards
Kai-Uwe
06-02-2021 01:14 PM - edited 06-02-2021 01:15 PM
I've tested the Python example with the client on the ctrlX virtual and the server on the windows pc and got the same result. The client tries to establish a connection and as soon as the server is started the client is stuck in the connection method and sends only retransmissions. Started the python client on another machine and everything works perfectly.
06-15-2021 08:22 AM - edited 06-15-2021 08:25 AM
After checking on your code we got end of last week we could not reproduce the problem. We will start a live meeting for further investigations.
06-16-2021 01:42 PM
After a lot of tests and modification in the firewall, I found the problem. It was due to outdated firewall settings (probably created during the first tests). I had tested the snaps on a real ctrlx core and initially encountered the same problem, but was able to solve this in the firewall through appropriate settings, as discussed at yesterday's appointment. After taking a closer look at the firewall on my computer locally, I noticed that there were still outdated settings. After I deleted the old settings and adjusted the new ones according to the working example, the TCP server on the host device and the client on the ctrlX core (virtual) worked without problems.
If someone encounters same or similar problems, check your firewall settings. The following settings worked for me: Create an firewall inbound rule and change the protocol type (under protocols and ports) to TCP, set Local port to 13001 (or the one of your TCP server port) and leave remote port with all ports. Set the Remote IP Address (under Scope) to the IP Address of the ctrlx core (virtual) and specify the profiles (under Advanced) to private and public.