[Dnsmasq-discuss] Release candidate dnsmasq-2.47rc1

[Simon Kelley]

Olaf Westrik wrote:
> Carlos Carvalho wrote:
>> Simon Kelley (simon at thekelleys.org.uk) wrote on 27 January 2009 22:03:
>>  >             Don't dynamically allocate DHCP addresses which may break
>>  >             Windows.  Addresses which end in .255 or .0 are broken in
>>  >             Windows even when using supernetting.
>>  >             --dhcp-range=192.168.0.1,192.168.1.254,255,255,254.0 means
>>  >             192.168.0.255 is a valid IP address, but not for Windows.
>>  >             See Microsoft KB281579. We therefore no longer allocate
>>  >             these addresses to avoid hard-to-diagnose problems.
>>
>> Which in turn may produce hard-to-understand no-free-leases
>> problems... Please make it an option.
>>   
> 
> really?
> 
> Unless you are doing something like
> 
> --dhcp-range=192.168.0.254,192.168.1.1,255,255,254.0
> 
> (which is a pretty weird thing to do if you ask me), you have a fairly
> large dynamic IP range.
> Now *I* am not going to sit down and look which IP addresses are left
> unused in a /23 network.
> When 500-something IP addresses are used, it is time to either enlarge
> the supernet or split the network into two (or more) networks.
> 
> 
> If it will be an option (say
> --break-windows-client-caused-by-strange-concept-of-supernets), I want
> the default to be to not break the windows dhcp client(s).
> 
> 
> Olaf
> 

It's worth noting that dnsmasq can fail to allocate a dynamic DNS
address for two different reasons.

1) There are no free addresses (no address available)
2) The number of leases allowed has been reached (no leases left)

The limit on the first is the size of the address range, less addresses
which can't be allocated. The limit on the second defaults to 150 and is
set using --dhcp-lease-max


It's good practice to set the limit on the number of clients on  your
network using dhcp-lease-max, not by limiting the address range. The
reason for this is that dnsmasq picks the address it offers a client
using a hash of the MAC address. If you use nearly all the addresses in
the available range, then hash collisions become more likely, and the
desirable feature that an individual client always gets a stable IP
address is lost: It's likely that a clients "preferred" address will be
in use.

The same applies to ISC dhcpd which doesn't use the hash method, but
keeps a database of all clients it has ever seen. If the address range
is heavily used then addresses have to be re-allocated and address
stability is lost.

I don't want to make the "windows fix" optional and default off, and if
I made it optional and default on, it's better for systems which are
affected to expand the address range, rather than turn it off.

It's also worth noting that this only affects addresses which are class
C in the non-CIDR world. 10.0.1.0 is still OK for use.

Cheers,

Simon.