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
Hi, I just saw this (I am WfH) and I thought perhaps you could have a look at the DataMiner.xml Telnet tag in order to activate the Telnet interface. Check it out and see if this makes a difference.
This telnet feature of DataMiner has nothing to do with polling of devices, no need to activate this.
Thank you for the suggestion, Conan. This setting was not activated in Dataminer.xml. I edited the file and restarted Dataminer to sync. However, this did not fix the problem.
Thank you for the clarification, Bert. I did not know this.
By comparing the two Wireshark captures, I found a possible clue that might explain this strange behaviour.
With Telnet CMD closed, our 192.168.122.168 is sending from all different ports, ranging in this Wireshark capture from port 57089 to port 57138. With Telnet CMD Open, it also started with little variations, but when it started using source port 57023, it stuck with this port and the element was not in time-out anymore.
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…