Hell@ all,
has Radiator some kind of so called 'Phantom Record'?
As we see in AddressAllocatorSQL.pm, when an Access-Request packet arrives,
an 'update' statement is executed, doing a
$q = "update RADPOOL set STATE=1, TIME_STAMP=$now,
EXPIRY=$expiry, USERNAME=$username where YIADDR='$details{yiaddr}'";
Then, if an Accounting-Request packet corresponding with the above packet
never arrives, the ip-address doesn't become available again.
We are thinking in a 'patch' for AddressAllocatorSQL, a kind of PHANTOM
RECORD.
Example:
an IP-ADDRESS is available, with STATE=0;
*********************
an Access-Request arrives -> an IP-address is reserved, and STATE becomes 1.
an Accounting-Request arrives and it's OK -> ip-address changes with STATE =
2
******************
Then, if an Access-Request arrives, and there is no Accounting-Request...
if a second Access-Request arrives, the first one becomes unusable, and a
new one is allocated, doing a duplicated 'assigned' ip to the same user,
with a non used ip.
****************
The solution-> if a second Access-Request arrives, check for a previous
allocated IP address with STATE=1 and delete them,
and allocate a new one
Humm... it sounds a little confusing..
When we have the solution for this problem, we email to you...
Thanks..
Xavier Morano Merc�
System Manager
Tel:� (+34) 91 270 64 68�
Fax:�� (+34) 91 270 61 61�
Email: [EMAIL PROTECTED]
�������
===
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.
