Mike, can you share the list of NTP servers that it attempts to contact? I can try spoofing one or more of those and see if it accepts it.
I’d like to know too, thanks.
If NTP is the only access that it needs, I don’t get Wyze’s reasoning to make this a requirement.
Just what I’m going for. In my viewpoint, if a device functions poorly on its own in all possible combinations then it has a code problem.
As a programmer that’s how I do things. It should deal well with all unexpected events. One really doesn’t know what issue this could be causing in the end if it can’t deal with a full block, failures, etc.
Lets just say NTP failed for whatever reason and the cam couldn’t deal with it? Problem? Yes.
To me, if it can’t deal with a full block yet still stream rtsp for a while (and even at all) then it has a problem and doesn’t work right. That might be what its doing and its messed up.
I don’t play around
(If its going to have an issue then it shouldn’t start the rtsp stream in the first place. eg it should already know if its fully blocked.)
However, I do still need to double check my test on the AP router as well and see how things go there. It would be interesting if it just happened to make a difference.
I remember a while back I ran tcpdump on my router to grab packets going between the Wyzecam v3 and the internet, and there were not only requests to an NTP server but also to wyze’s own API servers so it may not be sufficient to spoof the NTP server response to prevent the cam from disconnecting.
Requests to their API servers are over HTTPS and I attempted to use ssldump to grab and decrypt data but I didn’t get very far.
From an old pcap file I’m seeing that the NTP server is clock.fmt.he.net, but it appears DNS resolution on the cam is hardcoded to reach google’s DNS servers (220.127.116.11). Might be possible to solve with DNS redirection at the router level to resolve to a server on the internal network, but again may not be enough to prevent the connect/disconnect dance.
Most encryption/connectivity is based off of certificates. Certificate have a valid life from and to. If the camera boots and does not have a battery backed clock the likelihood it will default to the clock chips default (maybe 1980 even still for most new clock chips) or the software build time, any which way it will be way out of sync with the real world, so it cannot say the certificate is valid and make a secure connection. Hence NTP is one of the 1st things that happen when the system boots up. Its not just Wyzes reasoning, just about all embedded devices that do not have a battery backed clock behave the same.
Yes, it tries to do a number of things - connect to Wyze’s P2P partner’s system, pulls time from NTP, uses Google’s DNS with the IP hard-coded as you saw. If it can’t get to what it wants at first, then it tries various other things like the other NTP servers that I mentioned above. Not sure that NTP is all that’s required to keep them up if blocked. Have to try to set up here to test that.
I’ll try again when I get a chance. Pretty sure that Google’s was on the list and pool.ntp.org. As above zedramus mentions clock.fmt.he.net. I don’t recall seeing that one but may very well have been in the list of 10 or 20.
Hi, Where can I get the firmware? Wyze Cam v3 RTSP firmware, there does not appear to be any links on Wyze website.
At this point, we might as well say Wyze is officially no longer supporting RTSP. I will no longer recommend this brand.
This link posted above by Waterbug takes me directly to the file.
First link in this thread.
Try these for NTP servers:
Had to do it a different way so don’t think that I got all of them but all of those are tried on startup when blocked.
Thanks for those. I hope to be able to try them this morning.
So I was able to redirect the NTP server to a local host. I use Pihole and just pointed clock.fmt.he.net to my local time server in the local DNS setup. Works fine. Cam picks up the correct time and no longer searches for a time server. Pfsense (or various other ways) should be able to do the same.
But the cams still disconnect every few minutes when blocked.
In addition to an NTP server, they also continually look for the following hosts:
w w w.google.com (had to insert spaces so forum doesn’t create a link)
You could redirect these domains in the same way but without something providing whatever it’s looking for there, then it won’t do much for you.
Note these are only the hosts that show in DNS lookups. I’d have to change things around too much on my network to pick up whatever attempts are made using an IP address directly. As I said earlier, I have seen that the cams will look for Google’s DNS at 18.104.22.168 if it can’t find one, so at least some of that does appear to happen.
I imagine making this work isn’t high on Wyze’s list. In fact, they may actually not want it to work. They derive a lot more money from subscriptions than from hardware. Why make something that doesn’t generate a monthly annuity?
Here are my thoughts about this. Wyze may not make direct money out of RTSP but if they keep all the RTSP users happy, we will still stay their customers, we will still use the Wyze App to configure the cameras, we might buy more stuff from Wyze and even if some of us don’t, we will certainly contribute to promoting the Wyze Cam on many forums, with friends, family etc…
Since RTSP is not meant for everyone, most new customers would probably go for the Wyze cloud service. In other words, while we talk about Wyze, we don’t talk about the competitors Amcrest, Foscam etc… so IMO it’s still a win-win.
Yup, as I mentioned in an earlier post I spent a bit of time trying to get ssldump working to decrypt the requests/responses between the cam and the API servers just so I could spoof the request/response cycle but could not get it compiled on my router. Aside from the hosts already mentioned the cam also tries to resolve
kinesisvideo.us-west-2.amazonaws.com - possibly for video processing or machine vision
wyze-iot.s3-us-west-2.amazonaws.com - retrieving/storing something in an S3 bucket
It’s interesting that the cam tries to resolve www.google.com, It’s not even any of google’s APIs. I have a hunch it may be using the google homepage as a way to test internet connectivity - if it receives a timeout from such a commonly used service then it assumes internet connectivity is gone, and tries to re-establish connectivity by reconnecting to wifi.
Following on from this it may be worth it try have the google domain resolve to a custom server in the internal network that responds with data and a 200 OK for any GET requests. You’d probably want DNS resolution rules per MAC unless you never want to use google.com in the household.
This is great info and thanks to @MikeA , @zedramus , and others for sharing, even if it’s essentially a fool’s errand at this point. I do wonder why no 3rd party version has emerged.
Yeah, would require a lot more effort than I’m going to put into it. Probably right about the Google call. I tried pointing that to a local server as a quick test too. Still needs more to stay connected. Which isn’t all that surprising given that it’s normally connecting to their P2P network, checking credentials, subscription status, etc. Still appears to be trying to do all of that even in the RTSP version. They likely just added the RTSP functionality to the same code without necessarily adapting everything required to function completely independently.
Kind of interestingly, if you let the cam out for a moment then most of the calls out stop. When I’d looked once before you can see that once connected it sets up some outgoing and incoming port connections. I can see the returns trying to come in from outside on my router. If blocked, those can’t happen but the calls to set them up seem to stop. Still now and then checks the NTP. The one call that I see that seems persistent after is that about every 35 seconds it tries to get to api.wyzecam.com. So maybe whatever is missing could be found there.
I don’t see the calls to the hosts that you note for the cam when blocked even after it’s let out briefly. For another cam running unblocked that I let out to test I do see similar connections made to:
I altered the leading part of the names with xxxxx at the end since that may point to mine specifically. And again I’m just looking at calls made out through my local DNS by name and I’m not looking all that hard so likely missing some things.