[Dnsmasq-discuss] [PATCH] dnsmasq 2.47 introduced a work-around for errant Windows behaviour, in that it did not assign IP addresses ending in .255 or .0 within the class c range even when using supernetting. 15 years on, the Windows versions that were broken in this way have reached end of support, and so we can now swing these addresses into use.

[Petr Menšík]

When thinking about this again, maybe it would be safer to make it not 
compiled by define at compile time, before we remove that additional 
check altogether?

I have hit this comment once too. And wondered why we need such hacks 
long after Windows XP are history.

Do we have any proposal, how to make such workarounds, if we need to 
work with ancient broken systems? Would declaring explicit dhcp-host 
with 0 and 255 final prevent assigning that to new system, if needed?

dhcp-range=192.168.0.1,192.168.1.254,255,255,254.0
# would this prevent leasing this address instead?
dhcp-host=reserved01,192.168.0.255
dhcp-host=reserved02,192.168.1.0

I think it should be possible to move this from the code to the 
documentation, but just removing safe-guards without alternatives seems 
risky. Recommended replacement should be somehow specified. Would 
specification of two dhcp-range work, one for 192.168.0.* and 
192.168.1.* separately, if I want to avoid some addresses? Even if the 
real netmask on interface is 192.168.0.1/23?

Cheers,
Petr

On 24/09/2024 08:52, Jan Ceuleers wrote:
> Signed-off-by: Jan Ceuleers <jan.ceuleers at gmail.com>
> Reviewed-by: Wang Xiaobo <xiangbo.wang at nokia-sbell.com>
> ---
>   src/dhcp.c | 9 +--------
>   1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/src/dhcp.c b/src/dhcp.c
> index b65facd..586117d 100644
> --- a/src/dhcp.c
> +++ b/src/dhcp.c
> @@ -821,16 +821,9 @@ int address_allocate(struct dhcp_context *context,
>   	      if (addr.s_addr == d->router.s_addr)
>   		break;
>   
> -	    /* Addresses which end in .255 and .0 are broken in Windows even when using
> -	       supernetting. ie dhcp-range=192.168.0.1,192.168.1.254,255,255,254.0
> -	       then 192.168.0.255 is a valid IP address, but not for Windows as it's
> -	       in the class C range. See  KB281579. We therefore don't allocate these
> -	       addresses to avoid hard-to-diagnose problems. Thanks Bill. */	
>   	    if (!d &&
>   		!lease_find_by_addr(addr) &&
> -		!config_find_by_address(daemon->dhcp_conf, addr) &&
> -		(!IN_CLASSC(ntohl(addr.s_addr)) ||
> -		 ((ntohl(addr.s_addr) & 0xff) != 0xff && ((ntohl(addr.s_addr) & 0xff) != 0x0))))
> +		!config_find_by_address(daemon->dhcp_conf, addr))
>   	      {
>   		/* in consec-ip mode, skip addresses equal to
>   		   the number of addresses rejected by clients. This

-- 
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB