Dear members of the Dojo community,
A device is accessible on a certain IP address and port 111 via Telnet. An element on the DMA running a serial protocol sends commands but is not receiving commands. If you start a command prompt on the same server and type 'telnet <ip-address> 111', a dialogue box opens and as long as this dialogue box is open the element in Dataminer is not in time out anymore.
Is there a setting on this Dataminer System or specifically in the connector that has an impact on this behaviour?
Okay, I will try to investigate if I find a difference in the messages sent before or after opening the Telnet dialogue.
I made two Wireshark captures, one with the dialogue box open and one with the dialogue box closed to search for a difference. If I find a difference, I will share it here with the Dojo Community.
I added a finding of this comparison as a new answer below.
Hi,
The Wireshark capture shows that it constantly tries to setup the TCP connection (SYN messages) and immediately after that it received the ACK it is closing the connection again (FIN messages)
-First thing to investigate is the version that the DMA is running: does it include RN 33053 (from 10.3.0, 10.2.9 CU0 onwards)? And if so, does it also include RN34355 (from 10.3.0, 10.2.9 CU1 onwards)? I would suggest to increase the "Timeout of a single command" in the element wizard (e.g. 2000 as a test).
-Second thing to take into account is how the response definition looks like. If this only contains a "next param" type of parameter without header/trailer, or when the entering response does not match the expected response, it will constantly close the connection and reopen it again when sending a new command.
Regards,
Thank you for the input Laurens.
The DM version the problem occurs on is 10.2.0.0-12603-CU11. So I think this is prior to the release notes you mentioned. I tried increasing the time-out for a single command, without a different result.
The response definitions contain no header but all end with the LF trailer (0x0A).
Maybe enabling the SLPort logging could shed some more light on why the connection is being closed. To activate that logging, see https://docs.dataminer.services/user-guide/Reference/Skyline_DataMiner_Folder/More_information_on_certain_files_and_folders/PortLog_txt.html
I don’t immediately have an answer for this bizarre problem, but maybe you can also take a look with Wireshark if there is something you notice in the communication on the wire…