I’ve been annoyed with my v2 WyzeCams pinging away at Google so that traffic is blocked using Pi-Hole. Works great but then I started wondering if they had hard-coded DNS entries so I blocked all outbound port 53 traffic on my router and guess what? Wyze is trying to get around my DNS server. Devices at .101 and .102 are Wyzecams while the other two devices are Amazon Echo Dots. I expect that kind of ass-hattery from AMZ but not Wyze.
I’ll have to chase it down with wireshark at some point but really, why is Wyze doing this?
Not sure I understand this log data. Is Wyze trying to resolvewww.google.com, to use www.google.com as a DNS resolver (unlikely), getting to a by-you-unauthorized resolver to ask for the address? Using a hard coded IP for www.google.com or to reach its own dedicated DNS server?
All I can tell from the second screenshot is the camera tried to reach www.google.com and was blocked. How it got the IP address and from where is not clear.
Two things going on here. First, the cams are trying to resolve and connect to google.com presumably just to check network connectivity. But, it’s already doing that with api.wyzecam.com so not sure why it’s trying to talk to google,
Second, my DHCP server is telling all devices that DNS queries should be sent to 192.168.1.3 which is the Pi-Hole that blocks adware, malware, beacons, etc. So, the Wyze cams are going around that and trying to send DNS queries directly to somewhere else (I still haven’t run wireshark so I don’t know where). My router is now blocking all DNS requests (port 53 UDP/TCP) from devices on my network from going outside so whatever Wyze is trying to get around, they aren’t now.
One way devices are offered with low prices is to package and sell data as an ongoing revenue stream derived from a one-time purchase. You know, if you’re not paying for the product, you are the product. So, the Facebook model but for subsidized hardware. LG TVs are bad about this and so is anything Amazon running FireOS (they both have hard-coded DNS). For now, either changing IP tables on the router to point back to the Pi-Hole or outright blocking port 53 outbound works. But.
At some point, they are going to start using DNS over HTTPS so all DNS requests will go out encrypted over the same port 443 as all other HTTPS traffic and I can’t block that. Right now, I’m also blocking DNS over TLS (port 853) but DoH is going to be a large problem not just for me but for anyone using DNS to enforce policy (think businesses, schools, etc.).
I suppose at some point, someone will come up with a DNS blocker but that’s going to be much harder to implement. For now: Why is Wyze sneaking around?
Thanks, that makes more sense to me now - the first screenshot indicates devices that were making queries anywhere but your designated resolver. Hmm, from a quick search this is the only other discussion I see on this (and it’s not very good). Also apparently some Alexa devices are regularly querying example.org, .net, and .com, which frankly seems like one of the more responsible ways to do a keepalive.
I suppose you could try padding additional resolvers in your DHCP response but that probably wouldn’t change the behavior.
By the way I wouldn’t necessarily attribute this to malice or tracking, but rather to resilience? Who knows; I’m naive.
I found the hard-code finally. WyzeCam v2 firmware is also trying to resolve google.com by pointing to 8.8.8.8 (which is Google’s DNS service) as well as the DHCP entry. So, nothing malicious but it still seems odd that they are trying to connect to Google so much.
Yup, as I said, probably for resilience, or because the firmware is OEMed to other vendors, or in case Wyze rebrands, or in case the Wyze servers are down, and/or to narrow down potential issues to general Internet connectivity versus the ability to reach Wyze cloud servers specifically. (Or somebody left it in the code by accident. )
Interesting as I noticed some odd slows downs on my network over the last few days and had’nt been able to pin point the culprit.
I use pihole to block ads but don’t typically have it set as a DHCP server as that is done by my router(I can tell from your screenshot that your pihole is set as your DHCP server). As such pihole stats aren’t granular by device but just lumped under the router IP. When I looked at the pihole dashboard the number of DNS queries was off the charts and pihole was restrcting the number of queries to 1000/min.
Some Googling later I found the required changes to turn off the limit. I then switched off DHCP on my router and switched it on on pihole lets yo usee what traffic comes from what device. I was stunned, in less than 5 mins my basement v3 cam had hit www.google.com 62,943!!!
That’s insane - camera was working fine in the Android app. I rebooted it and the madness went away - but why was it doing that in the first place? I have 6 cameras, 5 in use all with firmware 4.36.6.17 and no other camera does this.
I can block www.google.com via piehole but would like to know WT?
Cameras now have firmware 4.36.7.22 and another went rogue yesterday again with over 60,000 DNS lookups for www.google.com
I have it blocked for my cameras in pihole for now but this needs fixing - sems it was acknowleged by Wyze in Feb this year and fixed. Well IT’S BACK!!!
I had this same problem with one of my v3 cameras over the past 2 days - 70k+ lookup attempts to google.com which managed to fill up /var/log and bring my pihole to its knees. I’ve left the cam unplugged for now. Running firmware 4.36.8.32. Would really appreciate a response from Wyze on this.
I’m having this same issue now too. Anyone figure out what is going on/how to fix?
I have 2x v3 and 1x v2 cameras running and I’m only seeing this on one of the v3 cameras. 32k lookups in 24hrs for www.google.com from that camera, 1.5k from the other v3 (still seems like a lot, but is a lot less), ~650 from the v2. All are running up-to-date firmware
