Hi Mike,
I use 2.13.1 with the patches downloaded at 24. June as I wrote in
the first mail. But you are right, I didn't say 2.13.1, sorry.
> > I installed the patches downloaded at 24. June.
as you can see in my config (first posting) I defined NasType to
ascend. Do you use an internal finger prog to cross check it,
because I didn't define an external FingerProg?
Anyway, again it would be fine to see the internal state, perhaps
you remenber my postings at end of june about my wishlist
for a signal handler :-)
Regards
Charly
Mike McCauley schrieb:
>
> Hello Karl,
>
> You havent mentioned which versions you are using, but there is a problem with
> the internal s4ession databse of 2.13.1, where retransmissions of accounting
> requests can cause the counts to be wrong. There is a patched SessINTERNAL.pm
> available at http://www.open.com.au/radiator/downloads/patches-2.13.1/
>
> Radiator wil not double check logins in the case of an apparent over-use
> _unless_ you have defined NasType for your clients. If you do define NasType
> Radiator will try to contact the NAS to check with reality when it looks like a
> user is already logged in too many times.
>
> There is no way to see the contents of the INTERNAL session database. If you
> want to see whats in the session database, you need to use a DBM or SQL
> SessionDatabase, and use radwho.cgi to inspect it.
>
> Hope that helps.
>
> Cheers.
>
> On Jul 5, 12:17pm, Karl Gaissmaier wrote:
> > Subject: (RADIATOR) Still problems with internal session database: MaxSess
> > Hi all,
> >
> > I've still problems with the internal session database, see the
> > sections in my simple config:
> >
> >
> > <Client ulmathome.rz.uni-ulm.de>
> > Secret nottotell
> > NasType ascend
> > </Client>
> >
> > # NasType is an Ascend MAX TNT, no FingerProg specified
> > # but finger to the MAX is allowed if radiator will use an internal
> > # finger subroutine (noboby knows the algorithm when radiator is
> > # ross checking his internal session database with the real state)
> >
> > <AuthBy UNIX>
> > Identifier UnixPwd
> > Filename /etc/shadow
> > GroupFilename /etc/group
> > </AuthBy>
> >
> > <Handler NAS-IP-Address=X.Y.A.B>
> > AcctLogFileName %L/%C/detail
> > # here is the limitation to 2 concurrent sessions
> > MaxSessions 2
> > <AuthBy FILE>
> > Filename %D/users-file
> > </AuthBy>
> > </Handler>
> >
> > I installed the patches downloaded at 24. June.
> >
> > Symptoms: Some users can't dial in because radiator erronously
> > decides that the maxsessions are exceeded even if you can
> > check with finger that this user isn't online. See the fragment
> > of my trace file, trace level 3:
> >
> > Jul 1 12:14:19 1999: INFO: Access rejected for usera: MaxSessions
> > exceeded
> > Jul 1 12:14:34 1999: INFO: Access rejected for usera: MaxSessions
> > exceeded
> > Jul 1 12:14:53 1999: INFO: Access rejected for usera: MaxSessions
> > exceeded
> > Jul 1 12:16:07 1999: INFO: Access rejected for usera: MaxSessions
> > exceeded
> > Jul 1 12:16:37 1999: INFO: Access rejected for usera: MaxSessions
> > exceeded
> > Jul 1 12:16:49 1999: INFO: Access rejected for usera: MaxSessions
> > exceeded
> >
> >
> > Any help welcome.
> >
> > Questions: How does radiator validate his internal session database with
> > the reality?
> >
> > How can I trigger radiator to show me his internal session
> > database?
> >
> > Regards
> > Charly
===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
