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
>
>
>
--
Regds,
Ujwol Manandhar
Mercantile Communications Pvt Ltd
P.O.Box 876
Durbarmarg,Kathmandu, Nepal
Tel: +977-1-240920
Fax: +977-1-225407
===
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.
