atcomsystems.ca/forum Forums TDM Business Telephone Systems Inter-Tel Telephones & Systems Defaulting Older Style IP-SLA

Is there any way to default the older style IP-SLA (the one w/o the reset pinhole in the back)?

It is the policy of this board to not give out any backdoor or password information. You might want to contact a dealer in your area.

Hi Drew:

Maybe it's just precaffine, but I'm having trouble picturing exactly what you're referring to. Can you give us more info on the system? I'm assuming you're referring to an Axxess. Is this the 770.3000? Please update with a part number.

I am an Inter-Tel dealer. There is nothing in their knowledgbase that describes how to simply default the older style IP-SLA (770.3000).

To default newer style IP SLA (from IP Devices Manual)

"To default the IP SLA:

1. Press and hold the DEFAULT button using a pinhole tool (such as a bent paper

clip). The SL STATUS LED flutters for five or six seconds.

2. When the ON-LINE LED is lit, remove the pinhole tool from the DEFAULT button.

The ON-LINE LED turns off."


The knowledgbase gives info on how to determine which IP address the SLA thinks it is, but not how to simply default to the original factory settings. (The newer ones have pinhole reset button on the back.)

Further info from the customer:

Hello, Drew. This IP-SLA seems to be somewhat broken, in that it appears to think that it is 192.168.70.1, but is not responding to any requests to that address (ping, telnet, www, etc.). Additionally, it is broadcasting ARP requests, asking who has 192.168.70.1.

Specifically, when I look at the network traffic with Ethereal, I see periodic broadcast traffic from its MAC address as 192.168.70.1, on UDP port 5567. This is presumably it looking for a card on its local subnet.

If I then configure one of our IPC cards to be on the 192.168.70.0/24 subnet (specifically, I gave it the address 192.168.70.55) and program the IP-SLA's MAC address on one of its circuits, I can see the following traffic in Ethereal:

192.168.70.1 to 255.255.255.255, UDP port 5567 (presumably the IP-SLA looking for a card on its local subnet)
192.168.70.55 to 192.168.70.1, UDP port 5567 (presumably the IPC card trying to respond)

But, still, the card at 192.168.70.55 is not able to establish a connection to the IP-SLA: it never says it's connected, and the IP-SLA continues to send out broadcasts to 255.255.255.255 on UDP port 5567, presumably still looking for an IPC card to connect to.

Additionally, the IP-SLA is also continuing to send out ARP requests, asking who has 192.168.70.1. My guess here is that it's also trying to connect to the IPC card address programmed into its local database (which is 64.81.6.100; outside its local subnet), and it has 192.168.70.1 programmed as its default gateway. So to send out a UDP packet to 64.81.6.100, it needs to get the address of its default gateway, so it can send the packet through it... but that's not working, as it is not responding to its own ARP requests.

So, anyway, we can confirm that the device thinks that it is 192.168.70.1 (it's sending out Ethernet packets with that IP address), but it is not responding to any traffic sent to 192.168.70.1 (either ping, telnet, www, or an IPC card trying to respond to its broadcast attempts to connect to a card on the local subnet).

So we're completely stuck now. Is there really no way to set this back to factory defaults--maybe a switch on the motherboard if we open it up? Or any other way to try to talk to the device? There must be some way to revive its configuration...

Did he try going to 192.168.70.1 in a web browser on a PC with the same subnet?

Well I'm sorry to say that the 770.3000 support doc is of no use, and so far neither is the IP Devices Version 1.2 manual. One of our Admins has a HUGE database of little known fixes like this, but he is currently in transition from Nevada back to California and is being delayed by the wildfires. Perhaps when Chris gets in this afternoon he'll have the info. I'll keep looking after I get out of this next meeting.

Tried web, telnet, etc. to no avail. Worked with tech support and they ended up issuing an RMA.

What we think may have happend is that the cust fat-fingered in the same ip in both fields.

That could certainly do it, and it would put it into a loop where you couldn't talk to it either to go through the default process. Without the pin hole, you'd need to be able to open the box and shunt the capacitor to ground to clear the memory. Glad you got an RMA. I'm sorry we weren't more help. Rhett, (RCA) is our resident librarian when it comes to Inter-Tel support docs, and he is still stuck in transition with limited net access due to the California fires.

Trace..where did you find out how to do that?