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