See earlier in the thread, it does work (to a certain extent, and with some caveats) with cameras, at least until your authentication runs out.
For me it is a non-starter as the cams are on an isolated network so they can only be reached by “tromboning” through the internet.
Edit - sorry was discussed toward the end of this thread (I didn’t think it worked either but you just really have to force it)
Interesting. I had, of course, disabled isolation and switched my phone to the IoT network but the Wyze App gave me the “thanks for playing… sorry not gonna work for ya” 
The reason i had mentioned this because construction hit a fiber line, so I was down 12 hrs (house wise) and I had my thermostat locked so the adult kids would stop changing the settings and I needed to kick it down a bit as it happened to be extra hot that day in FL. I have a MiFi (thanks to work…shhh 
) so my phone and computers had internet but no access to any smarthome IoT devices.
But thanks for bringing the post, i clearly missed, to my attention. Thinking in terms of the typical average, non tech savvy user, it would be great if the app somehow had the ability to recognize loss of internet connectivity and automatically allowed you to at least view things without having to enable/disable this or that.
It is a common issue with phones, they’re not great at managing two networks, they want to use one, and if that goes down, use the other. So when the wifi goes to “no internet access” it just wants to send everything via mobile data, including DNS lookups that should be hitting your local DNS server (your router). So you can access the cams by IP but not hostname, which I’m assuming is what the app is doing.
Even after disabling mobile data, it was pretty buggy due to many things wanting to access the internet. These are cloud cams after all, in reality they’re just designed to be reliant on the internet. Obviously NVR based systems are more robust but more expensive too.
There are things like mDNS and caching the cams private IPs etc they might be able to do, but I doubt it is a priority for them, especially when they’ve actually taken steps in the other direction (like getting rid of RTSP).
I believe the main thing is the authentication requires the internet.
Using modern authentication methods that allow for single sign on and all the other security features wyze has on your account, it’s just not possible (or at least practical) to do that locally. It relies on secrets only the servers know and cannot be shared elsewhere.
It may be possible to CONTINUE viewing your cameras when the internet goes down, as long as you already started the session and your authenticated, but probably not for very long as I’m sure it will time out.
I believe as long as the cameras themselves have authenticated recently, the app will authenticate to them. However yes, it seems it will time out after a certain number of hours from when they last authenticated.
I love all the apologists in this thread that try to justify Wyze screwed up completely untrustworthy protocols they use for these cameras. Wyze lists the ports that are required for the cameras to operate at https://support.wyze.com/hc/en-us/articles/360031479511-What-ports-are-necessary-for-Wyze-Cams-to-operate#:~:text=Here%20is%20a%20list%20of%20the%20necessary%20ports%3A,TCP%3A%2080%20Local%20timelapse%20download%20Timelapse%20TCP%3A%20123. I have a connection going to naturecuredhule.com on port 8000. 8000 isn’t on the list of ports that Wyze lists in their document. I’ve also seen it connect to that site using port 10001, which the document states is used for P2P streaming. It says in the document that it’s used for “Local live streaming over WiFi”.
whois says that that host is registered in Iceland, but, I also did a search on Google and it appears that there is a business under that name in India.
root@wireless:~# whois naturecuredhule.com
Domain Name: NATURECUREDHULE.COM
Registry Domain ID: 2923549457_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Updated Date: 2024-11-09T11:23:45Z
Creation Date: 2024-10-08T10:41:15Z
Registry Expiry Date: 2025-10-08T10:41:15Z
Registrar: NameCheap, Inc.
Registrar IANA ID: 1068
Registrar Abuse Contact Email: abuse@namecheap.com
Registrar Abuse Contact Phone: +1.6613102107
Domain Status: clientTransferProhibited EPP Status Codes | What Do They Mean, and Why Should I Know? - ICANN
Name Server: NS07.DOMAINCONTROL.COM
Name Server: NS08.DOMAINCONTROL.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form: Submitting a Complaint to ICANN Contractual Compliance - ICANN
Last update of whois database: 2024-11-10T16:06:20Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
NOTICE: The expiration date displayed in this record is the date the
registrar’s sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant’s agreement with the sponsoring
registrar. Users may consult the sponsoring registrar’s Whois database to
view the registrar’s reported date of expiration for this registration.
TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services’ (“VeriSign”) Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.
The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.
Domain name: naturecuredhule.com
Registry Domain ID: 2923549457_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Updated Date: 0001-01-01T00:00:00.00Z
Creation Date: 2024-10-08T10:41:15.00Z
Registrar Registration Expiration Date: 2025-10-08T10:41:15.00Z
Registrar: NAMECHEAP INC
Registrar IANA ID: 1068
Registrar Abuse Contact Email: abuse@namecheap.com
Registrar Abuse Contact Phone: +1.9854014545
Reseller: NAMECHEAP INC
Domain Status: clientTransferProhibited EPP Status Codes | What Do They Mean, and Why Should I Know? - ICANN
Domain Status: addPeriod EPP Status Codes | What Do They Mean, and Why Should I Know? - ICANN
Registry Registrant ID:
Registrant Name: Redacted for Privacy
Registrant Organization: Privacy service provided by Withheld for Privacy ehf
Registrant Street: Kalkofnsvegur 2
Registrant City: Reykjavik
Registrant State/Province: Capital Region
Registrant Postal Code: 101
Registrant Country: IS
Registrant Phone: +354.4212434
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: 48680f54142e476bbff54e9919e51447.protect@withheldforprivacy.com
Registry Admin ID:
Admin Name: Redacted for Privacy
Admin Organization: Privacy service provided by Withheld for Privacy ehf
Admin Street: Kalkofnsvegur 2
Admin City: Reykjavik
Admin State/Province: Capital Region
Admin Postal Code: 101
Admin Country: IS
Admin Phone: +354.4212434
Admin Phone Ext:
Admin Fax:
Admin Fax Ext:
Admin Email: 48680f54142e476bbff54e9919e51447.protect@withheldforprivacy.com
Registry Tech ID:
Tech Name: Redacted for Privacy
Tech Organization: Privacy service provided by Withheld for Privacy ehf
Tech Street: Kalkofnsvegur 2
Tech City: Reykjavik
Tech State/Province: Capital Region
Tech Postal Code: 101
Tech Country: IS
Tech Phone: +354.4212434
Tech Phone Ext:
Tech Fax:
Tech Fax Ext:
Tech Email: 48680f54142e476bbff54e9919e51447.protect@withheldforprivacy.com
Name Server: ns07.domaincontrol.com
Name Server: ns08.domaincontrol.com
DNSSEC: unsigned
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
Last update of WHOIS database: 2024-11-09T18:42:45.51Z <<<
For more information on Whois status codes, please visit https://icann.org/epp
Someone explain to me why my camera would need to be connecting to a host in India, and on a port that the documentation says is for local streaming.
Here is another address that is being connected to on port 443. ip186.ip-192-99-36.net which appears to be in Canada.
This whole thing is designed in a really screwed up fashion. The only thing the cloud should be needed for is uploading clips and retrieving clips. Any sane system wouldn’t be doing things in such a screwed up manner.
This is just the way corporations operate these days though. They don’t value anyone’s privacy or care about security.
If what is supposed to be happening is load balancing, servers on the other side of the world shouldn’t be being connected to. Wyze’s document on the required ports isn’t even accurate. I’ve seen random other ports used in the past as well.
There are a lot of connections to amazonaws.com on port 8883 which isn’t documented.
It is amazing how the Internet routes traffic.
That document appears to have been accurate years ago, but only up to the time when all they had were indoor cameras and the only protocol they used was TUTK and the only camera supplier they used was Hualai. A lot has changed since those days and they have several camera models that don’t even use TUTK at all anymore, new SDKs in some devices and some new suppliers, and likely use a lot of new ports, etc depending on the device in question. It would be nice to get an updated list since this old one is clearly out of date and doesn’t include any changes in recent years, and there have been a lot.
They said they also use it for the initial authentication before approving p2p connection for Livestreaming. As for your Iceland or India questions related to naturecuredhule, I haven’t seen that on my network yet. Do you know which device model specifically made said connection?
Whois info can be hard to trust since a lot of people or companies (myself included) use third parties in the information. The ones I own also say they are for entirely different places. So, since I do that myself, I’m generally not too concerned about location. However, I agree that Wyze should update their documentation since a lot of things have changed since back in the era of V2 cams when this documentation was made. Lots of new cameras and security updates and server changes and new SDKs and protocols, etc. This documentation for sure isn’t including what they use to go through the Web Portal (with Amazon kinesis), and probably isn’t including the changes they made to Alexa and Google Home now using low latency WebRTC instead of the old way. I bet there are lots of new things that could be added to that old document.
Check this out. Each camera appears to be opening up 3 connections to different servers on port 10001. back-window and driveway are V3. kitchen is V2. I had port 10001 blocked, but, enabled it to see what it would do. I’m thinking if you block 10001, it might try using a different port, because I saw random other ports in use when I had it blocked. I’m not even using the phone app. Port 10001 is supposed to be used for P2P local streaming. So, I would like to know why those connections are even there.
I would like to know the answers as well. I think your questions are valid, good questions. I think Wyze needs to update its documentation for it.
If you do try blocking some, I would be interested to know if you find out what it switches to.
This is what I see on my Panv3s
Port 443/TCP and 8883/TCP to AWS are always there, these are both secure messaging protocols and used for general status, configs, etc.
Port 10001/UDP to several 3rd party hosting providers is always there. Also fairly low bandwidth and my understanding from a while back was this was used for sending updates to Google, Amazon, Apple, etc for integration with their stuff. Even if you don’t use those, the camera doesn’t know that so maintains the connection and sends the updates, they’re probably just discarded if you don’t use them. My understanding was you can block this port if you don’t use those services but have not tried.
Various 10xxx/UDP to those same 3rd party providers, which is for streaming the video if you aren’t on the same LAN as the cameras or if they can’t talk directly to your phone for some reason. This is where the bandwidth adds up quickly. I’m guessing the older protocol used by these cameras is hardcoded to use those hosting providers, or the streaming is provided as part of the licensing of that old (TUTK?) protocol and it uses whatever provider is cheapest. Many of these are somewhat small-scale providers and probably pretty inexpensive compared to AWS, which is likely why the Xfinity/Rogers XB7 gateway blocks them as suspicious.
I didn’t wait for an event upload to see what connection it used, I suspect it would be a connection via AWS directly to Wyze but not positive.
My OGs send everything, including live stream, via AWS, I believe they use the newer streaming protocol (Tencent?) and probably finally eliminated those old hosting providers as middlemen.
On the OGs they always are sending updates to UDP port 28800 at Wyze, and occasionally TCP 20083 pops up, I’m guessing for camera status updates. Then the streaming uses a few different UDP ports, not sure if they are fixed or random, but all at AWS.
I believe @carverofchoice knows a lot about the two protocols and possibly some of the nuances/agreements in place for them.
Note I didn’t test with the phone on the same LAN as the camera where it streams direct (what I’d consider P2P) so that may very well use 10001, not sure.
I feel like I know relatively little as it is definitely not my area of expertise. Others here know quite a bit more than I and have even worked with them, whereas I have no personal experience with them like they do. Though I won’t name-drop them into controversy.
@jemiller I can tell you what I would personally do if I was concerned about these issues: I would email security@wyze.com and link them to your explanation here along with a summary of your concerns.
I would show them that screenshot of the strange destination and the ports being used that don’t match up to their current documentation and ask them to please look it over to make sure there are not any bugs or unintended communication there. And if they confirm that those are all official and expected, then you can ask them why their documentation indicates otherwise and see if they can give you a reasonable explanation and whether they will go update their documentation to explain all the new changes in the last few years.
At least that is what I would do. Generally speaking, the security email is supposed to be used when someone is concerned about a security threat such as hacking or something like this. In theory, you do have such a concern because you are seeing strange destinations and ports that are not matching up with their officially published documentation, so it would be a legitimate concern to ask them to look into it and see why you are getting strange or unexpected traffic not in line with the documentation. That is a legitimate reason to contact the security email.
If you do so, please feel free to update us.
