Wyze Cam Base Station DHCP Server?

Cameras
, ,
1

I started having issues on my network the last few days, which coincided with the last set of 2 Outdoor cams that we ordered and installed. About 3 weeks ago we had bought an outdoor cam starter kit with a base station and all had been working well. However, when we installed these 2 cams we noticed that there was an update available. So we went ahead and updated everything. This put the Base Station on version 4.16.1.14 and the outdoor cameras all on 4.17.1.35. The base station is connected via ethernet.

Normally, I run a pihole on a raspberry pi 4 which is also set up as my DHCP server for the network with a /16 subnet. The past few days I’ve started having DHCP issues where i am being assigned 255.255.255.0 instead of 255.255.0.0 which is breaking my connections. So, today I got a bit tired of it and fired up Wireshark. I am receiving DHCP offers from my expected DHCP server (192.168.1.4) but I am also receiving them from 192.168.200.1 the mac address that showed was reported as a Wyze MAC when I googled it. I noticed that the base station was rapid flashing blue as well and showed offline in the app, I am assuming that this means that it reset for whatever reason. I unplugged my base station and the extra replies stopped. I plugged it back, it got a new IP address and I still am not receiving the extra DHCP Offers from it now.

Is this an issue that I should expect the base station to just randomly corrupt my network’s DHCP setup from time to time and I will just have to go power cycle the base station or is this indicative of a larger issue? For the time being, I may just assign it a static IP lease via mac on the DHCP server… However, it does seem a little ridiculous that the device would even be able to corrupt my network like this. If it loses its settings it should really set up a wifi hotspot to connect to during setup via the app, with it offering DHCP addresses on that hotspot, rather than assuming that it can just use some subnet on my network and causing these issues.

This feels like a pretty big oversight on someone’s part.

-Joe

2 Likes
2

But that’s how DHCP works. It’s a broadcast on a given subnet. The subnet isn’t defined by you selecting a /16 mask. It’s defined by what the switch / hub is willing to treat as a single layer two segment. So of course you are seeing both servers trying to respond to your broadcast lease requests. (Why the base is getting reset is another question.)

You can probably work around this by setting DHCP scope options.

3

Yeah, I don’t want to set DHCP Scope options. I want to know when there are rouge DHCP servers on my network that I didn’t setup. Which exactly where I figured out that this is doing that.

The netmask is determined by the /16, sorry I misspoke in my OP. I want it to assign for the entire 192.168.x.x range for many reasons, not the least of which being that some malware will setup DHCP servers within your network. So, I’m running a 255.255.0.0 subnet with the 192.168.1.1/16 netmask.

Like I said though, the problem with this is devices assuming that they can just take a portion of the the 192.168.x.x subnet and start running their own DHCP server on it. Even my cheap ESP8266 devices running ESPhome are smart enough to only run their DHCP servers on a fallback hotspot when they cannot connect to the main network rather than adding an unwelcome DHCP server to my main network.
-Joe

4

I think you’re still missing my point. Nothing is "taking a portion of the 192.168.x.x subnet*. That IP subnet doesn’t EXIST for DHCP broadcast purposes. You aren’t controlling or blocking anything, so long as your layer 2 switch(es) are dutifully propagating broadcasts to everything.

Identifying rogue DHCP servers is interesting and I can’t think of a good way offhand to do so.

Edit: looks as if most of the approaches are either probing for responses or telling your switch to reject DHCP offers.

5

I may be wording it wrong or something. However, this is definitely causing a conflict on the subnet as I said.

I have 192.168.1.4 netmask 255.255.0.0 as my DHCP server. It’s assigning out 192.168.5.1 - 192.168.255.255 with netmask with netmask 255.255.0.0. This is necessary so that my devices can communicate across the subnets within that range.

When the base station resets (for whatever reason that is) is starts serving as 192.168.200.1 with netmask 255.255.255.0 and assigning addresses within my network IPs within 192.168.200.2-192.168.200.255 with a netmask of 255.255.255.0 which prevents the devices from accessing the gateway at 192.168.1.1

So yes, it’s highjacking the 192.168.200.x range within my network and assigning an incorrect subnet mask to devices within that range (which, as intended, breaks those devices’ access to the internet).

The way to detect rouge servers is to look for DHCP Offers from servers which are not your intended servers. The reason that I have my network configured the way that it is, is for exactly the reason that I noticed in the first place. The additional DHCP server ends up racing my intended server, causing issues that would eventually make me look for extra DHCP Offers as happened here.

-Joe

6

This is the issue with the wording and conception. You can have any number of IP ranges on the SAME network segment on the same switch. It’s the difference between a layer 2 VLAN and a layer 3 IP network subnet. Dynamic addresses are a special case because they are blindly looking for something with a broadcast.

You probably want to establish a few VLANs on a layer 3 switch and isolate the Wyze gear. When it’s on its own VLAN it won’t accept DHCP broadcasts from your other equipment.

It’s entirely possible that I’ve gotten some of this wrong. :slight_smile:

7

That…
Or like most smart devices, it should only do its setup on a Wifi Hotspot and run its DHCP server on that hotspot.
Or, resort to some other method… Unicast, UPNP, etc to look for Wyze devices and check for one which is not configured.

Setting up VLans is not really a “home” use-case, at that point you’re definitely getting into “niche cases”. Subnetting and controlling devices by broadcast range at least is. Having a device that defaults to a fixed IP/subnet in the incredibly common 192.168.x.x range, is a somewhat questionable design choice. Most of the devices that default to a static IP usually do so in the 172.16.x.x range, which is far less commonly used in home networks (no idea why this is… but it’s a thing). However, even these generally don’t spin up a DHCP server when they do so.

Like I said from the beginning, this is one of the first smart devices that I have had decided to run its own DHCP server at all, especially within the 192.168.x.x range, in my network. This may be how all Wyze devices work, and it ends up not being a huge issue usually since it is only listening during setup/pairing. Usually, you’re focused on this during the 4-5 minutes that it takes you to add it to the app, at which point it turns off its DHCP server. Even if one of your other devices requested, and received, a bad lease from the base station during this time… You would most likely reboot it anyway as the first step of troubleshooting, which would then get a proper lease from your actual DHCP server… so you would have no reason to dig into it.

The bigger issue is probably that it is randomly resetting itself (didn’t start doing that until this firmware version) and until I notice the issue and go reboot it… it is fighting with my actual DHCP server. (again why most smart devices have you connect to them on a dedicated wifi-hotspot when they are not configured and only run their DHCP server on that hotspot, never on your actual network). That issue is what exposed what was probably determined to be a “low clash scenario” since most customers would only have it conflicting for a few minutes… ever.

However, in the event that the base station decides to not load its configuration (it’s not lost, since it loads it back up on a power cycle) it goes into this mode for an indefinite period of time… until you notice it flashing or go to access the cameras and notice that they’re offline along with the base station. This then starts overlapping leases expiring and whatnot. So far, this has interfered with my laptop, 2 smart lights, and one of my google home minis… that I have noticed over the last 3 days or so.

As I said, I can understand the design perspective of there not being much time that this would clash… However, real-world, this could interrupt network operations for hours, if not days depending on how often you look at the base station or access the cameras (since they’re motion activated).

-Joe

8

I’ve got VLANs set up and they are common these days when you isolate end users from each other.

Following this as you are finding the crappy stuff I’ve seen too.

Notice Wyze is also using hard coded DNS and bypassing your RPi. I’m blocking all 53 TCP/UDP and 853 TCP to limit these bad faith actors.

1 Like
9

Customer, I think you are missing the point. The Wyze base station SHOULD be acting as a DHCP server on the WiFi network between it and the outdoor cameras. it SHOULD NOT be acting as a DHCP server on it’s wired network side. It SHOULD be operating as a DHCP client on the wired network.

As for VLANs, I also have my Wyze cameras on a separate VLAN that has no connection to the rest of my network.

2 Likes
10

Thanks, that’s a valid take but not what was presented. :wink:

I would guess that the box’s OS has a DHCP server that isn’t discriminating as to which interface it’s willing to respond on. But you are right, on its Ethernet side it should be client only.

11

Unless I am mis-reading the original post, that is exactly what joseph is reporting. The Wyze base station is acting as a DHCP server on his wired LAN - which it should not be doing…

12

Correct. But it only does so on the ethernet interface only when it goes back into pairing mode, which it has done randomly a few times. Though it hasn’t since yesterday, so fingers crossed.

Though, I just double checked and it does assign the cameras ip addresses in the .200 range, so it is running a dhcp server on its wifi interface. This will eventually cause collisions if I allow my dhcp server to assign ips in this range.

Imo. The base station should only ever act as a dhcp server when it’s in travel mode or pairing mode (both of which would only be on the wifi adapter). If it is connected to a network it should forward the dhcp requests to the dhcp server for that network. There is literally no reason for it to ever be a DHCP server while it is connected to a network.

-Joe

13

My Wyze Base station is doing the same thing and unfortunately somehow a bunch of non-Wyze devices are utilizing it as a DHCP server over the WiFi network, getting 192.168.200.x addresses assigned and not being able to route to the internet.

14

Yeah. There’s absolutely no reason that the base station ever has to run a dhcp server on the ethernet interface. It makes some sense to run in the wifi interface for the cameras (though really, out should just act as a dhcp forwarder if it has a DHCP lease imo).

This is definitely something that should be changed in the firmware.

15

Yuhp, agreed. I’m trying to figure out how to resolve this within the next few days or I’m going to have to replace all the Wyze cameras with something that behaves properly on a network.

16

@WyzeLi Looping in WyzeLi in on this thread for visibility

1 Like
17

Good thinking. I went to try and report it as an issue through the app… But unfortunately, there is no “report an issue” option for the base station.

Like I said previously in this thread. There are a few options that might work to alleviate this problem.

  1. Only start a dhcp server while in travel mode.
  2. Only run the dhcp server on the wlan interface (this would still create an issue though for people who connect the base station via WiFi)
  3. Wait for a certain timeout to receive a dhcp reply/advertisement before starting the server.
  4. Only sign ips to Mac addresses that belong to wyze outdoor cameras.

This would need some rework on how their assigning ip’s to the cameras though, since I’m assuming that they’ll only accept ips from the base station rather than another dhcp server. Unless maybe they’re not even on a normal wifi connection… Then there’s no reason to even run a dhcp server on the wifi or ethernet interfaces outside of travel mode, ever.

18

@WyzeLi Any help? There are complaints about the same problem since January on Twitter as well. Some sort of response would be helpful.

19

4 is the solution but what i dont get is why have to use the base station at all if your wifi is strong enough. I have a decent mesh network that get me coverage everywhere i have cameras.

20

Hi all,

Thanks for the tag! After confirming with the dev team, we’ll disable the DHCP server while the base station is not in pairing or travel mode in the next firmware release.

Thanks!

5 Likes