We have configured our element to listen on a smart serial port, but it does not seem to be receiving data. The device that posts to this port has errors of "No connection could be made because the target machine actively refused it".
Looking on the machine itself, I can see that the port is not open (using Resource Monitor), but all 5 instances of SLPort are running and no apparent errors in the logs.
Where would you start to investigate? Please note that it will be very challenging to install wireshark so any other suggested tips would be appreciated (but if this is the only way then so be it).
Recently upgraded from DM9.6.10 to DM10.1 CU2 (unsure if related, but other environments do not have the above issue)
Investigation showed the port was in use by another non-DataMiner process running on that server.
FYI, for future references:
SLPort logs the following on debug level 1 when it can’t bind to the port:
“Finished connect thread. bind failed.10048”
Where error code 10048 translates to WSAEADDRINUSE. This error occurs if an application attempts to bind a socket to an IP address/port that has already been used for an existing socket, or a socket that was not closed properly, or one that is still in the process of closing.
Hi,
First place to look in these cases is the StreamViewer.
This will show you all the incoming data.
In case you see data and you don't see that represented into your displayed parameters it means that the received data does not correspond with the defined expected response.
You can use the element log > Debug level on Log Everything. Using this level you should be able to see what responses do not match.
As an extra Tip:
Smart-serial integrations usually find issues by defining header or trailer params that are not used. It is often forgotten that SLPort will take these definition into account even when it's not part of a Response definition. My personal reminder for this is to see these params as indications to SLPort to "pay attention to these keywords in the big pile of data it will/can receive" A bit like someone would say your name in a conversation you are not even part of.
Hi Mieke. Thanks for the suggestions.
As it turns out, we see nothing on StreamViewer, even where this is working on our other agents. Even after raising the logging to 6-6-6.
I’ve just come from the incident being resolved so will add an edit on my original question with how it was (embarrassingly) resolved, but thanks for the tips
Hi Jack, Is this specific port opened in firewall?
Hi Joey. Yes, the port is open on this agent. The communication is going via localhost
In this case you configured “localhost” as IP Address when creating your element?
In this case, we use any – but we actually used a similar step to this to help diagnose. Thank you!
Yes, for fuller detail for someone finding this later, there was a confusion by another team between the netstat report of active ports and the Resource Monitor’s list of listening ports. This additional application had an established connection on this port range (hence not appearing as listening). Setting the smart serial temporarily to a different port showed that it was then listening without issue. We were confused for a long time as there was nothing suggesting that we had failed to grab the port (even SLDataMiner suggested the log had been successfully claimed).
Lessons learned:
1) Netstat > Resource Monitor
2) Add debug messages to logs where possible to confirm the acquisition of ports
3) Make sure applications in general use reserved ports only rather taking any old thing!