[Dnsmasq-discuss] dnsmasq not responding to DHCPv6 DHCPCONFIRM messages attempting to confirm an unknown lease

[Michael Marley]

Hi,

I have dnsmasq set to be a DHCPv6 and DHCPv6 server for my local
network. Here is the relevant part of the configuration:

interface=vlan1
interface=vlan2
interface=vlan3
interface=vlan4
interface=vlan5
dhcp-authoritative
dhcp-range=interface:vlan1,10.1.0.2,10.1.255.253,1h
dhcp-range=interface:vlan2,10.2.0.2,10.2.255.253,1h
dhcp-range=interface:vlan3,10.3.0.2,10.3.255.253,1h
dhcp-range=interface:vlan4,10.4.0.2,10.4.255.253,1h
dhcp-range=interface:vlan5,10.5.0.2,10.5.255.253,1h
dhcp-range=interface:vlan1,fdda:5f29:421b:1::2,fdda:5f29:421b:1::ffff,64,1h
dhcp-range=interface:vlan2,fdda:5f29:421b:2::2,fdda:5f29:421b:2::ffff,64,1h
dhcp-range=interface:vlan3,fdda:5f29:421b:3::2,fdda:5f29:421b:3::ffff,64,1h
dhcp-range=interface:vlan4,fdda:5f29:421b:4::2,fdda:5f29:421b:4::ffff,64,1h
dhcp-range=interface:vlan5,fdda:5f29:421b:5::2,fdda:5f29:421b:5::ffff,64,1h

My problem is that if a DHCPv6 client attempts to confirm an unknown
lease (from another network, for example if I unplug a computer from
vlan4 and plug it into vlan3), dnsmasq doesn't respond to the
DHCPCONFIRM messages that the client sends. I just get a long string of

DHCPCONFIRM(vlan4) 00:01:00:01:20:65:91:d7:3c:97:0e:7f:f5:ba

until the client finally gives up and acquires a new lease from scratch.
This also happens if I connect a client to my network that was
previously connected to another network with a DHCPv6 lease. For DHCPv4
in the same situation, it works correctly and sends a DHCPNAK, causing
the client to retry from scratch immediately and get a new lease quickly
as described in the documentation for the "dhcp-authoritative" option.
It seems to me this ought to take place for DHCPv6 as well, preventing
the client from having to time out before obtaining a lease. Have I
configured something wrong or is there a bug?

Thanks,

Michael Marley

[Michael Marley]

Post by Michael Marley
Hi,
interface=vlan1
interface=vlan2
interface=vlan3
interface=vlan4
interface=vlan5
dhcp-authoritative
dhcp-range=interface:vlan1,10.1.0.2,10.1.255.253,1h
dhcp-range=interface:vlan2,10.2.0.2,10.2.255.253,1h
dhcp-range=interface:vlan3,10.3.0.2,10.3.255.253,1h
dhcp-range=interface:vlan4,10.4.0.2,10.4.255.253,1h
dhcp-range=interface:vlan5,10.5.0.2,10.5.255.253,1h
dhcp-range=interface:vlan1,fdda:5f29:421b:1::2,fdda:5f29:421b:1::ffff,64,1h
dhcp-range=interface:vlan2,fdda:5f29:421b:2::2,fdda:5f29:421b:2::ffff,64,1h
dhcp-range=interface:vlan3,fdda:5f29:421b:3::2,fdda:5f29:421b:3::ffff,64,1h
dhcp-range=interface:vlan4,fdda:5f29:421b:4::2,fdda:5f29:421b:4::ffff,64,1h
dhcp-range=interface:vlan5,fdda:5f29:421b:5::2,fdda:5f29:421b:5::ffff,64,1h
My problem is that if a DHCPv6 client attempts to confirm an unknown lease (from another network, for example if I unplug a computer from vlan4 and plug it into vlan3), dnsmasq doesn't respond to the DHCPCONFIRM messages that the client sends. I just get a long string of
DHCPCONFIRM(vlan4) 00:01:00:01:20:65:91:d7:3c:97:0e:7f:f5:ba
until the client finally gives up and acquires a new lease from scratch. This also happens if I connect a client to my network that was previously connected to another network with a DHCPv6 lease. For DHCPv4 in the same situation, it works correctly and sends a DHCPNAK, causing the client to retry from scratch immediately and get a new lease quickly as described in the documentation for the "dhcp-authoritative" option. It seems to me this ought to take place for DHCPv6 as well, preventing the client from having to time out before obtaining a lease. Have I configured something wrong or is there a bug?
Thanks,
Michael Marley
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

I apologize for my ineptness, but it seems dnsmasq does actually send a
NOTONLINK reply in this case (rfc3315.c:1105). It just doesn't log that
it is doing so, which is what led me to believe that it wasn't. My
actual problem appears to be caused by defective/bugged DHCPv6 snooping
on a switch, which I will report to the manufacturer. I do think that
logging the NOTONLINK reply would probably be a good idea though, to
avoid confusion.

Michael

[Simon Kelley]

One line patch to log DHCPCONFIM failure applied. That seems sensible.
Thanks for the suggestion, and apologies for leading you up a blind alley.


Cheers,

Simon.

Post by Michael Marley

Post by Michael Marley
Hi,
I have dnsmasq set to be a DHCPv6 and DHCPv6 server for my local
interface=vlan1
interface=vlan2
interface=vlan3
interface=vlan4
interface=vlan5
dhcp-authoritative
dhcp-range=interface:vlan1,10.1.0.2,10.1.255.253,1h
dhcp-range=interface:vlan2,10.2.0.2,10.2.255.253,1h
dhcp-range=interface:vlan3,10.3.0.2,10.3.255.253,1h
dhcp-range=interface:vlan4,10.4.0.2,10.4.255.253,1h
dhcp-range=interface:vlan5,10.5.0.2,10.5.255.253,1h
dhcp-range=interface:vlan1,fdda:5f29:421b:1::2,fdda:5f29:421b:1::ffff,64,1h
dhcp-range=interface:vlan2,fdda:5f29:421b:2::2,fdda:5f29:421b:2::ffff,64,1h
dhcp-range=interface:vlan3,fdda:5f29:421b:3::2,fdda:5f29:421b:3::ffff,64,1h
dhcp-range=interface:vlan4,fdda:5f29:421b:4::2,fdda:5f29:421b:4::ffff,64,1h
dhcp-range=interface:vlan5,fdda:5f29:421b:5::2,fdda:5f29:421b:5::ffff,64,1h
My problem is that if a DHCPv6 client attempts to confirm an unknown
lease (from another network, for example if I unplug a computer from
vlan4 and plug it into vlan3), dnsmasq doesn't respond to the
DHCPCONFIRM messages that the client sends.  I just get a long string of
DHCPCONFIRM(vlan4) 00:01:00:01:20:65:91:d7:3c:97:0e:7f:f5:ba
until the client finally gives up and acquires a new lease from
scratch.  This also happens if I connect a client to my network that
was previously connected to another network with a DHCPv6 lease.  For
DHCPv4 in the same situation, it works correctly and sends a DHCPNAK,
causing the client to retry from scratch immediately and get a new
lease quickly as described in the documentation for the
"dhcp-authoritative" option.  It seems to me this ought to take place
for DHCPv6 as well, preventing the client from having to time out
before obtaining a lease.  Have I configured something wrong or is
there a bug?
Thanks,
Michael Marley
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

I apologize for my ineptness, but it seems dnsmasq does actually send a
NOTONLINK reply in this case (rfc3315.c:1105).  It just doesn't log that
it is doing so, which is what led me to believe that it wasn't.  My
actual problem appears to be caused by defective/bugged DHCPv6 snooping
on a switch, which I will report to the manufacturer.  I do think that
logging the NOTONLINK reply would probably be a good idea though, to
avoid confusion.
Michael
_______________________________________________
Dnsmasq-discuss mailing list
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss