summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorsbyx <steven@midlink.org>2014-08-12 15:05:17 +0200
committersbyx <steven@midlink.org>2014-08-12 15:05:17 +0200
commitaa5659eb06a386ddf2bc80ad078891820f12c410 (patch)
treec67f5f5b903fce5be51199567a23f71e95f36aa2
parentde90ff1b27ef8e41c819d40d80f0fd6d8be86ded (diff)
parent428908569b8da45613891e21736c587894e0c449 (diff)
Merge pull request #21 from mehlis/fix-nak-by-doing-valid-reply
dhcpv4: offer a valid configuration with DHCP NAK
-rw-r--r--src/dhcpv4.c11
1 files changed, 10 insertions, 1 deletions
diff --git a/src/dhcpv4.c b/src/dhcpv4.c
index 7b200cd..d978da8 100644
--- a/src/dhcpv4.c
+++ b/src/dhcpv4.c
@@ -334,7 +334,16 @@ static void handle_dhcpv4(void *addr, void *data, size_t len,
} else if (reqmsg == DHCPV4_MSG_REQUEST && reqaddr.s_addr &&
reqaddr.s_addr != htonl(lease->addr)) {
msg = DHCPV4_MSG_NAK;
- lease = NULL;
+ /*
+ * DHCP client requested an IP which we can't offer to him. Probably the
+ * client changed the network. The reply type is set to DHCPV4_MSG_NAK,
+ * because the client should not use that IP.
+ *
+ * For modern devices we build an answer that includes a valid IP, like
+ * a DHCPV4_MSG_ACK. The client will use that IP and doesn't need to
+ * perform additional DHCP round trips.
+ *
+ */
}
if (reqmsg == DHCPV4_MSG_DECLINE || reqmsg == DHCPV4_MSG_RELEASE)