In my long and fruitless search for a working UC560, (and having dragged an unsuspecting Dave Trad into
the morass as well, who has given unstintingly of his time and expertise!), thanks to Dave I had an internal phone network functional (well, 3 SIP phones...).
Was attempting to get a path to the router and following reboot got this message.
Went through the reset password routine using CLI (well, when CCA just leaves, what on earth are you supposed to do???); but no change - I was only resetting the Priv 15 password
Given there was no attempt to touch any aspect of security, apart from removing NAT and Firewall (behind a router, OK?)
I have no idea, what possessed the unprinatable box to lose whatever credential it need to "authenticate via TelNet".
Has anyone seen this and/or has a suggestion how to retrieve the situation - apart from formatting the flash cards and starting all over yet again.
My 3 SPA phones all talk nicely to each other still... just CCA wont talk to me.
I have a gut feeling as to what the problem is, but I think it is best if I login again remotely and show you what it is so you can be familiar with these types of problems.
Let me know when you are free for a session and I'll help you out with it, we can post results once it is resolved for the benefit of others.
Posted from my mobile device.
Well after about 3 hours of debugging and fault finding the system, I managed to get it back to partial life, after about 15 attempts to get it to accept the default config file, it turns out the CUE is in a failed state and remains at boot loader prompt status.
For quite a long time the system would not comitt the default cfg file to NVRAM (CME not CUE), it took having to delete the NVRAM to blank status and then writing the file to startup after a cold reboot to get it to accept the file (On the 15th attempt I must add).... Never seen this happen before so I was a little baffled at first.... But then it is not often you see a machine in a bad state like this one was
So now I am a little stuck with this issue, I was going to setup a TFTP sevrer on one of the desktops connected to the UC and try and upload a new image, using the boot diag loader command, but I am not sure if this is a physical hardware fault or if it is a typical generalized error.
bl_boot_cf_diag_cmd fatload ide 0:1 0x1000000 cue-installer.uc5184.108.40.206
** Unable to read "cue-installer.uc5220.127.116.11" from ide 0:1 **
Failed to load diag image from CF using FAT filesystem, trying reiserfs.
** Bad Reisefs partition or disk - ide 0:1 **
Failed to load diag image from CF.
So Rob has now been advised to log a SBS case (assuming the NFR kit was ordered with one) and have them resolve it, worst case scenario if no support is provided on this system I will resolve it via CLI but I really do fear it is a physical hardware fault.
Thoughts and suggestions regarding the above error is much appreciated.
Please contact SBS and provide them with the UC560 serial number, this starts with FHK and you can see this on the CLI if you type ROUTER# sh version
I think it is fair to say I have hit a cross roads on this, and the best path to take is to ensure that support review this issue and if it is a physical problem the system gets RMA'ed, if it is not a physical hardware issue and you have no support contract then we will resume this and get the machine up and running one way or another
OK now back to those pestering kids, they always seem to get hungry and thirsty when I am on the phone
Enjoy the rest of your weekend.
I have run into this error a couple times on different UC500's. I look forward to hearing the cause and fix.
In one situation, the login screen never displayed for my UC520. I would have to login to my switch incorrectly, and then the login screen appeared for my UC520. I logged in correctly, and then correctly login the switch, and it worked. But everytime I opened CCA, I had to login incorrectly to the switch in order to have the option to login to my UC520. If I logged in correctly to the switch the first time, I got the error CCA Cannot authenticate using telnet.
Roberts situation was quite different to yours, basically the system would not reset to factory defaults, even when CCA did it the system would not default, in stead after the reload you were presented with a system that resembled that of a complete NVRAM wipe. It took quite a while to resolve this but it was done, also there was far too many different subnets running around and the configuration was originally muddled.
Robert is going through what I went through 5 years ago, breaking things whilst trying to learn and this is the best way to learn but ultimately the most frustrating and agonizing way
The whole system is undergoing a complete rebuild as we speak, however the CUE has become currupt so I am going to attempt to remotly resolve this although I have not quite been presented with this scenario before so it will be a first time attempt. I have upgraded and resolved other forms of CUE corruption, this was is just not the same as the 3.2 or 7 series, so a learning curve for me as well
With your issue you need to make sure the devices are all on the same subnets, and when using CCA you need to make sure you add the switch to site, also putting the user/pass the same on both appliances (Switch and UC) is positive side effects to it as well.
I have seen this several times in the last two months with my UC540. I can't guarantee that my issue is the same although the message given was the same. Each time I had to do a command line "reload" after which authentication was possible again. When I spoke to the SBCS engineers about it they said that the instabilty might be caused by the 7.4.8 firmware on my phones and that I should downgrade them to 7.4.7. Since doing that a week ago I haven't experinced the problem again.
At a guess I would say your issue was different, even though the error was the same its root cause would have most likely been different as I have seen your configuration and it was nothing like Rob's
However though the only way to tell would be to see the CCA logs, on Rob's CCA logs you could clearly see that CCA was confused with the IP address assignments and it had a major hissy fit (Which is fully understandable). Your configuration would not have produced the same background result, so if it happens again provide us the CCA logs 1 hour before the problem (If possible) and 1 hour after it or earlier, and we can see what was causing this issue.
I would create a new CCA site with just the UC5xx and confirm it works.
If this doesn't work, then check the VTY line settings. If it was CCA configured, they are set for you. But if it is a very old CCA, there was once an option to disable telnet, which might have done something there.
If it works, then put a static IP on the switch and add it to the site.
I use the same PW so that only one challenge comes, and it's usually the switch. If they are all the same, it should authenticate without subsequent prompts.
Technical Solutions Architect - Partner Sales, USA
7025 Kit Creek Road
Research Triangle Park
North Carolina, 27709