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



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

Dnsmasq-discuss mailing list

Reply via email to