Ok - I have installed a pi-hole, and am seeing MASSIVE pings/queries over DNS to www.google.com. I’m trying to pin it down - and STRONGLY suspect it is a Wyze Cam. This started after a new cam went online a week or two ago, and required a firmware update.
I just reset my pihole about 25 minutes ago, and am already up to 245 DNS requests for www.google.com
I could blacklist it - or have an entry in pihole to “sink” the request to 127.0.0.1 - but since I’m not sure WHY this is occurring (other posts also seem to indicate V3s spamming thousands of requests to google.com.
WHY? What’s the purpose of this? It really seems to be slowing down my network.
In the time it’s taken me to write this since I said I had 245 requests - now up to 267.
Really? Pings and DNS requests are tiny. Unless you are on a slow dialup, the rate that you are seeing these would hardly be noticable…
Granted, that statement does not necessarily make the number of packets right or wrong, but please don’t try to tell us it’s slowing down your network…
I am only assuming pings and DNS - I have not gotten anything out to exam packets yet. Other posts about the same thing (Dec '21, etc) indicate that packets are being sent, encrypted.
And I do know my network. Since this started, I’ve had a lot of issues with buffering (Roku was doing something similar till I squelched it late last week), and I’m getting VPN drops while working. Which has also started up since this started. Seems like it’s sensitive to a lot of requests.
I’ll have to test a few more days - but this amounts - at times - the number of packets start to encroach into DOS territory. Not totally blocking - but certainly causing issues.
And regardless - why is it sending so many packets - sometimes up to 15-20 a second? There are no alerts, no notifications, no videos, etc - so there’s absolutely NO reason for this to go on.
I will say, I’ve unplugged my newest V3 - and the packets have slowed dramatically over the last 30-40 minutes. I’ve still got a couple more I’ll pull to confirm it IS the V3 cams causing the issue
Thanks! I’ll have to see if my router supports that. Not sure if it does. What is happening is that the DNS queries are hammering my Pihole, and it’s FLOODING the sd card with logs. Actually destroyed one card already (probably on it’s last legs), and is filling the other. Found out that the latest pihole releases (I hadn’t updated anything but the ad blocking for a while), now not only writes a logfile, but also writes to a sqllite SQL database. And turning “logging” off doesn’t disable the sqllite DB.
So it’s affecting my network due to the constant writes out to the card. So I either have NO logging at all, or I will wear out SD cards, and have network issues, or get rid of the Wyze cams. The VPN I use for remoting in to my office is apparently very timing sensitive, and I’m getting drops through the day on my VPN due to this.
And strangely - I didn’t have this problem until about 2 weeks ago. Got a new V3, and had to update the firmware on it - now I’ve got the issue. My other 2 V3s were pre-orders - so within the first batch. This may also have something to do with the version of the board in the V3 - but that’s just a guess.
So - anyone with a pihole, and a relatively recent update of the pihole software - be advised there are TWO logging avenues - one a normal .log - the other a sqllite DB that is going to be more impactful.
Over the last 12 hours, I’ve had just over 73,000 DNS requests - 50.1% are being blocked, and of those, 80%+ (by rough count), are to google.com and api.wyzecam.com
Yeah, and as of this morning too, I’ve seen that pihole is now rate limiting me as well. My pihole is configured to be the DNS server for anything that gets a DHCP address.
Also found that I had over 1000 requests in 60 seconds recorded by the pihole. I don’t have rule-level firewall control, so the best I’m trying to figure another way. pihole has a firewall, which I’ve not needed before, so I’ll have to dig into that
Regardless, even if I can mitigate the requests - that firewall would have to front-end the pihole to keep the logging down - or that just kills my network and my sd card.
Depending on your router, you may be able to configure the Wyze cam to use a diffrent dns, so it doesn’t kill your pihole. That could work as a temp fix.
Sorry for the delay, been very busy at both work and home. I’ve decided the only way at this point to get around the issue is to put another Wifi AP in the network, but place it between my current AP/router, and my ISPs router. I can’t set up multiple subnets with different DNS on just the one router.
So I’ll effectively set up a DMZ using a different AP and subnet. Fortunately I live “in the county”, and don’t have any other wifi routers around that I can “see”. So setting up another AP in the house shouldn’t cause too many issues.
I’ve started the process with 2 cams - and the app still works ok with a mix of devices on different networks (but all on my account, etc.) after I’ve reset them, and set them up again on the new wifi AP.
Now I just have to get 3-4 hours to go around, getting the cameras down and reset, set back up, etc.
Thanks for posting this question and the great responses and links to similar / ongoing issues. I’ll have to invest some time reading through the mitigation steps, but wanted to quickly chime in and suggest that it is absolutely occurring with V3 cams. We just have a single Wyze V3, which has been mostly great for the price point – however, this morning i had to quickly pull the plug as I noticed this behavior. BOTH Pi-hole devices show similar levels of activity, all from the cam, all pointing to www.google.com (which is served from cache, so i didn’t notice any network slowdowns).
Thankfully the default rate-limiter on Pi-hole kicked in. I’m using Pi-hole v5.11.4 with Unbound and invisibility catch and redirect all hard-coded DNS queries back to my Unbound instances. I’ve found the caching abilities of Unbound to be quite good. If you can live with the brief delay from initial queries, it’s lovely to take advantage of those sub 1ms response times to any domains already stored in cache. Highly recommend: unbound - Pi-hole documentation
I will attempt to reproduce the issue in the coming weeks and see if I am able to capture a log file, so i’m able to provide something to Wyze support team. Thanks for pro-tip!
This has been reported to support, and they are supposedly “working on it”. They asked me for a log - I sent them one, but unless they are specifically logging this type of request, not sure a log will show anything up.
peatrick - yes, you’ll get a response from cache, but seems like on mine, about every 5th - 7th DNS request still goes out and does not hit cache. It seems it will only respond out of cache so many times.
This is something that the team is aware of and is working on, I know a beta for the v3 went out today but I am currently unaware if this firmware addresses this issue or not.
Really interested to see where this goes, I am experiencing very heaving querying from my WyzeCam v3 on Pi-Hole.
Let me know what you need, if anything regarding tests and logs. I am tempted to block it’s communication entirely or remove it from the network. I have about 10 Wyze cameras, this is the only one with this problem - is it being used as a supernode or something, for all wyze communication???
If YOU hear anything - please let me know. Been months, and not a word or a beta out of Wyze regarding this issue. I’ve contacted them - put in a bug report, which they promptly closed after they sent me confirmation it was occurring.
I’ve tried several things - nothing helps/works. At least short of just taking them off the network. But they are still (when I plug them in), sending so many queries that it gets shut down. There’s a configuration item in pihole that allows you to set how many requests per minute before it shuts down. I’ve set it from 1000 to 2000, and have exceeded that a couple of times. Really screws up the other devices on my LAN.
I find it’s like a negative feedback loop.
If there’s a hiccup in connectivity for a single device, it starts spamming the connectivity check.
Once it starts spamming, DNS server throttles incoming requests impacting the entire LAN.
Now all of the wyze cams (not just the initial single device) see that as a connectivity failure and they all start spamming the connectivity check.
