I have no experience with RTSP, so I can’t personally say. It is possible fact that they have RTSP means that the camera complies to a standard that allows the proper hardware/software device to communicate with them, without using the internet. But, it may also mean that the Wyse server converts the camera’s data that it gost over the internet, into a RTSP format, and then forwards that over the internet.
I tried one of the free RTSP viewers for android, and it first wanted me to enter the brand of the camera. The Wyse had no listings.
RTSP does NOT require internet connection, so that is the only way to do LAN only. It makes no sense that the non-RTSP mode requries internet connection, this is one of the reasons i don’t like this camera, it phones home to china and you can’t do nothing about it. Even with a firewall if you enable it then the camera can’t connect to “initiate” the connection.
RTSP is an option, but the problem is that is capped @ 10 fps and the lag is significant, about 5 seconds.
I am about to return these cameras back to Amazon, As i dont see a path with such a poor FPS in LAN only mode. It is a shame that you can’t run the app in LAN only mode with the native app
The cams DO NOT phone home to China. The security hounds would have a fit if they thought anyone could view the stream, so the reason for requiring Internet is to verify authorization to view the live stream. That is the choice Wyze made.
Other cameras may suit you better, as you say. This is an inexpensive camera, however. Most of the others are not.
they have constant requests for Google DNS, AWS and other “random” IP addresses. Help me understand why the “authorization” needs to go to the cloud and back? why risk it? just do local LAN authentication if no cloud is available, like you do with RTSP. The day the wyze cam servers which who knows where they are become hacked or are down for some reason everyone will be screwed.
I am really interested to hear on the technical reason on why they need to authenticate on the cloud. Is it data harvesting?
thanks for pointing that out. i replied there. If you have more information on your “SECURITY REASONS” statement please share as that will help the community earn trust in this product.
Unfortunately, a lot of people are not technical savvy enough and fall for this, when the camera is constantly connected to the internet doing something and giving away their privacy and selling giving away all the data harvested by the wyzecams for $20. When in reality who knows what data is being collected from users.
As you can see in this picture, there was a total of 75MB of data uploaded to a server in AZ when no one was connected to my camera and i had object detection and all features OFF. So why is 75MB of data from my camera uploaded to their servers when no user was watching?
either pictures or live video was uploaded for sure… so this is not authentication only. and that is the data to prove it
Hey, folks. I’m going to see about getting someone from the dev side in here. We aren’t selling data and we’ve limited our server use to North America but some of the specifics here are beyond my knowledge.
Newshound said "The cams DO NOT phone home to China. "
But if there are updates to the firmware, that does permit them to make the change in the future to permit such data collection. It may even be possible to target a firmware update to a specific user.
But, of course, all that is probably available to the U.S. government via cell phones, and PCs. In fact the U.S. government was exposed by Snowden, to be tracking call information for every American. It was approve by a judge, but was blatantly unconstitutional. So, I don’t know if it mattes if the company is owned by a Chinese company or not.
It is also typical for most smart appliances to require the use of the internet even when it really isn’t necessary for most usages. This certainly a way to give up one’s privacy, but I think most Americans are OK with this now.
Remember most are OK with having their pictures taken of them naked via airport scanners, or to have their genitals touched while being searched at the airports. All blatant violations of the Constitution, but again, people just don’t care.
The data is for device heartbeat. We need to keep the device alive for future connections. All three servers were verified to be our P2P provider’s servers. We have some articles about using ThroughTek as our P2P service provider. They are at https://support.wyzecam.com/hc/en-us/articles/360027279571-ThroughTek-User-Privacy. From your data, the average packet size is 585 bytes. There is not too much we can collect with 585 bytes (including all the packet overhead).
We are working really hard to protect customer’s security and privacy. It is the whole company’s goal since we formed the company. I will respect your decision if you want to keep or return your camera. No matter what we will keep working hard to deliver our promise to the customers. Thank you and have a great day!
Thanks for chiming on on this thread. I appreciate the link you posted to the ThroughTek FAQ as it has some useful commentary on the system architecture.
I’ve looked at the firewall data provided in post #16 above and find the numbers rather surprising. According to @gelly035-happy, the line stats are for a single V2 camera that had no media flow (“… no one was connected to my camera and object/event detection OFF”). The screenshot shows nearly 75 MB of data transferred over 11.5 hours. Here’s how this breaks down:
on average, a constant data flow of around 14 kbps (kilobits per second).
the packet rate is about 3 pps (packets per second).
average packet size is 585 bytes.
You indicated that this data flow is required for “device heartbeat”.
I fully understand the need for some sort of heartbeat in the Wyze network architecture. The primary reason is to maintain the NAT mapping in the Customer’s router so a P2P connection can be established when the owner wants to view remotely. But sending 3 packets per second to maintain the NAT mapping seems extreme. Typical timeout for a TCP mapping is 10 to 15 minutes, sometimes even longer. If it’s a UDP flow, the typical timeout for consumer routers is 30 seconds. I can’t imagine any legitimate reason to send a ‘heartbeat’ packet every 0.33 seconds.
The size of these heartbeats also seems excessive. It does not require a 585 byte packet for a keep-alive. The NAT mapping can be maintained with single minimum-size packet, transmitted much less often than 3pps. You indicate that “there is not too much we can collect with 585 bytes”. Perhaps not with a single 585 byte packet. But according to @gelly035-happy, the V2 camera is sending three such packets every second. That’s over 6.5 MB per hour. That’s a lot of customer data that could be getting exfiltrated, one 585 byte packet at a time.
To be clear, I have no reason to believe that Wyzecams are exfiltrating Customer data. But the mere fact that these large and seemingly unnecessary flows exist is a concern to many.
I hope you can explain (a) the reason for such a high packet rate for the ‘heartbeat’, and (b) the reason the packets are so large.
On a practical note, assuming gelly’s firewall stats are correct, the V2 camera is sending around 150 MB per day, or 4.5 GB per month. That’s an awful lot of data for an administrative heartbeat, and may result in internet overage charges for Customers who don’t have the luxury of an unlimited internet plan. And I shudder to think of the the traffic flows hitting 22.214.171.124 from hundreds of thousands of Wyzecams sending these heartbeats at 3pps. Deployment of 100K cameras would hammer that server with over 1Gbps just of heartbeat traffic. That would overload a GigE ethernet link. As a system engineer, this seems to me to be a sub-optimal network design that may not scale gracefully…
I wonder if there’s an anomaly (a.k.a. bug) in gelly’s Wyzecam such that it was constantly transmitting media of some sort even though all such features were apparently turned OFF. That might account for the 75MB of data reported over 11.5 hours.
@WyzeTao can you explain what “future connections” mean? having that open effectively gives you access to the camera remotely and on a potential scenario where your servers get hacked, pretty much the hackers have access to everyones LAN through the wyzecams.
I am paranoid yes, understand that you guys strive for security, then please give us an option to use the cameras within our LANs and in private networks. It is an option that will bring this product to the next level in terms of privacy.
You do this already with RTSP, it can be accessed without internet. However 10FPS is unusable, need at least 20FPS. Maybe you will need to do a better port of the RTSP GNU/Open Source implementation which is likely what was done.
Significant data is being transferred silently from your network to the internet
Unknown/Unpredictable “future connections” from Wyze servers to your network exposing your LAN to who knows where/who
Assumptions that you will never be hacked…
No option to give the user privacy or use in private networks or firewall environment
The day Wyze servers experience a glitch everyone will be down
My two wyzecams are boxed, ready to go back to Amazon. I will stay tuned, in case you come with a LAN only option or better FPS with RTSP that allows me to do that, then i will go back and buy the cameras. I am willing to pay up to $40 for a version of these cameras with those features. The app is good, the quality of the video is good and it is a small camera that fits everywhere. But the requirement to be connected to the cloud and no option to use within a firewall environment is a killer for me.
On top of that there is the reliability problem. Servers go down, and all your camera users will go down with it. Google, Amazon and Netflix servers experienced these problems and they “own” the Internet let’s say. The assumption that it won’t happen to you and leave all your users in the dark is a major one in terms of this future. Raise the prices a little and deliver a more holistic product, people will still buy and you’ll get glowing reviews.
I’ll stay tuned to these forums to see if anything changes
The cameras are intended to be accessed by your phone, which could be your local network or anywhere your phone goes. After a camera is setup the camera will periodically tell our servers and say ‘I am alive’. When an app tries to connect to the camera, it talks to the server first to find the device (only the server knows where the device is and create a connection from internet to the camera). That is what I meant by ‘future connections’.
There is one exception when you try to connect from home. Our app will broadcast in local network and search for the device as well. Once your camera responds a connection can be made without our server.
You have a good point. I only did the math for the size of the packets but not the # of packets. This needs some digging. I will get back on this. Unfortunately I won’t get camera log since the device is taken down. Otherwise it could be easier to figure it out.
@gelly035-happy Can you confirm you didn’t perform any streaming tasks since the very beginning? Thanks!
I have observed this behavior - it’s a clever design, as no internet bandwidth need be consumed for viewing the camera if the client (the app) is local. However, your search for the device doesn’t work if there is no internet connection. Even if the app (smartphone) and camera are on the same WiLAN and the same subnet, the camera does not respond to the search if there’s no internet connectivity. So the app cannot connect to the camera. No Live View. No viewing of Events recorded on the SDcard. No functionality of any kind. Is that a bug or by design?
It’s not so much the # of packets, but the packet rate that is of concern. The 3 packets per second over 11 hours reported by gelly is tremendously excessive (wasteful, expensive) for any kind of a ‘heartbeat’. To keep the NAT mapping in the router alive, a packet every few minutes should suffice.
More math for you to ponder: the 3pps rate is for the connection he reported to 126.96.36.199. Take a look at the flows to the other two servers (188.8.131.52 and 184.108.40.206). The firewall log shows a packet every 3.5 seconds or so over those 11.5 hour connections. That’s an order of magnitude less that what’s hitting 220.127.116.11, but an order of magnitude more than what should be required for a keep-alive.