IP403 reboots

[MisterLister]

i have an ipo403 on 2.1.15, and has been that way for over a year without any problems until now.

the avaya box reboots at different times of the day, and i have run out of possible tests to do.

i have
check with bt that the pri line is ok
check the cable between the ipo403 and the nte
replaced the ipo403 with a new 403
replaced the pri card with a card
confirmed there is no corruption within the config using the wizrd.
erased the config and reloaded it.
check all the phone connections
check all the ethernet connections
check all the pcs connected to the network for a virus
check the hub/switches links to each other
check for new equipment on the lan and ruled it out as it is on the other side of a router.

while testing i used monitor and ping command to the ipo403, this kept the ipo403 from rebooting as often. monitor only shows a .FATAL message just before the reboot (alarm dump at end)
moved the voicemail server ethernet connection from one of the external switches to the intergrated switch on the ipo403, this only increased the frequency of reboots.
replaced the network card and drivers in voicemail server. the ipo403 still rebooting. replaced the ethernet cable with a known good one. still rebooting.
moved the ipo403 ethernet connection from one hub/swicth to another until the ipo403 has been on all of them, still the pig403 reboots.

help is there anything else i can try? apart from upgrading the firmware as the inhouse software was developed around this version (2.1.15). updates to later version 2.1.27 just killed the inhouse software.

Alarm Dump:
3016mS PRN: ALARM: 02/10/2006 09:10:27 IP 403 2.1(15) <TLB Data Error> CRIT RAISED addr=0086ca04 d=5 pc=ff5dbe60 ff5e00b8 ff5dbfc8 ff5e3460 ff7f06ac ff7eec24
3016mS PRN: ALARM: 03/10/2006 16:23:57 IP 403 2.1(15) <TLB Data Error> CRIT RAISED addr=0086ca04 d=5 pc=ff5dbe60 ff64baa0 ff5dbfc8 ff5e3460 ff7f06ac ff7eec24
3017mS PRN: ALARM: 04/10/2006 09:14:25 IP 403 2.1(15) <TLB Data Error> CRIT RAISED addr=0086ca04 d=5 pc=ff5dbe60 ff5db3e0 ff5dbfc8 ff5e3460 ff7f06ac ff7eec24
3017mS PRN: ALARM: 04/10/2006 09:19:58 IP 403 2.1(15) <TLB Data Error> CRIT RAISED addr=0086ca04 d=5 pc=ff5dbe60 00000000 ff5dbfc8 ff5e3460 ff7f06ac ff7eec24
3018mS PRN: ALARM: 06/10/2006 17:34:04 IP 403 2.1(15) <TLB Data Error> CRIT RAISED addr=0086ca04 d=5 pc=ff5dbe60 ff64baa0 ff5dbfc8 ff5e3460 ff7f06ac ff7eec24
3018mS PRN: ALARM: 10/10/2006 17:29:07 IP 403 2.1(15) <TLB Data Error> CRIT RAISED addr=0086ca04 d=5 pc=ff5dbe60 ff5e00b8 ff5dbfc8 ff5e3460 ff7f06ac ff7eec24

 

[disturbedone]

When you erased the config did you do it thru Manager or the DTE port? Erasing config via Manager doesn't get rid of everything. The only way to start afresh is to run the AT commands.

Have you replaced the IP403 base unit with a maintenance spare, loaded their config, and monitored to see if it reboots. Could be a faulty system.

Also if their inhouse software doesn't work on anything other than 2.1(15) it hasn't been written very well. Or maybe it's Avaya that don't write software very well and change things.....surely not!!

 

[MisterLister]

via the dte port, i am getting a dab hand using that port unfortunly.

yes the ipo403 was replaced with new boxed unit, still the same.

least said about the s/w the better; as the manager could be reading this thread. the s/w has been working fine for the last year on that firmware version.

i am banging my head against a brick wall, what i do not understand is why changing an ethernet port for the voicemail server should make such a change in the frequency of reboots. plug the voicemail server directly to the ipo = increased reboots. plug the voicemail server into a switch/hub = decrease in reboots.

 

[disturbedone]

Looks like the VM is sending something to the IPO that it doesn't like. Who knows what but it looks like it. Now if you presented this to Avaya, you know what their response would be.........upgrade!

Has the config been rewritten by hand? When you default via DTE and put the config back in, you're starting from scratch not just loading the old config file in are you? Just to prove that the config isn't the issue. I doubt it, but it has to be done.

Unfortunately, it looks like a bug (what, in an IP Office?) and I think you've done all the can be done to try and rectify it. I can't explain it but you've basically proven it - something to do with the VM talking to the IPO is causing it. What version VMPro? Could that be upgraded to the latest 2.1 at least? Could, for testing purposes, the VM be disconnected for a while to see if it reboots? Or maybe just give them VMLite for a couple of days? It's not an ideal situation for the customer no, but there's not a lot else.

As I said, you already know Avaya's response!

 

[MisterLister]

hi disturbedone
i give redoing the config from scratch on the old ipo403. i had uploaded the cfg once it went through the wizard and confirmed no issues.

as for avaya's response i thought that might had been everyone else response too. but as i siad the firmware has been inplace for a long time now and has not been a problem until now, thats if it is the firmware at fault. i may just force a firmware update and get the firm to move with the times.

as for the vm server it does not only do vm but also call logging which disconnecting it is not an option, as the call logging has to be done, and moving the program (not avaya or inhouse) and data files to another machine is no walk in the park.

vmpro 2.1(5)
feature key 1.0

 

[disturbedone]

I doubt it's a config issue but it's worth a go.

I don't know what their inhouse software does but I would think it's more the system software rather than the VMPro software that is stopping you upgrading. There's nothing stopping you from upgrading the VMPro from 2.1(5) as that was the first release I think on 2.1. I don't work on them anymore but the last version I saw was 2.1(23) I think. It's worth upgrading that to see if thatfixes it and leave the IPO on 2.1(15).

What's their software doing? I just can't see why software upgrade would stop it working. Is it TAPI integration to a database or something?

 

[MisterLister]

its an vb front end, tapi interface and sql db.
the tapi is not called directly but via a piece of software called ExceleTel TeleTools v3.6 this allows the vb program to make calls and popup on recieving a call at the extention
logging the call details in the sqldb.

it works well enough on 2.1.15 but when i last upgraded the popups no longer happened and calls could not be placed from the software.
i have asked for them to check the firmware version it is compatible with.

 

[tlpeter]

try 2.1.73 and see if the software works
you can always go back to 2.1.15
2.1.15 is the worst version of 2.1

 

[aarenot]

see if you can make it reboot. try calling in and pressing undefined entries off of the aa's. like press 7 when 7 is not an option, etc.

have you uninstalled, and reinstalled the vmpro software for your server

You do not always get what you pay for, but you never get what you do not pay for.

 

[jamie77]

before you upgrade the vm to 2.1(23) or (25) are you running IMS.

There is a big problem with these releases and IMS. I have a PB written for one of our sites that fixes it.

I would try running the config on a spare unit and see if it reboots without anything connected to it.

It could be something silly like a power supply on the 403 or one the the expansion units.

Jamie Green

Fooball is not a matter of life and death-It is far more important!!!!

 

[MagicStardust]

You need to update your Loader to the current version.

 

[MisterLister]

i think i have found the problem.
11 days ago i was going to update the firmware and admin software. i found a corruption of the admin installation; within the add/remove programs the admin software was not listed. i installed the original admin s/w as if it was a new installation. the add/remove programs then had 2 admin s/w listed. i uninstalled the admin s/w.
installed the original admin s/w.
since then no problems with rebooting.

the only piece of software/hardware used 24/7 is the Feature Key which is used for the licencing. no other avaya admin software is used all the time.

i am thinking that with the corrupted admin installation the feature key software was giving out some sort of error when the ip403 was checking the licencing; which the ip403 could not handle so rebooted.