DHClient and unicast DHCPREQUESTs

[tix]

I've recently noticed stability problems with my WAN connection to my Cable ISP.  It seems to have been happening for sometime but was usually just apinger failure then a restore.  Recently I've finally noticed the DHCPREQUESTs showing in the system.log which I've never noticed until recently.

When the interface starts trying to renew the lease, dhclient is sending unicast DHCPREQUESTs back to the server but these fail.  Eventually dhclient gives up trying unicast and starts using broadcast and the lease is renewed.

Is there any way to disable unicast and force broadcast?

(System is a nano install on a firebox x700 - latest 2.1 snapshot).

Log file shows:

(many more of the following prior to this)
Jul 22 11:53:30 pfsense dhclient[15244]: DHCPREQUEST on re5 to 10.72.44.1 port 67
Jul 22 11:54:47 pfsense dhclient[15244]: DHCPREQUEST on re5 to 10.72.44.1 port 67
Jul 22 11:55:57 pfsense dhclient[15244]: DHCPREQUEST on re5 to 10.72.44.1 port 67
Jul 22 11:57:52 pfsense dhclient[15244]: DHCPREQUEST on re5 to 10.72.44.1 port 67
Jul 22 12:01:08 pfsense dhclient[15244]: DHCPREQUEST on re5 to 255.255.255.255 port 67
Jul 22 12:01:09 pfsense dhclient[15244]: DHCPACK from 10.72.44.1
Jul 22 12:01:09 pfsense dhclient: RENEW
Jul 22 12:01:09 pfsense dhclient: Creating resolv.conf
Jul 22 12:01:09 pfsense dhclient[15244]: bound to x.x.x.x -- renewal in 21600 seconds.
Jul 22 18:01:09 pfsense dhclient[15244]: DHCPREQUEST on re5 to 10.72.44.1 port 67
(many more after this until eventually dhclient tries a broadcast like above)

[tix]

Replying to myself to document a resolution….

Worked with Tier4 support to get this fix but turned out to be a problem with the DHCP server at the ISP not responding to unicast renewals.  They have corrected the problem with my regional server.

The second part of this is that the BOGONs rule was preventing the reciept of the packet which required a rule to allow traffic from this specific IP.

I still would like to find out a way to have the dhclient send only broadcasts (even if it breaks the RFC) in the event this problem arises in the future.