02-08-2013 01:25 AM - edited 03-21-2019 09:59 AM
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.
02-08-2013 02:59 AM
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:
You need to identify the configuration tag causing the reboot. At the first, verify that no tag is twice in configuration file.
02-13-2013 03:08 AM
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?
02-13-2013 03:49 AM
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.
02-13-2013 03:53 AM
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
02-13-2013 04:02 AM
02-13-2013 06:11 AM
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:
Regards,
Patrick---
02-13-2013 07:15 AM
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
02-13-2013 07:31 AM
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
02-13-2013 07:38 AM
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.
02-15-2013 07:49 AM
Ok, we've found the source of the problem.
If the parameter "Upgrade_Enable" is set to 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.
02-15-2013 09:23 AM
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).
To fix this put a conditional statement in the upgrade rule saying (if software version is 1.3.1 don't upgrade)
(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
SPA1x2 device:
! like TFTPD64.exe, but there are other free syslog tools
dlm...
02-15-2013 09:24 AM
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.
09-12-2013 01:46 PM
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
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
09-12-2013 02:37 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide