Kernel.Error SYSTEM REBOOTED (Reason: 3, lifecycle: 3634)<000>

[nmssystems1]

Any have this problem of the obi rebooting through out the day..

all the units have the new firmware on them..

it does this serveral times a day it seems..
it almost seems like the unit reboots if it can not talk to the google voice servers
after so many attemps.. just and idea not sure what it is..

thanks

here is the entire syslog entry..for the event..

2012-01-20 22:29:10   Kernel.Error   192.168.3.190   SYSTEM REBOOTED (Reason: 3, lifecycle: 3634)<000>
2012-01-20 22:29:10   Local5.Notice   192.168.3.190   ZT: CustomID 1<000>
2012-01-20 22:29:10   Kernel.Emerg   192.168.3.190   SLIC_init ...<000>
2012-01-20 22:29:10   Kernel.Emerg   192.168.3.190   Reset SLIC...<000>
2012-01-20 22:29:10   Local2.Info   192.168.3.190   Setup Provisioning2 for system start! 1800<000>
2012-01-20 22:29:12   Kernel.Emerg   192.168.3.190   SLIC & DAA is initialized<000>
2012-01-20 22:29:14   Kernel.Info   192.168.3.190   Start Main Service Now<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   Voice Main<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   [CPT] --- FXS s/w tone generator (ringback) ---<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   BASESSL:load cert:5<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   BASESSL:Load certificate ok<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   XMPP:State changed from: 0 to:1<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   GTT:Init xmpp node ok<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   XMPP:State changed from: 1 to:2<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   XMPP:Invalid cfg use for xmpp<000>
2012-01-20 22:29:14   Kernel.Debug   192.168.3.190   GTT:xmpp not configured<000>
2012-01-20 22:29:16   Kernel.Debug   192.168.3.190   [SLIC]:Slic#0 ON HOOK<000>
2012-01-20 22:29:18   Kernel.Debug   192.168.3.190   [DAA]: FXO ONHOOK MONITOR<000>
2012-01-20 22:29:19   Kernel.Debug   192.168.3.190   XMPP:State changed from: 2 to:3<000>
2012-01-20 22:29:19   Kernel.Debug   192.168.3.190   TCP:Connect OK(xmpp)14<000>
2012-01-20 22:29:19   Kernel.Debug   192.168.3.190   XMPP:State changed from: 3 to:4<000>
2012-01-20 22:29:19   Kernel.Debug   192.168.3.190   XMPP:Enable reqto<000>
2012-01-20 22:29:19   Kernel.Debug   192.168.3.190   XMPP_PROC:TLS required!<000>
2012-01-20 22:29:19   Kernel.Debug   192.168.3.190   XMPP:State changed from: 4 to:5<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   TC:ssl connected<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 5 to:6<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:Enable reqto<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:new stream restarted from remote, old state=1<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 6 to:8<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 8 to:9<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:Enable reqto<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:new stream restarted from remote, old state=1<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 9 to:10<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 10 to:11<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 11 to:12<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 12 to:13<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:State changed from: 13 to:14<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   XMPP:Disable reqto<000>
2012-01-20 22:29:21   Kernel.Debug   192.168.3.190   GTT:xmpp service up<000>
2012-01-20 22:29:22   Kernel.Debug   192.168.3.190   GTALKVM:Checking VM....<000>
2012-01-20 22:29:22   Kernel.Debug   192.168.3.190   GTALKVM:state changed from 0 to 1<000>
2012-01-20 22:29:22   Kernel.Debug   192.168.3.190   [CPT] --- FXS s/w tone generator (sit_1) ---<000>
2012-01-20 22:29:22   Kernel.Debug   192.168.3.190   TCP:Connect OK(lhttpc)18<000>
2012-01-20 22:29:22   Kernel.Debug   192.168.3.190   Trying to connect ssl<000>
2012-01-20 22:29:23   Kernel.Debug   192.168.3.190   TC:ssl connected<000>
2012-01-20 22:29:23   Kernel.Debug   192.168.3.190   LHC:Response OK<000>
2012-01-20 22:29:23   Kernel.Debug   192.168.3.190   LHC:set Retrying:www.google.com, 1<000>

[RonR]

Just as an experiment, log into the OBi directly and temporarily set:

System Management -> Auto Provisioning -> ITSP Provisioning -> Method : Disabled
System Management -> Auto Provisioning -> OBiTALK Provisioning -> Method : Disabled

and see if the periodic reboots go away.

You must click Submit at the bottom of the page and then click Reboot in the upper right corner of the page for these changes to be made.  After the reboot, log back in and verify that they took.

Once you determine whether this has any effect on the reboots, you can restore these settings if you wish to by simply checking the Default checkboxes again.

[nmssystems1]

ok what do these settings do for the obi?

can you explain?

thanks

[RonR]

2012-01-20 22:29:10   Kernel.Error   192.168.3.190   SYSTEM REBOOTED (Reason: 3, lifecycle: 3634)<000>

The reboot reason code being displayed in your Syslog is 3:

3: Reboot after New Profile Invoked

This would seem to indicate that the OBiTALK Web Portal may be repeatedly sending a new profile to your OBi, causing it to reboot each time.

Disabling Auto Provisioning will stop the loading of new profiles from the OBiTALK Web Portal and might identify the source of your unexpected reboots.

[nmssystems1]

I kind of thought it was getting some kind of update from the web portal config files etc..

then restarting..

my next question would be if i change some thing on the web portal will this particular obi device that i have disabled provisioning on. will it get the update change from the obitalk web portal? my guess is no it will not.

this means i can not manage the obi device that has provisioning disabled using the obitalk web portal?

thanks

[RonR]

You will have have to make changes to the OBi directly while Auto Provisioning is disabled.  Unless you actually need to be able to configure an OBi that is at a remote location, the OBiTALK Web Portal doesn't offer any particular advantage over direct configuration.  You actually have access to a few more settings and status with direct access.

[Huib]

I noticed this morning that my OBi was rebooting, showing code 3 (profile change) as reason. I haven't made any changes recently so I thought "that's odd" but left it at that. Now I noticed it again, same code. Don't know how many times it has done this but it's not right that it's rebooting so many times for no reason.

[RonR]

I noticed this morning that my OBi was rebooting, showing code 3 (profile change) as reason. I haven't made any changes recently so I thought "that's odd" but left it at that. Now I noticed it again, same code. Don't know how many times it has done this but it's not right that it's rebooting so many times for no reason.

Have you tried temporarily disabling Auto Provisioning to see if it eliminates the reboots and identifies the problem as described on Reply #1 above?

[nmssystems1]

yes it does seem to fix the problem of the reboot.. but i have around 25 of these in remote sites
using various dsl, cable and wireless internet service providers.

not using the obi web portal is going to make the managment of the obi devices more time consuming
and complicated.

humm one problem leads to another it would seem..


thanks for all the help and info..

[RonR]

yes it does seem to fix the problem of the reboot..

At least the cause of the reboots has apparently been identified and an immediate solution to the problem is known.  Presumably, OBihai will fix the problem someday.

[Huib]

Yes, I have stopped the provisioning and as of yet no reboots. Hopefully OBIHAI will fix this sooner than "someday" 

[ProfTech]

I noticed the same issue with an Obihai 110 yesterday. I expected it might have something to do with Obitalk also. This morning the Obi was not showing online at all. Talked to the owner and he indicated that it was continuously rebooting. The interesting thing seemed to be that after he changed the port to 100 / full, he could talk to me over the Obi even though the Red LED seemed to indicate the unit was rebooting. I had him turn off Obitalk provisioning and the reboots stopped. I too have one in India that I am not sure if it is working at this time or not. I did load build 2669 the other day but these units were working until Friday, I think so it seems to me the problem may be with Obitalk and not the firmware.

[obi-support2]

We are looking into this issue right now.
It may be related to a server glitch when we upgrade our server 2 days ago.
Apologize for the inconvenience.
We will post an update here soon.

Thank you.

[nmssystems1]

FYI :

I noticed this problem before the server upgrade two days ago but was not as bad.

maybe a 2 - 4 times a day.


I will try to turn provisioning back on this device tonight and see if the problem comes back..

since there are two provisioning options to enable i will enable one at a time and see if there is a particular one that it causing the reboot.

thanks

[RonR]

since there are two provisioning options to enable i will enable one at a time and see if there is a particular one that it causing the reboot.

I think you'll find that you only need to work with ITSP Provisioning.

OBiTalk Provisioning is disabled by Default.

[obi-support2]

The problem was caused by an error on our server when generating device profiles.
We have just fixed this issue (it may take some time to propagate to all affected units).
If you still see this problem happening to your unit, please
send as an email at support@obihai.com

This problem only affects units provisioned by OBITALK.

Thank you.

[nmssystems1]

yes you are correct.. but the other one is still config from the obi portal server..so it is that portal server obi talk that is not configing the google voice correct in my case..any one else have that problem with sip providers?

thanks

[nmssystems1]

in the past i have seen this problem before .. it is just worse now since the server upgrade a few days ago..

what i did to get past it is to delete all the obi devices out of the obitalk profile then create a new email then add my devices in there all at once instead of over time..this seems to do better with there portal server..

in ether case i think the profile is fubar at this point just start over on the new obitalk server..from the new server..they upgraded a few days ago..

ether way guys it is still better than no obi portal and config each obi on its own with the web interface.. for each device..

just my idea.. now if i could figure out a way to send the inital measage to the obi server server and not have the user at each remote site dial the **5 code i would be in heven..

then i could rebuild my profile with any user interaction..

thanks

[nmssystems1]

yes the problem is still there and the only soultion i have found for this in the past is to delete all the obi devices out of the server and pray that the obi portal server does not corrupt the profile some how for the devices when i recreate them.


Since i have 25 plus of these devices at remote sites that do not have staff there at the location all the time it is a major problem and alot of people time that are being paid for by the company.

the cost of reinstalling the obi deivce in labor hours is about the same as the device cost..50 bucks..

I am not sure at this point if it is even worth using the obi portal vs using direct configureation of the obi device via it own web interface.. would be more work install and setup but atleast at the end i would not have to touch them again since we are not installing any more of them at remote locations any way..

thanks for all the help and info..