On Thu, May 23, 2019 at 9:30 AM Krzysztof Charusta <[email protected]> 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. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
