ring: repeatedly getting [Ring] Failed to reach Ring server at https://oauth.ring.com/oauth/token. connect ECONNREFUSED 127.0.0.1:443. Trying again in 5 seconds...
Bug Report
Describe the Bug
About a month ago, I started getting HomeKit not being able to reach the Ring Pro video. I had stayed on an older version of the plugin for a long time. I decided to upgrade to latest (and generated a new refresh token).
Every 5 seconds I get this: 8/30/2021, 1:09:21 PM [Ring] Failed to reach Ring server at https://oauth.ring.com/oauth/token. connect ECONNREFUSED 127.0.0.1:443. Trying again in 5 seconds…
I saw a similar error, but not with trying to connect to 127.0.0.1:443. I don’t know why it’s trying to do that.
To Reproduce
Install homebridge-ring 9.21.0 via HOOBS. Create refresh token and add to configuration. Save to restart HOOBs/homebridge. Get repeated errors. Persists after Pi reboot.
Expected behavior
normal functionality without error.
Screenshots/Logs
Additional context
I have removed and re-added plugin, I have tried earlier versions of plugin. Each version has some other odd problem. Ultimately it’s not working anymore with this consistent reproducible error now.
Homebridge Ring Config
{
"refreshToken": "myTokenHere",
"sendCameraMotionNotificationsToTv": true,
"plugin_map": {
"plugin_name": "homebridge-ring"
},
"platform": "Ring",
"hideDeviceIds": [],
"locationIds": [],
"onlyDeviceTypes": []
}
Environment
- OS: Raspbian
- Node.js: v12.14.1
- NPM: 6.13.4
- homebridge-ring: 9.21.0
- homebridge: ?
- hoobs: 3.3.12
Any help would be appreciated so I can use Ring again with my iOS devices and AppleTV.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 30 (6 by maintainers)
I had the same issue (oauth.ring.com resolving to 127.0.01 in error logs). I upgraded my other home bridge plugins one by one and found that after upgrading the homebridge-smartthings plugin, the homebridge-ring functionality started working.
I migrated from homebridge-notification and now everything works as expected https://github.com/ilcato/homebridge-ifttt. homebridge-ifttt offers more functionality than homebridge-notification so there are no drawbacks, only advantages.
@dgreif This aligns with my comment above that these problems were most likely caused by use of other addons using outdated dependecies which were patching the NodeJS https functions and thus breaking got.
Taking a quick glance at homebridge-notification, it looks like it hasn’t been updated in ~5 years and depends on iftttmaker which itself depends on an ancient version of https-proxy-agent which is known to cause this error with got. My guess is any number of plugins that haven’t been updated in recent times could cause this issue, not just homebridge-notification.
@dgreif After recreating the bug multiple times I am confident that the triggering source is causing the issue. I have shared a link to a screen recording to your FB account where you can see it happen. Let me know if I can share more information with you!
Hey @mkellsy, thanks for looking into this issue! It’s been on my radar, but seemed non-specific to the plugin so I wasn’t sure where to start. Hopefully your research leads to a new image with a fix!
Regarding the refresh token, the plugin does look at the
expires_infield when a new auth token is received - https://github.com/dgreif/ring/blob/master/api/rest-client.ts#L115-L121. It also watches for requests that fail authentication - https://github.com/dgreif/ring/blob/master/api/rest-client.ts#L328-L331. Both of these mechanisms have worked reliably, and I don’t think they are related to the issue at hand.Also big thank you to @tsightler for carrying this conversation along. I appreciate your help, especially given this is not directly related to your library 😄
I have done some extensive testing on this. I did this test with both the HOOBS image and the Homebidge image, both have the same issues with this plugin. The good news is, I found that this doesn’t affect the operation of the plugin.
From what I can tell this plugin fetches a new refresh token on a timer. I think this can be slowed down because I think a refresh token is good for 14 days. A better approach, is to read the JWT token and find out when it expires. Then fetch a new refresh token if it is close to expiration. The downside of this is, if the device if off when the token expires the user will need to login again.
Anyway, I tested my network first. I always look at the network first as it is the most likely candidate to fail first. My network is a Amplifi Alien WiFi 6 mesh connected to a gigabit fiber. I checked trace routes to oauth.ring.com and looked for latency in any step along the way. I also tested latency on a loaded network vs an idle network (streaming Netflix of not). I found out that my network is fine, no issues here.
I then moved to the device its self. To test this I ran this plugin on a Pi 4, Pi 3 and a Debian VM. I noticed that I was getting the same results on Pi 4 and Pi 3, but not the Debian VM. Remember that I tested this on both HOOBS and Homebridge. This led me to believe it is something in the image because the Debian VM was setup from scratch. Now realize HOOBS and Homebridge are related, even when it comes to the image. Both HOOBS and Homebridge use the same Pi-Gen tool to make the images. It makes sense the two would act the same.
I started to look into the drivers on Raspbian from the Pi-Gen tool. I started to notice that I was getting intermittent network “brown-outs” where the WiFi would not see the outside world, but would remain connected. So I looked into resolv.conf, network-manager, dhcpd and all the other systems that control the network on the Pi. Everything was default. HOOBS and Homebridge don’t modify the network out side of using WiFi-Connect, and both images use the same exact tool for this.
The only thing left is the Broadcom firmware its self. I have been building a new HOOBS image based on Debian directly (not Raspbian) and a completly different build process using vmdb2. Broadcom support has been added to the Linux kernel, and the firmware package that Raspbian uses is no longer needed. This new image is not ready yet, but I will update you all as soon as I am able to test it on my setup.
My first thought when I see this is that there is some type of DNS issue as there’s no way that oauth.ring.com should be resolving to localhost, and I have no idea how this plugin could be causing that. Any chance you have a pi-hole or some other DNS blocking tool which is inadvertently blocking Ring servers from resolving as I know some of those systems return 127.0.0.1 as their “blocked” mechanism, although I think pi-hole uses 0.0.0.0.