Hello Mark -
On Thu, 20 Jul 2000, Orcon Network Coordinator, Mark Mackay wrote:
> > As per my previous mail, I don't think what you are proposing is really what
> > you want to do.
>
> > Third - introducing an intermediate state of 1 causes a race condition which
> > will undoubtedly create duplicate addresses, as there is a timing window
> > between the Access-Accept and the Accounting-Start in which an IP address that
> > has been allocated but not yet confirmed can be re-allocated.
>
> I got the impression from looking at the code and mysqlCreate.sql that there
> was a state=1 and state=2 planned:
>
> >From "goodies/mysqlCreate.sql":
> "#An entry for each allocatable address for AllocateAddress SQL"
> "# STATE: 0=free, 1=offered; 2=confirmed"
> "# TIME_STAMP: last time it changed state"
> "#....
>
> Looking in the AddressAllocator code - there was also reference to ->confirm
> (which simply called $MAIN::ACCEPT) then exited. (looking as though was a
> Work-in-progress)
>
This is the first release of this code, and we are interested in your comments
and test results.
>
> I don't see where the race condition could come from (if you've got time can
> you give me a hint -- so I don't stuff
>
The race condition is due to the time difference between when Radiator sends an
Accept-Accept to the NAS with a Framed-IP-Address, and when the NAS replies to
Radiator with an Accounting Start. During that time, if you get a second
request that is also given the same Framed-IP-Address, both sessions will start
with the same address.
> > It seems to me more prudent to err on the side of sensible routing and let the
> > LeaseReclaimInterval deal with addresses that are really stale.
>
> Quite true -- but one of our major (nationwide) dialup pools is controlled
> by a third party (sort of like iPass) -- and they do have problems from time
> to time, which is why I'm trying to make our code self-healing.
>
> > Again - the only problem you have at the moment is a missing Stop record.
> > Setting the DefaultLeasePeriod and the LeaseReclaimInterval to reasonable
> > values for your installation is the preferred method of reclaiming stale
> > addresses.
>
> Fair enough -- although IP's aren't freely issued in NZ (without reasonable
> justification), meaning you have to use address space efficiently. If you
> set it to a 'reasonable' time of 12 hours (we don't restrict session
> lengths, it still means in the event of some unforseen problem that you
> could need 2xNAS capacity to make sure there's possible shortage of IPs.
>
> > Second - you can trap NAS-Error and similar problem packets in a special
> > Handler. This is the preferred approach for dealing with these sorts of
> > problems.
>
> Fair enough -- was trying to find out whether Open.com.au was working on
> improving the AddressAllocator code before implementing such custom hooks
> myself.
>
You don't need to implement a custom hook for this, simply configure a Handler:
<Handler Acct-Terminate-Cause = NAS-Error>
.....
</Handler>
> [Can you confirm that there are no major changes/improvements planned for
> the current code in the near future -- as I may just hack the current
> AddressAllocator.pm code rather than using Hooks.]
>
Correct. We are happy to discuss possible changes, but Mike would need to be
convinced of the desirability of including those changes.
regards
Hugh
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
