Hello again Mark -
Further to this post from yesterday, I was thinking some more about the
discussions Mike and I had while doing this address allocation feature and what
we decided was this: Because radius is based on UDP and because packets can and
will go missing, there is no way to determine from Radaitor's point of view
whether a session has not started after an address has been allocated (your
state 1), or whether a session has started but the accounting start has been
lost (ie what should be your state 2). This is in addtion to the race condition
described below. Therefore we decided that it would be best to just allocate
the address and let it time out if it was allocated incorrectly. Note that the
above is an unsolvable problem due to the nature of the protocol.
I think you would be better to approach the problem from a different direction
entirely and write a little external perl program that you can run from cron
every 10 minutes say, that will go through the IP address pools and ping each of
the addresses that are marked as in use (state 1). If the address cannot be
pinged some configurable number of times through the list (ie after 20 or 30
minutes), then you can simply mark it as free again (state 0).
The code to do the above would be less than 50 lines.
BTW - we do undertake contract development work from time to time, so if you
would like us to do something like the above, please let us know.
regards
Hugh
On Thu, 20 Jul 2000, Hugh Irvine wrote:
> 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.
--
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.
