Re: (RADIATOR) AddressAllocator SQL - "confirm" appears disabled

[Orcon Network Coordinator, Mark Mackay]

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


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

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

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

.........................................................................

Mark Mackay,
Network Coordinator,
Orcon Internet.


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