In my pretty extensive tests, a long initial lease time is almost always the DHCP server's fault. I didn't see really any time wasted in DHCP REQUEST in my test

In my pretty extensive tests, a long initial lease time is almost always the DHCP server's fault. I didn't see really any time wasted in DHCP REQUEST in my tests across many devices and operating systems. I think setting your DHCP server to authoritative will usually cause it to do a DHCP NACK in response to a bogus DHCP REQUEST, which prevents any delay there as observed in the article. I measured lease time when connecting a client as "time from DHCP DISCOVER to DHCP ACK", which I found effectively represents the time between a device connecting to WiFi and being available on the network with an IP address. With stock dnsmasq, the shortest "new connection" lease time I observed on an uncongested network was around five seconds. Almost all of the time was spent waiting for the DHCP server to respond. With a modified dnsmasq, the shortest time to lease I observed was 20ms. That was also the longest time to lease on every platform I tested except iOS, which spends about a second trying to ICMP ping the IP address before it takes it. On iOS devices, the time to lease was almost always exactly 1s20ms the first time, and about 20ms on subsequent attempts with the same device. You can do the same tests yourself by sitting on a wireless network with Wireshark and connecting with a device that has had the network forcibly "forgotten". Mark the first DHCP DISCOVER packet you see, and set the timestamps to relative. Filter the traffic to just show the MAC address of the router and connecting device, then look for the DHCP ACK from the router.