udhcpd initial lease

Denys Vlasenko vda.linux at googlemail.com
Sun Nov 28 20:53:33 UTC 2010


On Sunday 28 November 2010 10:14, Ralf Friedl wrote:
> Denys Vlasenko wrote:
> > On Friday 26 November 2010 23:04, Dan Fandrich wrote:
> >   
> >> Yes, exactly. If the server is going to provide an address anyway
> >> (eventually) and the suggested one is valid, why not give the client what
> >> it wants?
> >>     
> >
> > That's what we do:
> >
> > When we receive DISCOVER packet, we retrieve "requested IP",
> > put it into the lease table for 60 seconds,
> > put it into packet.yiaddr and send the reply.
> >
> > When we later get REQUEST packet, we find "requested IP"
> > in lease table and therefore ACK this REQUEST.
> >
> > This is how it supposed to work.
> >
> > We need to understand why it doesn't work.
> >
> > tcpdump output would be very useful to see.
> Actually I've never seen DISCOVER packets with a requested IP.
> The Client will not send DISCOVER, it will immediately send a REQUEST 
> for the last IP. Only after a NAK to this REQUEST it will send a a 
> DISCOVER, and then a new REQUEST for the IP from the OFFER.
> 
> So it would be reasonable to grant a REQUEST if the IP is in the correct 
> range and free, even if it was not previously OFFERed.

You are right. RFC 2131 says:

"o DHCPREQUEST generated during INIT-REBOOT state:

   'server identifier' MUST NOT be filled in, 'requested IP address'
   option MUST be filled in with client's notion of its previously
   assigned address. 'ciaddr' MUST be zero. The client is seeking to
   verify a previously allocated, cached configuration. Server SHOULD
   send a DHCPNAK message to the client if the 'requested IP address'
   is incorrect, or is on the wrong network"

and in this case, we don't answer at all. Looks like a bug.

The minimal fix would be to at least send a NAK, forcing client
to fall back to re-negotiating DHCP form the start:



diff -ad -urpN busybox.0/networking/udhcp/dhcpd.c busybox.1/networking/udhcp/dhcpd.c
--- busybox.0/networking/udhcp/dhcpd.c  2010-11-27 22:25:51.000000000 +0100
+++ busybox.1/networking/udhcp/dhcpd.c  2010-11-28 21:45:13.000000000 +0100
@@ -584,11 +584,15 @@ o DHCPREQUEST generated during REBINDING
                                send_ACK(&packet, lease->lease_nip);
                                break;
                        }
-                       if (server_id_opt) {
-                               /* client was talking specifically to us.
-                                * "No, we don't have this IP for you". */
+                       /* No lease for this MAC, or lease IP != requested IP */
+
+                       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;
 
                case DHCPDECLINE:


-- 
vda


More information about the busybox mailing list