[Dnsmasq-discuss] dhcpv6 problem with static allocations and "no addresses available"

Discussion:

Carlos Carvalho

2015-10-20 21:33:05 UTC

I'm stumbling on an important problem that looks like a bug in dnsmasq. Clients
declared statically in a zone are being denied their address with the message
"no addresses available":

Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 available DHCPv6 subnet: 2801:82:80ff:7f05::/64
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 vendor class: 40712
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 client MAC address: 10:bf:48:71:65:99
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 DHCPSOLICIT(meteo) 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 DHCPADVERTISE(meteo) 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 no addresses available
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 tags: known, dhcpv6, meteo
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 14 option: 1 client-id 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 10 option: 2 server-id 00:03:00:01:00:24:8c:0c:37:90
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 24 option: 13 status 2 no addresses available

Note that the client is recognized because the known tag is set. The dhcp
config is the following:

interface=meteo
dhcp-range=::,constructor:meteo,static,infinite
enable-ra
dhcp-range=192.168.5.1,static

dhcp-host=cobb,192.168.5.11,[2801:82:80ff:7f05:12bf:48ff:fe71:6599],10:bf:48:71:65:99,id:00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99
[other dhcp-host declarations]

dhcp-host=elbrus,192.168.5.75,[2801:82:80ff:7f05:12bf:48ff:fe79:aa07],10:bf:48:79:aa:07,id:*

At first I tried to use only id:* for all machines but started getting refusals
like the above. I noticed that the DUID was changing, so I fixed it in the
client. Still got sporadic refusals (it doesn't happen everytime?!). Then I put
the full id in the config as shown above for host cobb. Even then dnsmasq is
refusing it. How can this be? Also, the refusal is for IPv6 only.

There's no collision with other declarations omitted above, I checked with
grep.

This is important because these hosts are diskless and without the IP they
cannot access the root server and thus don't boot.

On a related issue, is it possible to always use only the hardware address for
dhcpv6 and not the full DUID? In my case it may happen when diffent programs
are used for requests, such as UEFI firmware and linux in diskless stations.
Since the machine doesn't have permanent storage it's difficult to keep the
DUID constant.

Simon Kelley

2015-10-21 21:51:32 UTC

Permalink

Post by Carlos Carvalho
I'm stumbling on an important problem that looks like a bug in
dnsmasq. Clients declared statically in a zone are being denied
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 available DHCPv6
6947286 client MAC address: 10:bf:48:71:65:99 Oct 20 09:56:10
dnsmasq-dhcp[18342]: 6947286 DHCPSOLICIT(meteo)
00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 Oct 20 09:56:10
dnsmasq-dhcp[18342]: 6947286 DHCPADVERTISE(meteo)
00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 no addresses available
Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 tags: known, dhcpv6,
meteo Oct 20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 14
option: 1 client-id 00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99 Oct
20 09:56:10 dnsmasq-dhcp[18342]: 6947286 sent size: 10 option: 2
server-id 00:03:00:01:00:24:8c:0c:37:90 Oct 20 09:56:10
dnsmasq-dhcp[18342]: 6947286 sent size: 24 option: 13 status 2 no
addresses available
Note that the client is recognized because the known tag is set.
interface=meteo dhcp-range=::,constructor:meteo,static,infinite
enable-ra dhcp-range=192.168.5.1,static
dhcp-host=cobb,192.168.5.11,[2801:82:80ff:7f05:12bf:48ff:fe71:6599],10

:bf:48:71:65:99,id:00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99
[other dhcp-host declarations]

Post by Carlos Carvalho
dhcp-host=elbrus,192.168.5.75,[2801:82:80ff:7f05:12bf:48ff:fe79:aa07],

10:bf:48:79:aa:07,id:*

Post by Carlos Carvalho
At first I tried to use only id:* for all machines but started
getting refusals like the above. I noticed that the DUID was
changing, so I fixed it in the client. Still got sporadic refusals
(it doesn't happen everytime?!). Then I put the full id in the
config as shown above for host cobb. Even then dnsmasq is refusing
it. How can this be? Also, the refusal is for IPv6 only.

Maybe there are leases for old UIDS and the static address still the
database?

Post by Carlos Carvalho
There's no collision with other declarations omitted above, I
checked with grep.
This is important because these hosts are diskless and without the
IP they cannot access the root server and thus don't boot.
On a related issue, is it possible to always use only the hardware
address for dhcpv6 and not the full DUID? In my case it may happen
when diffent programs are used for requests, such as UEFI firmware
and linux in diskless stations. Since the machine doesn't have
permanent storage it's difficult to keep the DUID constant.

Yes, in general. The DHCPv6 spec makes it hard, but dnsmasq will allow
you to use just the MAC address to identify DHCP hosts even for
DHCPv6. If you are using a DHCPv6 relay, then the relay has to add an
option which specifies the MAC address. If network is directly
connected to the DHCP server, then it should Just Work with recent
dnsmasq releases.

Cheers,

Simon.

Post by Carlos Carvalho
______________

_________________________________

Post by Carlos Carvalho
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Carlos Carvalho

2015-10-21 22:18:42 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

:bf:48:71:65:99,id:00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99
[other dhcp-host declarations]

Post by Carlos Carvalho
dhcp-host=elbrus,192.168.5.75,[2801:82:80ff:7f05:12bf:48ff:fe79:aa07],

10:bf:48:79:aa:07,id:*

Maybe there are leases for old UIDS and the static address still the
database?

No, I start dnsmasq without any lease. Just noticed that I didn't include a few
lines of the config, sorry. Here it is, complete:

interface=meteo
dhcp-range=::,constructor:meteo,static,infinite
enable-ra
dhcp-range=192.168.5.1,static

dhcp-host=cobb,192.168.5.11,[2801:82:80ff:7f05:12bf:48ff:fe71:6599],10:bf:48:71:65:99,id:00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99

[other dhcp-host declarations]

dhcp-host=elbrus,192.168.5.75,[2801:82:80ff:7f05:12bf:48ff:fe79:aa07],10:bf:48:79:aa:07,id:*

# extra config lines missed in first email
log-dhcp
dhcp-authoritative
dhcp-lease-max=250
dhcp-ignore=#known
dhcp-ignore-names
no-ping
leasefile-ro
domain=my.domain
dhcp-option=option:ip-forward-enable

Note that only known machines are accepted. The lease-max is 250 but there are
only 7 dhcp-host declarations (2 of them are listed above). Since only
statically declared machines are accepted I use leasefile-ro, so there are no
disk files and when the process starts there are no leases.

Good. There are no relays so when we solve the current issue I can go back to
using id:*. I'm running 2.74-rc2.

Albert ARIBAUD

2015-10-22 05:20:34 UTC

Permalink

Hi Carlos,

Le Wed, 21 Oct 2015 20:18:42 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Simon Kelley
Maybe there are leases for old UIDS and the static address still the
database?

No, I start dnsmasq without any lease.

Just to make sure, as your answer may mean various things: did you
explicitly delete the current leases file while dnsmasq was stopped and
only then start dnsmasq again?

Amicalement,

--
Albert.

Carlos Carvalho

2015-10-22 14:50:14 UTC

Permalink

Post by Albert ARIBAUD
Le Wed, 21 Oct 2015 20:18:42 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Simon Kelley
Maybe there are leases for old UIDS and the static address still the
database?

No, I start dnsmasq without any lease.

Just to make sure, as your answer may mean various things: did you
explicitly delete the current leases file while dnsmasq was stopped and
only then start dnsmasq again?

With leasefile-ro nothing is read when the process starts.

Albert ARIBAUD

2015-10-22 16:33:28 UTC

Permalink

Hi Carlos,

Le Thu, 22 Oct 2015 12:50:14 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Albert ARIBAUD
Le Wed, 21 Oct 2015 20:18:42 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Simon Kelley
Maybe there are leases for old UIDS and the static address still the
database?

No, I start dnsmasq without any lease.

Just to make sure, as your answer may mean various things: did you
explicitly delete the current leases file while dnsmasq was stopped and
only then start dnsmasq again?

With leasefile-ro nothing is read when the process starts.

Technically, with --loeasefile-ro, no lease file is read but the
lease-change script can still produce valid leases on its stdout, and
these will be taken into account.

Now, I assume you don't use the lease-change script or you have made
sure it does not output any valid lease.

Amicalement,

--
Albert.

Carlos Carvalho

2015-10-22 18:05:12 UTC

Permalink

Post by Albert ARIBAUD
Hi Carlos,
Le Thu, 22 Oct 2015 12:50:14 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Albert ARIBAUD
Le Wed, 21 Oct 2015 20:18:42 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Simon Kelley
Maybe there are leases for old UIDS and the static address still the
database?

No, I start dnsmasq without any lease.

Just to make sure, as your answer may mean various things: did you
explicitly delete the current leases file while dnsmasq was stopped and
only then start dnsmasq again?

With leasefile-ro nothing is read when the process starts.

Technically, with --loeasefile-ro, no lease file is read but the
lease-change script can still produce valid leases on its stdout, and
these will be taken into account.

Correct.

Post by Albert ARIBAUD
Now, I assume you don't use the lease-change script or you have made
sure it does not output any valid lease.

Yes. In message
Message-ID: <***@fisica.ufpr.br>
I made sure to not miss any dhcp configuration, and there's no dhcp-script
there. Further, it's not compiled in:

Oct 20 10:01:27 dnsmasq[23897]: started, version 2.74test2 cachesize 500
Oct 20 10:01:27 dnsmasq[23897]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-scripts TFTP no-conntrack no-ipset auth DNSSEC loop-detect inotify

Additionally, the refusal doesn't happen everytime. Since the current process
started, on the date shown above, there have been no problems. However, the log
I sent before shows that it does happen. If undue refusals appear I have to
restart the process to get the client to boot.

Albert ARIBAUD

2015-10-22 18:48:50 UTC

Permalink

Bonjour Carlos,

Le Thu, 22 Oct 2015 16:05:12 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Albert ARIBAUD
Hi Carlos,
Le Thu, 22 Oct 2015 12:50:14 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Albert ARIBAUD
Le Wed, 21 Oct 2015 20:18:42 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Simon Kelley
Maybe there are leases for old UIDS and the static address still the
database?

No, I start dnsmasq without any lease.

Just to make sure, as your answer may mean various things: did you
explicitly delete the current leases file while dnsmasq was stopped and
only then start dnsmasq again?

With leasefile-ro nothing is read when the process starts.

Technically, with --loeasefile-ro, no lease file is read but the
lease-change script can still produce valid leases on its stdout, and
these will be taken into account.

Correct.

Post by Albert ARIBAUD
Now, I assume you don't use the lease-change script or you have made
sure it does not output any valid lease.

Yes. In message
I made sure to not miss any dhcp configuration, and there's no dhcp-script
Oct 20 10:01:27 dnsmasq[23897]: started, version 2.74test2 cachesize 500
Oct 20 10:01:27 dnsmasq[23897]: compile time options: IPv6 GNU-getopt no-DBus i18n IDN DHCP DHCPv6 no-scripts TFTP no-conntrack no-ipset auth DNSSEC loop-detect inotify
Additionally, the refusal doesn't happen everytime. Since the current process
started, on the date shown above, there have been no problems. However, the log
I sent before shows that it does happen. If undue refusals appear I have to
restart the process to get the client to boot.

I've seen only one log in this discussion, in your initial post, and I
believe it only showed a failure case. The ideal log to diagnose your
issue would be from startup through successful leases to failures.

Amicalement,

--
Albert.

Neil Jerram

2015-10-22 16:46:41 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Could it be because even static allocations still require a matching IP
range to be configured?

Regards,
Neil

Albert ARIBAUD

2015-10-22 17:07:59 UTC

Permalink

Hi Neil,

Le Thu, 22 Oct 2015 16:46:41 +0000, Neil Jerram

Post by Neil Jerram

Post by Carlos Carvalho
interface=meteo dhcp-range=::,constructor:meteo,static,infinite
enable-ra dhcp-range=192.168.5.1,static

Could it be because even static allocations still require a matching IP
range to be configured?

They don't. I've got a setup here with no dynamic range set up just
like the "dhcp-range=192.168.5.1,static" above, and static leases, and
it works like a charm.

Post by Neil Jerram
Regards,
Neil

Amicalement,

--
Albert.

Carlos Carvalho

2015-10-22 17:40:59 UTC

Permalink

Post by Albert ARIBAUD
Hi Neil,
Le Thu, 22 Oct 2015 16:46:41 +0000, Neil Jerram

Post by Neil Jerram
Could it be because even static allocations still require a matching IP
range to be configured?

They don't. I've got a setup here with no dynamic range set up just
like the "dhcp-range=192.168.5.1,static" above, and static leases, and
it works like a charm.

Yes, the manual says that it's enough to have the static address in the same
subnet of "a valid dhcp-range". In other words, you just have to turn on the
dhcp server on the interface.

But I did declare the ranges, they got burried when the message was

Post by Albert ARIBAUD

Post by Neil Jerram

Post by Carlos Carvalho
interface=meteo dhcp-range=::,constructor:meteo,static,infinite
enable-ra dhcp-range=192.168.5.1,static

See my original message with the full config,
Message-ID: <***@fisica.ufpr.br>

Albert ARIBAUD

2015-10-22 18:12:07 UTC

Permalink

Bonjour Carlos,

Le Thu, 22 Oct 2015 15:40:59 -0200, Carlos Carvalho

Post by Carlos Carvalho

Post by Albert ARIBAUD
Hi Neil,
Le Thu, 22 Oct 2015 16:46:41 +0000, Neil Jerram

Post by Neil Jerram
Could it be because even static allocations still require a matching IP
range to be configured?

They don't. I've got a setup here with no dynamic range set up just
like the "dhcp-range=192.168.5.1,static" above, and static leases, and
it works like a charm.

Yes, the manual says that it's enough to have the static address in the same
subnet of "a valid dhcp-range". In other words, you just have to turn on the
dhcp server on the interface.
But I did declare the ranges, they got burried when the message was

Post by Albert ARIBAUD

Post by Neil Jerram

Post by Carlos Carvalho
interface=meteo dhcp-range=::,constructor:meteo,static,infinite
enable-ra dhcp-range=192.168.5.1,static

See my original message with the full config,

I'd seen them -- hence my 'like the "dhcp-range=192.168.5.1,static"
above'.

What you have not described, however, is how your interfaces are
configured. Could you produce the result of ifconfig -a, or else
the content of /etc/network/interfaces file or equivalent?

Amicalement,

--
Albert.

Carlos Carvalho

2015-10-22 20:05:13 UTC

Permalink

Post by Albert ARIBAUD
What you have not described, however, is how your interfaces are
configured. Could you produce the result of ifconfig -a, or else
the content of /etc/network/interfaces file or equivalent?

It's done by a script, and certainly there's no problem here because leases
work most of the time:

meteo: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.5.17 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::224:8cff:fe0c:3790 prefixlen 64 scopeid 0x20<link>
inet6 2801:82:80ff:7f05::1 prefixlen 64 scopeid 0x0<global>

Post by Albert ARIBAUD
Le Thu, 22 Oct 2015 16:05:12 -0200, Carlos Carvalho

Post by Carlos Carvalho
started, on the date shown above, there have been no problems. However, the
log I sent before shows that it does happen. If undue refusals appear I
have to restart the process to get the client to boot.

Startup was on Monday and the first log has already been removed by rotation.
With the current run there have been no failures.

However your request gave me an idea. The declaration of the refused host is
currently

dhcp-host=cobb,192.168.5.11,[2801:82:80ff:7f05:12bf:48ff:fe71:6599],10:bf:48:71:65:99,id:00:01:00:01:1d:a8:3f:4a:10:bf:48:71:65:99

with a full id:. With this declaration in the config there have been no
unexplained failures. However before I used

dhcp-host=cobb,192.168.5.11,[2801:82:80ff:7f05:12bf:48ff:fe71:6599],10:bf:48:71:65:99,id:*

with id:*. I think I changed the declaration right before starting the current
process. Now, this particular host sometimes changes its DUID because it may
boot from a local disk instead of the network. It could have booted from disk
on Monday, and on Tuesday it booted from the net and was refused, then I
changed the declaration to the full id: above and restarted dnsmasq, and booted
the machine from the net. Now it always works booting from the net but never
when booting from disk.

I also had failures weeks ago when clients used a random DUID when booting from
the net: the first boot always worked but subsequent ones were refused and I
had to restart the dnsmasq process. When I fixed the DUID in the clients the
problem disappeared.

What if, with an id* declaration, dnsmasq accepts any DUID the first time but
refuses other requests with different DUIDs? This hypothesis explains the
events above and all others I've seen. However it contradicts what Simon
says, that the hardware address is enough to identify a client.

As I explained in another post in this thread, it's important that dnsmasq
makes no difference at all if the link address is the same.

Simon Kelley

2015-10-22 22:20:48 UTC

Permalink

Post by Carlos Carvalho
What if, with an id* declaration, dnsmasq accepts any DUID the
first time but refuses other requests with different DUIDs? This
hypothesis explains the events above and all others I've seen.
However it contradicts what Simon says, that the hardware address
is enough to identify a client.

I should clarify: the hardware address is enough to identify the
client, but if the dhcp-host includes a DUID _that_has_to_match_as_well.

The intention, since DUIDs are so difficult to use to identify
actually machines, is to be able to use just the MAC address, in the
same way as is commonly done with DHCPv4.

Cheers,

Simon.

Carlos Carvalho

2015-10-22 22:58:45 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I should clarify: the hardware address is enough to identify the
client, but if the dhcp-host includes a DUID _that_has_to_match_as_well.

Yes, but I'm talking explicitly about id:*. With it dnsmasq accepts any DUID
the first time but if the same client presents another DUID later dnsmasq
refuses the declared address. If there are dynamic ones available it'll give
one to the client, otherwise it bounces with "no available addresses". This
means that dnsmasq is taking history into account, not only the hardware
address. I think it should completely ignore the DUID if the dhcp-host has
id:*.

The manual says:

For DHCPv4, the special option id:* means "ignore any client-id
and use MAC addresses only." This is useful when a client
presents a client-id sometimes but not others.

How do I do the same for DHCPv6 as well? I need it for both protocols, for the
same reason.