[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]

LGTM

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