[Dnsmasq-discuss] DHCP static host sitting in dynamic pool (dnsmasq 2.33)

[Matthias Andree]

Greetings,

I have difficulties with a certain configuration on dnsmasq 2.33, where
DHCP clients with static assignment do not move from the dynamic pool to
their static address.

I would like dnsmasq to move the host to its static address without need
to touch the client. ISC DHCPd currently does with a comparable
configuration.

I have two networks, one publicly visible and one 192.168.0.*.
The public  network knows _only_ static addresses,
the private network knows mostly dynamic addresses (except for static
routers and servers and stuff).

These networks are shared over the same wire, on a Linux host with this
configuration (so this is an interface with traditional Solaris-style IP
alias):

(NOTE: all files shown are indented for readability only in this
message. The pristine files such as hosts, to OF COURSE not have this
indentation.)

  2: ethint: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0a:e4:7f:13:84 brd ff:ff:ff:ff:ff:ff
    inet 10.1.163.59/26 brd 10.1.163.63 scope global ethint
    inet 192.168.0.1/24 brd 192.168.0.255 scope global ethint:0
    inet6 fe80::20a:e4ff:fe7f:1384/64 scope link
    valid_lft forever preferred_lft forever

PROBLEM:

  If one of the hosts for which I have a static IP assigned in
  dhcp-host, say "maggie", is in the dynamic pool, dnsmasq will not NAK
  it and move it to its static address. It will however refuse to record
  the host name.

CONSEQUENCES:

  1 - the host isn't on the static IP where it should be

  2 - there is no valid DNS entry for the host. The one returned is stale.

EXPECTATION:

I see that the CHANGELOG for release 2.10 lists this change:

  NAK attempts to renew a pool DHCP lease when a statically allocated
  address has become available, forcing a host to move to it's allocated
  address. Lots of people have suggested this change and been rebuffed
  (they know who they are) the straws that broke the camel's back were
  Tim Cutts and Jamie Lokier.

So I'd expect that the host "maggie" is NAK'd and offered its static IP
address next time a DHCPDISCOVER is received.

Moving hosts that brought a 172.16.15.14 lease from home into the
192.168.0.* pool works fine though.

Log entries:
  dnsmasq[999]: DHCPREQUEST(ethint) 192.168.0.19 00:30:05:XX.XX.XX
  dnsmasq[999]: DHCPACK(ethint) 192.168.0.19 00:30:05:XX.XX.XX

I've tried adding id:* to maggie's dhcp-host entry, to no avail.

I CAN of course force maggie to give up its older lease and fetch a
fresh one, in that case, it will move to her static IP, but I would
like to do this without needing to touch the client.

Is there any hidden debug option that lets me trace how dnsmasq decides
which IP to use?

Is this a configuration issue or a remaining dnsmasq bug?

This is the corresponding leases entry (ARP masked for privacy):

  1155131548 00:30:05:XX:XX:XX 192.168.0.19 * 01:00:30:05:XX:XX:XX

This is my configuration (I've replaced the network identifier by 10.1
and the domain by example.org and masked the last 24 ARP bits with XX):

  domain-needed
  bogus-priv
  no-resolv
  no-poll
  server=127.0.0.1
  address=/doubleclick.net/127.0.0.1
  address=/ivwbox.de/127.0.0.1
  user=nobody
  group=nogroup
  except-interface=ethext,lo
  bind-interfaces
  addn-hosts=/etc/hosts-dnsmasq
  expand-hosts
  domain=example.org
  dhcp-range=10.1.163.0,static,15m
  dhcp-range=192.168.0.10,192.168.0.99,15m
  dhcp-option=42,10.1.163.1,10.1.163.62
  dhcp-option=40,foo
  dhcp-option=19,0           # option ip-forwarding off
  dhcp-option=44,0.0.0.0     # set netbios-over-TCP/IP nameserver(s) aka WINS server(s)
  dhcp-option=45,0.0.0.0     # netbios datagram distribution server
  dhcp-option=46,8           # netbios node type
  dhcp-option=47             # empty netbios scope.
  dhcp-leasefile=/var/db/dnsmasq.leases
  dhcp-authoritative
  cache-size=15000
  local-ttl=60
  bogus-nxdomain=64.94.110.11
  srv-host=_ldap._tcp.example.org
  dhcp-host=00:30:05:XX:XX:XX,maggie

maggie has an entry in /etc/hosts-dnsmasq:

  10.1.163.9   maggie

In case you're wondering, there's a current BIND 9 listening on
127.0.0.1 and ::1, port 53.

Thanks in advance for any help offered.

Kind regards,

-- 
Matthias Andree