diff options
author | sbyx <steven@midlink.org> | 2014-08-12 15:05:17 +0200 |
---|---|---|
committer | sbyx <steven@midlink.org> | 2014-08-12 15:05:17 +0200 |
commit | aa5659eb06a386ddf2bc80ad078891820f12c410 (patch) | |
tree | c67f5f5b903fce5be51199567a23f71e95f36aa2 | |
parent | de90ff1b27ef8e41c819d40d80f0fd6d8be86ded (diff) | |
parent | 428908569b8da45613891e21736c587894e0c449 (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.c | 11 |
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) |