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,,,1h
> dhcp-range=interface:vlan2,,,1h
> dhcp-range=interface:vlan3,,,1h
> dhcp-range=interface:vlan4,,,1h
> dhcp-range=interface:vlan5,,,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
> Dnsmasq-discuss@lists.thekelleys.org.uk
> 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. 

Dnsmasq-discuss mailing list

Reply via email to