[Dnsmasq-discuss] Reg: Info related to leases file

[Vladislav Grishenko]

> From: Simon Kelley [mailto:simon at thekelleys.org.uk]
> Sent: Tuesday, September 24, 2013 9:16 PM
> 
> On 24/09/13 15:31, Vladislav Grishenko wrote:
> > Hi Simon,
> >
> >> However, if you're interested in the MAC addresses of clients, the
> >> very
> > latest
> >> dnsmasq code can determine that in most cases. The MAC address is not
> >> stored in the leases file, but it can be used to key configurations
> >> to
> > particular
> >> MAC addresses, and it's made available to the DHCP lease external
> >> script,
> > so
> >> an external application can use it.
> >
> > Storing MACs for DHCPv6 clients is just exactly I'm looking for.
> > In my scenario, lease file is used to obtain current list of DHCP4/6
> > clients as some status information, the latter usage of this info is:
> > * DHCP4/6 reservation, it's MAC-based, because client DHCP6 DUID-LLT
> > is dynamic by the nature, thanks for implementing this approach
> > * client blocking, it's MAC bases too
> > So, storing lease info with MAC for DHCPv6 clients (if available, that
> > is highly likely for direct-connected clients) is the simplest way for
> > my case without usage any other leasudump-like api
> >
> > Best Regards, Vladislav Grishenko
> >
> >
> >
> 
> I realise that adding to MAC to the leasefile for DHCPv6 clients would
make
> this possible, but I'm reluctant to change the leasefile format.

I understand that leasefile format is preserved due legacy reasons to allow
dnsmasq precompiled updates.
What if just to add LEASEFILE_LEGACY_FORMAT define to control the subj
format?
Ppl who able to build it and to control lease format dependent apps would be
able to enable/disable it and use on his own, while the rests can continue
to use legacy defaults with no harm.
No code redundancy would be brought this way, new/old lease-format code
would be just not compiled in, anyway don't treat this opinion as a kind of
pushing, just consider it's probably good to have it in upstream.

> One way to do this now is to script (as script or with Lua) something
> which maintains an extended lease database. It's actually possible to do
> without the leasefile at all (which saves on writes to flash
> filesystems) and have the script maintain the database in any database
> engine you like.
> Another possibility for a future enhancement is to add a method to the
> DBus interface to read the lease database. There's a lot of information
> that can be known about a lease/client that will never go into the
> leases file, but could be accessible this way: look at all the
> environment variables set when the DHCP script is run.

Thanks for the remind, both cases require either HAVE_SCRIPT or HAVE_DBUS to
be enabled, openwrt folks use scripts from the very start. 
So, dnsmasq code, additional not-dnsmasq file sizes & required mem
increases, complexity grows, possible fault places number too, with the same
desired result as if leasefile contains new lease info.
In my humble opinion, it seems a little bit overkill for embedded world.
As an example - a number of recent mails of Tomato firmware folks here in
the list when they decided to update dnsmasq and have accidentally dropped
homegrown leases-save code, that extends the format of the original one.
They have the same reasons - keep dnsmasq & outter environment as small and
functional as possible.

Best Regards, Vladislav Grishenko