News:

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

Main Menu

TCP connection to 125.141.125.74 failed

Started by GreenView, October 05, 2017, 02:07:42 PM

Previous topic - Next topic

GPz1100

#40
Here's something interesting.

Test was done by forcing dns on the pc to 8.8.8.8 and the comodo dns 8.26.56.26.  Each nslookup was repeated at least 30 times, noting the resolved ip for talk.google.com.  Here's the values received.  Ipconfig /flushdns was run after changing dns server setting.

-=}nslookup talk.google.com

Using 8.8.8.8 for dns server
results:
173.194.192.125
209.85.234.125
74.125.69.125


Using 8.26.56.26 for dns server
results:
74.125.133.125
66.102.1.125
64.233.184.125
74.125.71.125


During the test, the values would often repeat, but the above were the unique values resolved. Note that there is *NO* overlap in results between the two dns servers.

Next, to put this theory to a test, I forced talk.google.com to point to each of the 4 ip's in my firewall - albeit a bit limited because the firewall does not support a host dns pool (multiple ip's for a single FQDN) so each ip had to be added manually then tested.

I then pointed the obi to my firewall's dns service.  Rebooted (several times after each ip change for talk.google.com).

Results:  After each and every reboot the obi connected just fine to GV.  No backing off message.

Conclusion:  First, it's unclear why comodo dns is the only one resolving to these ip's. I tried opendns, 8.8.8.8 and 4.2.2.2.  4.2.2.2 did come up with a few other values but it's unclear if those would work or not. I believe there may be some misconfiguration on google's part.  However, it doesn't doesn't address why gv works just fine through the pbx and hangouts.

I looked at the source code for the freepbx gv module - https://github.com/FreePBX/motif/archive/release/12.0.4.2.zip .  Looks like it just references talk.google.com - functions.inc.php file, line 160.

Could be the _way_ obi is authenticating with gv is different from that of the pbx module.

Second, it's unclear exactly how talk.google.com is referenced by the obibox.  Is it using strictly talk.google.com, or something else.  Is there a pool of talk.google.com hostnames (talk.1.google.com?).  Based on the results, I'd say it's simply referencing talk.google.com.

It will be interesting to see whether the fix involves a firmware update..




Taoman

Quote from: GPz1100 on November 02, 2017, 10:28:32 AM

It will be interesting to see whether the fix involves a firmware update..


Indeed. And if it does I would assume that means all 1xx EOL devices are SOL.

GPz1100

http://check-host.net/check-dns?host=talk.google.com

All those working IP's show up on European servers. I bet some google pixie dust will fix this.

kelemvor

Howdy,

I have this same error so came looking for an answer.  Lots of ideas are being tossed around and some work for some people and some work for others.

I'm currently set to DHCP but I do have 8.8.8.8 and 8.8.4.4 as my DNS servers.

My error shows: Backing Off (1s):TCP connection to 74.125.132.125 failed

Not sure which thing I should follow for the best results or if it's best just to wait it out?  Any thoughts?  It's been down for a few days now.

pro450

Quote from: OBiSupport on November 02, 2017, 08:02:58 AM
Modify the DNSServer1 parameter value:  Select System Management / Network Settings / to DNSServer1 / input 4.2.2.2 (or 8.8.8.8 ).

I don't have "Network Settings" under "System Management".  Under "System Management" I see "Auto Provisioning" and "Device Admin".  The only place I see to change the DNS is under "Router Configuration" then "WAN Settings".  It looks like I have to uncheck the column where it says "OBiTALK Settings" and then enter the DNS value.  I would assume that it would not override the DHCP values, but I'll give it a try.

So then when I enter 4.2.2.2 in the DNSServer1 field and save it, when I go back into it the field has a red exclamation point next to it.

n0xlf

#45
This does not appear to be a DNS issue, or at least one that isn't Google's fault.  The authoritative DNS servers for google (ie - the servers that other DNS servers query) are ns1-4.google.com, which is the place to look for the "right" answer.

If you query those directly (216.239.[32,34,36,38].10), or put them in as the name server(s) in your Obi device, it still [mostly] doesn't work.  If you test these, don't leave them there as they will only resolve google.com IPs and nothing else so you'll break Obitalk, FW updates, other SIP services, etc.

At this point it's just luck if you happen to get a working GV server via whatever DNS you are using.  If you are desperate for service, these IPs are the most likely to get it working for you though, as the responses constantly change based on Google's load balancing and aren't cached like all other DNS servers.  Put one of these as the primary DNS and a public DNS server as secondary and that gives you the best chances for everything working for now.

GPz1100

For me and a number of others that have posted, the only dns servers that allow gv to work seem to be

8.26.56.26   
8.20.247.20

I've had no luck with 8.8.8.8, 8.8.4.4, 4.2.2.2, opendns, isp's dns or some others i've tried.

I'd say at least for this issue, obi's knowledge base article is outdated.

pro450

#47
Performed the instructions from OBiSupport.  When I can catch it connecting in the OBi dashboard, it says "Connecting to 74.125.69.125" for about a minute, then displays "Backing Off :TCP connection to 125.69.125.74 failed"

kirk


I don't have "Network Settings" under "System Management".  Under "System Management" I see "Auto Provisioning" and "Device Admin".  

So therefore the instructions are confusing at best, thanks!

Any ideas?  Thanks

GPz1100

Quote from: pro450 on November 02, 2017, 11:17:35 AM
Performed the instructions from OBiSupport.  When I can catch it connecting in the OBi dashboard, it says "Connecting to 74.125.69.125" for about a minute, then displays "Backing Off :TCP connection to 125.69.125.74 failed"


Look carefully at the numbers.  The IP in the backing off message is reverse of the connecting.

@Kirk, System management, Wan settings for the obi200.  For obi202, router configuration, wan settings.

kelemvor

I just tried:
DNSServer1    8.26.56.26
DNSServer2    8.20.247.20

Still getting:
Status   Backing Off (4s):TCP connection to 74.125.206.125 failed

W7VFR

Switching DNS servers fixed the problem for me too! Yay! Thank you

kirk


[/quote]
@Kirk, System management, Wan settings for the obi200.  For obi202, router configuration, wan settings.
[/quote]

Thanks @, GPz1100 --  OBI202 here.  Under Router configuration>wan settings, There is DNS server 1 and DNS server 2. Both are blank, does not allow me to enter a number, regardless of checking or unchecking associated boxes.

Thanks for the help, frustrating, obi support seems to be clueless with the faulty inaccurate instructions.

ceg3

Thanks!  I didn't think it included me until you pointed out the edit.  I have a 510 device, but I've had no backing off issue.

GPz1100

@kelemvor  Give it a minute or two then refresh the status page.  I've seen a number connection attempts where it'll show backing off, then in a minute or two connect successfuly.

@kirk It may be because you have it set to use obitalk to configure the device.  Obitalk is the web portal where you enter your gv info, token created, etc.  It then 'pushes' the configuration to your obi device.

Initially when I did the setup here (obi200 & 202 boxes), after getting gv tokens provisioned I disabled all the obitalk settings, auto firmware updates, and anything else that talks back to the obi mothership. All my changes are done directly on the obi device itself. 

Without going through this disabling process on your device, I think you can access similar settings using the 'obiexpert' button on the obitalk dashboard.  Click on your device on the dashboard.  Way at the bottom look for Obi Expert Configuration, click it, then click ok.

Click on Enter Obi Expert. In the left margin you should see this.
.

Note the two boxes are uncheck for each dns row.

WARNING: DON'T TOUCH ANYTHING ELSE OR ANYTHING YOU'RE NOT FAMILIAR WITH.  There's nothing in there that will brick it, but changing certain entries will make it inoperable, requiring a factory reset.

I think the obitalk portal is a double edged sword. It's great for ease of initial configuration and for non tech people. It's also required to create the gv tokens.  Without this gv will not work.  There is a way of generating these tokens manually but obi doesn't provide the necessary information to do so.  Also, there is no place even in obiexpert mode to enter these tokens. Although the obi box is has embedded linux, shell access is denied.  One of these days I'll see if I can connect to it via a serial console, but that's beyond the scope of this discussion.

drgeoff

Quote from: Taoman on November 02, 2017, 10:44:45 AM
Quote from: GPz1100 on November 02, 2017, 10:28:32 AM

It will be interesting to see whether the fix involves a firmware update..


Indeed. And if it does I would assume that means all 1xx EOL devices are SOL.
I don't think you should assume that if a firmware update is necessary, Obihai would not provide one for 1x0 devices, despite their EOL status.

And I'm far from convinced that this current problem is of Obihai's making.  I'm keeping an open mind until the cause is identified and proven.

kelemvor

Yep.

I can confirm that after changing it to the Comodo DNS entries, my phone is now working. Of course, the first call I got was from a Telemarketer.  Maybe I'll just change it back and enjoy the silence.

GPz1100

Quote from: drgeoff on November 02, 2017, 12:24:59 PM
And I'm far from convinced that this current problem is of Obihai's making.  I'm keeping an open mind until the cause is identified and proven.

I'm sure it's not.  Change probably originated with google, now to figure out how to make it work for everyone using the least invasive method.  We got our obi's in the last 2 years, after oauth 2 became a requirement.  If I recall correctly sometime in 2014 this change did require a firmware update.

Taoman

Quote from: drgeoff on November 02, 2017, 12:24:59 PM

I don't think you should assume that if a firmware update is necessary, Obihai would not provide one for 1x0 devices, despite their EOL status.


http://blog.obihai.com

QuoteHowever, any services that cannot be supported with the current software (firmware) will not work on the OBi100 and OBi110.

I infer (assume) from that statement there will be no new firmware for 1xx series. Do you disagree?


drgeoff

I infer that new services such as things like OBiEXTRAS will not be backported into an update to support them. And I expect that any minor bugs which have no significant effect on functionality will not be fixed.

I don't agree that Obihai will never under any circumstances make an update for 1x0 devices.

If, and it is a big if, the current GV problem is Obihai's fault, the cost to them of making a new 1x0 firmware incorporating the same fix that they need to make for 2xx ATAs, 10x2 phones (and 5xx models?) will be minimal compared to the cost of lost future business if they do not.