We recently encountered a scenario where 2 different client machines sent discover packets at the exact same time and ended up getting offer responses for the same IP address. I confirmed that the algorithm in dhcp.c::address_allocate() would use the same start value for both of these MAC addresses so it would appear as though we got unlucky and had a collision on the MAC address for these two specific clients.
This is the config entry:
dhcp-range=set:xyz,192.168.29.2,192.168.29.254,255.255.255.0,1d
These are the logs (first 4 bytes of MAC addresses obfuscated to 02:11:22:33 from their actual values):
daemon.log:2016-02-16T13:55:57.000 localhost dnsmasq-dhcp[12225]: info DHCPDISCOVER(eth0) 02:11:22:33:1c:83
daemon.log:2016-02-16T13:55:57.000 localhost dnsmasq-dhcp[12225]: info DHCPOFFER(eth0) 192.168.29.40 02:11:22:33:1c:83
daemon.log:2016-02-16T13:55:57.000 localhost dnsmasq-dhcp[12225]: info DHCPDISCOVER(eth0) 02:11:22:33:1b:cc
daemon.log:2016-02-16T13:55:57.000 localhost dnsmasq-dhcp[12225]: info DHCPOFFER(eth0) 192.168.29.40 02:11:22:33:1b:cc
daemon.log:2016-02-16T13:55:57.000 localhost dnsmasq-dhcp[12225]: info DHCPDISCOVER(eth0) 02:11:22:33:1c:83
daemon.log:2016-02-16T13:55:57.000 localhost dnsmasq-dhcp[12225]: info DHCPOFFER(eth0) 192.168.29.40 02:11:22:33:1c:83
daemon.log:2016-02-16T13:55:58.000 localhost dnsmasq-dhcp[12225]: info DHCPREQUEST(eth0) 192.168.29.40 02:11:22:33:1b:cc
daemon.log:2016-02-16T13:55:58.000 localhost dnsmasq-dhcp[12225]: info DHCPACK(eth0) 192.168.29.40 02:11:22:33:1b:cc
daemon.log:2016-02-16T13:55:59.000 localhost dnsmasq-dhcp[12225]: info DHCPREQUEST(eth0) 192.168.29.40 02:11:22:33:1c:83
daemon.log:2016-02-16T13:55:59.000 localhost dnsmasq-dhcp[12225]: info DHCPNAK(eth0) 192.168.29.40 02:11:22:33:1c:83 address in use
daemon.log:2016-02-16T13:56:03.000 localhost dnsmasq-dhcp[12225]: info DHCPREQUEST(eth0) 192.168.29.40 02:11:22:33:1c:83
daemon.log:2016-02-16T13:56:03.000 localhost dnsmasq-dhcp[12225]: info DHCPNAK(eth0) 192.168.29.40 02:11:22:33:1c:83 address in use
daemon.log:2016-02-16T13:56:07.000 localhost dnsmasq-dhcp[12225]: info DHCPDISCOVER(eth0) 02:11:22:33:1c:83
daemon.log:2016-02-16T13:56:07.000 localhost dnsmasq-dhcp[12225]: info DHCPOFFER(eth0) 192.168.29.41 02:11:22:33:1c:83
daemon.log:2016-02-16T13:56:11.000 localhost dnsmasq-dhcp[12225]: info DHCPREQUEST(eth0) 192.168.29.41 02:11:22:33:1c:83
daemon.log:2016-02-16T13:56:11.000 localhost dnsmasq-dhcp[12225]: info DHCPACK(eth0) 192.168.29.41 02:11:22:33:1c:83
>From a DHCP point of view things seem to have resolved themselves automatically at both the client and server. There were ensuing tftp issues on the client which got the NAK and subsequently got a second IP address but I don't believe this to be related to dnsmasq.
My question is about why the duplicate IP address was even offered to the second client. Looking at the dhcp.c::address_allocate() code it seems that this scenario is avoided only if OPT_CONSEC_ADDR is set (which we do not set). Unless I am missing something it seems that any time the address matches and (r->hash != j) the loop should be terminated and a new address should be allocated. Can you comment on whether this is intentional because of RFC requirements or whether this should be changed?
if (r->addr.s_addr == addr.s_addr)
{
/* consec-ip mode: we offered this address for another client
(different hash) recently, don't offer it to this one. */
if (option_bool(OPT_CONSEC_ADDR) && r->hash != j)
break;
return 1;
}
Regards,
Allain
Allain Legacy, Software Developer
direct 613.270.2279 fax 613.492.7870 skype allain.legacy
[WIND]<http://www.windriver.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160220/ddf9999f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 1807 bytes
Desc: image001.png
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160220/ddf9999f/attachment.png>