I run a DHCP server using Linux’s dhcpd program to serve addresses to a bunch of clients. These clients are connected over several wireless links, and the radios are sometimes quirky. Specifically, some clients never get the DHCPOFFER unless the ‘always-broadcast’ parameter is on. This usually works out fine.
Today, however, we had a problem where we just saw a bunch of incoming DHCPDISCOVER messages, to which the server would reply with a DHCPOFFER. The devices would just continually send discover messages, and none would ever DHCPREQUEST an address.
From what I can conclude, I think that the clients were confused when they received multiple broadcast responses back for their DHCPDISCOVER message. The client would then send another discover message, which just caused a never-ending loop of requests and offers.
To resolve the problem, I turned off always-broadcast for a few minutes. This made the clients wait for a random period of time before discovering again. Some clients accepted the IP fine even though it wasn’t broadcast. For the ones that didn’t, I then re-enabled always-broadcast, and they picked up an address the next time that they tried.
For a long term solution, we’re working on subnetting the two /24 networks that are currently together into smaller /26 or /27 blocks. That should reduce the possibility of having this happen again.
Might be a rogue “dhcp discovery tool”? I made one.
http://tv.latinsud.com/dhd/