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

Carlos Carvalho carlos at fisica.ufpr.br
Thu Oct 22 21:05:13 BST 2015


Albert ARIBAUD (albert.aribaud at free.fr) wrote on Thu, Oct 22, 2015 at 04:12:07PM BRST:
> 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>

Albert ARIBAUD (albert.aribaud at free.fr) wrote on Thu, Oct 22, 2015 at 04:48:50PM BRST:
> Le Thu, 22 Oct 2015 16:05:12 -0200, Carlos Carvalho
> <carlos at fisica.ufpr.br> a écrit :

> > 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.

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.



More information about the Dnsmasq-discuss mailing list