(RADIATOR) Freaky AuthBy DynAddress Problem

[Brian Morris]

Hi All,

Apologies for the long message...

I have discovered a freaky problem in Radiator - this is not Radiators fault
but it causes problems.

The situation I have found is as follows :

We use Authby DyanAddress to allocate IP addresses to broadband users -
radius requests are sent to our radiator from a proxy radius at the vendor
end.  A routing mess-up meant that reply information was not getting back to
the vendors proxy radius therefore users could not successfully
authenticate.

However, the proxy radius kept on sending the requests (as it should) and
users kept on trying to connect (as they do).

Radiator kept on receiving these requests and processing them as usual - and
one of the steps was to allocate an IP address from the RADPOOL table -
However, since multiple requests were coming through (due to no response
being received) Radiator kept on allocating IP addresses from RADPOOL an not
clearing the old ones it had previously allocated to the users last request.
Pretty soon our RADPOOL table ran out of available IP addresses and even
though routing was finally fixed, users could still not connect because
there were no more available IP addresses.

Now I know that the sessiontimeout paramater will eventually clear this up
(after 24 hours though) but is there any other way that this can be checked
for or prevented in the first place.  Perhaps some checking like is done in
RADONLINE where the users entry is cleared before being added again??

I know this is a very unusual problem that many peole will never encounter
but I hope someone else will benefit from my experiences.

I suspect that this problem may also occur on a highly congested (slow) link
where a NAS resends an auth request after a timeout.

Regards,

Brian Morris







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