why SPA122 reboots itself every hour after reprovisioning

damianas77 · ‎02-08-2013

The problem we're detecting is that this phone adapter reboots itself
when it takes the provisioning file from the server after 3600 seconds.
That should not be necessary (or at least we think it should be possible
to deactivate it), and sometimes it can cause further networking problems
if there are some other devices connected to the Ethernet port. Moreover,
when it takes between 2 or 3 minutes to recover itself from restart.

Is there any chance development team would take this under consideration?

Thanks in advance.

Dan Lukes · ‎02-08-2013

So configuration you are uploaded into device contain a change that require reboot.

Example of simple configuration with such behavior (reboot everytime the configuration is loaded) follows:

No

Yes

You need to identify the configuration tag causing the reboot. At the first, verify that no tag is twice in configuration file.

damianas77 · ‎02-13-2013

I've checked our provisioning files and there are no duplicate entries that may cause this behaviour. Unless there's a specific tag that causes a mandatory reset, we think the phone adapter should not reset itself on reprovisioning.

Is there any way we can send you a config file so you can check it?

Dan Lukes · ‎02-13-2013

Unfortunately, no debug message mark configuration tag that triggered reboot.

I know no tag causing "mandatory reset". And I have no SPA122, but SPA112 only. Despite of it, you can attach your configuration file there so someone may look into it.

In advance, you can divide your configuration in half, searching for the half containing tag causing reset. Then you can split the reboot-causing half into half (e.g. every piece will be quarter of original file) searching for the part causing the reboot again. And so on. It will help you to identify smaller parts of configuration that are responsoble for reboots.

Of course, a tag within configuration file is not only possible reason for reboot. It can be caused by firmware bug as well - something like the one described in

By the way, you didn't mention firmware of your device. So I assume it's the latest.

damianas77 · ‎02-13-2013

Thanks for your fast answer!

Concerning the Firmware, yes, we're using 1.3.1_003, which is the latest I know.

I'll try to upload a config file (or copy it here) just in case somebody could take a look on it and let me know if there's something incorrect that may cause this behaviour.

KR,

Damian

damianas77 · ‎02-13-2013

I attach the config file, it's a bit long.

(Sorry for copying the whole file first, I didn't saw the attach file section)

Patrick Born · ‎02-13-2013

Damian,

I see that Resync_Periodic is set to 24 hours. Your initial post says that the device reboots hourly after a resync. Did you change the timer between your first post and when you posted the config?

Dan's advice is sound. I encourage you to follow his suggestion about reducing the size of the config file as part of the isolation process. In addition, I recommend you do the following:

Read through your configuration file, do you really need to provision every parameter that you're provisioning? If the parameter is the same as the factory default version, there's no real reason to provision it again unless you're concerned that somebody is accessing the device and making changes that you want to reset each time the device provisions.
Now that you've been through #1 from above, make a very small configuration file.
Factory reset the ATA.
Set the Resync_Periodic timer down to a short period, for example 5 minutes. Does the device still reboot after every resync? If so, enable debug level 3 which may help identify the reboot reason.

Regards,

Patrick---

Dan Lukes · ‎02-13-2013

The Resync_Error_Retry_Delay is set to 3600, e.g. 1 hour.

Read through your configuration file, do you really need to provision every parameter that you're provisioning? If the parameter is the same as the factory default version, there's no real reason to provision

If I can speak for myself, then definitely yes. It's the only way to ensure that every parameter has the required value. Not only because a value can be changed intentionaly or unintentionaly by authorized or unauthorized user.

Even the 'factory default' values can't be trusted.

Release notes contain so many references to non-public documents identified by code like CSCuc5388 only. Some changes seems not to be mentioned at all. It's not possible to decide if a factory default value has been changed between N-firmware and N+1-firmware.

In short, there is no reliable source of information related to possible changes in factory default values. It's better not to depend on it and set all of them to well known values.

Just my $0.02

damianas77 · ‎02-13-2013

I'll try to follow your advice in using a shorter provisioning file, but I have to say that I agree with Dan. If changes in the firmware affect to some of these parameters, and they're still not provided within a changelist (maybe because it's not the final version), then there's no way we can try to use firmware updates and keep the options under control.

In addition, I didn't changed the Resync_Periodic parameter, we normally use it set to 24 hours, that's the reason why we are annoyed that the ATA reboots more or less every hour.

I'll keep any news on it posted

Dan Lukes · ‎02-13-2013

There are two different things. Routine provisioning - here I agree with you, complete configuration is best. But this threat is dedicated to "why my device reboots". All tags not affecting the issue should be removed as part of problem isolation process. Also, debug messages may help (or may not help) to you.

damianas77 · ‎02-15-2013

Ok, we've found the source of the problem.

If the parameter "Upgrade_Enable" is set to Yes:

Yes

And there's no upgrade to make (specially if there's no upgrade available), then the ATA reboots itself and there's a cut on the ethernet connection.

Consequences:

1. Phone service is unavailable during 15-20 seconds (at least)

2. Ethernet connection behind the ATA unavailable during same time.

This has been "workarounded" setting this parameter to No, but it causes now we cannot upgrade massivelly all the ATAs in case needed.

We think Developpers Team should consider changing this behaviour, for it is affecting us to the point we're beggining to lose customers, unsatistified with the service.

--------------------------------------------------

Not so long ago we used to install Linksys SPA2102 as the IP Phone Adapter solution for our customers. The device worked really good and it never caused any of these problems. Suddenly, someone decided not to produce it anymore and we were forced to use the Cisco SPA122.

We felt strongly upset with this change, but there was nothing to do from our side. We hope somebody can take in charge of this issue and find a solution.

Dan Miley · ‎02-15-2013

Once you set up logging, there will be a reboot reason in the log. (syslog setup below)

You can look up the reboot reason here

https://supportforums.cisco.com/docs/DOC-9889

Some reasons the ATA might reboot.

- reboot reason: provisioning: something changed in the provisioning file, this can be caused by a script tagging the date and time on the file, a serial number, or changing a feature, then changing back (as Dan Lukes mentioned).

- reboot reason: firmware update.

your device may be requesting firmware from the server, then downloading the firmware, once the firmware is installed, it reboots. then the upgrade rule kicks in after the upgrade_error_delay (3600 in this case).

3600

http://XXXXX_my_ip_address_XXXXX/$PN.bin

To fix this put a conditional statement in the upgrade rule saying (if software version is 1.3.1 don't upgrade)

($swver != 1.3.1)? http://XXXXX_my_ip_address_XXXXX/spa122.1.3.1.bin

(verify this in the provisioning guide)

https://supportforums.cisco.com/docs/DOC-9894

Or remove the upgrade rule and see if that fixes the issue.

in terms of sending the factory default config out to the ATA each time.

Best practise is to test your config with factory default + minimal config.

send the minimal config for device/network (in this case spa112.cfg is the default)

send the user/phone specific config as the $ma.cfg file ( cfg-88755604a1fa.txt in this case) as minimum config.

that way the configuration and provisioning server load will be less, configuration is simpler to troubleshoot, etc.

It's really not a good idea to send the same config parms to different devices, or different firmware versions, as the parms or features may have changed. Most may work, but I've seen syntax differences between device types and firmware cause all kind of wierd errors. You can download the SPC tool for each firmware and device, use that to create a FDefault profile, then pull your config lines from there.

Much more exciting reading the provisioning guide.

If it's still rebooting post the syslog of a boot cycle, and we'll review.

or contact the support center at 866-606-1866. You can create a case first, then call in with an existing Service Request number. Just make sure you have a descriptive problem description, logs, etc attached.

To enable logging on the spa go to

Voice --> system

add the IP address of your log server in the debug and syslog, set debug level =3

Go into the extension --> sip settings --> sip debug option to full

This will allow you to get all the sip messages between the call manager and the ATA. Might not be required for this issue.

To set up syslog and debug through provisioning add these lines to the config

ip.add.ress.of.server

3

full

SPA1x2 device:

3

IP.OF.LOG.SRV

full

! like TFTPD64.exe, but there are other free syslog tools

dlm...

Dan Lukes · ‎02-15-2013

I assume your's "there's no upgrade available" mean there is no firmware different from the one already installed avaiable.

In such case, setting the setting Upgrade_Enable to yes when no upgrade avaiable is not optimal. Device know no firmware version of remote firmware file unless it download (at least part of) them. Such periodic transfers waste bandwith and increase load of http server.

there was nothing to do from our side

Disagree, somewhat. Our approach is:

1. Profile_Rule URL look like: https://....../Provisioning.php?Product=$PN;SW=$SWVER

device asking for provisioning expands $PN and $SWVER to actual values, so resulting request look like (for example):

.../Provisioning.php?Product=SPA112;SW=1.3.1(003)

2. Our script evaluate product and current firmware version, then decide if other firmware should be downloaded to device. If yes, then Upgrade_Enable=yes and Upgrade_Rule=new_firware. If no firmware change required, then

Upgrade_Enable=no and Upgrade_Rule is empty

Your ability to upgrade all devices remain untouched - device will be upgraded automatically on nearest periodic configuration check. In advance, you can use SIP NOTIFY Event: check-sync to invoke immediate configuration check (e.g. upgrade if necesarry).

Note that we didn't developed this because of "periodic problem" but we wanted to avoid unnecesarry periodic firmware transfers.

moisansyl20 · ‎09-12-2013

Hi, we have the same issue since we are now using those spa122 instead of spa2102. I did the tests as described above. Here is what I have discovered. We are using 2 configuration files. One with the generic information like proxy address and the second file contains information like user ID, password, dial plan etc...

For the test, I just used 1 file.

Periodic Resync at 120 (2 minutes for the test).

After the boot, it gets the file. 2 minutes later it gets the file again and then it reboots.

When I removed section in the file, the spa didn't reboot. So I removed this section in the second file and tried using both files and the spa reboots. Then I decided to test only the second file and the spa didn't reboot. In the provisioning section of the spa, I use the field Profile Rule. At the moment there are 2 files, one in the field Profile Rule and the other in the field Profile Rule B, the spa reboots each 2 minutes.

So for now I use only one configuration file (without the router configuration section) and the spa doesn't reboot. I hope this can help Cisco to find what is the problem. As other user said, it is really frustrating that Cisco decided to change spa2102 for spa122 with all these problems.

Regards

Dan Lukes · ‎09-12-2013

I assume that both configuration files overlap somewhat. E.g. there is a option within both files but with different value. It's change trigger reboot. If single file tested only (either first or second), then value is stil same, so no reboot is initiated.

Of course, guessing only - you didn't supplied logs nor configuration data, so serious analysis is not possible.