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>
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.
ok what do these settings do for the obi?
can you explain?
thanks
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.
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
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.
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.
Quote from: Huib on January 21, 2012, 11:35:41 AM
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?
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..
Quote from: nmssystems1 on January 21, 2012, 11:49:34 AM
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.
Yes, I have stopped the provisioning and as of yet no reboots. Hopefully OBIHAI will fix this sooner than "someday" ;)
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.
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.
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
Quote from: nmssystems1 on January 21, 2012, 03:59:38 PM
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.
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.
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
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
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..