(RADIATOR) Freaky AuthBy DynAddress Problem

[Brian Morris]

Agreed,

However, I notice that Radiator removes any 'freaky' entry from the
RADONLINE table along the lines of:

Delete from radonline where nasidentifier = 'whatever' and nasport =
'whatever'

prior to adding the new entry to the RADONLINE table.

Couldn't a similar sanity check be used for RADPOOL?

Regards,  Brian Morris






----- Original Message -----
From: "Hugh Irvine" <hugh at open.com.au>
To: "Brian Morris" <brian at netspeed.com.au>; <radiator at open.com.au>
Sent: Monday, February 04, 2002 2:53 PM
Subject: Re: (RADIATOR) Freaky AuthBy DynAddress Problem


>
> Hello Brian -
>
> As you say - this is not a Radiator problem - and it is difficult to see
how
> Radiator can be made to deal with a network routing issue. Depending on
the
> exact contents of the radius requests that you are receiving, it may be
> possible to set up a session database and use session limiting, however I
am
> not optimistic and you may introduce more problems than you solve.
>
> regards
>
> Hugh
>
>
> On Mon, 4 Feb 2002 12:59, Brian Morris wrote:
> > 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.
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.

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