(RADIATOR) How to refuse a call based on Called-Statio-ID (aka DNIS) on MAX TNT
Title: Message Hi Folks, This isn't a radiator specific question but should be of general interest: We have a need where in certain emergencies, we need to block/refuse/busy a call which is in-coming on our MAX TNT. We don't want the go through the process of having the RAS send a access-request to our Radiator process, and then we refuse the call based on the Called-Station-ID attribute. We want to do this as the call is in the process of establishing. Is there something in the MAX which allows this to be done? thanks, mahesh
RE: (RADIATOR) Xeon procs and session DB.
A technique we are experimenting with is to use a load balancer before the radiusd processes. We setup a dual proc system with two IP addresses. Then we run two radiusd processes where each process is bound to a one of the IP addresses. Then the load balancer (foundry server iron) is configured to load balance between the two IP addresses. However, since we can do port based load balancing, we direct ACCT to one I and AUTH to the other IP. By adding additional systems with a similar config, we can direct ACCT/AUTH to the different systems without having to modify any config files. mahesh -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 16, 2003 5:33 PM To: Wesley Hof Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) Xeon procs and session DB. Hello Wesley - The simplest way to make use of dual processors is to run two instances of radiusd, one for authentication and the other for accounting. You can use different databases for sessionDB and accounting by setting the DBSource lines in each clause appropriately. regards Hugh On 16/12/2003, at 10:23 PM, Wesley Hof wrote: Hi list, I have 2 questions. 1) Radiator is based on perl, so I suppose that dual-proc machines don't have any purpose ? What about a machine with a xeon proc ? 2) Is the sessionDB split-up from the accounting DB? Thanks. W. -- (o_ Wesley Hof //\ UNIX System Engineer V_/_ UNInet ))) A Scarlet Company === 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. NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. - CATool: Private Certificate Authority for Unix and Unix-like systems. === 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. === 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.
RE: (RADIATOR) NULL usernames in Radius Packets
Just a followup. We indeed were ignoring those types of packets since
we don't have a handler where username is NULL (we check based on
realms). So we added:
Handler
RejectHasReason
AuthBy INTERNAL
DefaultResult REJECT
AcctResult ACCEPT
/AuthBy
/Handler
And this seems to have helped. From what I can tell, others have also
had problems with TNT sending NULL usernames.
Thanks again,
mahesh
-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 10:27 PM
To: Mahesh Neelakanta
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) NULL usernames in Radius Packets
Hello Mahesh -
Yes it does look like the NAS has been trying to send this accounting
for a long time.
What does the trace 4 debug from Radiator show? Perhaps your
configuration file is not processing the request and it is simply being
being ignored and retried forever.
regards
Hugh
On Thursday, Oct 2, 2003, at 02:20 Australia/Melbourne, Mahesh
Neelakanta wrote:
Elias and Hugh,
Thanks for your responses. We had though about this but what we are
getting is a Start Accounting packet (captured from radstock):
NAS-IP-Address Len 6 XX.XX.XX.XX
NAS-Port-IdLen 6 111
NAS-Port-Type Len 6 Async
Acct-Status-Type Len 6 Start
Acct-Delay-TimeLen 6 75841
Acct-Session-IdLen 12 432625102*
Acct-Authentic Len 6 Local
Idle-Timeout Len 6 0
Ascend-Modem-PortNoLen 6 21
Ascend-Modem-SlotNoLen 6 7
Ascend-Modem-ShelfNo Len 6 1
Calling-Station-Id Len 12 2122859024
Called-Station-Id Len 6
What is strange is the Acct-Autentic (Local?) and the
Acct-Delay-Time (over 21 hours). We believe this is definitely a
local
RAS issue but are not sure what it could be. It's almost as if the RAS
has a HUGE backlog of old accounting which it is trying to re-send but
only sends a portion of the full information.
We did set acct-drop-stop-on-auth-fail = no to no avail.
mahesh
-Original Message-
From: Elias [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 11:10 PM
To: Mahesh Neelakanta
Cc: Hugh Irvine
Subject: Re: (RADIATOR) NULL usernames in Radius Packets
***
Your mail has been scanned by TMnet VirusWall.
***
Hi Mahesh,
We've had the same thing happen to us before. Its actually a
configuration
on the tnt boxes. If I remember correctly it will send an Stop
accounting
packet with a blank username if the line gets dropped prematurely
(before a
proper connection gets established).
- Elias -
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Mahesh Neelakanta [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 6:41 AM
Subject: Re: (RADIATOR) NULL usernames in Radius Packets
***
Your mail has been scanned by TMnet VirusWall.
***
Hello Mahesh -
Unless you are using a RewriteUsername, Radiator does not do anything
with the username. I suspect that the NAS is sending an empty
username,
but without seeing a copy of your configuration file (no secrets) and
a
trace 4 debug from Radiator showing what is happening it is not
possible to say any more.
regards
Hugh
On Wednesday, Oct 1, 2003, at 07:02 Australia/Melbourne, Mahesh
Neelakanta wrote:
Hello,
We are seeing the following error in radiator.log:
Tue Sep 30 16:56:20 2003: ERR: do failed for 'insert into RADONLINE
(USERNAME, NASIDENTIFIER, NASPORT,ACCTSESSIONID, TIMESTAMP,
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE,CALLERID,CLIENTPORTDNIS)
values ('', 'XX.XX.XX.XX', 01071,'432626086', to_date('30 09 2003
16:56:20', 'DD MM HH24:MI:SS'), '','Async',
'','2126823450','5000')': ORA-01400: cannot insert NULL into
(RADIUS.RADONLINE.USERNAME) (DBD ERROR: OCIStmtExecute)
From what we can tell, the RAS XX.XX.XX.XX is sending us start or
stop
packets with no username. Is there something in the configuration
(on
the radiator side or the ras, which is a lucent tnt) which could
cause
this. My guess is that it is a RAS issue but we are not sure
what/why
this is occuring.
mahesh
===
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.
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence
RE: (RADIATOR) NULL usernames in Radius Packets
Elias and Hugh,
Thanks for your responses. We had though about this but what we are
getting is a Start Accounting packet (captured from radstock):
NAS-IP-Address Len 6 XX.XX.XX.XX
NAS-Port-IdLen 6 111
NAS-Port-Type Len 6 Async
Acct-Status-Type Len 6 Start
Acct-Delay-TimeLen 6 75841
Acct-Session-IdLen 12 432625102*
Acct-Authentic Len 6 Local
Idle-Timeout Len 6 0
Ascend-Modem-PortNoLen 6 21
Ascend-Modem-SlotNoLen 6 7
Ascend-Modem-ShelfNo Len 6 1
Calling-Station-Id Len 12 2122859024
Called-Station-Id Len 6
What is strange is the Acct-Autentic (Local?) and the
Acct-Delay-Time (over 21 hours). We believe this is definitely a local
RAS issue but are not sure what it could be. It's almost as if the RAS
has a HUGE backlog of old accounting which it is trying to re-send but
only sends a portion of the full information.
We did set acct-drop-stop-on-auth-fail = no to no avail.
mahesh
-Original Message-
From: Elias [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 11:10 PM
To: Mahesh Neelakanta
Cc: Hugh Irvine
Subject: Re: (RADIATOR) NULL usernames in Radius Packets
***
Your mail has been scanned by TMnet VirusWall.
***
Hi Mahesh,
We've had the same thing happen to us before. Its actually a
configuration
on the tnt boxes. If I remember correctly it will send an Stop
accounting
packet with a blank username if the line gets dropped prematurely
(before a
proper connection gets established).
- Elias -
- Original Message -
From: Hugh Irvine [EMAIL PROTECTED]
To: Mahesh Neelakanta [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, October 01, 2003 6:41 AM
Subject: Re: (RADIATOR) NULL usernames in Radius Packets
***
Your mail has been scanned by TMnet VirusWall.
***
Hello Mahesh -
Unless you are using a RewriteUsername, Radiator does not do anything
with the username. I suspect that the NAS is sending an empty
username,
but without seeing a copy of your configuration file (no secrets) and
a
trace 4 debug from Radiator showing what is happening it is not
possible to say any more.
regards
Hugh
On Wednesday, Oct 1, 2003, at 07:02 Australia/Melbourne, Mahesh
Neelakanta wrote:
Hello,
We are seeing the following error in radiator.log:
Tue Sep 30 16:56:20 2003: ERR: do failed for 'insert into RADONLINE
(USERNAME, NASIDENTIFIER, NASPORT,ACCTSESSIONID, TIMESTAMP,
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE,CALLERID,CLIENTPORTDNIS)
values ('', 'XX.XX.XX.XX', 01071,'432626086', to_date('30 09 2003
16:56:20', 'DD MM HH24:MI:SS'), '','Async',
'','2126823450','5000')': ORA-01400: cannot insert NULL into
(RADIUS.RADONLINE.USERNAME) (DBD ERROR: OCIStmtExecute)
From what we can tell, the RAS XX.XX.XX.XX is sending us start or
stop
packets with no username. Is there something in the configuration
(on
the radiator side or the ras, which is a lucent tnt) which could
cause
this. My guess is that it is a RAS issue but we are not sure
what/why
this is occuring.
mahesh
===
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.
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, 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 [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
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.
(RADIATOR) NULL usernames in Radius Packets
Hello,
We are seeing the following error in radiator.log:
Tue Sep 30 16:56:20 2003: ERR: do failed for 'insert into RADONLINE
(USERNAME, NASIDENTIFIER, NASPORT,ACCTSESSIONID, TIMESTAMP,
FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE,CALLERID,CLIENTPORTDNIS)
values ('', 'XX.XX.XX.XX', 01071,'432626086', to_date('30 09 2003
16:56:20', 'DD MM HH24:MI:SS'), '','Async',
'','2126823450','5000')': ORA-01400: cannot insert NULL into
(RADIUS.RADONLINE.USERNAME) (DBD ERROR: OCIStmtExecute)
From what we can tell, the RAS XX.XX.XX.XX is sending us start or stop
packets with no username. Is there something in the configuration (on
the radiator side or the ras, which is a lucent tnt) which could cause
this. My guess is that it is a RAS issue but we are not sure what/why
this is occuring.
mahesh
===
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.
RE: (RADIATOR) AddToReply Usage
Thanks Hugh. Will this Reply-Message also match the %1 from the FailureFormat of the AuthLOG? The reason is that in our Radiator (2.19), %1 should print Request Denied but does not. mahesh -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED] Sent: Saturday, September 13, 2003 6:43 PM To: Mahesh Neelakanta Cc: [EMAIL PROTECTED] Subject: Re: (RADIATOR) AddToReply Usage Hello Mahesh - You can use the RejectHasReason in your Realm or Handler clause. See section 6.16.23 in the Radiator 3.6 reference manual (doc/ref.html). regards Hugh On Sunday, Sep 14, 2003, at 00:27 Australia/Melbourne, Mahesh Neelakanta wrote: Hello from Sunny South Florida, USA, I have a pretty simple question: We want to add the attribute Reply-Message only when we reject a connection. For example if we have a handler: AuthBy GROUP Identifier Test_Group AuthByPolicy ContinueUntilReject AuthBy Auth_1 AuthBy Radius_2 AuthBy File_1 AuthBy SQL_1 /AuthBy AuthBy FILE Identifier FILE_1 Filename %D/users.txt /AuthBy AuthBy RADIUS Identifier RADIUS_1 Host XX Secret X Retries 10 RetryTimeout 15 /AuthBy . . . In the RADIUS_1 or FILE_1 (or perhaps better still in Test_Group, I need to append Reply-Message only when we are going to reject the AUTH. Thanks, mahesh === 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. NB: have you included a copy of your configuration file (no secrets), together with a trace 4 debug showing what is happening? -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows, 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) AddToReply Usage
Hello from Sunny South Florida, USA, I have a pretty simple question: We want to add the attribute Reply-Message only when we reject a connection. For example if we have a handler: AuthBy GROUP Identifier Test_Group AuthByPolicy ContinueUntilReject AuthBy Auth_1 AuthBy Radius_2 AuthBy File_1 AuthBy SQL_1 /AuthBy AuthBy FILE Identifier FILE_1 Filename %D/users.txt /AuthBy AuthBy RADIUS Identifier RADIUS_1 Host XX Secret X Retries 10 RetryTimeout 15 /AuthBy . . . In the RADIUS_1 or FILE_1 (or perhaps better still in Test_Group, I need to append Reply-Message only when we are going to reject the AUTH. Thanks, mahesh === 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.
(RADIATOR) Default AuthLOG for all Handler's
Title: Message Is there a way to enable all handlers to usea single AuthLOG? I.e. we have many, many handlers and need to log success/failures to find out if we are failing authentications. However, we want to avoid having to code this into each handler. thanks, mahesh ps. quick dirty fixes are accepted :-)
RE: (RADIATOR) Default AuthLOG for all Handler's
Title: Message
Thanks
Hugh. This is what we started doing. However, having to put the "AuthLog
SQLAuthLog" into each handler would be too much (we have over 1000) to do by
hand. What I was hoping for is a "global" AuthLog entry which would do it for
all handlers, etc.
mahesh
-Original Message-From: Hugh Irvine
[mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 10:24
PMTo: Mahesh NeelakantaCc:
[EMAIL PROTECTED]Subject: Re: (RADIATOR) Default AuthLOG for all
Handler's
Hello Mahesh -
You can use an Identifier in your AuthLog clause, then refer to it as
follows:
AuthLog SQL
Identifier SQLAuthLog
.
/AuthLog
Handler
.
AuthLog SQLAuthLog
.
/Handler
See section 6.49 in the Radiator 3.6 reference manual ("doc/ref.html").
NB - this same technique can also be used with AuthBy clauses,
SessionDatabase clauses, etc.
regards
Hugh
On Wednesday, Aug 20, 2003, at 23:51 Australia/Melbourne, Mahesh
Neelakanta wrote:
Is there a way to enable all handlers to
usea single AuthLOG? I.e. we have many, many handlers and need to log
success/failures to find out if we are failing authentications. However, we
want to avoid having to code this into each handler.
thanks,
mahesh
ps. quick dirty fixes are accepted
:-)
NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
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.
