News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

SIP phones no longer connected after 3.2.1 (Build: 5794EX) Saturday 1/21/18

Started by BlakeN, January 21, 2018, 05:58:11 PM

Previous topic - Next topic

BlakeN

Hi All,

       Any help would be greatly appreciated.  It appears that both of my OBI 200s were updated automatically with software yesterday [3.2.1 (Build: 5794EX)].  After the update neither of my SIP phones will connect - found this way when I entered my office this evening.  After research of forum see that updates to OBI 200 were pushed yesterday.  My last call received on my phone was yesterday.  I verified and current s/w seems to match.  Both OBIs external lines are connected just fine (2 goggle voice and one Anveo).  I am getting Failed(Authenticate) errors on Cisco phones.  I have two OBI 200s with two lines each.  I have Cisco SPA514G phones connected to them - I believe one line of each OBI to each phone (2 lines programmed on each phone).  I have been using these without any trouble for years and have made no changes to config.  I did try rebooting my router, phones and Obi devices with no resolution.  Thanks in advance for any advice. 

ProfTech

Wow.  :( Did you happen to have a backup of the .xml config for the Obi's? You could make a new backup and then compare/diff it to the old one.

RFC3261

Quote from: BlakeN on January 21, 2018, 05:58:11 PM
Thanks in advance for any advice. 
Not exactly a "fix" (just a workaround), but it seems that adding fw.obihai.com to your bind RPZ zone(*) (to prevent the device from updating) and then force loading one of the previous firmwares is a workaround for now.  SIP phones work again.

We will have to wait and see if this was an accidental breakage that will be resolved with a further firmware update, whether one will be forced to stay on the older firmware (forever?), or whether one will need to investigate alternative solutions (other than the OBi devices).


(*) bind (named) RPZ zones can be used to block DNS requests for specific or generic targets.  They are used by some to block lookup to known bad actors (or advertisement sources).  As is typically the case, there are typically many ways to accomplish the equivalent thing, but when one is already using RPZ, it becomes an obvious choice in these cases.

BlakeN

Hi All,

      Thanks for the ideas.  I do have a backup.  I set this up in 2015.  I don't see any real differences in the configuration.  Everything carried through.  As I said I tried reseting passwords on both sides in case that did not carry through.  Thats not saying there is some obscure setting somewhere.  There are lots of parameters as you know.  The XML formatting changed between exports in 2015 and now so the diff is a bit hard to read - meaning it is not easy to see the differences. 

      Is the November 3-2-1-5757 (10.4MB) version the one I want?

     Can I blacklist fw.obihai.com in my router to accomplish the same thing?  I am not familiar with RPZ zones.

     Thanks for the help!

TheLliez

Same problem here.   Something happened this weekend.  My 202 is on firmware 3.2.1. and my SIP phone does not register anymore.


RFC3261

Quote from: BlakeN on January 22, 2018, 12:29:01 PM
Is the November 3-2-1-5757 (10.4MB) version the one I want?
The 5757EX version is working for me (I suspect the non-EX version works too, but I have not tested it).
Quote
Can I blacklist fw.obihai.com in my router to accomplish the same thing?
Individual routers vary in terms of their capabilities.  Blocking the DNS name (in my case via RPZ) appears to work for me for now.  Blocking the IP address probably would work too, but may or may not work long term (the DNS name may change to a different IP at some point).  Removing the OBI from the portal entirely also reportedly works to prevent auto-firmware updates.

If one presumes that one only needs a temporary solution (i.e. OBi will address the issue), any solution is probably adequate for today (and sometimes it is all about the now).

Blake4913

Reverted to Nov 5757EX version and that solved the issue.  It is goofy they both have the same version number.  No config change needed.  Just loaded software and it all came back to life.  Now to see if my black list in my router firewall will keep software from updating again.  Fingers crossed for now.  Thanks again for the support.  I sent in a support ticket to Obi.  Hopefully they will resolve in new code.

Blake4913

hmmm - I got the "Your OBi device doesn't have a valid support coverage so we're unable to view anything further on this device." response.  I sent a very nice reply even though after spending about 4 hours of my time troubleshooting this I was not real happy with the response.  If one of you have a device under warrantee or have Premium support it may be worth putting a ticket in.  It appears Obi may still not be aware of the issue.   

RFC3261

Quote from: Blake4913 on January 22, 2018, 01:41:47 PM
hmmm - I got the "Your OBi device doesn't have a valid support coverage so we're unable to view anything further on this device." response.
Pretty sure that is the new normal response (close to reflexive?) for any device without a support contract.
Quote
It appears Obi may still not be aware of the issue.   
Possibly.  My guess (with zero evidence) is more likely that internal engineering is aware of it one way or another (as OBi once documented how to do the configuration (in a blog post long ago taken down) one would think they would expect some people were doing what they said to do), but that the support group has a policy to not invest support resources to even check unless you have a support contract.

If I had the time to invest (I certainly did not invest anywhere near 4 hours like you did) I might pay the $10 just to force a response, for $10 is less than two designer coffees.

BlakeN

Trust me - I thought about saying I would be happy to pay them $10 to fix it.  I put this together about 3 years ago.  It probably took me 2 hours just to remember what I had done even though everything was backed up and I had drawn diagrams and tables of IP addresses, etc.  It sucks to get old.  But hey, it is better than paying Verizon $70/month for a POTS line.  Thanks again for your insight!!

RFC3261

Quote from: BlakeN on January 22, 2018, 04:23:18 PM
Trust me - I thought about saying I would be happy to pay them $10 to fix it.
There is the rub.  Paying them $10 means they will answer the question, not that they will fix anything (everyone paying for service deserves an answer, sometimes the answer is no, and sometimes the answer is hell no).

[conjecture (zero value)]
I think some (including I) hope the answer will be another firmware update that restores the functionality they themselves documented, but times change, and perhaps that is no longer a supported configuration (in which case it would be nice if they said that, but they have no requirement to do so).  That the blog entry was disappeared does raise an eyebrow, but given the complexity of the configuration (and I am guessing the support cost to help people work through it (that you and I and a few others managed it probably show the exception that proves the rule that it was not trivial)) that may have simply been a prudent business decision.  Of course, OBiPLUS made it easy to configure one/two SIP phones.  But they explicitly removed that too (at least for the "free" service).
[/conjecture]

TheLliez

Since the update I get the following on my phone log:   
Registration failed User: xxxx, Error Code:480 Temporarily not available

Is there a log on the obi202 side?

LarryDP

Same issue with OBi 202 and 2 Polycom IP335 phones not registering. I made no change. Obi, what's the fix?

LarryDP

Same issue with OBi 202 and 2 Polycom IP335 phones not registering. I made no change. Obi, what's the fix?

ProfTech

What firmware was in your 202 before? I believe a couple of users reported they were able to (re) load 5757 to correct the issue. You may need to permanently remove the Obi from the portal to make the change "stick" though. If you remove it from the portal be sure and disaable all of the auto provisioning and disable obitalk.

RFC3261

Quote from: LarryDP on January 25, 2018, 08:32:03 PM
Obi, what's the fix?
OBi staff (at least in the general case) does not read/respond on this forum (yes, there are exceptions, but do not count on it).

If your device is still under a warranty or a support contract (or you are willing to pay the $10 fee to obtain a new contract) open a case to get some sort of formal response.

Or you can try to approaches reported to be successful earlier in this thread (although, as with all else, your results may vary).

RFC3261

FWIW (in case someone has an open ticket with OBi, and wants to send some addtional info), I took a look at the traffic on the wire (well, actually the logs).

It appears that the new firmware is responding to the first unauthenticated registration request with the expect 401 (not authenticated), asking for authentication with an interesting WWW-Authenticate string of the form:

WWW-Authenticate: Digest algorithm=MD5,nonce="37b7b4ad3BCEF40E",opaque="f66fc17e4fff9789",realm="pnn.obihai.com",nonce="5E7F538C",response="5E7F538C5E7F538C5E7F538C5E7F538C"

The old firmware replies with:

WWW-Authenticate: Digest algorithm=MD5,nonce="7fdddb54F4FF4579",opaque="5aafd8f577bcdc0d",realm="pnn.obihai.com"

Note that the new firmware is sending two nonces (which it really should not), along with a response value (which should not exist) which is just the second nonce value repeated 4 times.  It would appear my SIP phone is replying using the second nonce value (which is arguably correct (use the last value, based on Postel's law))), but I am guessing the OBi is calculating the values with the first.

Anyway, I see a bug.

TheLliez

Great detective work looking at the WWW-Authenticate.

BTW, how did you guys downgrade?  I went back to 3.1.1 (Build: 5774) but that did not resurrect my phone.

Did you have to reset to factory the 202 before the update? 

LarryDP

Reverted to Build 5757 available at fw and problem solved. This doesn't say much for Obi QA and customer care that this has gone on for a week. Polycom needs to fix or I'll go elsewhere.

RFC3261

Quote from: LarryDP on January 29, 2018, 08:54:14 AM
This doesn't say much for Obi QA and customer care that this has gone on for a week.
Well, has anyone actually opened a support case with a supported (under contract) OBi?  I have not (I don't have any OBi's under contract).  You can't expect fixes if there are no open support tickets (and OBi seems to have been rather consistent recently in closing tickets with no further process if you do not have a valid support contract; even if they agree there is a bug (unknown), you don't prioritize such fixes if no one that is paying for support is asking for it).

As far as QA, from long experience, I know you that it is not atypical to tend to test in QA things that are normal/expected cases, and a few you think could be issues, and then tend to add things only later that you failed to test in the past and had caused issues with new releases.  It is possible configuring an OBi with SIP phones was not in the test harness (it just worked).  Perhaps they will add it to future QA testing.

And (to play devils advocate), if they do have a QA process, you can't expect a new release before the fixes have gone through QA.  A week might be quick for their QA process (in the telco world an agile development methodology has not been typical).

Personally (again, since I have a fairly trival workaround) I am willing to wait for a few weeks with a possible new firmware update to see what happens before escalating.