[Dnsmasq-discuss] Automatic DHCP client naming

Ferenc Wagner wferi at niif.hu
Mon Apr 19 17:32:44 BST 2010


Simon Kelley <simon at thekelleys.org.uk> writes:

> Ferenc Wagner wrote:
>
>> I can recall reading some warnings about long-running dhcp-scripts, that
>> they block dnsmasq.  Did this change?
>
> It has never been the case, dnsmasq will continue to function even if
> the a dhcp never completes. The rules go like this: at most one instance
> of the script is ever running (dnsmasq waits for the script to exit
> before running the next). Changes to the lease database are which
> require the script to be invoked are queued waiting running of the
> script. The only time that a slow script can have any affect is if
> multiple state-changes occur to a single lease before the script can be
> run. In that case earlier states are discarded and the current state is
> refelected when the script runs.

This paragraph really desires a prominent place in the manual.  Thanks
for the clarification!

>> Anyway, wouldn't synchronous scripts be a worthy option, especially if
>> given the possibility to communicate data back to dnsmasq?  It's also
>> easy to fork off an async worker from a sync helper, if needed.
>
> Strict asynchronous (ie block the daemon completely until the script
> returns) would be a very bad idea since it would stop DNS requests as
> well as DHCP. It's very difficult to write a script and be sure that it
> never does DNS resolution, so deadlock would be an ever-present
> possibility. Being a bit more clever and just blocking DHCP would be
> possible, but still opens up the possibility of strange effects if a
> script blocks. Making the DHCP server multi-task will turn dnsmasq into
> ISC dhcpd: a biggish program with a much bigger memory footprint and
> make it much less useful on hardware-limited platforms.

Yes, a timeout should be forced in all cases.

>> A built-in solution (maybe in dhcp-generate-names) would be safer and
>> more efficient, but somewhat cumbersome, because one may want to use the
>> hardware address, the IP address, the client ID, the client provided
>> hostname etc. as a source. 
>
> It's also the case that of the members of that list, _only_ the IP
> address is guaranteed always to be available. (though a proxy for the
> MAC address is always around too.
>
>  For my purposes, something like
>
>> dhcp-ignore-names
>> dhcp-generate-names=hwaddr:y/:/-/
>> 
>> would be enough, and dnsmasq already has some regex machinery included,
>> but I'm not sure this scheme is general enough, or whether the extra
>> safety and efficiency is worth it.  Just brainstorming...
>
> There's no regex machinery available.

Then I was misled by
--naptr-record=<name>,<order>,<preference>,<flags>,<service>,<regexp>[,<replacement>]

> something like
> dhcp-generate-names=mac:<prefix>,<tag>
> and
> dhcp-generate-names=ip:<prefix>,<tag>
> would be OK, both prefix and tags being optional.

I'd certainly appreciate something like this.  Given some instructions,
I'd even try implementing it, if it's easy enough.  Is there a public
source control repo for dnsmasq?
-- 
Thanks,
Feri.



More information about the Dnsmasq-discuss mailing list