Hi
I have gone thru' the FAQs, and something still not clear to me. I have a
proxy radius server, which proxies the requests based on
usr_chassis_call_slot for the Hipers and called_station_id for the as5300.
On the proxy radius server config, there is no any check for Maxsessions. My
Hi,
I use radwho.cgi with SQL DB and was interested on the time online for
some users. Script does not sort properly clicking Time On link, so
I modified script as below. I'm yet to install 3.5, so I haven't checked
whether this is already ok.
# diff /sysadmin/Radiator-3.4/goodies/radwho.cgi
Yes. You shut put your most detailed match first and work down to more
generic ones.
-Original Message-
From: Tom Swenson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 04, 2003 12:14 PM
To: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Auth only on same realm
Just so I understand
Ok guys, Im trying to finish up my migration off of livingston radius.
Here is what I would like to do.
Currently in radiator I am authing users out of an SQL database.
Some of my users have Static IP address and Framed routes.
For these users I had entries in the Users File in livingston.
Hello Tom -
Yes. Handlers are evaluated in the order they appear in the
configuration file with the first match being the only match.
For completeness, you should be aware that mixing Realms and Handlers
in the same configuration file is not recommended, as Realms are
*always* evaluated
Hello -
You are correct, you can only query the NAS's and maintain a session
database from the level of the proxy server.
As you rightly point out, if you are receiving the requests from a
proxy, the only Client clause is for the proxy itself, not the NAS's.
regards
Hugh
On Tuesday, Feb
Hello William -
All of what you want to do is fairly straightforward, although dealing
with ISDN will probably involve the use of Handlers.
Here is what I would do:
# define AuthBy clauses
AuthBy SQL
Identifier CheckISDN
.
# set up AuthSelect for ISDN only
AuthSelect .
.
We are getting into compatibility problems with different Ascend NASes
from our providers, which requires us to run different AuthBy for each.
Since we use them with the same realms, what is the best way to
differentiate NASes? Rewrite realms to something weird like
realm.com-provider in the
Hi Hugh,
Thanks for the info. I was doing something similar with the
replaceProfiles hook you were using. I do have a question though.
Below in the AuthColumnDef you say Group-Id, request
Are you sure that is supposed to be request and not reply?
I don't get anything with using request when I
Hello William -
Yes I do mean request, which you can reference with:
$gid = $p-get_attr('Group-Id');
The reason for doing it this way (as described in my previous mail) is
because you then don't have to bother with any housekeeping as the
request packet is discarded automatically. You can
Hello Dan -
The best way to do this sort of thing is like this:
# define Client clauses
Client 1.1.1.1
Identifier Ascend-Type-A
.
/Client
Client 2.2.2.2
Identifier Ascend-Type-A
.
/Client
Client 3.3.3.3
Identifier Ascend-Type-B
.
/Client
Client 4.4.4.4
Identifier
Hugh Irvine wrote:
Hello Dan -
The best way to do this sort of thing is like this:
# define Client clauses
Client 1.1.1.1
Identifier Ascend-Type-A
.
/Client
Handler Client-Identifier = Ascend-Type-A
AuthBy Auth-Ascend-Type-A
..
/Handler
Ouch, I
Hello Dan -
The manual is available in several formats (PS, PDF, HTML) in the doc
directory.
I myself use doc/ref.html constantly.
regards
Hugh
On Wednesday, Feb 5, 2003, at 12:44 Australia/Melbourne, Dan Melomedman
wrote:
Hugh Irvine wrote:
Hello Dan -
The best way to do this sort of
13 matches
Mail list logo
