That specific message comes from a successful TCP connect to the IP address and port shown in the message. Connecting to one of several TCP ports is one of the tests MCTB uses to check the status of the controllers. Note, this test is deferred in version 2.4.0, and only conducted of all other conditions suggest a possible CFOD situation. This greatly speeds up the normal polling cycle, reduces OS resource consumption, and avoids a TCP port exhaustion issue on Windows platforms.
thanks abrian, sure, i've already install the latest version 2.4.0, i've some network problem on my cutomer site, so, do you have some details on how the TCP connect is detect ? to help me find what the problem is. The controller is down and TCP connet is true ...
I've seen this before. In the previous case there was a caching proxy, load balancer, or NAT/PAT gateway that was responding on behalf of the controller, even though the controller was actually down. Naturally, you want to avoid having anything between MCTB and the controllers that might cause these tests to behave incorrectly.
You can confirm this isn't an MCTB issue (which it really can't be, since all MCTB is doing is a TCP connect) by going to the MCTB host and running "telnet <IP> <port>" to confirm that the port still connects outside of MCTB. You might also be able to isolate the problem by doing a traceroute (or tracert on Windows), and then doing the telnet test above from a host in each of the networks indicated by the route, until you get a connection timeout. The problem would be at the boundry of that network and the previous one (working from the MCTB host inwards, towards the controller).
I'm not sure if there is anything in the actual MCTB host OS itself that might cause this behavior, but you might want to do the telnet from another host in the same network or even segment as the MCTB host to start.
Hope this helps. Let me know if you have more questions.
You can effectively remove port 80 checking by assigning that port to another acceptable port, such as one of the other two that are succeeding. Although this means that the test is redundent, it shouldn't be a problem, especially in MCTB version 2.4.0. Here's how to do that
Create a file 'mctb.properties' in the MCTB install directory
Insert the following line: WEB_PORT=445
This will change the web port to be the same as the CIFS port. So, you'll have two tests that execute against 445 and one against 2049 (NFS). Assuming both those ports are working normally, you should be ok.
Those properties allow you to assign laternate ports to use for the controller connection test. If you want to use NDMP instead of CIFS, you can assign that port to CIFS_PORT. It will just test a TCP connect, so the actual protocol on the port doesn't matter. You can't change the name, but you can assign any value.