Option 82 renew/rebind problem

[Andre Schubert]

On Thu, 10 Jul 2008 16:17:17 +1000 (EST)
Glenn Satchell <Glenn.Satchell at uniq.com.au> wrote:

> 
> >Date: Thu, 10 Jul 2008 08:07:04 +0200
> >From: Andre Schubert <andre at km3.de>
> >To: dhcp-users at isc.org
> >Subject: Re: Option 82 renew/rebind problem
> >
> >On Wed, 09 Jul 2008 23:21:58 +0200
> >Claus Holm Christensen <iscdhcp at claushc.dk> wrote:
> >
> >> Andre Schubert wrote:
> >> > But i have seen some CPEs that send their packets directly to the 
> dhcp-server asking to renew the lease.
> >> > When this happens, the relay agent has no chance to add the agent 
> information to the packets.
> 
> This is normal bahaviour. DHCPDISCOVER is broadcast, but DHCPRENEW is
> unicast direct to the dhcp server. Have a look in dhcpd.leases for a
> lease on one of these devices - it should have recorded the dhcp relay
> options in the lease information so they can be re-applied for unicast
> packets.
> 

right these informations are already stored from the intial bootup of the cpe.

> >> > I searched through the archives and found the following snipped:
> >> 
> >> Maybe you are looking for the stash-agent-options parameter?
> >> 
> >>  From dhcpd.conf manual (ver 3.0.6):
> >> 
> >> > If the stash-agent-options parameter is true for a given client, the server 
> will record the relay agent information options sent during the
> >> > client’s initial DHCPREQUEST message when the client was in the SELECTING 
> state and behave as if those options are included in all subsequent
> >> > DHCPREQUEST messages sent in the RENEWING state.  This works around a 
> problem with relay agent information options, which is that they usually
> >> > not appear in DHCPREQUEST messages sent by the client in the RENEWING 
> state, because such messages are unicast directly to the server and not
> >> > sent through a relay agent.
> >> 
> >> Hope this helps.
> >> 
> >
> >thanks for your answer, but stash-agent-options is already set to true and 
> doesnt help in this place.
> >It seems that stash-agent-options comes in after a lease has been assigned and 
> the agent information options
> >are put onto the outgoing packet.
> >
> >Maybe is it possible to get the dhcp-server working with such a scenario ?
> 
> Like I said above, this is normal behaviour and dhcpd handles it. Check
> the leases file to see what infoprmation is stored in the lease. Then
> the next step is to see either why the option-82 information is
> missing, or why it is not being used for subsequent renewals.
> 
> Is unicast traffic from the CPE to the dhcp server permitted? ie
> there's no firewall blocking packets or missing routes?
> 

the problem here is, the when the cpe send a renew it does this with unicast
directly to the dhcp-server thatswhy the relay-agent could not add the
relay agent information options. I could see these packets coming in to the
dhcp-server. The dhcp-server itself returns a DHCPNAK, because the packet
seems to not be put in the right class because of the missing agent information options
in the incoming packet.
If i compile the dhcp-server with DEBUG_FIND_LEASE, i could see the dhcp-server finding
the right lease, but then i see a not permitted for the pool the lease was initally assigned.

Regards,
Andre Schubert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20080710/5d996246/attachment.bin>