In networking/udhcp/dhcpc.c: I can see that the RX ACK and NAK processing does not qualify on the RFC required DHCP option "server-id". When accept the offer or when renew, the server-id has been saved from the offer we accpted, we should reject therefore any ACK or NAK that does not have this required matching server-id. I can see that when i have another dhcp server on the network (how be it a dumb server), it NAKs my T1 renew, and then i get kicked back into discovery, and renew the lease. For a small moment, i have no IP binded, not good.
Also note i do not see any fixes for this in the newer builds, i discovered this using busybox 1.11.2, but i have looks at all bug patches up to 1.19.2. Very simple to fix, couple lines of code, i can patch it if anyone likes. Thanks
Created attachment 3998 [details] ignore DHCP NAK from wrong servers This bug is present in 1.1.3, too. I am sorry the version I am reporting is so old, but this is the currently running version on (older) FreeWRT (www.freewrt.org) embedded routers. However, I am submitting my patch for 1.1.3, hoping it will somehow apply against current versions, too. Thoughts on the situation/the attached patch: DHCP NAKs are ignorable if they do not have any Server ID. The right server (with the right server id option) could answer with ACK any time later. If no ACK is received in the following because the NAK was meant as a definite NAK, the timeouts will catch the situation. DHCP NAKs with the right server id are defnite. These reset the internal state to INIT_SELECTING IMHO this behaviour is compatible with RFC2131. On pg. 29 it says that "Server identifier" is a MUST field for NAK packets. Thus, expecting a server identifier should be ok. -Martin
Fixed in git: commit e2318bbad786d6f9ebff704490246bfe52e588c0 Author: Denys Vlasenko <vda.linux@googlemail.com> Date: Thu Feb 27 18:15:50 2014 +0100 udhcpc: ignore NAKs from "wrong" servers