[Dnsmasq-discuss] [PATCH] Create temporary leases for DHCPOFFER actions

[Simon Kelley]

On 08/07/2022 21:26, Petr Menšík wrote:
> Hi!
> 
> I have already described similar problem back in year 2021 [1]. There 
> exists race condition when higher count of clients starts at similar 
> time and requests DHCP(v4). First two patches were already sent. I think 
> I have sent also following patches already, but were not able to find them.

I remember the first time around, and my reply then still applies.

https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015997.html


The first two patches make sense, though I don't think they solve the 
problem. Calling do_icmp_ping() with a zero hash only happens when the 
client suggests an address in the DHCPDISCOVER, which is probably not 
the case in the mass-netboot scenario.

Looking at the code, I wonder why the a possible address is rejected if 
it got pinged recently only in consecutive-ip mode? The technique would 
work just as well in the situation you're looking at: when there's a 
shortage of free IPs, so two hosts with different MAC addresses (and 
hashes) get offered the same IP just because there's only a few actually 
available.


Just removing the !option_bool(OPT_CONSEC_ADDR) condition in dhcp.c line 
850 may well be enough to keep behaviour sensible until there are very 
few addresses left.

I'm still unhappy about the half-lease approach, and I still think that 
this a band-aid for problem elsewhere. I can see two scenarios.

1) Allocating real public IP addresses to VMs. In this case everybody 
sane allocates the addresses beforhand in provisioning. That's necessary 
for setting up DNS or load-balancers anyway. It's pointless messing 
around with the DHCP server so it can allocate the last address on a 
subnet because it all falls over anyway when the next unprovisioned 
server comes along.


2) Allocating RC1918 addresses behind a NAT.
In this came just make the subnet bigger.


I appreciate that you're getting complaints, Petr, from people who are 
trying to do these crazy things, but overcomplicating dnsmasq and 
failing to solve the problem won't help anyone.

Cheers,

Simon.


> 
> Anyway, some DHCP clients tend to handle badly situation, where dnsmasq 
> first offers them some address. Then later in the process it realizes 
> such address were offered also to someone else and denies acking it. We 
> already have a workaround merged for IPv6 case, where it will ack 
> instead different address. I think it would be nice also for IPv6 the 
> same way, but I think it is not as urgent as for IPv4.
> 
> I have created a kind of half-lease. When it offers someone address, it 
> makes it reserved for that address. That should prevent unnecessary race 
> during startup, where some clients tend to receive NACK. When client 
> continues with DHCPREQUEST, it converts a temporary lease to a permanent 
> lease, which is then stored into lease file.

I'd like to avoid
> 
> It solves a race in case more clients requests address than addresses on 
> such network are available. When there are the same amount of temporary 
> leases and remaining addresses, it reuses random temporary lease. Of 
> course in such situation a failures are unavoidable. But I think it 
> should attempt do the best available.
> 
> I am attaching also setup.sh, which I used to emulate starting multiple 
> clients at similar time. I configured dnsmasq listening on virbr1 device 
> and offering addresses. Then run that script as root and record 
> communication in wireshark. Unlike current situation, there should not 
> be any NACKs present. Even though ISC dhclient handles NACK well and is 
> able to retry, unlike some netbooting firmware, which fails the boot in 
> such situation.
> 
> Comments or testing would be welcome.
> 
> This is tracked on redhat bug #2028704 [2]. I have pushed those commits 
> also to dhcp-temp-leases branch in github [3].
> 
> 1. 
> https://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2021q4/015982.html 
> 
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=2028704
> 3. https://github.com/InfrastructureServices/dnsmasq/tree/dhcp-temp-leases
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss