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" <[EMAIL PROTECTED]> To: "Brian Morris" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > > To unsubscribe, email '[EMAIL PROTECTED]' 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
