Dnsmasq options to make wyzecams happy?

Hoping someone in the know can help out here. I’m trying to get all my devices happy with the dhcp options I send back for dnsmasq. i.e. android/win7 clients needed a wpad option specified.

So next on my list are the wyzecams. they appear to be unhappy about something and continually send DHCPREQUEST msgs instead of accepting the DHCPOFFER. This was the same pattern my bad androids would exhibit without the wpad option (252).

Here’s an example of a chatty wyzecam upon bootup. 13 seconds to obtain an IP, eeks.

May 23 04:18:05 dnsmasq-dhcp[1786]: DHCPDISCOVER(eth0) 2c:aa:8e:10:xx:xx
May 23 04:18:05 dnsmasq-dhcp[1786]: DHCPOFFER(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:05 dnsmasq-dhcp[1786]: DHCPREQUEST(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:05 dnsmasq-dhcp[1786]: DHCPACK(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:08 dnsmasq-dhcp[1786]: DHCPDISCOVER(eth0) 2c:aa:8e:10:xx:xx
May 23 04:18:08 dnsmasq-dhcp[1786]: DHCPOFFER(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:08 dnsmasq-dhcp[1786]: DHCPREQUEST(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:08 dnsmasq-dhcp[1786]: DHCPACK(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:12 dnsmasq-dhcp[1786]: DHCPDISCOVER(eth0) 2c:aa:8e:10:xx:xx
May 23 04:18:12 dnsmasq-dhcp[1786]: DHCPOFFER(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:12 dnsmasq-dhcp[1786]: DHCPREQUEST(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:12 dnsmasq-dhcp[1786]: DHCPACK(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:15 dnsmasq-dhcp[1786]: DHCPDISCOVER(eth0) 2c:aa:8e:10:xx:xx
May 23 04:18:15 dnsmasq-dhcp[1786]: DHCPOFFER(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:15 dnsmasq-dhcp[1786]: DHCPREQUEST(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:15 dnsmasq-dhcp[1786]: DHCPACK(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:18 dnsmasq-dhcp[1786]: DHCPDISCOVER(eth0) 2c:aa:8e:10:xx:xx
May 23 04:18:18 dnsmasq-dhcp[1786]: DHCPOFFER(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:18 dnsmasq-dhcp[1786]: DHCPREQUEST(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx
May 23 04:18:18 dnsmasq-dhcp[1786]: DHCPACK(eth0) 192.168.86.210 2c:aa:8e:10:xx:xx

Here’s the options I set currently, any dnsmasq users out there that have solved this?

dhcp-option=option:router,192.168.86.1
dhcp-option=6,0.0.0.0,192.168.86.10
dhcp-option=252,"\n"

To add a little color to my network setup I have GoogleWifi and a pihole on my network. GoogleWifi doesn’t let me turn off it’s DHCP server, so technically there are 2 (non-overlapping pools) DHCP servers. GoogleWifi has a pool range of 1 ip reserved for the pihole. The pihole has the rest of the subnet in it’s pool.

Looking at some tcpdump messages I see the GoogleWifi respond with a NACK wrong server id, and the dnsmasq on the pihole respond with an ACK:

06:05:56.182408 44:07:0b:02:XX:XX > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 64, id 37629, offset 0, flags [none], proto UDP (17), length 328)
    192.168.86.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300, xid 0x74ed2f30, secs 6, Flags [Broadcast]
      Client-Ethernet-Address 2c:aa:8e:10:e9:ea
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: NACK
        Server-ID Option 54, length 4: 192.168.86.1
        MSG Option 56, length 15: "wrong server-ID"
06:05:57.925926 b8:27:eb:ce:XX:XX > 2c:aa:8e:10:XX:XX, ethertype IPv4 (0x0800), length 343: (tos 0xc0, ttl 64, id 64742, offset 0, flags [none], proto UDP (17), length 329)
    192.168.86.11.67 > 192.168.86.210.68: BOOTP/DHCP, Reply, length 301, xid 0x74ed2f30, secs 6, Flags [none]
      Your-IP 192.168.86.210
      Server-IP 192.168.86.11
      Client-Ethernet-Address 2c:aa:8e:10:XX:XX
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 192.168.86.11
        Lease-Time Option 51, length 4: 86400
        RN Option 58, length 4: 43200
        RB Option 59, length 4: 75600
        Subnet-Mask Option 1, length 4: 255.255.255.0
        BR Option 28, length 4: 192.168.86.255
        Domain-Name Option 15, length 3: "lan"
        Default-Gateway Option 3, length 4: 192.168.86.1
        Domain-Name-Server Option 6, length 8: 192.168.86.11,192.168.86.10

Does this NACK mess up the DHCP client on wyzecam? Is it triggering a loop of the DISCOVER/OFFER/REQUEST?

In the REQUEST packets I see it asking for these options:

	    Parameter-Request Option 55, length 7:
	      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
	      Domain-Name, BR, NTP

The only options I don’t see in the OFFER is Hostname and NTP:

	    DHCP-Message Option 53, length 1: Offer
	    Server-ID Option 54, length 4: 192.168.86.11
	    Lease-Time Option 51, length 4: 86400
	    RN Option 58, length 4: 43200
	    RB Option 59, length 4: 75600
	    Subnet-Mask Option 1, length 4: 255.255.255.0
	    BR Option 28, length 4: 192.168.86.255
	    Domain-Name Option 15, length 3: "lan"
	    Default-Gateway Option 3, length 4: 192.168.86.1
	    Domain-Name-Server Option 6, length 8: 192.168.86.11,192.168.86.10

I could fire up an NTP server, but do any of these clues sound like a culprit to anyone?

In general terms, having two DHCP servers on the same LAN segment is bad. Having a DHCP server that has no available IPs in it’s IP pool is bad.

The Wyze cameras don’t require anything “special” for a DHCP server other than the server must correctly provide the gateway and DNS server addresses that clients should use. However those two are normally given by a DHCP server.

I’m not specifically familiar with DNSMASQ - although I have heard of it before.

Agree on both points, I’m pleading with Google to let us Google wifi owners disable their DHCP server (which is dnsmasq also), but that’s an uphill battle.

You can have 2 DHCP servers on the same network with a little configuration. The trick is to set the address pool different on each server, I dont know your exact setup but you can do something like 10-122 and 122-254. The DHCP server address must be different, and use same subnet. Then the trick is to set the delay in responding to a call. Set the one you want to use to 0ms, and then the other to 1000ms. This will ensure two things.

  1. The one you want to use will answer the call first and silence the call.
  2. If first server fails to answer the 2nd one will and will assign ip that isn’t already in use because
    it has a different range. Also gives you some redundancy when one server fails.

Hope that helps…

I have them setup with non-overlapping pools. Google Wifi pool is a single IP .10, my dnsmasq machine is .20-.250

I would love to be able to set the delay on the Google Wifi dnsmasq but I don’t have access to the config files. That would probably do the trick if I could though.

Just trying to offer a quick fix. Waiting on Google is going to be a while. The google Wifi is a mesh system with Ethernet backhaul. Not sure why you wouldn’t use that in the first place. DHCP is a super fast handshake and then its done. I would think that Google would let you assign static address as well. Why do you want to stick with your dnsmasq machine? Are you using it for some of the functions of a layer 3 switch, (BOOTP/TFTP)?

It’s for my pihole machine. I don’t want the GoogleWifi puck to advertise it’s own IP as the DNS server to clients and proxy all DNS requests through the puck. I want to advertise the pihole as the DNS server to clients on the network.

Even when you specify custom DNS servers in the GoogleWifi app it doesn’t send that in the OFFER option 6, it sends it’s own IP and relays all the network DNS requests.

Appreciate the tip though, I hadn’t thought of offsetting the delay, wish I could set it :slight_smile:

I haven’t had the time to look into a Pi hole machine yet. Understand the principles of it. The speed difference between 1ms and 20ms not noticable, both are super fast, but does the add blocker really work? I use the smartthings wifi mesh system and it lets you turn off the DHCP server. I use a windows server with a Linux Gateway. It would appear your sold on that Pi Hole, lol Have a good holiday weekend. If you could figure out how to offset the Google WIFI that would solve your problems. Maybe look for a custom firmware for it.

Yeah it does a more than decent job. Here’s some stats to geek out over :slight_smile:

I see most resolutions in the <20ms range, occasionally in the 30-40ms range.

I also sdwan into it with my cellphone for ad blocking while on cell network. It’s fantastic, much less ads on my entire home network and cellphone everywhere.

1 Like

I’ll have to get that implemented, thanks!

Since you’re already running a dedicated machine you could run pihole via docker right along side it.

I’m curious if there was ever a solution here. I have a single DHCP server (PFSENSE) and have a few devices that regularly are unable to pull and IP and produce the same request/offer

Blockquote
|Apr 29 10:52:17|dhcpd|16807|DHCPOFFER on 10.11.12.9 to 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:17|dhcpd|16807|DHCPDISCOVER from 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:14|dhcpd|16807|DHCPOFFER on 10.11.12.9 to 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:14|dhcpd|16807|DHCPDISCOVER from 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:11|dhcpd|16807|DHCPOFFER on 10.11.12.9 to 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:11|dhcpd|16807|DHCPDISCOVER from 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:08|dhcpd|16807|DHCPOFFER on 10.11.12.9 to 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:08|dhcpd|16807|DHCPDISCOVER from 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:05|dhcpd|16807|DHCPOFFER on 10.11.12.9 to 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:05|dhcpd|16807|DHCPDISCOVER from 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:02|dhcpd|16807|DHCPOFFER on 10.11.12.9 to 2c:aa:8e:f7:ee:6f via cxl0|
|Apr 29 10:52:02|dhcpd|16807|DHCPDISCOVER from 2c:aa:8e:f7:ee:6f via cxl0|

sorry my solution was to rip out Google wifi and install ubiquiti devices so I had control over all my network device configs.