(RADIATOR) Radiator and the DHCP allocator

[Iain Wade]

Here is the revised patch.

So this one just implements the Stateless flag, and multiple Host destinations.

Regards,
--Iain

On 10/7/05, Iain Wade <iain.wade at gmail.com> wrote:
> I did check out 3.13 but didn't notice the patch set.
>
> I'll rework the other parts against the patch set and get back to you.
>
> Regards,
> --Iain
>
> On 10/7/05, Hugh Irvine <hugh at open.com.au> wrote:
> >
> > Hello Iain -
> >
> > Curiously enough, I have recently issued a patch for the "secs"
> > problem, which is included in the latest Radiator patch set for
> > Radiator 3.13.
> >
> > This fix was for the "secs" problem only, so I wonder if I could
> > prevail upon you to get the latest patches and apply your patches to
> > that.
> >
> > I would really appreciate it if you could assist in this way as I am
> > overseas at the moment and can't really do any testing.
> >
> > Many thanks for your help and contribution.
> >
> > regards
> >
> > Hugh
> >
> >
> > On 7 Oct 2005, at 07:29, Iain Wade wrote:
> >
> > > Hi,
> > >
> > > The DHCP allocator in Radiator seems to maintain state for the purpose
> > > of storing the constructed HW address and correctly following the
> > > Subnet-Selection RFC. Unfortunately, as implemented currently, a Stop
> > > record sent to a different Radiator instance will not result in a DHCP
> > > release as it cannot lookup that state.
> > >
> > > The DHCP allocator can only be pointed at one IP address; I have a
> > > failover cluster of ISC DHCPd servers in different data centres (i.e.
> > > different subnets) and need to be able to parallel send the DISCOVER
> > > to both.
> > >
> > > For failover clusters of ISC DHCPd to correctly handle certain split
> > > brain scenarios clients are required to correctly increment the secs
> > > field on retransmissions. This wasn't happening.
> > >
> > > I have attached a patch which solves these problems for me. Any
> > > feedback is welcome.
> > >
> > > I submit them to the list in the hope that these changes (or some like
> > > them) make their way into future releases.
> > >
> > > The patch implements a new flag "Stateless" which cannot be used in
> > > conjunction with Subnet-Selection. When operating in Stateless mode,
> > > the HW address is constructed by using a crc32() of the
> > > Client-Identifier rather than a sequence number (xid). This allows the
> > > Stop record to construct the same address without state (assuming the
> > > Client-Identifier is based on a field which exists in both Auth
> > > records and Acct/Stop records).
> > >
> > > It splits the Host field on comma and parallel sends to all hosts
> > > listed for DISCOVER (and subsequent retransmissions if no OFFER is
> > > received). It then talks directly with the first host send an OFFER.
> > >
> > > Every time it retransmits a packet it is reconstructed with the secs
> > > field set to the elapsed time since first DISCOVER.
> > >
> > > Regards,
> > > --Iain
> > >
> > > <Radiator-dhcp_failover.patch>
> > >
> >
> >
> > NB:
> >
> > Have you read the reference manual ("doc/ref.html")?
> > Have you searched the mailing list archive (www.open.com.au/archives/
> > radiator)?
> > Have you had a quick look on Google (www.google.com)?
> > Have you included a copy of your configuration file (no secrets),
> > together with a trace 4 debug showing what is happening?
> >
> > --
> > Radiator: the most portable, flexible and configurable RADIUS server
> > anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> > -
> > Nets: internetwork inventory and management - graphical, extensible,
> > flexible with hardware, software, platform and database independence.
> > -
> > CATool: Private Certificate Authority for Unix and Unix-like systems.
> >
> >
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Radiator-dhcp_failover_3.13_patches.patch
Type: application/octet-stream
Size: 11439 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20051009/0374cae1/attachment.obj>