DHCP Proxy broken with particular interface/server (7.0.235.3)

Question

We are evaulating a NAC solution that wants to be the authoritative DHCP server for its quarantine vlans.
So we created a new interface on the controller, and set that interface to use this product as the DHCP server.
Systemwide, we are running with DHCP Proxy enabled because some years ago the passthrough option was not working reliably for us alongside DHCP_REQD.  Since this is a global setting we are somewhat reluctant to go playing around with it.
The WiSM card sends the DHCP request to the alternate DHCP server, that server replies, and we can even see the DHCP offer being sent out the PortChannel to the controller via a span sniff. All the source and destination addresses on the offer look OK.  However, clients assigned to this interface do not acquire a DHCP address.
A DHCP address can be successfully obtained from a wired client joined to the same VLAN (the helper address is there, too.  This should not interfere, and doesn't, as we tried removing it just to be thorough and still the WLC does not work.)
In the debug logs we see that interface marked as dirty for failure to resolve DHCP.  However we are not using interface groups so there should be no other alternative, and as far as we can tell delivery of the requests to the DHCP server is not being blocked by the failover mechanism:
*DHCP Proxy DTL Recv Task: Feb 21 13:58:24.70 9: %SIM-3-DHCP_SERVER_NO_REPLY: sim_interface.c:1039 Failed to get DHCP response
on interface 'regtest'. Marking interface dirty.
We've tried moving the APs temporarily and rebooting the controller with the interface configuration saved to flash.  This did not jog anything loose.  If we set the DHCP servers on the interface back to the same servers that all the other interfaces use, DHCP works for wireless clients.
The NAC appliance uses what appears to be a vanilla Linux server, as do we in production.  We can see and even alter the config for that server, and it does not contain anything eclectic, just the run of the mill options.
We've tried using DHCP override on the test SSID to send all DHCP for every interface to the NAC appliance (not our desired final result, just as a test.)  This fails as well.
Anybody have any other ideas as to how to jog this loose, how to ferret more information out of the controllers, something we may have missed configuration-wise, or a bug ID?

Answer 1

It's a hold over from the Airespace code.  In the early versions, the way the WLC learned the client IP address to put them into a RUN state, was to proxy the DHCP request, so they could see the IP offered to the client.
Granted it wasn't ideal but it was the way they did it.  Now it's learned a different way, but proxy is still the default, and required if the WLC acts as a DHCP server.
HTH,
Steve
Please remember to rate useful posts, and mark questions as answered