I am afraid there are some implementation problems found in IPv4 DHCP allocations. If multiple machines start at the same time (I have script to launch 16), especially with dhcp-sequential-ip it is problematic. ISC dhclient can cope with it somehow well, but some PXE booting firmware is less patient.
I think icmp_ping code needs to be reworked. It needs to be asynchronous and it has to support multiple pings pending at one time. I have attached two dumps. no-ping one shows how well it works with no-ping. It takes under 8 seconds. test2 file shows how it ping just single discover, waits ages (3 seconds), sends offer and tries another. This algorithm may work on small networks, but anything with more than 10 clients should not be started at the same time. Because it may fail to start. I think hash should be removed from ping cache. Instead, weaker form of lease should be done for offers also, with just short 3 second lifetime. It would ensure we do not offer the same address to different clients while we still have more addresses available. Needed with dhcp-sequential-ip mode. I think some kind of timeout action is needed for pings. It is not a problem sending 15 pings in two seconds, when every has different target mac. But it should wait for timeout in parallel. It does wait sequentially now. While it does, it does not respond to DHCP. Any idea, how that could be improved without a major rewrite? I have tested 2.79 version. which needs fixed from 2.81. But it seems nothing important changed since then in current code. Cheers, Petr On 12/8/21 01:18, Petr Menšík wrote: > > Hi Simon and others, > > 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. > > 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. > > Few details are at RH bug #2028704 [1]. Original tested version 2.79 > did not contain commit 0669ee7a69a > <http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0669ee7a69a004ce34fed41e50aa575f8e04427b> > [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. > > Cheers, > Petr > > 1. https://bugzilla.redhat.com/show_bug.cgi?id=2028704 > 2. > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0669ee7a69a004ce34fed41e50aa575f8e04427b > > -- > Petr Menšík > Software Engineer > Red Hat, http://www.redhat.com/ > email: pemen...@redhat.com > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
dnsmasq-16-no-ping.pcapng
Description: application/pcapng
dnsmasq-16-test2.pcapng
Description: application/pcapng
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
