Re: dnsmasq dhcp failure

On Friday, 14 October 2022 10:07:22 PM AEDT Erich Titl wrote:
> Hi
> 
> Am 14.10.2022 um 10:41 schrieb Andrew:
> 
> > 14.10.2022 01:24, Erich Titl пишет:
> 
> ....
> 
> 
> >> It would be different if this was the DNS caching part of dnsmasq. But 
> >> then, to be honest, I hasve not even looked at this as a client 
> >> becomes nonfunctional if it cannot get an IP address.
> >>
> >>
> >>
> >> cheers
> >>
> >>
> >>
> >> ET 
> > 
> > monit can run external command or script. for ex., something like 'ip 
> > n|grep 192\.168\.0 | wc -l' (but it needs to have at least 1 client 
> > active), or compare iptables packes counter for 2 rules (input/output) 
> > for DHCP.
> 
> 
> Yes, an external check is what it takes but it cannot be as simple as 
> just checking the ip stack. There may be valid dhcp leases and still 
> issuing new leases may fail.
> 
> It would require a process which fakes a client, e.g. injects a dhcp 
> request into the IP stack. I have not looked into this but it appears 
> not to be that simple.
> 
> Maybe a virtual machine which just tries to get a dhcp lease and in case 
> of a failure sends a wakeup call to the dhcp daemon. But then who 
> watches the virtual client and its communication. This may just as well 
> fail like the dhcp daemon itself. This said it is not as easy as just 
> install monit.
> 
> Maybe we can switch on dhcp logging on dnsmasq and find patterns that 
> allow us to detect the failure in the logs.
> 
> ET


Can we not send a dhcp request using nc or similar, requesting a dhcp address?  
The offer never needs to be accepted, but no offer means dnsmasq is not working 
properly.    

A cron script could do that without too much difficulty.

There is a deeper problem though.  If dnsmasq gets restarted, the existing 
dhcp lease information is lost.  Until those client renew their address, they 
are not resolvable.   I set long leases on security cameras, typically 24hrs 
so they don't lose their address and go offline if the dhcp server is not 
available.  This is ok because  I can still resolve via know ip address, but 
this won't work for casual clients in non bound systems.  









------------------------------------------------------------------------
leaf-user mailing list: [email protected]
https://lists.sourceforge.net/lists/listinfo/leaf-user
Support Request -- http://leaf-project.org/