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

[Denys Vlasenko]

On Fri, May 24, 2019 at 2:09 PM Krzysztof Charusta <charustak at gmail.com> wrote:
> Hi,
>
> I am not saying that changing to LISTEN_RAW is acceptable/optimal solution.
>
> I think the question that needs answer is:
> Should a client listen to broadcast messages while in the RENEWING state?
> I didn't find in RFC2131 any suggestion that the client should *only* listen to unicast while in the RENEWING state, it only says that a renew DHCPREQUEST should be a unicast in that state (Sec 4.4.5). The standard also states the server can broadcast a DHCPNAK to inform about error or so. It feels natural to me that the client listens to this.

Broadcast NAK is sent to 255.255.255.255, not client's address.
IIUC, receiving that packet requires having a raw socket
to listen to *all* packets.

Since RENEWING state, unlike REBINDING, can last for hours,
this would make udhcpc listen to all packets for all this time.

> As I understand it is the only way for the server to inform the client
> about an error/change of config (e.g. IP-pool change).
> Now, if the client does not listen to what server says until REBINDING
> (which in case of busybox is only the last 60sec of the lease time)
> then potentially a lot of time is wasted.

Well, DHCP makes no promises that there is a way to switch to
new IPs sooner than all leases have expired.