Starting around 11:34am (EDT) my firewall has been getting hit with UDP packets from 108.62.57.36, 192.99.101.72 and 148.72.153.115 on source port 10001. There are nine different destination ports (6739, 14559, 12996, 7919, 42492, 53518, 55270, 32678, 12531). Before, 11:34 my firewall was dropping around 0.2 packets per second and after it jumped to 18 packets per second. I believe the issue started when I upgraded to the lasted 3/17 firmware since I did it around that time. As soon as I identified the issue as coming from Wyze owned IP addresses, I unplugged all my cameras and the flood of packets has actually gotten worse and is not stopping (averaging about 42 packets dropped per second). This is completely unacceptable and needs to be looked at immediately. I am waiting for support to let them know directly as well.
If you have the ability, I would recommend checking your firewall activity and see if the same is happening to you.
This has been discussed before. Short answer is it is part of the handshaking between the cameras and the Wyze servers. You said your firewall is dropping the packets - why? Presumably if the firewall drops the packet, the camera will need to try again.
I currently have about 30 Wyze cameras on my IoT LAN. I set up two rules as packet counters. One is counting outbound UDP packet from my IoT LAN with destination port of 10001, and the other is counting inbound UDP packets from the internet with a source port of 10001. Inbound packets are running 0 - 4 packets per second with the highest data rate I have seen in about 5 minutes of 6Kb/s and an average of less than 2 kb/s. Outbound packets are running 5 to 20 packets per second and the highest data rate was a little under 20kb/s and averaging more like 3 kb/s.
We all know that IoT devices tend to be very chatty. In other words, why is this unexpected behavior?
Thank you for the reply. It is unexpected because it wasn’t happening until this morning so something changed. I understand the UDP handshaking. The normal chatty traffic flow is working fine and I am observing that with my tools as well. The cameras are working fine and I can view video both on the network and remote without issue.
The problem is all of sudden this morning I am getting hit with these extra UDP packets that are not part of the sessions started by my cameras hence why the firewall is dropping them. So something must have changed or something is rogue on their backend generating these unwanted UDP packets. Also, why would there be any traffic from Wyze hitting my firewall when I shutoff the cameras. That has me the most concerned. Nothing should be coming to my firewall when the cameras are off.
Here is a screenshot of my firewall packet drops for today. I confirmed with the firewall logs that those increased packet drops from 11:34 on are all from Wyze IP addresses.
So far support has been of no help. I have asked for the case to be escalated further. I tried downgrading the firmware on all my cameras and I disabled Cam Plus Lite but nothing has helped at all.
I continued my investigation of this issue and was able to confirm that Wyze’s backend is using stale UDP port/states for my cameras even though the current active ports/state is operational. I was able to verify the ports my firewall was expecting for the return UDP 10001 traffic by checking its state table and I compared that to the blocked traffic and of course they don’t match. My firewall is doing exactly what is supposed to do by dropping the erroneous packets. I am guessing something on the Wyze backend is trying to communicate to my camera’s with stale UDP state information from earlier today first when I upgraded and then when I powered them off which would explain why the drop rate then doubled. Something on the backend was not clearing out old/stale connections for my cameras and nothing I do on my end makes any difference.
At this point I have provided all this information in detail to the support team (Ticket #1898250) to prove there is something misbehaving in their environment and sending erroneous UDP traffic to my network. Hopefully someone at Wyze takes this seriously and looks into properly before I have to report them and their IP addresses for abuse. I also hope this isn’t a widespread issue for all users.
This is some good work, thank you. If the connections really are stale then Wyze (or its vendor) are also wasting their own resources.
I think everyone can agree it makes no sense to be hammering your router hours after your cameras were turned off.
HOWEVER, if this means turned off in the interface and NOT powered off, then it doesn’t apply. The cameras are never really “off” while powered and they DO continue to communicate, regardless of the app toggle.
Definitely, that why I am surprised about the lack of response from their support. I also let OVH know since one of the addresses is owned by them. I am assuming it actually hasn’t made it someone that actually understands what is going on.
I made sure all cameras were unplugged from power. I know these type of devices are always talking if they have power.
Instead of waiting for Wyze support to do anything useful, I just went ahead and forced a DHCP change on my firewall/cable modem WAN interface by changing the MAC address. As soon as I did that the packet drop rate on my firewall returned to normal and my cameras are working fine.
The question now is if the backend is still sending stale UDP streams to my old IP address and is this happening to other customers without their knowledge.
Thanks for the suggestion. I forwarded the information to security@wyze.com as well. I will update the thread with any response.
As of the this morning, the stale UDP stream issue hasn’t carried over to my new IP address so at least there is workaround for anyone else that runs into this as well.
I feel bad. On several other threads I dismissed the reports as alarmist and blamed the security software for over-reporting and scare mongering.
Your analysis seems to indicate there really is a recurring problem - though still nearly certainly accidental and not malicious (and not a distributed attack).
I will definitely be keeping an eye on it to see if it ever happens again since I know exactly what to look for. Hopefully Wyze reviews the details of the case since it would be to their benefit to remedy the issue since it is wasting their resources which in turn is wasting their money. I agree it is accidental and not malicious. Their code or service monitoring needs to be updated to deal with conditions like this.
I had issues watching the livestream and it was dropping to 0KB after only a few seconds. My firewall was blocking multiple UDP packets per second from IPs using port 10001. It stopped when my public IP changed after spoofing the MAC address of the WAN interface. Livestream seems fine now that the packet flood stopped. Definitely something weird going on on Wyze end.
