(RADIATOR) Hacking around an upstream issue.

[Claudio Lapidus]

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 <hugh at open.com.au>
>To: "Martin Edge" <martinedge at kbs.net.au>
>CC: "Radiator" <radiator at open.com.au>
>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:hugh at open.com.au]
>>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 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.
>>
>>
>>
>
>--
>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.




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

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