Behavior with clients using "Broadcast Flag"

Nicolas C. dhcp at
Fri Oct 5 22:09:57 UTC 2012


I'm using dhcpd version 4.1.1 (Debian Squeeze) and I have some Windows 
Seven clients doing some "discover" instead of "request". This is an 
example :

Sep 26 01:19:34 dhcpd: DHCPDISCOVER from 00:1c:c0:fc:f7:24 (VNDLOL65TEE) 
Sep 26 01:19:34 dhcpd: ICMP Echo reply while lease valid.
Sep 26 01:19:34 dhcpd: if IN TXT 
"31a956a7940aee9c9191f5c7770adf3ed5" rrset exists and IN A rrset exists delete IN A success.
Sep 26 01:19:34 dhcpd: if IN A rrset doesn't 
exist and IN AAAA rrset doesn't exist delete IN TXT "31a956a7940aee9c9191f5c7770adf3ed5": success.
Sep 26 01:19:34 dhcpd: removed reverse map on
Sep 26 01:19:34 dhcpd: Abandoning IP address pinged before 

I think this behavior is caused by the DHCP "Broadcast flag" introduced 
by default by windows Vista (to be confirmed) :

I'm trying to understand what's happening. The DHCP server :

  - receives a "DHCPDISCOVER", assumes that the client has no IP address 
but in fact the client is using its currently leased address (

  - finds a previous lease with the client hardware address, associated 
with the IP address

  - sends an ICMP message to the IP address before replying to the client

  - gets and ICMP response from the IP address and declares the lease 
invalid, cleans the DNS

  - assigns another IP address to the client (not displayed in the log).

Am I right?

Is there a workaround for this on the server-side, maybe on newer 
versions of dhcpd?

Off topic : we've been playing with the registry settings to reproduce / 
fix this problem and it's not working : the clients keep doing broadcast 
whatever the settings are and we cannot force a "fresh" install to do 
broadcat (!!).

Any help on this would be appreciated, the tech support is blaming the 
DHCP server :)



More information about the dhcp-users mailing list