The DHCP-client in RENEWING state does not reply to broadcast messages

[Denys Vlasenko]

On Thu, May 23, 2019 at 9:30 AM Krzysztof Charusta <charustak at gmail.com> wrote:
> I upgraded busybox from version 1.29.2 to 1.30.1 and noticed that the client behaves differently after commit "udhcpc: ensure at least one
> unicast renew attempt" (c05aa6a776ab2420a42c041a3b5d45db587fd9ef).
>
> I'm testing a setup:
> - dhcp server (dnsmasq-2.78) lease time 122 sec.
> - dhcp client (busybox 1.30.1)
> with a dhcp relay in between (also busybox but this should not matter).
>
> Actual result:
> In the test scenario the server restarts/reconfigures and when the client sends a renew DHCPREQUEST the server replies a broadcast DHCPNAK ("address not available"). However, when in RENEWING state (T1 reached) the client does not reply to broadcast messages due to change_listen_mode(LISTEN_KERNEL). The client then waits until the REBINDING state (T2) and only then listen to broadcast.
>
> Expected result:
> According to [https://www.ietf.org/rfc/rfc2131.txt, Page 22, Sec 4.1]: "In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff."
> Would it be reasonable to think that the client should listen to broadcast in RENEWING state as well?

Well, no. My understanding is the whole point why RENEWING
state exists instead of all clients just go back to bcast
REBINDING, is to avoid using bcast / perusing all packets,
instead of only those packets sent to our IP:PORT.

Compare udhcp_recv_raw_packet() and udhcp_recv_kernel_packet().
Raw receive sees way more packets.