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

[Simon Kelley]

On 24/09/13 19:06, Vladislav Grishenko wrote:
>> 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.

The problem is that you're asking for two incompatible things. You want 
the leasefile format to be a defined interface, which implies, amongst 
other things, that it's stable, and you want to change the leasefile format.

BTW, as far as I'm concerned, the leasefile format has never been a 
defined interface, if people are looking in there directly, that's their 
risk.

>
>> 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.

HAVE_SCRIPT isn't very big and this tiny shell script makes a file of 
(IP-address, MAC-address) pairs. It's trivial to alter it to split IPv4 
and IPv6 into different files or include any information from the fields 
exposed by the script interface. The script interface is defined and 
I'll keep it compatible going forward.


#!/bin/bash

MACFILE=/tmp/macfile

action=${1:-0}
ip=$3
mac=$2 # IPv4

if [ ${DNSMASQ_IAID} ] ; then
    mac=${DNSMASQ_MAC} # IPv6
fi

if [ ! -f ${MACFILE} ] ; then
     touch ${MACFILE}
fi


if [ ${action} = add ] ||
    [ ${action} = old ] ||
    [ ${action} = del ] ; then
     grep -v ^${ip} ${MACFILE} >${MACFILE}.new
     if [ ${action} = add ] ||
        [ ${action} = old ] ; then
	echo ${ip} ${mac} >> ${MACFILE}.new
     fi
     mv ${MACFILE}.new ${MACFILE}
fi


Cheers,

Simon.