<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hello Simon and others.</p>
<p>In certain situations, dnsmasq DHCP will offer multiple different
clients single IP address. Later it ACKs the first client and NACK
the second. It relies on ability of those clients to retry, but it
seems netbooting software often cannot recover from such
behaviour.</p>
<p>Attaching script I use to reproduce this issue. Just create some
local bridge, have a limited IP pool on its dhcp-range option.
Just few addresses above actual number instances. They start
roughtly at the same time.</p>
<p>There is also pcap file in linked bug with some other reports.
Good summary is in commetn 85 [3].</p>
<p>In attached patches, I introduced thing I call temporary leases.
Those leases are never saved into leased file. They have short
time duration, set to 30 s same as ping timeout. It ensures even
with dhcp-sequential-ip, different clients have reservations for
different addresses. It helps especially in case --no-ping is
used. Without this change it takes quite long to retry multiple
times discover-offer-request solutions. Because pings contain sort
of workaround for this deficiency, but will cover only 6 different
addresses in default configuration. Then it switches to overload,
similar to no-ping. Then it offers multiple clients the same
address, but when the 2nd client requests the lease, it denies it
again.</p>
<p>I think I were able to find relative simple algorithm. I think
IPv6 should receive similar approach. We side-stepped this by
offering different address in ACK in thread [4]. While it seems
that works, I think it would be better to not offer address it
later rejects itself. We test DHCP clients abilities for no good
reason.</p>
<p>With this patches, even multiple clients without ping boot fast
enough, even when they start at similar time. Starting at similar
time if common thing on boot of cloud hosting instances, which may
use dnsmasq for local caching. OpenStack is example that recorded
it, but it can happen even in normal machines. For example in a
classroom with 10 computers.</p>
<p>Would you look at it or test it, whether some issues with those
changes can be found?</p>
<p>Cheers,<br>
Petr<br>
</p>
<p>3. <a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=2028704#c85">https://bugzilla.redhat.com/show_bug.cgi?id=2028704#c85</a><br>
4.
<a class="moz-txt-link-freetext" href="https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015585.html">https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q3/015585.html</a><br>
</p>
<div class="moz-cite-prefix">On 12/8/21 01:18, Petr Menšík wrote:<br>
</div>
<blockquote type="cite"
cite="mid:bca4d11e-5fe7-82fc-505c-902b5c0cc275@redhat.com">
<p>Hi Simon and others,</p>
<p>I am debugging strange issue, which happens inside OpenStack in
certain situations. It seems under not precisely defined
conditions dnsmasq returns "no address available" error even in
situation, when not yet all leases are used.</p>
<p>It seems do_icmp_ping is responsible for ruling out recently
tried IP addresses. It seems a bit weird address allocation
happens only for addresses recently not pinged. I have found
another place which does do_icmp_ping, but does not use hash
value computed from hardware address. Even when it is already
known at that time. First patch attached adds hash also to
second place. That should mean single address would use shared
ping. The second patch simplifies a bit do_icmp_patch and its
return value. Instead of artificially ensuring hash would match,
just return correct value when hash matches. The second change
is just optional optimization.<br>
</p>
<p>Few details are at RH bug #2028704 [1]. Original tested version
2.79 did not contain commit <a
href="http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0669ee7a69a004ce34fed41e50aa575f8e04427b"
moz-do-not-send="true">0669ee7a69a</a> [2], which improves the
situation. But I think there remain cases when ping is not
accepted when it should be. Testing with latest release did not
work according to report. I think the first patch may fix still
missing part.</p>
<p>Cheers,<br>
Petr<br>
</p>
<p>1. <a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=2028704"
moz-do-not-send="true">https://bugzilla.redhat.com/show_bug.cgi?id=2028704</a><br>
2. <a
href="http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0669ee7a69a004ce34fed41e50aa575f8e04427b"
class="moz-txt-link-freetext" moz-do-not-send="true">http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0669ee7a69a004ce34fed41e50aa575f8e04427b</a></p>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/" moz-do-not-send="true">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:pemensik@redhat.com" moz-do-not-send="true">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer
Red Hat, <a class="moz-txt-link-freetext" href="http://www.redhat.com/">http://www.redhat.com/</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:pemensik@redhat.com">pemensik@redhat.com</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>