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. On 20/07/18 15:43, Michael Marley wrote: > On 2018-07-20 09:01, Michael Marley wrote: > >> 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 >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasqfirstname.lastname@example.org >> <mailto:Dnsmasqemail@example.com> >> 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 > Dnsmasqfirstname.lastname@example.org > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > _______________________________________________ Dnsmasq-discuss mailing list Dnsmasqemail@example.com http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss