(RADIATOR) Freaky AuthBy DynAddress Problem

[Hugh Irvine]

Hello Brian -

As I mentioned in my previous mail, you will have to look closely at the 
requests that you receive from your NAS(s) to determine whether or not there 
is any way to apply a sanity check and indeed what that sanity check might be.

regards

Hugh


On Mon, 4 Feb 2002 16:55, Brian Morris wrote:
> 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.

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