06-17-2014 04:00 PM - edited 03-21-2019 08:17 AM
I've got a couple of SPA504G phones that are rebooting approximately every hour. However I have the parameter <Resync_Periodic ua="na">0</Resync_Periodic> in the configuration template. So it can't be a template configuration issue.
I enabled the debug and syslog server and set the debug level to 3. I get the following output when there is a reboot. The following two lines prior to the reboot seem suspicious.
"Jun 17 22:38:26 192.168.1.200 [0]UnRegOK
Jun 17 22:38:27 192.168.1.200 fu:1:0dfd5, 5.1.12 5.1.14 5.1.19 6.8 7.13 1"
Is there anyway to find out why the phone chose to unregister? And what does that cryptic last line mean does it explain the reason for a reboot?
Here is more of the syslog output.
Jun 17 22:37:52 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:38:07 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:38:22 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:38:26 192.168.1.200 [0]UnRegOK
Jun 17 22:38:27 192.168.1.200 fu:1:0dfd5, 5.1.12 5.1.14 5.1.19 6.8 7.13 1
Jun 17 22:40:59 192.168.1.200 IDBG: LS, 270-4d8
Jun 17 22:40:59 192.168.1.200 IDBG: SOK
Jun 17 22:40:59 192.168.1.200 IDBG: st-0
Jun 17 22:40:59 192.168.1.200 fu:1:0e07d, 4.71 1
Jun 17 22:40:59 192.168.1.200 Resolving 67.207.102.190
Jun 17 22:40:59 192.168.1.200 [BKpic]Loading blank background image
Jun 17 22:40:59 192.168.1.200 [BKpic]Loading blank background image
Jun 17 22:40:59 192.168.1.200 [0]Reg Addr Change(0) 0:0->43cf66be:5060
Jun 17 22:40:59 192.168.1.200 [0]Reg Addr Change(0) 0:0->43cf66be:5060
Jun 17 22:40:59 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:41:02 192.168.1.200 fs:033170:045903:131072
Jun 17 22:41:02 192.168.1.200 fls:faffffffff:1:17:464
Jun 17 22:41:02 192.168.1.200 fbr:1:3000:3000:1dfd5:0004:0005:7.4.9c
Jun 17 22:41:02 192.168.1.200 fhs:01:0:0001:upg:app:M:7.5.2
Jun 17 22:41:02 192.168.1.200 fhs:02:0:0002:upg:app:0:7.4.9c
Jun 17 22:41:02 192.168.1.200 fhs:03:0:0003:upg:app:1:7.4.9c
Jun 17 22:41:02 192.168.1.200 fhs:04:0:0004:upg:app:2:7.4.9c
Jun 17 22:41:02 192.168.1.200 dhcp opt 66: ""
Jun 17 22:41:02 192.168.1.200 dhcp opt 160: ""
Jun 17 22:41:02 192.168.1.200 dhcp opt 159: ""
Jun 17 22:41:02 192.168.1.200 dhcp opt 150: ""
Jun 17 22:41:02 192.168.1.200 fu:1:0e097, 5.1.1 1
Jun 17 22:41:14 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:41:17 192.168.1.200 fs:033170:045903:131072:091609447999
Jun 17 22:41:17 192.168.1.200 pbs 230912
Jun 17 22:41:17 192.168.1.200 SPA504G e0:2f:6d:60:8c:96 -- Requesting resync http://192.168.1.10:80/spa/spaE02F6D608C96.cfg
Jun 17 22:41:17 192.168.1.200 SPA504G e0:2f:6d:60:8c:96 -- Requesting resync http://192.168.1.10:80/spa/spaE02F6D608C96.cfg
Jun 17 22:41:17 192.168.1.200 FMM >>>> Requesting profile
Jun 17 22:41:17 192.168.1.200 content len (hdr) =0
Jun 17 22:41:17 192.168.1.200 content len (pld) =57858
Jun 17 22:41:17 192.168.1.200 SPA504G e0:2f:6d:60:8c:96 -- Successful resync http://192.168.1.10:80/spa/spaE02F6D608C96.cfg
Jun 17 22:41:17 192.168.1.200 SPA504G e0:2f:6d:60:8c:96 -- Successful resync http://192.168.1.10:80/spa/spaE02F6D608C96.cfg
Jun 17 22:41:17 192.168.1.200 FMM >>>> Successful profile
Jun 17 22:41:29 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:41:44 192.168.1.200 [0]RegOK. NextReg in 19 (1)
Jun 17 22:41:59 192.168.1.200 [0]RegOK. NextReg in 19 (1)
What else could cause the phone to reboot? Is there anyway to get better debug information from the device? I don't currently have physical access to he phone. I greatly appreciate any help in this matter.
06-18-2014 12:59 PM
Is there anyway to find out why the phone chose to unregister?
No, but in my humble opinion it's because your phone is going to reboot.
So you are interested to identify reboot reason.
You need no physical access to it, use WWW browser. See phone's WWW UI, tab named "Info", section named "Reboot History".
I assume you have latest firmware version.
09-12-2014 03:49 AM
The phone is rebooting because it has got the configuration from the provisioning server. I can see on the syslog:
Successful resync http://192.168.1.10:80/spa/spaE02F6D608C96.cfg
I just don't undertand is why the phones restarts if the configuration files don't change any configuration. :)
09-12-2014 04:31 AM
Are you pretty sure they are same ? Well, in such case the most common cause of unsolicited reboot is "flapping option". I mean that the SAME option is set twice. Despite the resulting value is still the same (the last set wins) the option has been changed during the provisioning process. So reboot is triggered.
09-12-2014 06:17 AM
Spotted the problem. In my situation I really have a "flapping option" that causes the restart. As soon as I clear the "flapping", the phone doesn't reboot.
I owe you a dinner. :)
09-12-2014 07:08 AM
Glad to hear we solved it.
09-24-2014 08:39 PM
Joao,
Where do you find this 'flapping option' that causes the restart. Is it on the phone or on the provisioning server where you cleared the 'flapping'.
Thanks
09-19-2014 06:17 AM
Dan.
Can you explain a little more about the "flapping option you describe above. I just inherited an office full of these phones. Even after upgrading the firmware on them, I still get the random reboots. I'm still getting syslog setup. I can verify the switch interface isn't flapping. Can you tell me more?
Thanks!!!
Patrick
09-19-2014 06:29 AM
It depends on how the provisioning server is providing the configuration files to the phone. Imagine that you have set the phones to load the configuration from Profile_Rule and Profile_Rule_B.
On Profile_Rule you set a property to true. on Profile_Rule_B you set the same property to false. This property / Option is flapping between configuration files, even if it in the end is not changed, for the cisco SPA Phones is still a change that needs to trigger a reboot.
09-21-2014 12:25 AM
It will apply even in the case you set one property twice within one profile configuration file.
But reboots caused by load of configuration are not random - the occur just at the time of profile loading. Also, "reboot reason" is accesible trough WWW UI as well as phone's menu. So check the value - it may help you to analyze the issue. Also, syslog&debug messages may help you.
09-24-2014 09:38 PM
Just to clarify here, the clearing of flapping is done on the provisioning server. Could you please place a screen shot of what you did.
Thanks,
Harry
06-25-2014 05:41 PM
Could also be a physical issue with the cabling ... make sure the patch cables to the sets are good (swap them out with known good), and the cables from the patch panel to the jack have RJ45 terminations that follow the T568 B Standard ...
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