Hi Dojo,
Are there any "client side" settings that can prevent CUBE from using Eventing even when the related connection is established?
We've got a default connection set-up that works as expected through
.Net-Remoting>Eventing:
when connecting, the client ".4" can almost instantly start receiving element states and severities
We have the same connection settings configured also for another client, same subnet, same destination DMA, however for the ".7", even if the netstat shows that connections are established via ports of the high dynamic range, this other client keeps reverting to polling:
The Windows Defender settings are not accessible to the user - but given that the connection is "established" at the netstat output, what could be still causing the failback to polling?
Any application log that can give a hint in this specific case?
Thanks
Hi Alberto,
Filtering the netstat list on port 8004 may not give the full picture. When a client connects to the server using .NET Remoting, an outgoing TCP connection is established from that client to TCP port 8004 on the server. The clientside TCP port will be a randomly assigned port (blue). For the eventing callback channel, the client will start listening on a random TCP port and inform the server of the port number (red, port 63843). The server will then try to establish an outgoing TCP connection to that port, using a random port number on the server side, not 8004.
Incase there is a firewall on the client blocking the incoming callback connection, the client will fall back to polling mode over the outgoing blue connections.
You can better diagnose what is going on by filtering netstat on the process ID of Cube, e.g. netstat -anop tcp | find "16216". This should reveal the listening TCP port, waiting for incoming callback connections from the server, and whether any connection has been established on that port.
(or use Process Explorer like in my first screenshot)
According to https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/tcp-ip-port-exhaustion-troubleshooting it should indeed be [49152;65535].
It also states that you can look up the exact range on a certain computer with the following command:
netsh int ipv4 show dynamicport tcp
Or configure it manually with:
netsh int ipv4 set dynamicport tcp start=49000 num=15000
Bert, thank you so much! 500 points! ^^
This answer sets a much better picture indeed – from the high level drawing in the documentation, it seemed that only 8004 was used server-side, now I understand a random port will be picked even there: do you happen to know if there’s a defined range for the server-side port in Eventing?
I might be able to whitelist any port from the DMA, but just to be safe.
If it is the dynamic port range selected by Microsoft, am I correct that the range will generally depend on the OS version in use on the server?
Most of the new ones seem to rely on 49152-65535 (IANA recommended)