(RADIATOR) Hacking around an upstream issue.

[Ingvar Berg (EAB)]

Sounds like a broken NAS, sending alive packets for a terminated session...
/Ingvar

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


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