[Dnsmasq-discuss] Sequential address assignment

[Eric Thibodeau]

Simon Kelley wrote:
> Eric Thibodeau wrote:
>>    I would like to know if it would be possible to add a simple 
>> feature that would tell dnsmasq to assign addresses sequentially (ie: 
>> --dhcp-sequential). I am looking at address_allocate() in dhcp.c and 
>> it would seem feasible without much "damage" but I'm not accustomed 
>> to the code sufficiently to propose a patch. The obvious question is 
>> WHY? Well, here is a use case:
>>
>>    I am building a clustering livecd (as stated in a previous e-mail) 
>> and one of the tasks which tends to be long, annoying and error prone 
>> is the identification of nodes, typing of MAC addresses and node 
>> number assignment, which usually comes in the form of a static 
>> configuration file. To ease the process, one would fire up dnsmasq 
>> (on the master node) and sequentially start his slave nodes for the 
>> first time. I make sure the assignment remains static after the 
>> initial start by auto-generating (dhcp-script) the dnsmas.ndoes.conf 
>> which I'd obviously source within dnsmasq.conf.
>>
>>    Is this a reasonable feature to ask for? Does this violate any 
>> RFC? As far as security is concerned, it's not an issue since this is 
>> a closed network.
>
> The reason it's done the way it is goes like this: It's good to offer 
> the same address to a node whenever it does dhcpdiscover. Not doing so 
> is probably OK from an RFC  point of view, but may well confuse some 
> clients. The standard way to do this is to keep some state in the 
> lease database when DHCPDISCOVER happens, you record what address was 
> offered. That's how ISC dhcpd works.
>
> For dnsmasq, I wanted to have the DISCOVER/OFFER part of the DHCP 
> protocol work without touching the lease database - it make 
> implementing that much easier. Therefore the offered address is 
> determined as a hash of the MAC address. Apart from collisions, a host 
> is always offered the same address when is does a DISCOVER, without 
> needing to use the lease database.
Is this the part of code you're referring to (dhcp.c):

552       /* pick a seed based on hwaddr then iterate until we find a 
free address. */
553       start.s_addr = addr.s_addr =
554         htonl(ntohl(c->start.s_addr) +
555           ((j + c->addr_epoch) % (1 + ntohl(c->end.s_addr) - 
ntohl(c->start.s_addr))));

Which then gets an offset if it happens to match an existing lease which 
isn't his and is in use:

589           /* address in use: perturb address selection so that we are
590              less likely to try this address again. */
591           c->addr_epoch++;

Would this be the part to be swapped by an optional --incremental to 
something like (pseudo code):

if (sequential)
    start.s_addr = RANGE_START + 1

(search for address collisionn)

if (collision)
    start.s_addr++

(^^^ my blunt ignorance of the addr scruct value but the idea is there. )

This implies the search by address is already implemented and the code 
leads me to believe it is.
>
> If that's changed, you either need to complicate the lease database, 
> or just use a counter and offer the next address each time a DISCOVER 
> comes in. That means that a client gets offered different addresses 
> each time it does a DISCOVER. Very early versions of dnsmasq worked 
> like this, and it didn't cause problems.
Yeah, comment above.. Simple `static int counter`. Let's not forget the 
incremental search will also assign holes when one is met and is not 
reserved, which makes sense.
>
> Cheers,
>
> Simon.
>
>>
>> Thanks,
>>
>> Eric Thibodeau
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>