Hi Team,
after having upgraded a single DMA to 10.6 (CU2), we cannot connect with a certain Cube client anymore (while other clients would still connect).
ConnectionSettings.txt entry "type" is set to "type=GRPCConnection", Cube logon option "Connection type" is set to "Auto".
Exception messages as shown in the screenshot:
I have also played around with
- ConnectionSettings.txt entry "type" set to RemotingConnection
- together with <EnableDotNetRemoting>true</EnableDotNetRemoting> in MaintenanceSettings.xml and
- Cube logon option "Connection type" set accordingly to "Remoting"
but without any effect. Is it true that changing those settings (ConnectionsSettings.txt, MaintenanceSettings.xml) do not require a DMA restart?
The monitoring app under http://1.2.3.4/monitoring/ is shown up and working properly. And, by the way, an older Cube installation (based on 10.4) on the same client can also connect to its DMA.
Actually I assume some firewall/port issue for GRPC with this client, but I am wondering what hint I should give the IT team.
Can anyone give some advice?
Thanks and Regards
Jörg
Hi Jörg,
Regarding the bit about changing connectionsettings/maintenancesettings without a restart.
Connectionsettings can be changed without a DataMiner restart.
MaintenanceSettings, it depends on the setting. For the "EnableDotNetRemoting" a restart is needed. DataMiner only checks this during startup and configures the necessary endpoints based on this info. (Which may be part of the problem here).
That being said, the exception you are showing indicates that the connection does attempt to use the RemotingConnection, so it seems the cube settings and the connectionsettings are ok.
However "could not autodetect URI" indicates that the client fails to find the endpoint that is used for remoting. The autodetection tries to read this from http://<ip>/endpoints.txt (which is empty when DotNetRemoting is disabled). You can access this through a browser to see if it contains entries like http(s)://<ip>:8004/SLNetService.
If it is empty, it likely means there has been no restart since <EnableDotNetRemoting> was set to true, and this should be the first thing to try.
If this file contains entries like http(s)://<ip>:8004/SLNetService Then the DMA should be listening for RemotingConnections.
Things to check here:
- On the dma, run a "netstat -ano | findstr 8004" using an elevated command prompt: Check if there is anything listening on port 8004, and if it processID is the same as SLNet. If not, SLNet did not initialize the port correctly, which can be due to errors such as incorrect casing in the MaintenanceSettings, or check the /Logging/SLNet/StartupLog.txt for errors related to RemotingConnection.
- Open a powershell on the same host as the failing cube, and run "Test-NetConnection ip -port 8004" If the TCP test fails it likely means there is some firewall blocking the communication to port 8004.
- If both succeeds try opening a browser and surf to one of the endpoints mentioned in the endpoints.txt, the expected result is an exception stating "System.InvalidOperationException: Cannot accept GET requests.". If this is not the case, then again check the StartupLog for errors.
If all these succeed, then in theory RemotingConnection should work.