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? In the test scenario the lease time is short (122 sec) so the time between T1 and T2 is just 30sec but if time between the RENEW and REBIND state is large then, I guess, this could be a problem. Changing listening mode in RENEWING state fixes the problem (see below) but I am not sure if this is the right way to go. Let me know what you think. Index: busybox-1.30.1/networking/udhcp/dhcpc.c =================================================================== --- busybox-1.30.1.orig/networking/udhcp/dhcpc.c +++ busybox-1.30.1/networking/udhcp/dhcpc.c @@ -1517,7 +1517,7 @@ int udhcpc_main(int argc UNUSED_PARAM, c /* 1/2 lease passed, enter renewing state */ state = RENEWING; client_config.first_secs = 0; /* make secs field count from 0 */ - change_listen_mode(LISTEN_KERNEL); + change_listen_mode(LISTEN_RAW); log1("entering renew state"); /* fall right through */ case RENEW_REQUESTED: /* manual (SIGUSR1) renew */
(In reply to Krzysztof Charusta from comment #0) > 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.