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 18.104.22.168 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.