Thanks, I will try the 'log-async' option. Hopefully this will help mitigate the problem.
Thanks, Justin On Wed, Apr 28, 2010 at 10:23 AM, Simon Kelley <si...@thekelleys.org.uk> wrote: > 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. > > > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >