Justin McAteer wrote: > Simon, et al, > > I have a device with a DHCP client that will occasionally go insane. I > have and will continue to work with the vendor, but that is another > discussion altogether. What happens in the particular scenario I am > addressing here is that the DHCP client begins sending DHCP Discover > messages as fast as is possiblefor the device (to the tune of about 40 > per second). DNSMasq seems to be behaving correctly, it is responding > with a DHCP Offer to each query. However, I have dchp-logging enabled > (and I'd like to keep it that way), and I have a fair number of > options going out to this type of client. The symptom is that DNSMasq > is flooding the system log, which seems to have buffering disabled > because kjournald CPU usage is going up to about 50% and wait is going > up to about 20%, so the system basically becomes useless. > > I wonder if it wouldn't make sense to have some kind of rate limiting > option in DNSMasq to help mitigate this type of problem? It seems to > me that this could be a potential avenue for a denial of service > attack.
Without logging, I think dnsmasq is already as hard as it could be against this sort of attack: The DISCOVER-OFFER transaction doesn't allocate any memory or other resources, so extra code to detect a flood would only be able to inhibit sending the DISCOVER packet, which probably costs less than flood-detection. This problem occurred some time ago and revealed a problem with the way dnsmasq does ping-checks on the allocated addresses. That process is now rate-limited for exactly this reason. Have you tried setting log-async in /etc/dnsmasq.conf? That should effectively rate-limit dnsmasq's logging and may provide a complete solution. > > As a side note, I believe this is a problem with the client dealing > with the 'infinite' lease times that we are using. I haven't exactly > pinpointed a repeatable scenario, but I am working on it; when I do I > will file another bug report with the device vendor. The client is broken, no doubt. Cheers, Simon.