Missing Information in ACK from DHCPInform
Stephens, Bill {PBSG}
Bill.Stephens at pbsg.com
Mon Aug 25 19:03:39 UTC 2003
Thanks for pointing me in the right direction. The subnet matches the one
the machine gets when it does a request. However the scope value seems to
possibly be out of whack. Here's what I'm seeing:
DHCPINFORM:
subnet - 0x8120820
in_options - 0x8120250
out_options - 0x8120418
scope - 0x80dac60
group - 0x8120888
ACK_LEASE (dhcprequest)
subnet - 0x8120820
in_options - 0x8120250
out_options - 0x8120418
scope - 0x81547b8
group - 0x8120888
Should the scope value be set to something other than &global_scope?
Thanks,
Bill Stephens
-----Original Message-----
From: David W. Hankins [mailto:David_Hankins at isc.org]
Sent: Friday, August 22, 2003 6:38 PM
To: dhcp-hackers at isc.org
Subject: Re: Missing Information in ACK from DHCPInform
On Thu, Aug 21, 2003 at 01:55:17PM -0500, Stephens, Bill {PBSG} wrote:
> After running the debugger, I can't make heads or tails out of where the
> dhcpinform subroutine should be looking up the options from the subnet
> configuration settings.
unless i miss my mark, server/dhcp.c:1003:
if (subnet)
execute_statements_in_scope ((struct binding_value **)0,
packet, (struct lease *)0,
(struct client_state *)0,
packet -> options, options,
&global_scope, subnet -> group,
(struct group *)0);
the if(subnet) check heading that shouldn't fail, if subnet is not set
by that time it would log an error and return.
other than the fact that dhcprequest() gets the subnet subnet pointer
from the lease, rather than from the client addr, this is identical.
a good place to start as ted mentioned is verifying the subnet is matching
the correct subnet structure.
otherwise, it's all common code, and nothing is jumping out at me as
being something that's done differently between the two.
--
David W. Hankins "If you don't do it right the first time,
DHCPD Maintainer you'll just have to do it again."
-- Jack T. Hankins
More information about the dhcp-hackers
mailing list