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

Simon Kelley simon at thekelleys.org.uk
Fri Sep 9 21:55:28 BST 2016

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.



More information about the Dnsmasq-discuss mailing list