DHCP Issues

I have a PfSense router / FW and a unifi switch / AP and have already disabled all of the broadcast features of the unifi stack.

What I have noticed is that whenever the broadcast flag is set on DHCP requests the PfSense box will not respond to the request. This could either be solved by not sending the flag which seems to be the default for almost all of the other IoT devices I have or just allowing static IP config on the Rachio.


" To work around some clients that cannot accept IP unicast datagrams
before the TCP/IP software is configured as discussed in the previous
paragraph, DHCP uses the ‘flags’ field [21]. The leftmost bit is
defined as the BROADCAST (B) flag. The semantics of this flag are
discussed in section 4.1 of this document. The remaining bits of the
flags field are reserved for future use. They MUST be set to zero by
clients and ignored by servers and relay agents. Figure 2 gives the
format of the ‘flags’ field."

I have done packet captures on the pfsense box of these conversations and can confirm the broadcast flag being set as well as the requests being seen by pfsense and the lack of response from pfsense itself.

I know nothing about pfSense but doubt that it would be incompatible with ancient (wired) devices that really need the broadcast flag. IMO Rachio setting it is a bug (a unicast reply would reach it just fine), but it is strange that pfSense would not merely ignore the flag, but block the request altogether.

Is the problem with DHCPDISCOVER, or with DHCPREQUEST? Also, what does the pfSense system log (as opposed to the packet capture) show? See

1 Like

I also run pfsense and had no issues with DHCP once the AP filtering is disabled, different manufacturers call this differently, but you need to make sure that an option to block LAN to WLAN broadcast is disabled, you’ll find this feature under Wireless Networks -> “Multicast and Broadcast Filtering: Block LAN to WLAN Multicast and Broadcast Data” (more on this here).

1 Like

@Gene Correct I have already disabled all of those options and remember I ran a packet capture on the pfsense box and confirmed that it was not responding to these requests so that is why I am focusing on PfSense at this time.

@Stewart I don’t think PfSense is blocking these requests, based on my packet capture it just doesn’t respond to them, maybe I am doing something wrong but when the request is unicast I see response and when it’s broadcast I do not see the response, and I am capturing via mac address and I don’t think promiscious mode is required since I am seeing the original request packet which was sent to broadcast and not unicast.

BTW : I do agree that setting this firmware to unicast like everything else would resolve the issue, so would allowing us to set a static ip.

Start with the pfSense system log. If we see the request but not the response, you are certainly correct and with luck there will be a setting to fix that. It’s also possible that the request is present on the LAN interface but not in the log (it is blocking them), or the response is present in the log but not on the LAN interface (some strange iptables rule?).

Please explain how you are doing the capture (actual commands used) and how you are viewing it, if the result is other than console output.

1 Like

@Stewart I can confirm via the DHCP logs that there is an offer being sent back from the discover from Rachio. However I can’t find this in the packet captures.

Here is the packet capture command line it is using.
Command line: /usr/sbin/tcpdump -i lagg0.100 -s 0 -w /root/packetcapture.cap ‘( ether host 58:d5:0a:xx:xx:xx)’

I hid the last part of the MAC.

1 Like

I suspect that ‘ether host’ does a literal comparison and so won’t catch a broadcast packet. Try
/usr/sbin/tcpdump -i lagg0.100 -s 0 -w /root/packetcapture.cap port 68
which should capture everything DHCP related. Then use Wireshark to see the stuff from/to Rachio.


pfsense has it’s own pocket capture tool, under diagnostics. Have you tried using that?

1 Like

@Gene this is what I am using.

@Stewart this capture shows the proper discover and offer, I am now going to start capturing on the UAP and see where the breakdown is.

Just ran a capture on the specific interface on the AP that corresponds to the SSID and 2.4ghz band and was able to see the broadcast offer being broadcast out.

Ended up disabling the 5ghz band and it seems to have pulled a valid ip address now, going to monitor and see if this sticks.