DCP 30 Failure

[pattbo]

After being powered off due to power problems I have a DCP 30 that is not recognized by the control unit. I powered off the whole stack (IP 403 running 2.0.18), brought up the modules and then the control unit and that did not help.

I then swapped the cable between the bad DCP 30 and a good DCP 30. The problem did not follow the cable. The module seems to be bad.

I am running 4.0.16 firmware on the modules and am not sure what else to do to see this module again. I have power to the module, it blinks like it is resetting but the control unit can not see it.

Suggestions?

 

[IPGuru]

you could try using the DTE port to erase the firmware from the DCP module to try to force a reload, it is basicaly the same procedure as erasing system firmware (check my faq for full details).

1 make sure you have a copy of the config
2 make sure your manager pc has a fixed IP address on the same subnet as the control unit
3 connect to the dte port of the module, 38400 Baud no parity 1 stop ( I also recommend NO flow control)
4 reboot the moduel whyle pressing esc to enter the monitor
5 type AT-X
6 start manager & set preferences to 255.255.255.255
7 reboot both module & IPO
8 Hope

if this does not work you will have o option other than replace the unit

 

[pattbo]

OK so I talked the onsite rep through the Hyperterm connection and then erasing the firmware (AT-X).

I am convinced this worked since it boots to just a "DCP 8/16 Loader 1.0" prompt and does not list out everything else like it did before. It then starts TFTP Polling.

We tried using manager and watching the tftp log and it says sending nadcp-16.bin and file size, then eventually says TFTP timeout. The file exists in the right directory. I tried another TFTP client and it reported ACK timeouts and failed as well.

I tried this from the original Manager system, and then from the 192.168.42.2 address recommended in the job aid. Both see the TFTP file request but then neither seem to send the file.

Has anyone seen this. For the record, we only dropped the firmware on the DCP 30 we are having problems with. We have not tried, since I don't have the impression it was necessary to, wiping the control unit as well. It still has a 10.x.x.x address and a live config working on the other modules (another dcp.

One more thing, monitor shows that it is tftping dcp-16.bin and not the nadcp-16.bin. Not sure why monitor sees it that way, TFTP was showing the right file (right as in available/existing) being requested.

Any suggestions from this point?

Thanks as always.

Pat

 

[Morrack]

Ensure your Manager is set to 255.255.255.255 in the preferences, and that the manager PC is on the same local subnet as the IPO.

Peter

 

[pattbo]

Yes, from a same subnet 10.x.x.x workstation with preferences set to 255.255.255.255 it sees the TFTP File get request, says it is sending, and then says it fails, over and over again.

 

[Morrack]

With the copy of Manager you are using as the TFTP server in question set to 255.255.255.255, you are able to open the config for the IPO?

If so, last thing I can think of before declaring the module pooched is to connect a laptop (or whatever) running manager directly into the hub on the 403 and see what that does. You could also run monitor, and clear all settings on all tabs, then turn on everything on the interface tab - use it as a packet sniffer to look for clues as to why the TFTP packets aren't getting to the DS30 (or it's acknowledgements aren't getting back to the TFTP server).

Peter

 

[IPGuru]

the name change looks suspicious to me, check you have all the bin files in the working directory.

the file should be Nadcp16.bin
if it is trying to download dcp16.bin you could try renaming it, but this is a last resort

 

[pattbo]

Morrack - Yes with the manager system in question set to 255.255.255.255 we are able to open the IPO config.

I have tried another manager system (laptop) plugged directly into the IPO and preference set to 255.255.255.255 and that did not work.

I just checked your Monitor suggestion. I am getting multiple replys for the TFTP broadcast saying file does not exist. The systems replying are not running manager.

Currently trying to find a window to remove the IPO from the production LAN and plug manager directly into the IPO to see if TFTP will be succesful when the extra TFTP "File Not found" replies are removed.


IPGuru - I made a copy of the file nadcp-16.bin and renamed it dcp-16.bin to match what monitor said. So I had both files (file names) in the working directory, and that did not work.


I'll remove the IPO from the production LAN and update you when I am done.

 

[IPGuru]

i think you could be correct in isloating the IPO I have 1 site that will always fail to upgrade if it is not isolated.
so far we have not identified what is causing the interferance.

 

[pattbo]

No luck. It didn't chagne the TFTP results once we pulled the IPO and manager off of the production network.

Waiting for Avaya.

Thanks everyone.

 

[Nokarro]

Maybe it is a stupid question but I had many people overlooking it ...

Do you have Manager 4.1(15) ? Is the Enabled box ticked in BootP ?

that was my 5 cents ...

Len

 

[pattbo]

Yes it was checked. Thanks for the suggestion.

 

[pattbo]

Avaya Swapped it. I was not onsite and did not get to speak to the tech. Anti-climatic but fixed.

Thanks all.