Bug 4267

Summary:	DHCP Client: accepts ACK or NAK from other servers
Product:	Busybox	Reporter:	Bill <bspitz>
Component:	Networking	Assignee:	unassigned
Status:	RESOLVED FIXED
Severity:	major	CC:	busybox-cvs
Priority:	P5
Version:	1.15.x
Target Milestone:	---
Hardware:	PC
OS:	Windows
Host:		Target:
Build:
Attachments:	ignore DHCP NAK from wrong servers

Description Bill 2011-09-29 05:42:28 UTC

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.

Comment 1 Bill 2011-09-29 05:45:04 UTC

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

Comment 2 busybox-bugs.20.masuefke 2012-01-25 22:56:16 UTC

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

Comment 3 Denys Vlasenko 2014-02-27 17:17:00 UTC

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