DHCP Issues

post by bigjohns97 on Jun 2, 2021

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.

https://www.ietf.org/rfc/rfc2131.txt

" 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.

post by Stewart on Jun 2, 2021

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?

post by Gene on Jun 2, 2021

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).

post by bigjohns97 on Jun 2, 2021

@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.

post by bigjohns97 on Jun 2, 2021

@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.

post by Stewart on Jun 2, 2021

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.

post by bigjohns97 on Jun 2, 2021

@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.

post by Stewart on Jun 2, 2021

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.

post by Gene on Jun 2, 2021

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

post by bigjohns97 on Jun 2, 2021

@Gene this is what I am using.

post by bigjohns97 on Jun 2, 2021

@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.

post by bigjohns97 on Jun 2, 2021

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.

post by bigjohns97 on Jun 2, 2021

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.

post by mnbf9rca on Apr 30, 2025

did you ever figure out how to get past this? I see the same thing with OPNSense:

Date
Severity
Process
Line
2025-04-30T18:31:41	Informational	dhcpd	DHCPOFFER on 192.168.17.210 to 00:9d:6b:c2:a2:f6 via lagg0
2025-04-30T18:31:41	Informational	dhcpd	DHCPDISCOVER from 00:9d:6b:c2:a2:f6 via lagg0
2025-04-30T18:31:33	Informational	dhcpd	DHCPOFFER on 192.168.17.210 to 00:9d:6b:c2:a2:f6 via lagg0
2025-04-30T18:31:33	Informational	dhcpd	DHCPDISCOVER from 00:9d:6b:c2:a2:f6 via lagg0
2025-04-30T18:31:29	Informational	dhcpd	DHCPOFFER on 192.168.17.210 to 00:9d:6b:c2:a2:f6 via lagg0
2025-04-30T18:31:29	Informational	dhcpd	DHCPDISCOVER from 00:9d:6b:c2:a2:f6 via lagg0
2025-04-30T18:31:16	Informational	dhcpd	DHCPOFFER on 192.168.17.210 to 00:9d:6b:c2:a2:f6 via lagg0

post by bigjohns97 on Apr 30, 2025

Ended up moving to a unifi dream machine pro and started the unifi config from scratch. What I would suggest is resetting the unfi configs back to complete default and seeing if that resolves your issue

Arp proxy and multicast optimizations are the likely culprit here.