Hello Chairath -
You will need to make the same change that you made to the Radiator
configuration file in the Radmin file called Radmin/Sql.pm. You will either
need to change the file in the Radmin distribution directory and re-install,
or you can change the file in the Perl hierarchy
Hello Frank, Hello Anton -
The special accounting requests of Accounting-On and Accounting-Off are used
for this, as are a couple of other special cases.
Here is the relevant code from Handler.pm (sub handle_request):
if ($status_type eq 'Start')
{
# Some Ciscos dont
Hello Buck -
On Wed, 27 Feb 2002 11:22, buck lane wrote:
ok, i sent you the file, now i got a questoin to get radiator to talk to
a MS SQL server i have to get an ODBC driver manager ( unixODBC ) a ODBC
driver ( FreeTDS OOB ) and i need to install perl-DBi and DBD::ODBC so
radiator can talk
Recently I've been noticing that the Radius Accounting packets coming
from some of our Cisco gear has been sending some attributes in
duplicate; in particular, we get two copies each of User-Name and
Nas-Port.
Fortunately, the two copies have identical values. But it still causes a
problem. We
Follow up:
I did some more digging in the RFC:
Some attributes MAY be included more than once. The effect of this
is attribute specific, and is specified in each attribute
description.
5.13. Table of Attributes
The following table provides a guide to which attributes may be
I don't know about all of you, but my Radiator uses SNMP and it
querys the NAS to see if a user is still on.if they are not, it
removes them from RADONLINE and lets them connect. It doesn't detect
the NAS restarting, but it does query it with SNMP and sees that the
user is no longer
Hello Dave -
I'm glad I didn't have to point you to that section of the RFC.
:-)
The easy way to deal with the problem is with a PreClientHook to remove any
duplicate attributes.
You know where to find the examples (goodies/hooks.txt).
cheers
Hugh
On Fri, 1 Mar 2002 03:02, Dave
Hi,
I haveRewriteUsername s/^([^@]+).*/$1/ in my
radius.cfg file however domains don't appear to be stripped from users who
inadvertently login with their email address. I'm getting errors in the logfile
such as "Could not find a handler for username@domainname: request is
ignored"
Below
Title: Message
Guys... Im doing
some AUTHBYFILE combined with a AUTHBY RADIUS and I have a problem.. the
radius AUTHBY RADIproxying is returning an Idle-timeout and Session-Timeout
settings. but what I need is a way to override those and put in my own...
which are passed from a AUTHBY
Hello Barry -
The way your configuration file is set up, you will only get usernames of the
form user@auth in the Realm auth clause. If the username is of the form
[EMAIL PROTECTED], it will not go to the Realm auth clause, hence will
not get rewritten. The other Realm clause will only match
Hello Anton -
You should use the StripFromReply in the AuthBy RADIUS clause. If you are
concerned about reply attributes in general, you can explicitly specify the
list of attributes that you will accept from a proxy in an AllowInReply.
See section 6.17.7 in the Radiator 2.19 reference
Try naming the realm
DEFAULT. It looks at anything after the @ to determine the realm
name. So, if a customer logs in as [EMAIL PROTECTED], it is going to look for a realm
called Realm abc.com. By default, if Radiator finds no matches, it
will try to use Realm DEFAULT.
-Ronan
-
Ive tested that using the StripFromReply removes the idletimeout and
sessiontimeout attributes from the proxy but it also removes them from
the authby file after that Will the allowinreply do the same? Ir
just remove the ones on the proxy authby radius clause and then let any
attrbiute from
Hello Anton -
Please send me a copy of your configuration file (no secrets) together with a
trace 4 debug from Radiator showing what is happening.
thanks
Hugh
On Fri, 1 Mar 2002 16:42, Anton Krall wrote:
Ive tested that using the StripFromReply removes the idletimeout and
sessiontimeout
14 matches
Mail list logo
