(RADIATOR) Radiator and the DHCP allocator

[Hugh Irvine]

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.