blob: 64a3afb43e982869a0ad4a47e34281a07f0a6f23 [file] [log] [blame]
From 27b2528b84b221a6b8ba4f67fa0a0360e22e7990 Mon Sep 17 00:00:00 2001
From: mukesh agrawal <quiche@chromium.org>
Date: Tue, 26 May 2015 15:37:33 -0700
Subject: [PATCH] Be more permissive on NAKs
Previously, we'd reject NAKs that did not include a server ID.
Since we'd only check that a server ID was present, but did not
validate it against any stored state, the test is merely pedantic.
Moreover, some DHCP servers (e.g. OpenBSD 4.6) send NAK messages
without a server ID. [1]
To improve compatibility with real-world DHCP servers, drop the
check for the presence of a server ID.
BUG=chrome-os-partner:27930
TEST=network_DhcpNak
[1] http://openbsd.7691.n7.nabble.com/dhcpd-omits-server-id-option-54-in-NAK-to-a-RENEW-request-td41044.html
Reviewed-on: https://chromium-review.googlesource.com/194972
---
dhcp.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/dhcp.c b/dhcp.c
index ec09a28..7196f13 100644
--- a/dhcp.c
+++ b/dhcp.c
@@ -2748,14 +2748,6 @@ dhcp_handledhcp(struct interface *ifp, struct dhcp_message **dhcpp,
}
if (type == DHCP_NAK) {
- /* For NAK, only check if we require the ServerID */
- if (has_option_mask(ifo->requiremask, DHO_SERVERID) &&
- get_option_addr(ifp->ctx, &addr, dhcp, DHO_SERVERID) == -1)
- {
- log_dhcp(LOG_WARNING, "reject NAK", ifp, dhcp, from);
- return;
- }
-
/* We should restart on a NAK */
log_dhcp(LOG_WARNING, "NAK:", ifp, dhcp, from);
if ((msg = get_option_string(ifp->ctx, dhcp, DHO_MESSAGE))) {
--
2.2.0.rc0.207.ga3a616c