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.



Reply via email to