diff options
| author | Christian Mehlis <christian@m3hlis.de> | 2014-08-12 14:25:33 +0200 |
|---|---|---|
| committer | Christian Mehlis <christian@m3hlis.de> | 2014-08-12 14:59:37 +0200 |
| commit | 428908569b8da45613891e21736c587894e0c449 (patch) | |
| tree | 27b512a6c77b21dd02542258537bdff294a00c57 /src | |
| parent | 634d9fe9142f62b7b2e7647ef88d6606e54ab155 (diff) | |
dhcpv4: offer a valid configuration with DHCP NAK
On network change the client requests a non valid
configuration. In this case we have to reply with
a DHCP NAK. But this NAK can include a valid
configuration like an ACK does.
With this change iDevices and Androids can finish
DHCP even with wrong configuration in first
REQUEST with two packets and without any additional
timeouts and round trips.
Diffstat (limited to 'src')
| -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 2093ecd..0d75730 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) |