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