(RADIATOR) Radiator and the DHCP allocator

[Iain Wade]

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.
>
>
>

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.