Martin, perhaps it's possible to set up a handler to deal with packets with Acct-Delay-Time > 0 and do the special handling just for those. Just an idea, I didn't give it a second thought, but at first it seems possible to me, doesn't it?
regards cl. >From: Hugh Irvine <[EMAIL PROTECTED]> >To: "Martin Edge" <[EMAIL PROTECTED]> >CC: "Radiator" <[EMAIL PROTECTED]> >Subject: Re: (RADIATOR) Hacking around an upstream issue. >Date: Wed, 4 Sep 2002 11:24:24 +1000 > > >Hello Martin - > >Its a bit hard to see how Radiator could deal with this situation in any >sensible fashion. > >I think I would still be inclined to use a seperate Handler for Alives and >use a special AddQuery to check the existence of a session before trying to >update it - although this will still be a problem if you have missed a >Start record. > >I would also check how and why you are missing accounting records in the >first place and fix whatever problem is causing this to happen (saturated >links?). > >Keep in mind that the "sanity" of the session database depends directly on >the sanity of the accounting records that are used to maintain it. Clearly >what you describe is not "sane". > >regards > >Hugh > > >On Wednesday, September 4, 2002, at 10:18 AM, Martin Edge wrote: > >>Hi Hugh, >> >>The normal processing of Alives is fine. The fact we get Alives ensures I >>can check the sanity of the SessionTable. >>Each time an Alive record comes in, it updates the SessionTable for each >>user's session >> >>The NAS's appear to be sending an Alive packet for a Session after we have >>received the Stop packet for the _same_ Session. >> >>This is due to the first attempt to send the Alive packet failing, the NAS >>waits 10 seconds for a retry. During this ten seconds, the user >>disconnects, >>the NAS sends a stop record. >> >>The NAS then sends off the second attempt for the Alive packet. >> >>Consequently, the session is 'reopened' in my SessionTable, as the Alive >>packet triggers a delete/insert .. for all intensive purposes I see a dead >>session, which was actually already closed off. >> >>Thanks >>Martin >> >>-----Original Message----- >>From: Hugh Irvine [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, September 04, 2002 9:50 AM >>To: Martin Edge >>Cc: Radiator >>Subject: Re: (RADIATOR) Hacking around an upstream issue. >> >> >> >>Hello Martin - >> >>What exactly is the problem? >> >>If you just want special processing for Alives, do something like this: >> >><Handler Acct-Status-Type = Alive> >> .... >></Handler> >> >>regards >> >>Hugh >> >> >>On Wednesday, September 4, 2002, at 09:23 AM, Martin Edge wrote: >> >>>Hey Guys, >>> >>>Want to see if anyone has any ideas of how I should deal with this >>>situation. >>> >>>We are currently getting the following for the 'occasional' user session >>>from our Upstream RADIUS.. >>> >>>Order Amount Type >>>------------------------------------------------- >>>1 1 Start >>>2 Many Alive's (every 15 min) >>>3 1 Stop (0 sec, Acct-Delay-Time) >>>4 1 Alive (9 seconds afterwards, Acct-Delay-Time=10) >>> >>>We are told that what is happening, is the first attempt is made to >>>send the >>>first Alive packet. By coincendence, the user disconnects between these >>>retries, and the Stop packet is fired off. The Retry Alive packet is >>>sent >>>after the Stop packet for that session has arrived. >>> >>>Until they can come up with a network-fix for the problem (to prevent >>>Additional Packets for the Same Session to be sent before completely >>>failing >>>the current packet (until $x times tried), I'm going to have to >>>develop a >>>hack around to work out on what basis to ignore these extra Alives. >>> >>>I was thinking I have two options >>> >>>1:- Make Radiator see whether the SessionID is still active for an Alive >>>packet (could be costly on DB work each instance) >>>2:- Make Radiator store recent sessionIDs it has closed off in a DB or >>>DBM >>>file, and check incoming Alive packet -isn't- in the recently expired >>>list. >>> >>>Which would be the best? Where should I start? :) >>> >>>Thanks, >>>Martin >>> >>>=== >>>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. >> >> >> > >-- >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. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com === 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.