PCNS not talking to UPSs

[Anonymous user]

Hi,

I have two UPS's at the moment that I have got MNCs for. They are Smart-UPS 3000's. I have installed the PCNS software on one test server and have been trying to get it to shutdown when I pull the power out of one of the UPSs. However, the management station will not communicate with the Management Cards.

I can ping the cards from the server and I can telnet to the server on port 3052 form another pc. I can't think what else could be causing the issue. Any ideas?

Oh, there is no firewall turned on on the server which is running Server 2003 Std.

Thanks for any help.

[BillP]

you definitely want to make sure that ports 80 and 3052 as well as 6547 (if using PCNS v 2.2.3) are open for TCP and UDP as well as incoming and outgoing connections. I realize you said you didnt have a firewall turned on but i have run into issues where firewall rules still get pushed out under group policy. also, you want to make sure the admin user name and password of the NMC is the same as what you are putting for the PCNS installations.

are the PCNS clients timing out when you are installing where they arent registering? (at the end of the installation, PCNS goes out and tries to register with the PCNS client and will tell you that registration is successful or not) or is it installing successfully and registering, then you are accessing PCNS and it says in the event log Powerchute cannot communicate with the network management card?

do you have a screenshot of the error you are getting as well just to confirm?

[BillP]

Hi,

Sorry for the delay in getting back to you. I have tried connecting to the NMC and server via telnet on the ports specified and I am able to make a connection so something is at least listening. I have attached screenshots of various bits and pieces for you to see exactly what I mean.

I have tried installing the latest firmware on one UPS but this seems to make no difference. I downloaded the latest pcns 2.2.3? but this would not install, it gave a timeout when trying to talk to the UPSs.

Any further ideas?


Thanks,

Chris

[BillP]

hi chris. since the PCNS client is registering successfully, it makes me think there is something going on with UDP port 3052 (incoming and outgoing). if you can guarantee the port is open by some method, then the only other things that would be happening are that someone is changing the authentication phrase either on the NMC or on the PCNS side, or the administrator user name has been changed. it needs to be the same on the card and PCNS installation.

dual network cards may also cause an issue like this. you could try changing your binding order if this is a setup you have. PCNS uses the first NMC in the binding order. This is under Network Connections->Advanced Menu at the top of the window->Advanced Settings->Adapters and Bindings.

[BillP]

Hi,

We do have our servers connected with two NICs in a team. Only the team i/f has any bindings for TCP/IP so this is the only interface that will be used.

I know that I can set the port that is used by the NMC, is it possible to change the port used by PCNS? Perhaps something else has grabbed 3052 although the server shows as listening on that port (*:* for UDP) in a netstat.

I'm sure the auth strings are correct as I have reset them, should I reboot the NMC after doing this or would it take the updated details whilst it is running?

Cheers,

Chris

[BillP]

i believe it should update automatically. you can log back out and log back in to make sure changes take effect. if the card needs to reboot, it will when you log out. you can change the port that PCNS runs on but it isnt recommended. [the method is mentioned in this article|http://nam-en.apc.com/cgi-bin/nam_en.cfg/php/enduser/std_adp.php?p_faqid=651]

[Anonymous user]

Also, just to be sure the cards in the UPS have a default gateway configured? This is a requirement.

If changing the subnet and re-installing PCNS 223 did not fix I am leaning towards the NIC teaming configuration. Obviously, the easiest way to determine this would be to remove the teaming setup and attempt this installation with one NIC. You would know within 2 minutes if communication were to fail. I don't know the consequences of you breaking the team (reboot required? server downtime etc) so I am not sure how feasible this option is for you. Either way, I assume you'd want this to work with the teaming setup to keep your redundancy or whatever your reasoning for the teaming. Can you provide more information about this teaming setup to possibly determine if there are any changes that can be made?

Message was edited by: Grenade

[BillP]

Hi,

I have run a network trace (see attached for results image).

I noticed there was an issue with the NetBIOS name query (even though it is using the correct IP addresses) so I tried adding the UPS's host name into the servers hosts file. This stopped this error from occuring (see second trace image). This has caused a change in the event logs output in PCNS (see image) as the app is resolving the IP to the hostname (some is blurred out). I have not changed or added the second UPS to the host file. I have also tried adding entries to the lmhosts file but this has not helped in any way.

Does this offer any light into what is going on?

Thanks,

Chris

[BillP]

Hi,

You are quite correct.

Have made the changes to the NMCs but no difference to result. Have uninstalled the app and removed the server ip as a client on the UPSs, then reinstalled. All appears to be ok install-wise but I'm still getting the same results in the PCNS event log.

Thanks,

Chris

[BillP]

Hi,

Sorry for the dealy in getting back.

Well, I started again from scratch, removed the software, re-entered the config on the NMCs and guess what, all is working as you would expect.

I have no idea what was wrong but I guess I had not put some detail in incorrectly somewhere.

Sorry for the fuss and thanks for all your help.


Chris

[Anonymous user · Accepted solution]

From looking at one of your wireshark captures, it looks like you may have an incorrect subnet mask configured on the card. The broadcast is being sent to 192.255.255.255 which is indicative of Class A mask. Looking at the rest of your IP addressing scheme, it seems you have a 255.255.0.0 mask. Can you verify if the mask is correct on the cards?