udhcpc -r broken ?

[Denys Vlasenko]

On Tue, Aug 2, 2011 at 6:13 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
> As I understand it, the -r option of udhcpc allows to tell the DHCP
> client that it should try to use the given IP address and suggest it to
> the DHCP server. However, it seems I can't get it to work (Busybox
> 1.18.4 is used) :
>
> # udhcpc -r 192.168.0.51
> udhcpc (v1.18.4) started
> Sending discover for 192.168.0.51...
> eth0: link up (100/Full)
> Sending discover for 192.168.0.51...
> Sending select for 192.168.0.55...
> Lease of 192.168.0.55 obtained, lease time 43200
> deleting routers
> route: SIOCDELRT: No such process
> adding dns 192.168.0.254
>
> I have asked for 192.168.0.51, but I got 192.168.0.55, even if the
> 192.168.0.51 IP address is definitely available. The thing that sounds
> strange is that udhcpc itself sends a select to the DHCP server with
> the 192.168.0.55 IP address.

rfc2131:

 1. The client broadcasts a DHCPDISCOVER message on its local physical
      subnet.  The DHCPDISCOVER message MAY include options that suggest
      values for the network address and lease duration.
...
   2. Each server may respond with a DHCPOFFER message that includes an
      available network address in the 'yiaddr' field (and other
      configuration parameters in DHCP options).
...
3. The client receives one or more DHCPOFFER messages from one or more
     servers.  The client may choose to wait for multiple responses.
     The client chooses one server from which to request configuration
     parameters, based on the configuration parameters offered in the
     DHCPOFFER messages.  The client broadcasts a DHCPREQUEST message
     that MUST include the 'server identifier' option to indicate which
     server it has selected, and that MAY include other options
     specifying desired configuration values.  >>>The 'requested IP
     address' option MUST be set to the value of 'yiaddr' in the
     DHCPOFFER message from the server.<<<

See? Client is not allowed to override IP address that server
gives to it.


> (Note: the IP address added in the "Sending discover for..." messages
> as been added by me, trying to debug the issue).
>
> Now, in the reception of the DHCP_OFFER, I have the impression that the
> IP address that the user has passed as -r option is completely ignored.

Yes, and it *should be* ignored.

> So I tried to use the following patch :
>
> --- busybox-1.18.4.orig/networking/udhcp/dhcpc.c        2011-03-13 02:45:40.000000000 +0100
> +++ busybox-1.18.4/networking/udhcp/dhcpc.c     2011-08-02 18:03:32.419364336 +0200
> @@ -1377,8 +1379,8 @@
>                                /* it IS unaligned sometimes, don't "optimize" */
>                                move_from_unaligned32(server_addr, temp);
>                                /*xid = packet.xid; - already is */
> -                               requested_ip = packet.yiaddr;
> -
> +                               if (requested_ip == 0)
> +                                       requested_ip = packet.yiaddr;
>                                /* enter requesting state */
>                                state = REQUESTING;
>                                timeout = 0;
>
> This should keep the IP address requested by the user on the command line.
>
> It gives the following results :
>
> # udhcpc -r 192.168.0.63
> udhcpc (v1.18.4) started
> Sending discover for 192.168.0.63...
> eth0: link up (100/Full)
> Sending discover for 192.168.0.63...
> Sending select for 192.168.0.63...
> Sending select for 192.168.0.63...
> Sending select for 192.168.0.63...
> Sending discover for 192.168.0.63...
> Sending select for 192.168.0.63...
> Lease of 192.168.0.63 obtained, lease time 43200
> deleting routers
> route: SIOCDELRT: No such process
> adding dns 192.168.0.254
>
> So it actually was able to get the 192.168.0.63, but it took a very
> long amount of time: the client had to send multiple DHCP SELECT
> queries before getting a reply from the server.

Your server must be somewhat forgiving towards clients
which illegally insist on using IP address they were not offered.
Other servers might plainly refuse to answer to such SELECTs.

-- 
vda