I just pushed a fix which should solve this:
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e7bfd556c079c8b5e7425aed44abc35925b24043 Cheers, Simon. On 21/12/2018 14:48, Jangala Anvesh wrote: > Hi, > > Problem Statement : > DNSMASQ is offering the declined address repeatedly to the station in > Sequential IP mode. > > DNSMASQ details and configuration : > DNSMASQ version 2.78. > > Mode - dhcp-sequential-ip > dhcp-range=lan,192.168.86.20,192.168.86.250,24h > > Im seeing the following messages: > > 2018-08-07T03:01:37.750559+00:00 INFO dnsmasq-dhcp[1177]: > DHCPDISCOVER(lan) 784f4331e43a > 2018-08-07T03:01:37.750725+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan) > 192.168.86.21 784f4331e43a > 2018-08-07T03:01:37.751702+00:00 INFO dnsmasq-dhcp[1177]: > DHCPDISCOVER(lan) 784f4331e43a > 2018-08-07T03:01:37.751872+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan) > 192.168.86.21 784f4331e43a > 2018-08-07T03:01:38.815690+00:00 INFO dnsmasq-dhcp[1177]: > DHCPREQUEST(lan) 192.168.86.21 784f4331e43a > 2018-08-07T03:01:38.815896+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan) > 192.168.86.21 784f4331e43a macbookpro2 > 2018-08-07T03:01:40.659116+00:00 INFO dnsmasq-dhcp[1177]: > DHCPDECLINE(lan) 192.168.86.21 784f4331e43a > 2018-08-07T03:01:52.487506+00:00 INFO dnsmasq-dhcp[1177]: > DHCPDISCOVER(lan) 784f4331e43a > 2018-08-07T03:01:52.487672+00:00 INFO dnsmasq-dhcp[1177]: DHCPOFFER(lan) > 192.168.86.21 784f4331e43a > 2018-08-07T03:01:53.557920+00:00 INFO dnsmasq-dhcp[1177]: > DHCPREQUEST(lan) 192.168.86.21 784f4331e43a > 2018-08-07T03:01:53.558117+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan) > 192.168.86.21 784f4331e43a macbookpro2 > 2018-08-07T03:01:56.147878+00:00 INFO dnsmasq-dhcp[1177]: > DHCPDECLINE(lan) 192.168.86.21 784f4331e43a > > > We are expecting a behaviour like: > > Whenever the dnsmasq receives a DHCPDELCINE message from the station and > the station tries to connect again DNSMASQ should offer the next free > address from the pool, but from the above sequene it is offering the > same address. > > Current Behaviour : > > As per the current implementation of DNSMASQ, found out that, whenever > DNSMASQ receives a DHCP-DECLINE message it will increment a counter. > When offering an IP address to a client, DNSMASQ fetches the largest > assigned address and from that address onwards it will try to allocate > the next free address. In the process of allocating an address to a > client, DNSMASQ will perform a PING check on the offering address and > based on the PING result it will offer the address to the client (if > PING fails) or it will check for the next address in the pool (when PING > is successful). > > If there are stations configured statically in the LAN network which > blocks ICMP ECHO REQUEST and if DNSMASQ offers the same IP address(as > PING fails) to the requesting station it will be declined. However > DNSMASQ is not offering different IP to the station which has declined > the IP when it tries to connect again. > Also, if the PING reply didn't reach the DNSMASQ within the timeout, > DNSMASQ is still trying to offer the same IP address(means declined > address) to the clients. > > Proposed alternatives: > > In order to overcome this issue, we are planning to have an ARPing > implementation along with the existing PING check in dnsmasq. > We came across a link > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2006q3/000846.html > which > discusses about the ARPing implementation. > With the above approach, DNSMASQ will perform a ARP resolution before > offering an address. If the ARP resolution is not successful, DNSMASQ > will proceed to allocate the address,else DNSMASQ will try to offer the > next free address in the pool. > > > Please look into this issue and ARPing approach as a resoution for the > same. If there are any other alternatives to resolve this issue please > suggest. > > Regards, > Anvesh. > > Disclaimer:This message is intended only for the designated > recipient(s). It may contain confidential or proprietary information and > may be subject to other confidentiality protections. If you are not a > designated recipient, you may not review, copy or distribute this > message. Please notify the sender by e-mail and delete this message. > GlobalEdge does not accept any liability for virus infected mails. _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss