DHCP server behavior in case of RENEW

[Denys Vlasenko]

On Tue, Jun 28, 2011 at 9:35 AM, vijay kanala <vijaykanala776 at gmail.com> wrote:
> Hi All,
> I am using busybox-1.18.5.
>
> I have this scenario:
> I have a standard linux client ( Fedora core 13, dhclient runs on
> this) connected to my DSL router ( on which i am using busybox dhcp
> sever).
>
> Lets assume the host got an IP address allocated by DHCP server. The
> dhcp client tries to renew in approximately half the lease time it
> got.
> Meanwhile if DSL router powers off and powers on ( either soft reboot
> or hard reboot), it looses all lease information. After it powers on,
> it continues to ignore all RENEW messages untill the client starts
> from scratch.
>
> For example, in case where lease time is 24 hours, it means the dhcp
> client can not get renewal from 12 hours onwards ( assuming DSL router
> rebooted in 0-12 hours) . The client needs to wait for extra 12 hours
> to get a new IP. But shouldnt dhcp server send some kind of NAK so
> that client is able to get a new IP?

I'm, not sure it should. It may have something to do with
multi-server setup - _another_ DHCP server might be able
to renew the lease.

> I saw this code in server:
> ======================
> if (server_id_opt    /* client is in SELECTING state */
>                         || requested_ip_opt /* client is in INIT-REBOOT state */
>                        ) {
>                                /* "No, we don't have this IP for you" */
>                                send_NAK(&packet);
>                        } /* else: client is in RENEWING or REBINDING, do not answer */
>
>                        break;
> =============================
>
> Shouldnt we  send NAK instead of "do not answer" ?
> Or is there any other way to solve this problem?

Comment from the dhcpd.c:

RFC 2131
...
o DHCPREQUEST generated during RENEWING state:

   'server identifier' MUST NOT be filled in, 'requested IP address'
   option MUST NOT be filled in, 'ciaddr' MUST be filled in with
   client's IP address. In this situation, the client is completely
   configured, and is trying to extend its lease. This message will
   be unicast, so no relay agents will be involved in its
   transmission.  Because 'giaddr' is therefore not filled in, the
   DHCP server will trust the value in 'ciaddr', and use it when
   replying to the client.

   A client MAY choose to renew or extend its lease prior to T1.  The
   server may choose not to extend the lease (as a policy decision by
   the network administrator), but should return a DHCPACK message
   regardless.

o DHCPREQUEST generated during REBINDING state:

   'server identifier' MUST NOT be filled in, 'requested IP address'
   option MUST NOT be filled in, 'ciaddr' MUST be filled in with
   client's IP address. In this situation, the client is completely
   configured, and is trying to extend its lease. This message MUST
   be broadcast to the 0xffffffff IP broadcast address.  The DHCP
   server SHOULD check 'ciaddr' for correctness before replying to
   the DHCPREQUEST.

   The DHCPREQUEST from a REBINDING client is intended to accommodate
   sites that have multiple DHCP servers and a mechanism for
   maintaining consistency among leases managed by multiple servers.
   A DHCP server MAY extend a client's lease only if it has local
   administrative authority to do so.




For me it's not clear what we are required to do in this case.
Not responding seems to be a safe choice: client in
RENEWING or REBINDING state should still be fully configured.
It should be able to access the net.

Please describe what you see in more details. For example:

> The client needs to wait for extra 12 hours
> to get a new IP.

In your case, is client still able to use the net while
it sends RENEW-type DHCPREQUESTs?

-- 
vda