(RADIATOR) Hacking around an upstream issue.

[Hugh Irvine]

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.

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