The best solution to this is to stop blocking ICMP.

The simplest solution is not to use dhcp-sequential-ip. The normal
address-allocation process in DHCP perturbs the hash function when a
DECLINE reply is received, so the next allocation will be to a different

Using ARP probing from the server is not a good fix, because is fails
when DHCP relay is in use and the server is on a different network to
the client. That's why ICMP is used by the server - it needs to be a
routable protocol.

If you can't use either of the the solutions above, then you'll need to
implement some sort of time-limited blacklisting of the declined
addresses, rather in the same which is done to disable static address
allocations which get declined.



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,,,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)
> 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)
> 784f4331e43a
> 2018-08-07T03:01:38.815690+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPREQUEST(lan) 784f4331e43a
> 2018-08-07T03:01:38.815896+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan)
> 784f4331e43a macbookpro2
> 2018-08-07T03:01:40.659116+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDECLINE(lan) 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)
> 784f4331e43a
> 2018-08-07T03:01:53.557920+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPREQUEST(lan) 784f4331e43a
> 2018-08-07T03:01:53.558117+00:00 INFO dnsmasq-dhcp[1177]: DHCPACK(lan)
> 784f4331e43a macbookpro2
> 2018-08-07T03:01:56.147878+00:00 INFO dnsmasq-dhcp[1177]:
> DHCPDECLINE(lan) 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
> 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

Reply via email to