I began noticing what appear to be mystery reboots / crashes of my unit starting with 2765. The symptom is the UpTime shows 12:13:23 or what ever but there is no reboot code. I have opened a ticket with Obi twice and their only answer is for me to run syslog and try to trap it myself. I haven't been looking at the unit or on the phone when it happened yet that I know of but it has happened 5 or 6 times that I know of, on two different Obi's. Was wondering if anyone else has noticed this?
I am noticing mystery reboots (no code after uptime field). This is an an Obi202, with the newest Firmware. I get about two days of uptime.
On the n-1 firmware (or maybe it was the n-2 version), I could go 30 or 40 days with no reboot (and the reboost that did happen were manual due to config changes I tweaked). On the 202 it's becoming both concerning and critical because twice in the last week it rebooted within 60 seconds of my placing a call, both calls to a GV SP.
I know you asked about an Obi110, I'll have to check an 110, it gets less use than a 202.
On my OBi110, I was getting reboots every 24-hours due to the Firmware check function being enabled. Since turning that feature off, I have not experienced any such reboot of the OBi110.
All Auto Provisioning is disabled. Only thing remotely connected to ObiHai is Voice Services -> ObiTalk Service -> Enable -> Checked. So I can make & receive Obi calls if desired.
I think these are some possible reasons for un/scheduled reboots:
Network issues
Auto Provisioning
X_AcceptResync (May want to set this one to 'NO', if you configure yourself)
> X_AcceptResync (May want to set this one to 'NO', if you configure yourself)
I note the help/tool tip in the browser/IP Address access mode says this:
QuoteAccept SIP NOTIFY with event=resync to reboot the device so it can download new configuration file. If authentication is required, the requestor must authenticate with the same AuthUserName and AuthPassword on this SIP
Choices are:
no
yes with authentication
yes without authentication (The Default)
It's not registering with me how this might work with GV, or any Voice Service for that matter. In any case, I'm gonna set to no in all four SPs and see what happens.
It looks like that field exists only in the 202. Anyway, I just got off the phone with ATT. My internet was not working last night. They said they had to re-route me over a new circuit. Hard to say how long there may have been an issue with it. I'll have to watch it and see if their fix stops the Obi from crashing. The weird thing is, since there is no reboot code I can't even be sure it is actually rebooting. Maybe something just crazy with the "Up Timer".
I'm 100% certain mine is rebooting. If you have aay doubt, setup syslog.
It's very easy to do, all you need is a computer on all the time you want to catch the logs entries.
See here for no cost syslog clients:
http://www.broadbandreports.com/forum/r27898113-Syslog-Server-Recommendations-
Quote from: QBZappy on February 13, 2013, 08:13:19 PM
I think these are some possible reasons for un/scheduled reboots:
Network issues
Auto Provisioning
X_AcceptResync (May want to set this one to 'NO', if you configure yourself)
An interim uodate. I changed the X_AcceptResync to No and my Obi202 is at 5 days, 8 hours of uptime. Since this is the only change I made, tentative conclusion is this makes a difference, and seems like the root cause of the problem.
This sounds promising. I hope others having unexpected reboots can confirm same results.
How incredibly frustrating. A few hours after I post this I get a random reboot.
How do I know it's random? No code on the uptime timestamp, and upon reboot I get an SMS text message alert from a txt received 48 hours ago.
I observed the SMS notify feature not working at all, except upon reboot (random or otherwise) I get a short ring and a Caller ID message. And the notifys have been for older messages, not current ones. Thinking there might be a connection, I disabled the SMS Notify on the two GV SPs in the unit. Will see how that goes.
Discovered that I had a duplicate IP on my network. Corrected that. Will have to monitor for a while. Also, I talked to a friend of mine yesterday who just bought a new Obi 100 and it came with build 2776 installed. 2774 is the latest available on the web page, however. I'm watching to see if they post anything else.
Follow up. I'm still in 'incredibly frustrating' mode, I'm getting random reboots anywhere from 24 to 36 hours.
Luckily, so far, none of the reboots have happened while on a call.
Another follow up with an interesting insight.
I still see no reboot reason code when viewed through the direct IP address mode. H0wever, when I export the configuration. and look at the XML export in MS Excel, I see reson code 91, as in "2 Days 10:10:37 (91)".
91 is not listed in the device admin manual, so you gotta wonder if this is some secret reboot reason code.
You should ask obi support for an explanation for what code 91 means.
That is interesting. I ran syslog for a couple of days but it never crashed. Since then, I have had other network issues not related to the Obi that either required me to reboot it, or an instance where we lost AC for a moment which caused my whole network to lose power. I would also like to know what the 91 means. Anyway, I saved my config a while back and did a paper clip factory restore. I have my fingers crossed but it seems to have possibly cured the situation. Time will tell.
I'm kind of like you in that I moved on to pursue this a different way. I did a factory reset on my Obi202, and reentered everything via the ObiTalk portal, which I plan to use until this gets revolved or goes away. And I want to see how the other half lives using the ObiTalk portal on a device under active configuration.
BTW, if you have any exports from the recent past, take a look and see if there's a mystery reboot code.
Edit:
Another mystery on my Obi202, I see that it's now using "3.0.1 (Build: 3741)", whereas before it was on 3722 (http://www.obitalk.com/forum/index.php?topic=9.msg13#msg13). Hum? For those not on using the ObiTalk portal, I see this in the FirmwareURL field: "IF ( $FWV < 3.0.1.3741 ) FWU http://www.obihai.com/firmware/OBi202-3-0-1-3741.fw" -- noticed via the Web Server-Based Local Configuration (Device IP address), not seen via the ObiTalk portal.
Note to self: Evidently when using the ObiTalk portal you get new firmware updates like this, without having to do anything or click anything, and before they are made available via ***6. An educated guess is these updates are not new feature releases (or they'd be announced as such), they are bug fixes.
My Obi202 FW: 3.0.1 (Build: 3722)
If it ain't broke... ;D
Just when I thought it might be Ok... It looks like it rebooted last night with a code of 94 this time. "0 Days 8:46:21 (94)". Maybe I will try putting it back in the portal and see if it gets an update.
FYI, I've got a 110 managed via the portal. It's at "1.3.0 (Build: 2774)", haven't seen that firmware change like I did on a 202.
I sent a ticket to Obi and they loaded 2776 into my 110. I have a 100 that I manage remotely via the portal and I noticed that the default is Auto Firmware update Off. I turned it On and of course the unit reboots whenever you make a change via the portal. I will check later and see if it updated.
*Edited* The unit did not update when it rebooted. But then I realized that the URL field appears to be blank by default. I think someone else reported that Auto Firmware update does not work on the 100/110. I think they said if set to "Periodically" it causes the unit to reboot every time it runs even though it never updates anything.
I have to vent on the 3.0.1 (Build: 3741) on my Obi202.
It's exhibiting an increasingly annoying assortment of bugs that are (mostly) random and not repeatable:
- The time sync takes an hour or two to update after a reboot. This one is not random it is repeatable. Thus I have multiple calls in history starting at 01/01/2010. I even have a few of these "01/01/2010 19:08:05" seeming to indicate it is taking 7 hours after a reboot to get the correct time. Using the same time server in my router works without issue, as it had been on earlier releases on the Obi.
- Out of nowhere today I got an SMS notification via Caller ID at 10:46 AM. Problem is I got that same SMS notification yesterday when the txt was first sent, and the txt message thread is archived in GV, and marked read. Both SMS messages are in the Obi call history.
- For the last week I sometimes have to forcibly power down for the Obi to get a DHCP address, such as after a config change reboot fails to get an address. No change in my router whatsoever.
- In the past five working days I have had three calls 'go dead' where the device stops responding in the middle of a call and I have to power cycle to reboot. Then hope the preceding acquire DHCP step works. Or else it takes 10 minutes to get back up and dialed back into a conf. call.
- I'm noticing numerous calls that 'drop' right after the dialed number connects to an auto attendant on the other end. I call the same number a lot during working hours, and this never happened before. It's either the auto attendant (no one else dialing in to the AA sees it) or my Obi. Call History shows the Call Ended originates by the phone on the Obi.
- On a positive note, I'm not seeing mystery reboots. On a bad note that is likely due to I have to manually reboot/power cycle once a day, on account of the above, for the last two weeks.
CoalMinerRetired,
I submit nomination for CMR as beta tester!
This is beyond an annoyance and out of hand right now.
- Between 5:00 pm and 7:00 pm this evening I had another mystery reboot. Also had a received call which shows in the Call History with a timestamp of "01/02/2010 23:05:35" which contradicts the working theory that the time after reboot starts as 01/01/2012 12:00:00. As of 7:00 pm the time is synced and correct again. The timestamp for the caller id on my desk phone shows 01/02 11:05 pm.
- Forgot to add a prevalent but not repeatable issue to the above list: Can't hangup a call! When on some calls I can't 'hang up', even if I disconnect the phone cord to the handset. When I do hangup the handset, I can pick up again 10 or 20 seconds later and the call is still connected. The phone port light(s) on unit are flashing clearly indicating the phone is in use. If the call is to a live person, I wait till they hangup, if I connect to some auto attendant, the only way to get out is a forced reboot. On a few rare occasions this has manifested itself by the device simply hanging in the middle of a call, and again the only option is a power cycle reboot.
- Things like the above make you want to scream and give up on the whole thing! Which this week I seriously considered doing. The only thing that stopped me was the ability to make calls directly from Gmail in a browser, and the Gmail doesn't have to have GV.
I'll be curious if anyone else sees any of these, even one, of these issues on an Obi202 with "3.0.1 (Build: 3741)"
Obviously, have you thought about regressing your firmware?
Quote from: Ostracus on March 07, 2013, 11:58:59 PM
Obviously, have you thought about regressing your firmware?
In the last few days, yes I have.
However just last week I moved from configuring the device locally to doing so via the ObItalk portal, thinking that would somehow make things better, as in contacting support for assistance. It was the portal that installed a newer firmware version (newer than is available via ***6). So I have to decide which is a better option, contacting support or rolling back and doing local configuration.
Had another crash last night with code 94. This time with build 2776. Sent a message to Obi and they responded with "Everything looks Ok. Ignore it"
I would try an uninterpretable power supply if I were getting those reboots.
Quote from: Shale on March 13, 2013, 11:12:24 AM
I would try an uninterpretable power supply if I were getting those reboots.
I have to rule that out. I have ten+ other devices (router, switches, cable modem, Obi110, analog phone, laser printer, cordless phone etc.) connected to the same circuit that do not hiccup from power interruptions.
Quote from: ProfTech on March 13, 2013, 10:57:19 AM
Had another crash last night with code 94. This time with build 2776. Sent a message to Obi and they responded with "Everything looks Ok. Ignore it"
I also contacted Obi support. Their response was enable ***27 100 Mhz duplex (already done) and then to selectively disable SP configurations, and determine if the issue goes away. The divide and conquer approach.
Hmmm... That is mildly interesting. I have CallCentric on sp1 for 2 years with no problem until now. I have CallWithUs on sp2 but it is set to not register. And Obitalk is enabled. I am only currently testing CallWithUs so could easily disable it but don't have much faith that will change anything since it isn't even registering and I don't have DID with them. It would be nice if they told us what code 94 is actually supposed to mean.
I'm getting beyond mildly annoyed by this, .... the reboots and the suggestion to try the divide and conquer approach).
I was away all of last week, and detected one reboot, and one unknown instance of I can't determine what happened because the status via ObiTalk portal was mixed up. Then after five days of uninterrupted uptime (and notable with zero calls placed and answered), and then one short call received this AM, I got a reboot an hour or two after the received call. So I guess I start the selectively disable two of four SPs and see what happens.
A 12-day update.
Using the divide and conquer approach, I have two (of four) SPs configurations disabled. Both are for Callcentric (with the CNAM with GV arrangement), and two GV SPs enabled.
Uptime has been 12 days so far, that exceeds any prior uptime duration (on this firmware release), so the obvious culprits are the two CallCentric SP services.
The devices behavior has not been 100% perfect these 12 days, though. Today I had an active call change into dead air. This is about the fifth or sixth time in as many days it happened. I'll be on a call, anywhere from 60 seconds to 15 minutes into the call the other party and I stop hearing each other.
There is no clicking on the line nor is there a hangup. In fact, I cannot disconnect the call, placing the handset down on the hook has no effect, the Obi ignores this signal and maintains the call still in progress, ... I cannot disconnect via the hook, no matter how many times I press the hook. All the while I see the Phone 2 phone port light flashing, indicating the "The phone is in use," and at the same time the Obi WebPage is un responsive, therefore I cannot do a "Remove" under the Status > Call Status to end the call. As a side note and curiosity, I see that "Remove" records the call as "Call Ended" by both parties, both columns, in Call History.
I chose not to reboot, and to wait it out and see for how long the Obi took to become responsive again. In today's case it was 60 to 90 seconds until the call hung up and I could place call again. Curiously, the Call History showed the call was ended by my phone, not by the other end.
And to add to the symptoms, today when I placed a follow up call (back into the ongoing multi-party conference call), there was an enormous amount of echo on the entire call, whoever spoke had a bad echo. After a few minutes I became suspicious I was causing it, I dropped off and dialed in again and the echo was gone. Other parties did the same so we're not sure who caused it, ... but I'm suspicious it was caused by my end.
So my next step is to re-enable the Callcentric SP services, will report back again.
It sounds like from yours and other posts that the 202 firmware has some issues. I can sympathize. I owned my 110 for about a year before the firmware was fairly solid and worked like it was supposed to, and mine was not one of the first units off the line. They were about 6 months into sales when I purchased. FWIW, Obi loaded 2776 into my unit. I disabled CallWithUs for the time being and my unit seems to be more stable now. Still using CallCentric on SP1. But I have made a few other minor tweaks along the way so hard to say what was actually going on. Stay tuned...
I reached the 14 day uptime milestone today. So I decided to carefully re-enable both Callcentric SPs.
Did so via the ObiTalk wizard for Callcentric. After doing so, made a few minor (from my pov) expert mode changes: for both CC SPs unchecked skip call screening ('cause I'm doing the GV & CC with CNAM thing), and for one of the two SPs (SP2) had to change the ring Profile to A, and default_ring to 7. Strangely, SP2 defaulted to Codex Profile B and Ring Profile B, whereas SP 1, 3 and 4 default to profile A.
By my count I have the two suspect Callcentric SPs now setup with only four small tweaks that vary from the ObiTalk portal wizard.
I hope the next update I add to this thread is to report success. If not I'm going to seriously consider giving up.
I tried several ATA's before I ended up with the Obi 110. It is the only adapter at its price point that supports the PSTN. I tried an SPA 3102 which hasn't been updated since 2009 and it was junk as far as the PSTN was concerned, and apparently no longer supported. After several firmware revs I am pretty happy with the 110 overall. I hate to say it, but maybe the Cisco SPA122 might be a better choice than the 202. It is new but several s/w revs have gone through so maybe they are getting the bugs worked out as well. Except for the 202 having Google Voice capability I think they are pretty close to apples to apples.
One more update in this never ending series of frustrations. I also want to post this before moving on to a new firmware (http://www.obitalk.com/forum/index.php?topic=5846.0;topicseen#msg37484) in case the issues just disappear ... or god forbid get worse.
In summary, it's still not fixed, but evidence is pointing to the two CellCentric SPs interfere with each other, in some as yet unexplained manner.
The details: I formally reported the issue to Obi Customer Support. Getting a direct answer, or even a response after multiple mails has been a challenge, which of course adds to the frustration. Support replied with the usual: try **0 Option 27 (100 Mp full duplex), then connect the Obi directly to my Cable Modem (no can do for days at a time in my case) and then 'try a new router'. My response to this last was "I just spent $150 on a new SOHO router four weeks ago, do I really need to try a third one?"
After some back and forth messages, many of which went unanswered and then some more prodding, they replied to change the registration periods for the two CC SPs to 600 and 615 seconds. I tried that, but it was in vain, I believe, because on the System Status page for the two CC SPs it would show expires in XX seconds, where XX was never more than 60. They did not acknowledge this in an email response (to the original 'try 600 and 615' reply), but since I was at wits end I deduced to try 59 seconds and 60 seconds, with the intent to change to 53 and 59 seconds (the greatest prime numbers less than 60) the next time I purposely reboot.
The change to 59 and 60 seconds are correctly reflected in the CC SPs on the main status page, and the conclusion here is there's a 60 second maximum registration period (for CC or all SIP providers? Nothing I could fin din the admin manual). Even more encouraging, the change to 59 seconds and 60 seems to have 'reduced' the problem, but not completely eliminate it in my uptime test so far.
After six days of uptime, I had one episode with no dial tone and unresponsive via the 192.168.xxx.yyy Obi WebPage. After about a minute or two got dial tone back, and the 192.168.xxx.yyy started to respond. Unlike past episodes, this one did not result in a spontaneous mystery reboot, and uptime is now at 8 days, which is a new record. So those two points are progress (although small), in my experience.
In addition to the change to 53 and 59 seconds, (after I see how far I can go with the uptime using 59 and 60), I think I'll add two backup DNS servers, Google Public DNS (http://googleonlinesecurity.blogspot.nl/2013/03/google-public-dns-now-supports-dnssec.html), which I think will be used in priority order ahead of my ISP's (Comcast) dynamically assigned DNS servers, based on the way I read the Admin Manual.
FYI, the maximum re-register time for CallCentric is 120 seconds. The thing is, the Obi 110 re-registers when 1/2 of whatever time you specify has expired. So the 110 will register every 60 seconds if you have it set to 120. You can go as big as you want but anything 120 or larger will cause the unit to register every 60 seconds. I looked at this a bunch a year or so ago and ended up setting mine for 120 every time. Not sure if the 202 works the same or not. The Mediatrix adapter I looked at allowed you specify how far in advance of expiration you wanted to re-register but I ended up sending it back because it kept dropping registration and wouldn't stay registered at all.
Now that you mention it, I think you (or someone else) posted this 1/2 the max time thing somewhere on here before.
My update here is the reboots no longer happen (and I'm not exactly sure why, several recent firmware releases play into this) but I still get the predecessor to the reboot, dead air and an unresponsive unit that will not 'hangup' or otherwise end a call for several minutes. Looking back at the timestamps on this thread, I've been fighting this since February, and at it's height it was incredibly frustrating.
This past weekend I setup a new approach. I previously had one Obi202 with
SP1 = GV1, SP2 = CC1
SP3 = Gv2, SP4 = CC2,
The two CC are used for the CNAM and E911.
I have a spare Obi202 available for a few weeks (from a friends and family installation that is postponed for a while), based on some things Obi support suggested to try (see above posts) so I decided to try this arrangement with only one CC SIP on one Obi:
Obi202 #1: SP1 = GV1, SP2 = CC1
Obi202 #2: SP1 = GV2, SP2 = CC2.
SP3 and SP4 are not configured on either unit.
I had high hopes for this, but alas today I got another episode of dear air while on an important conference call. The call was outbound on GV2, so CC was not in use.
I hope this was a one-off fluke, because it did not behave like the past episodes did, this one just became dead air, with no reboot, and unlike in the past I could hangup the call, however for several minutes neither GV1 or GV2 would accept an outbound call, just more dead air when anything was dialed. In hindsight I should have tried 933, which is the only outbound call I can make on a CC SIP, all other calls are incoming only on CC.
I am aiming for 10 days uninterrupted uptime as something of a huge milestone, but today's episode shattered that idea. This week is heavy on conf. calls so we'll see how the remaining seven or eight days go.
This is kind of an old thread but I thought I would post an update. After reading some posts about Callcentric issues I decided to try disabling ProxyServerRedundancy and SecondaryRegistration for Callcentric, while making sure X_DnsSrvAutoPrefix was checked. I'm happy to say the crashes have stopped. At this point I have been unable to detect any other differences between 2774 and 2776. I'm assuming the differences are minor since Obihai has never posted an update for 2776.
ProfTech - I too had been plagued with mystery reboots, often during a call.
Syslogs were likewise not able to catch anything.
My OBi110 would not display a reason code for the reboot either... but using the technique I found here of saving then examining the configuration file, I found it was 91 or 94 at various times.
My setup is an OBi110 with Google Voice on SP1 and POTS on the line port and hardware version 3.4 running build 2774. I have heavily edited some of the configuration settings, and was initially placing the blame for the mystery reboots on this.
What seems to have caused my reboot issue is that I was double-natted... yeah yeah I know it is not good, but FiOS requires their router for things like the program guide, etc... and I wanted the security of my Linksys running dd-wrt. Since I've moved the OBi to the FiOS router, eliminating the double-natting, I no longer have these mystery reboots.
-gary
Quote from: ProfTech on August 08, 2013, 07:27:03 AM
This is kind of an old thread but I thought I would post an update. After reading some posts about Callcentric issues I decided to try disabling ProxyServerRedundancy and SecondaryRegistration for Callcentric, while making sure X_DnsSrvAutoPrefix was checked. I'm happy to say the crashes have stopped. At this point I have been unable to detect any other differences between 2774 and 2776. I'm assuming the differences are minor since Obihai has never posted an update for 2776.
ProfTech, I read one of you your posts in another thread and remembered this thread. My short update here is the mystery reboots on my 202 are now completely gone. Unfortunately that is at a cost of using two Obi202 instead of one (where one should clearly work). I'm 100% convinced having two GVs and two CCs on one Obi202 is the root of the problem, it makes me wonder if that scenario has been fully vetted and tested by Obi.
A few points on your settings for ProxyServerRedundancy and SecondaryRegistration. If you use the ObiTalk wizard to setup a CC connection, it does **NOT** check the settings for ProxyServerRedundancy and SecondaryRegistration or X_DnsSrvAutoPrefix. I'm speaking for an Obi202, for reasons I can't imagine it might differ for an Obi100.
Also note that on CC support website, the manual configuration instructions for an Obi202 show to set ProxyServerRedundancy and SecondaryRegistration but not X_DnsSrvAutoPrefix. Also on CC's website, their manual configuration instructions for an Obi100 do not show any of the three fields ProxyServerRedundancy, SecondaryRegistration or X_DnsSrvAutoPrefix. CC's website does not have a section for an Obi110.
So we've got Obi and CC's instructions mot matching. I'd question if CC's website is fully up to date. If you recall back in Fall of 2012 they had an outage due to an attack, and I recall some of the interim work arounds they said to use were (set/check) the fields you mention. After the attack/outage ended somewhere they said revert to the prior settings.
Also, one other tidbit I found in setting up my two different Obi202s. For one 202 I'm using my ISPs DNS server entries. For the other I superseded the DNS servers and set them to Google's 8.8.8.8/8.8.4.4. Interesting observation is the last octet of callcentric.com resolves different under those two DSN servers, for my ISP's DNS servers the last octet is ".179", for Google's DNS servers the ;last octet is ".164". It's consistently been that way since the last post I had in here, May of this year. I'm not sure that is a problem, but I'm curious and it's worth noting.
EDIT: In 2nd paragraph, to it does
**NOT** check the setting...
I did quite a bit of testing on redundancy a year or so ago and according to what I saw, X_DNSSrvAutoPrefix seemed to be automatic when redundancy is turned ON. Makes sense. However, when I turned redundancy Off, the unit was registering to port 5060 if X_DNSSrvAutotPrefix was left Un_Checked. Should be 5080. Again, sort of makes sense based on what I saw before. So I suppose turning off redundancy in your 202 could solve the issue there. I can only speculate either CC isn't doing it quite right or the Obi isn't handling redundancy correctly. Like you said, CC web page doesn't say anything about turning redundancy ON for the 100. Either way, it is working great without it. :)