Render node failing all RemoteControl connection attempts

[PZ_Josh]

Hey guys,
We updated Deadline and have been having all sorts of network communication issues on a few machines.
It may be a combination of Windows updates happening at same time but most of the other issues have been resolved except on this one machine.

I am getting connection failures when trying to remotely start, restart, and stop the Slaves on this one node.
It throws the error:
“A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond (ip address):17000”

It will accept remote control commands to itself from Monitor, but any attempt to send remote control commands to it from other machines just throw the same error.
Have tried turning off firewall but makes no difference to Deadline communications. Only behaviour that changes when turning off firewall is the ability to ping the machine while firewall is off.
Have tried a few basic things like flushing dns and resetting network settings but nothing yet has made a difference.
So far only solution is to log in via RemoteDesktop to manually start/stop slaves on that machine, which isnt ideal.
Any ideas or things to try that maybe I haven’t thought of yet.

Cheer,
Josh

[eamsler]

Is the IP address 255.255.255.255? If that’s the case, it might in fact be DNS. Workaround here:

Troubleshooter's Corner - The machine may not exist on the network

Deadline has always made the assumption that it could connect to Slaves from the Monitor using DNS. Normally, this is a great idea because a machine’s IP address could change, but the host name is fairly consistent. The problem comes in when you’re working across platforms that do not have compatible multicast DNS mechanisms such as macOS and Windows. You’ll end up seeing errors with remote commands: could not resolve slave name (MyMachine2) to IP address. The machine may not exist on the netw…

It definitely does sound like a firewall issue though, especially given that it works locally. Usually we’d recommend using a simple tool like telnet just to see if you can connect to port 17000 via TCP. Because that tool’s not installed on most system’s these days it’s a bit of a pain. I did find an example of doing the same with PuTTY that is worth a look. Essentially, if PuTTY just sits there doing nothing, TCP is working.