DHCP Server Option 82 denial

[Scott Baker]

I've personally watched the lease "stagnate" for a least several
hours. So the customer makes that first DISCOVER, the DHCP server
sends an OFFER, and for whatever reason the client sends another
DISCOVER and thus we end up getting bit by that billing issue.

The customer was patient and waited the FULL lease time (4 hours)
and the DHCP server never gave them an IP. It continued to complain
that there was no available billing. Short of a full tcpdump capture
of the request process how can I help? This is our production DHCP
server so I'm sort of wary to hack C to try and make this work.

I haven't been able to reproduce this in our lab, and it only seems
to affect < 1% of our customers. I'll keep on it and get you as much
information as I can.

Scott

Apr 29 08:43:45 pisces dhcpd: DHCPDISCOVER from 00:02:a5:cf:49:75
via 65.182.241.1
Apr 29 08:43:46 pisces dhcpd: DHCPOFFER on 65.182.239.157 to
00:02:a5:cf:49:75 via 65.182.241.1
Apr 29 08:43:46 pisces dhcpd: DHCPDISCOVER from 00:02:a5:cf:49:75
via 65.182.241.1: no available billing

** SNIPPED TO SAVE SPACE **

Apr 29 13:51:45 pisces dhcpd: DHCPDISCOVER from 00:02:a5:cf:49:75
via 65.182.241.1: no available billing
Apr 29 13:57:36 pisces dhcpd: DHCPDISCOVER from 00:02:a5:cf:49:75
via 65.182.241.1
Apr 29 13:57:37 pisces dhcpd: DHCPOFFER on 65.182.243.56 to
00:02:a5:cf:49:75 (wsd-37f6388def3) via 65.182.241.1
Apr 29 13:57:37 pisces dhcpd: DHCPREQUEST for 65.182.243.56
(65.182.224.34) from 00:02:a5:cf:49:75 (wsd-37f6388def3) via
65.182.241.1
Apr 29 13:57:37 pisces dhcpd: DHCPACK on 65.182.243.56 to
00:02:a5:cf:49:75 (wsd-37f6388def3) via 65.182.241.1

David W. Hankins wrote:
> On Fri, May 26, 2006 at 10:11:07AM -0700, Scott Baker wrote:
>> May 26 09:53:39 dhcp-server dhcpd: DHCPDISCOVER from
>> 00:02:a5:cf:49:75 via 65.182.241.1
>> May 26 09:53:40 dhcp-server dhcpd: DHCPOFFER on 65.182.239.219 to
>> 00:02:a5:cf:49:75 via 65.182.241.1
>> May 26 09:53:40 dhcp-server dhcpd: DHCPDISCOVER from
>> 00:02:a5:cf:49:75 via 65.182.241.1: no available billing
> 
> Hm.  The obvious problem being that it appears the server is allocating
> the client a separate address on the second offer.  That's curious, it
> shouldn't.
> 
> Let's assume that the client is somehow identifying itself differently...
> by say providing a client identifier instead of not...there's no reason
> it shouldn't just offer the same address (and then that wouldn't run into
> billing problems).
> 
> But it doesn't make a lot of sense to bill a class for an OFFER.  The
> client isn't using the address (or at least shouldn't be).  There's no
> good reason to mark them for it until we send an ACK.
> 
> At the same time, we need to know if there's available billing before
> sending an OFFER, certainly, and we also need to link in the class for
> billing-class-scoped config parameters.
> 
> Immediately what makes the most sense to me is to unbill billed classes
> for offers immediately after ACKing.
> 
> If you're willing to experiment...
> 
> Find the function named 'dhcpdiscover' in server/dhcp.c, towards
> the end of the function (line 375 in my sources), find:
> 
>         ack_lease (packet, lease, DHCPOFFER, when, msgbuf, ms_nulltp,
>                    (struct host_decl *)0);
>       out:
>         if (lease)
>                 lease_dereference (&lease, MDL);
> 
> Which is literally the last lines of that function.
> 
> 
> Switch that last two lines so it reads instead:
> 
> 	if (lease) {
> 		/* XXX - Super Ultra Unwise Experimental Code - Do Not Run
> 		 * (unless you enjoy pain).
> 		 *
> 		 * There's no good reason to bill a class on an OFFER,
> 		 * but there's also no good reason to OFFER if we would
> 		 * fail due to billing on the ACK.  Unbill the class for
> 		 * now, and we will rebill it on receiving a REQUEST.
> 		 */
> 		if ((lease->flags & STATIC_LEASE) &&
> 		    (lease->billing_class != NULL) &&
> 		    (lease->state == FTS_FREE || lease->state == FTS_BACKUP))
> 			unbill_class(lease, lease->billing_class);
> 
> 		lease_dereference (&lease, MDL);
> 	}
> 
> Untested, random thoughts.
> 
> 
>> I'm assuming it will timeout eventually because the customer didn't
>> accept the lease. Is that timeout period controllable? If I stop and
> 
> 2 minutes, should be, unless the lease is active when they got this
> far.  And no isn't controllable (unless you edit sources).
> 
> I'm also pretty fuzzy on how non-active leases get 'expired'.  That's a
> fair quagmire of code I've never managed to read from one end to the other
> in one sitting.
> 
> It may be that you've illuminated where billing classes go to die.
> 

-- 
Scott Baker - RHCE
Canby Telcom System Administrator
503.266.8253