(RADIATOR) Problem with Radiator 2.19

[Hugh Irvine]

Hello Ujwol -

The only way I can think of to maintain the session database is to run a cron 
job that would run periodically to check the NAS's and delete stale sessions 
as required. There is currently no way to do this directly in Radiator.

regards

Hugh


On Wed, 6 Feb 2002 22:17, Ujwol Manandhar wrote:
> Hi Hugh,
>    Is there anyway we could delete the session automatically, when the
> Radius detects "the user has gone away"?
>    I'll try to send the config file and trace 4 debug.
> Regds
> Ujwol
>
> On Wed, 6 Feb 2002, Hugh Irvine wrote:
> > Hello Ujwol -
> >
> > On Tue, 5 Feb 2002 22:40, Ujwol Manandhar wrote:
> > > Hello Hugh,
> > >
> > >    Thanks for the reply. Please find the answers below
> > >
> > >   On Tue, 5 Feb 2002, Hugh Irvine wrote:
> > > > Hello Ujwol -
> > > >
> > > > On Mon, 4 Feb 2002 21:21, Ujwol Manandhar wrote:
> > > > > Hi,
> > > > >   Since upgrading to Radiator 2.19, I'm facing strange problems.
> > > > > First there was this session limit problem with "NasType
> > > > > Livingston". There is still that typo mistake in Nas.pm
> > > >
> > > > What typo is that?
> > >
> > > The typo I'm talking about is in Nas.pm
> > > In earlier versions of Radiator before 2.18, Nas.pm used to have
> > > following
> > > ------------------------------------------------------------------
> > >
> > > my $result = &Radius::SNMP::snmpget($nas_id,
> > >                          $client->{SNMPCommunity},
> > >                         
> > > "$main::config->{LivingstonMIB}.3.2.1.1.1.2.5"); my ($xport) = ($result
> > > =~ /^.*\"S([0-9]+)\".*$/);
> > >     $xport += 0;
> > >     my $portidx = $nas_port + (5 - $xport);
> > >     $portidx -= $client->{LivingstonHole}
> > >         if ($nas_port > $client->{LivingstonOffs});
> > >
> > >     $result = &Radius::SNMP::snmpget($nas_id,
> > >                       $client->{SNMPCommunity},
> > >
> > > "$main::config->{LivingstonMIB}.3.2.1.1.1.5.$portidx");
> > > #    print "------got $result\n";
> > >
> > >
> > >  But in the current versions it has
> > > -----------------------------------------------------------------
> > > my $result = &Radius::SNMP::snmpget($nas_id,
> > >                          $client->{SNMPCommunity},
> > >                          "$main::config->{LivingstonMIB}.2.1.1.1.2.5");
> > >     my ($xport) = ($result =~ /^.*\"S([0-9]+)\".*$/);
> > >     $xport += 0;
> > >     my $portidx = $nas_port + (5 - $xport);
> > >     $portidx -= $client->{LivingstonHole}
> > >         if ($nas_port > $client->{LivingstonOffs});
> > >
> > >     $result = &Radius::SNMP::snmpget($nas_id,
> > >                       $client->{SNMPCommunity},
> > >
> > > "$main::config->{LivingstonMIB}.3.2.1.1.1.5.$portidx");
> > > #    print "------got $result\n";
> > > -------------------------------------------------------------------
> > >
> > >   Please notice the number 3 is missing. This was pointed out earlier
> > > by my senior Deepak. But the error is still there.
> >
> > Thanks for pointing this out - I have forwarded your mail to Mike.
> >
> > > > >    Another thing is whenever the any NAS goes off, the session does
> > > > > not get deleted. There is only the message User has gone away.
> > > > > Since the session is not deleted, user can not login again.
> > > >
> > > > Do you mean when a NAS is restarted?
> > >
> > >   This happens when the link with the NAS gets disconnected. We have
> > > not checked when NAS is restarted. We're experiencing this problem with
> > > our cisco AS5300.
> >
> > Sessions will only be deleted from the session database when Radiator
> > receives an Accounting Stop from the NAS. If you do not receive the
> > Accounting Stop then the session will remain in the session database.
> >
> > > > >    And the most problematic one is, when such incidence occurs, or
> > > > > there are lots of duplicate requests, the radiator stops
> > > > > authenticating. It just freezes. I never had such problem with
> > > > > earlier versions of Radiator.
> > > >
> > > > This is very peculiar.
> > > >
> > > > Can you send me a copy of your configuration file (no secrets)
> > > > together with a trace 4 debug showing what is happening? And can you
> > > > also tell me what hardware/software platform you are running on?
> > >
> > >   Right now I don't have trace 4 debug output of when it happened, I
> > > can't send it. I can send you normal trace 4 debug output and the
> > > config file. We're using Radiator 2.19 on RH Linux 7.1 with DBD Sybase
> > > and user databases are in Win 2000 box which runs MSSQL 7.0.
> >
> > It would be helpful to see the configuration file and trace 4 debug.
> >
> > > > >    Lastly I was just wondering if I can find the list of possible
> > > > > debug errors and explanation. Mailing list is fine and most of the
> > > > > errors are obvious, but I was just wondering if there is any list.
> > > >
> > > > There is no list per-se, however the best way to find out what the
> > > > error messages  mean is to look at the source code to see what causes
> > > > the messages to be generated.
> > >
> > >  Thanks, I'll check the source code.
> >
> > May the source be with you ......
> >
> > :-)
> >
> > cheers
> >
> > Hugh

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