[Dnsmasq-discuss] [PATCH] rfc2131: Fix range address assignment not honoring vendor option filters

Hans Dedecker dedeckeh at gmail.com
Wed Sep 14 15:20:08 BST 2016


On Fri, Sep 9, 2016 at 10:55 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> On 05/09/16 15:35, Hans Dedecker wrote:
>> Problem is visible when using multiple dhcp-ranges; one dhcp-range is a "catch-all"
>> range without tags while the second dhcp-range has tags based on vendor-class/user-class/...
>> If a client sends a DORA with no specific IP and no vendor/user class it will get an IP addres
>> from the "catch-all" range; if the client renews (or restarts) with a vendor/user class
>> and a request IP option holding the "catch-all" IP it will get DHCP options from the
>> dhcp-range based on vendor-class/user-class but will get the requested IP address acked.
>> This patch solves this problem as it detects a tag is assigned based on the vendor-class/user-class
>> and actually checks if the requested IP belongs to the correct dhcp-range; if not the client will
>> be nacked to it can restart its DORA sequence.
>>
>
>
> I'm happy to work on understanding this patch if it's really necessary,
> but an alternative way of working around this client behaviour, without
> code changes, may be to abandon the "catch all" range, and declare the
> two ranges explicitly,
>
> dhcp-vendorclass=set:special, .......
>
> dhcp-range = tag:special, ......
>
> # range used for hosts that don't have a special class
> dhcp-range = tag:!special, ......
>
>
> If there are multiple special classes, the catch-all becomes
>
> dhcp-range = tag:!special1, tag:!special2, tag:!special3
>
> Doing it like this, when a previously ordinary client acquires "special"
> status, the catch-all range ceases to apply, and the re-addressing
> should happen automatically.
Maybe I should have added a slightly patch description which describes
the problem more clearly.
If a client sends a DHCP discover containing the requested IP option
dnsmasq acks the IP address (depending on certain conditions like ip
address is available in a defined range, no lease, etc ... )
irrespective from the fact a policy class is defined for the client
(eg based on the vendor class) instructing it to take an IP address
from a different pool.
You have no control over neither the presence or the contents of the
requested IP option in a discover message sent by the client but I
would expect the server to respect the policy class put into place
independent from the requested IP option.
I don't think this problem can be fixed by config unless I'm missing
something; the delivered patch addresses this problem.

Bye,
Hans
>
>
> Cheers,
>
> Simon.
>
>
>
>
>



More information about the Dnsmasq-discuss mailing list