cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3612
Views
5
Helpful
11
Replies

SPA504G Rebooting

andrew011
Level 1
Level 1

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.  

11 Replies 11

Dan Lukes
VIP Alumni
VIP Alumni
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.

 

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. :)

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.

 

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. :)

Glad to hear we solved it.

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

 

 

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

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.

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.

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

Brent Conway
Level 1
Level 1

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 ...