RE: (RADIATOR) SQL Accounting able to pick up a var from SQL subscribers table?

2002-01-16 Thread Frank Danielson

You could proabably use the Class attribute for this in your AUTH reply. The
NAS should send the Class attribute back in any accounting requests.

Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com


-Original Message-
From: Justin Scott [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 16, 2002 1:52 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) SQL Accounting able to pick up a var from SQL
subscribers table?


Hi guys,

I have another thing I'm trying to wrap my brain around here, that I can't
seem to figure out.

My client's reason for choosing Radiator is so that they can seamlessly
integrate it into their custom billing/accounting package (which is going
great!)

However, the billing system needs to have a CID (customer ID) associated
with everything for ease of report generation.

In my SUBSCRIBERS table, I have that CID listed with each individual user.
In the ACCOUNTING table, we also have one there.

However, since the Accounting table is generated by radius accounting, I
can't figure out a way to get that user's CID to propagate to each of their
records in the accounting table.

I first wondered if maybe I could send this information back to the NAS upon
replying to the AUTH request, and maybe the NAS could store and forward back
to the radius auth on radiator when accounting packets are handled.  I don't
think this will work, will it?

The other that I thought of was maybe to do an AcctSQLStatement before the
defs for the insert query, but how could I get the returned column for a
simple statement like:

select CID from SUBSCRIBERS where USERNAME = '%n'

Or similar into a variable that could then be passed back thru the
AcctColumnDefs into the accounting table?

Thanks for your help! :) 

Radiator is truly the most flexible package I have worked with in years.
The possibilities seem to be endless!  Keep up the great work!

cheers,
j
===
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) Session Database issues.

2002-01-17 Thread Frank Danielson

It looks like radpwtst is sending the default NAS-Port of 1234 for each
request. Since radiator sees the second call coming in on the same physical
port it assumes that the first session had to have ended. Change the
NAS-Port in the second test using the -nas_port parameter of radpwtst so it
looks like you  are putting up a second simultaneous call.

-Frank

-Original Message-
From: Griff Hamlin, III [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 17, 2002 2:03 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Session Database issues.


I am using Radiator 2.18.3 on AIX. I find that even though in my config
file I have DefaultSimultaneousUse 1 set, all users are still allowed
on. I use an SQL session database, and when I try tests using radpwtst I
find something peculiar.

I first run the following command:
/usr/local/Radiator-2.18/radpwtst -nostop -user=hamlin -password=
-auth_port=1645 -acct_port=1646 -calling_station_id 9095551212
-nas_ip_address 127.0.0.1

This gives me an accesss accept and place the user information into my
sql 'online' table. I purposely do not let radpwtst send a stop packet
so that the information will remain in the online table.

I then change the phone number (because I have a hook that checks for
it) and run the following command from radpwtst.
/usr/local/Radiator-2.18/radpwtst -noacct -user=hamlin -password=
-auth_port=1645 -acct_port=1646 -calling_station_id 9495551213
-nas_ip_address 127.0.0.1

Notice that now, I have changed it to -noacct since all I want is the
access reply.

Strangely enough, it is accepted! Yet I can see the row in the online
database. I get the following from the logfile on trace 4. This is the
access request after the user is already in the online sql database.

-logfile output 
*** Received from 127.0.0.1 port 46269 
Code:   Access-Request
Identifier: 17
Authentic:  1234567890123456
Attributes:
   User-Name = hamlin
   Service-Type = Framed-User
   NAS-IP-Address = 127.0.0.1
   NAS-Port = 1234
   Called-Station-Id = 123456789
   Calling-Station-Id = 9491234546
   NAS-Port-Type = Async
   User-Password =
207184f1542235p24618889160216}x153

Fri Jan 18 05:39:47 2002: INFO: Checking :hamlin: call-id :9491234546:
Fri Jan 18 05:39:47 2002: INFO: CallIDHook: returned row ---  'hamlin',
'9095551212'
Fri Jan 18 05:39:47 2002: DEBUG: Check if Handler Service-Type =
Call-Check should be used to handle this request
Fri Jan 18 05:39:47 2002: DEBUG: Check if Handler User-Name = admin
should be used to handle this request
Fri Jan 18 05:39:47 2002: DEBUG: Check if Handler
Request-Type=Accounting-Request should be used to handle this request
Fri Jan 18 05:39:47 2002: DEBUG: Check if Handler  should be used to
handle this request
Fri Jan 18 05:39:47 2002: DEBUG: Handling request with Handler ''
Fri Jan 18 05:39:47 2002: DEBUG: Rewrote user name to hamlin
Fri Jan 18 05:39:47 2002: DEBUG:  Deleting session for hamlin,
127.0.0.1, 1234   -### This seems odd to me
Fri Jan 18 05:39:47 2002: DEBUG: do query is: delete from online where
(nasidentifier='127.0.0.1')(nasport='1234')

Fri Jan 18 05:39:47 2002: DEBUG: Handling with Radius::AuthGROUP
Fri Jan 18 05:39:47 2002: DEBUG: Handling with Radius::AuthSQL
Fri Jan 18 05:39:47 2002: DEBUG: Handling with Radius::AuthSQL:
Fri Jan 18 05:39:47 2002: DEBUG: Query is: select check_items,
reply_items, case when (prepay='false') then
if(session_timeout,session_timeout,NULL) when
((prepay='true')(ISNULL(session_timeout))) then prepaid_timeleft when
((prepay='true')(!(ISNULL(session_timeout then
if(prepaid_timeleftsession_timeout,prepaid_timeleft,session_timeout)
end from users where (username='hamlin'  handler_group='defau')

Fri Jan 18 05:39:47 2002: DEBUG: Radius::AuthSQL looks for match with
hamlin
Fri Jan 18 05:39:47 2002: DEBUG: Query is: select username,
acctsessionid from online where username='hamlin'

Fri Jan 18 05:39:47 2002: DEBUG: Radius::AuthSQL ACCEPT:
Fri Jan 18 05:39:47 2002: DEBUG: Access accepted for hamlin
Fri Jan 18 05:39:47 2002::hamlin accepted from 127.0.0.1, called
123456789 from
9491234546
Fri Jan 18 05:39:47 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 46269 
Code:   Access-Accept
Identifier: 17
Authentic:  1234567890123456
Attributes:
   Framed-IP-Address = 255.255.255.254
   Framed-Routing = None
   Framed-Compression = Van-Jacobson-TCP-IP
   Framed-IP-Netmask = 255.255.255.255
   Idle-Timeout = 900
   Framed-Protocol = PPP
   Service-Type = Framed-User
--end logfile
output---

I have labelled the line above that seems strange to me. Why would it
delete the session from the online sql database before doing anything
else? I found the line in Handler.pm that does this and commented it
out. When I then tried this test, it works like a champ (It's line 257
in Handler.pm). Perhaps I am doing something wrong. My radius.cfg file
is as follows:

-- radius.cfg 

(RADIATOR) Long lived connection for AuthBy EXTERNAL?

2002-01-28 Thread Frank Danielson



We need to get 
authentication and send accounting data to an external system that we connect to 
via long-lived TCP connections. The only way I can think of to accomplish this 
is to create an intermediary server of sorts on the RADIUS server that maintains 
the connection to the external system and accepts requests from Radiator via 
hooks or AuthBy EXTERNAL. My concern is the overhead introduced by this and I'm 
hoping that I can do something like create a socket in a startup hook and pass 
it to a preauth hook later on.



Frank Danielson
[Infrastructure 
Architect]

wireless: 
407.467.7832
wireline: 407.515.8633

Data On Air
301 E. Pine St. 
Suite 450
Orlando, Fl 
32801
http://www.dataonair.com



RE: (RADIATOR) Graphing Individual Access Servers

2002-02-04 Thread Frank Danielson



If 
your NAS supports SNMP you could use MRTG to graph that dataor you could 
get SNMP data from Radiator. You could also generate graphs from the session 
data in the session database if you are using an SQL or DBM session 
database.

Take a 
look at section 6.14 in the manual for SNMP and radwho.cgi for the session 
database.




Frank Danielson
[Infrastructure 
Architect]

wireless: 
407.467.7832
wireline: 407.515.8633

Data On Air
301 E. Pine St. 
Suite 450
Orlando, Fl 
32801
http://www.dataonair.com



  -Original Message-From: Barry Andersson 
  [mailto:[EMAIL PROTECTED]]Sent: Monday, February 04, 2002 7:49 
  PMTo: [EMAIL PROTECTED]Subject: (RADIATOR) Graphing 
  Individual Access Servers
  Hi,
  
  Is it possible to use mrtg or some other graphing 
  utility to graph the total number of current users on any individual access 
  server or selectedgroup of access servers?
  
  Barry Andersson
  


(RADIATOR) Changing User-Name in hook

2002-02-22 Thread Frank Danielson



Hi-

We're trying to use 
Radiator to authenticate dialup users using the Calling-Station-Id instead of 
the User-Name. All of the users dial in using the same name and password so I 
want to use a hook to put the value of the Calling-Station-Id attribute into the 
User-Name attribute. It seems easy enough and the simple hook I wrote thinks 
that it is working but the user is still being logged in the session database 
and authenticated using the original User-Name value. Is there something I'm 
missing or is this just not possible for some reason?

Config file 
snippet:

PreClientHook sub 
{\my $p = ${$_[0]};\my 
$dnis=$p-get_attr('Called-Station-Id');\$dnis =~ 
s/\D//g;\$p-change_attr('Called-Station-Id',$dnis);\main::log($main::LOG_DEBUG,"Dnis:$dnis, 
");\if ($dnis eq "777") {\my $p = 
${$_[0]};\my 
$min=$p-get_attr('Calling-Station-Id');\my 
$olduser=$p-get_attr('User-Name');\$p-change_attr('User-Name',$min);\my 
$newuser=$p-get_attr('User-Name');\main::log($main::LOG_DEBUG,"Min:$min, 
OldUser:$olduser NewUser:$newuser\n");\}\}

Trace 4 
Debug:

*** Received from 10.1.10.6 port 1818 
Code: 
Access-RequestIdentifier: 184Authentic: 
1234567890123456Attributes: 
User-Name = "qnc" Service-Type = 
Framed-User NAS-IP-Address = 
203.63.154.1 NAS-Port = 
1234 Called-Station-Id = 
"#777" Calling-Station-Id = 
"987654321" NAS-Port-Type = 
Async User-Password = 
"136229173175\424618889160216}x153"

Fri Feb 22 13:15:25 2002: DEBUG: Dnis:777,Fri 
Feb 22 13:15:25 2002: DEBUG: Min:987654321, OldUser:qnc 
NewUser:987654321

Fri Feb 22 13:15:25 2002: DEBUG: Check if Handler 
Called-Station-Id=777 should be used to handle this requestFri Feb 22 13:15:25 2002: DEBUG: 
Handling request with Handler 'Called-Station-Id=777'Fri Feb 22 13:15:25 
2002: DEBUG: SDB1 Deleting session for qnc, 203.63.154.1, 1234Fri Feb 22 
13:15:25 2002: DEBUG: Handling with AuthINTERNAL:Fri Feb 22 13:15:25 2002: 
DEBUG: Access accepted for qncFri Feb 22 13:15:25 2002: DEBUG: Packet 
dump:*** Sending to 10.1.10.6 port 1818 
Code: Access-AcceptIdentifier: 
184Authentic: 1234567890123456Attributes:



Frank Danielson
[Infrastructure 
Architect]

wireless: 
407.467.7832
wireline: 407.515.8633

Data On Air
301 E. Pine St. 
Suite 450
Orlando, Fl 
32801
http://www.dataonair.com



RE: (RADIATOR) Changing User-Name in hook

2002-02-22 Thread Frank Danielson

We're authenticating and accounting for calls made by cellular phones to a 
3Com NAS. The phones are preprogrammed to all dial a certain number (#777) and 
all use the same user name and password. I had originally planned to 
authenticate from the Calling-Station-Id but the problem I ran into was that 
other funtions such as the session database and session limit checking use the 
User-Name attribute. We will be having some other users dialing in with unique 
names and passwords that will be authenticated normally so it seemd to make 
much more sense to do the User-Name translation in the beginning than worry 
about all of the other places where I may need to decide whether to use the 
User-Name or Calling-Station-Id.
 After a little bit of poking around I found that Radiator stores the original 
user name so even if you change the User-Name attribute in a hook, the 
original user name is used for later authentication and session-limit 
checking. Modifiying the OriginalUserName attribute fixed my problem although 
I'm sure there was a reason for keeping the original copy of it that I may not 
be aware of.

= Original Message From [EMAIL PROTECTED] =
Hello Frank -

You would usually just use the Calling-Station-Id attribute directly, and
provide an AuthSelect statement in the AuthBy SQL clause (assuming you are
using an SQL database).

Perhaps you could describe you requirements in  more detail?

regards

Hugh


On Sat, 23 Feb 2002 05:30, Frank Danielson wrote:
 Hi-

 We're trying to use Radiator to authenticate dialup users using the
 Calling-Station-Id instead of the User-Name. All of the users dial in using
 the same name and password so I want to use a hook to put the value of the
 Calling-Station-Id attribute into the User-Name attribute. It seems easy
 enough and the simple hook I wrote thinks that it is working but the user
 is still being logged in the session database and authenticated using the
 original User-Name value. Is there something I'm missing or is this just
 not possible for some reason?

 Config file snippet:

 PreClientHook sub {\
  my $p = ${$_[0]};\
  my $dnis=$p-get_attr('Called-Station-Id');\
  $dnis =~ s/\D//g;\
  $p-change_attr('Called-Station-Id',$dnis);\
  main::log($main::LOG_DEBUG,Dnis:$dnis, );\
  if ($dnis eq 777) {\
   my $p = ${$_[0]};\
   my $min=$p-get_attr('Calling-Station-Id');\
   my $olduser=$p-get_attr('User-Name');\
   $p-change_attr('User-Name',$min);\
   my $newuser=$p-get_attr('User-Name');\
   main::log($main::LOG_DEBUG,Min:$min, OldUser:$olduser
 NewUser:$newuser\n);\
  }\
 }

 Trace 4 Debug:

 *** Received from 10.1.10.6 port 1818 
 Code:   Access-Request
 Identifier: 184
 Authentic:  1234567890123456
 Attributes:
 User-Name = qnc
 Service-Type = Framed-User
 NAS-IP-Address = 203.63.154.1
 NAS-Port = 1234
 Called-Station-Id = #777
 Calling-Station-Id = 987654321
 NAS-Port-Type = Async
 User-Password =
 136229173175\424618889160216}x153

 

 Fri Feb 22 13:15:25 2002: DEBUG: Dnis:777,
 Fri Feb 22 13:15:25 2002: DEBUG: Min:987654321, OldUser:qnc
 NewUser:987654321

 Fri Feb 22 13:15:25 2002: DEBUG: Check if Handler Called-Station-Id=777
 should be used to handle this request
 Fri Feb 22 13:15:25 2002: DEBUG: Handling request with Handler
 'Called-Station-Id=777'
 Fri Feb 22 13:15:25 2002: DEBUG: SDB1 Deleting session for qnc,
 203.63.154.1, 1234
 Fri Feb 22 13:15:25 2002: DEBUG: Handling with AuthINTERNAL:
 Fri Feb 22 13:15:25 2002: DEBUG: Access accepted for qnc
 Fri Feb 22 13:15:25 2002: DEBUG: Packet dump:
 *** Sending to 10.1.10.6 port 1818 
 Code:   Access-Accept
 Identifier: 184
 Authentic:  1234567890123456
 Attributes:

 Frank Danielson
 [Infrastructure Architect]

 wireless: 407.467.7832
 wireline: 407.515.8633

 Data On Air
 301 E. Pine St. Suite 450
 Orlando, Fl 32801
 http://www.dataonair.com http://www.dataonair.com/

--
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.

===
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) Radonline flushing every 2 hours

2002-02-26 Thread Frank Danielson

Hugh-

For general education purposes could you elaborate on Radiator clearing
entries for a NAS if it sees a NAS restart? I'm not sure how Radiator would
detect that event and if some certain Client config is needed support this.

Thanks.

-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 26, 2002 5:33 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Radonline flushing every 2 hours



Hello Anton -

Please send me a copy of your configuration file (no secrets) together with
a 
trace 4 debug showing what is happening.

Radiator will automatically remove all entries for a NAS if it sees a NAS 
restart, but I can't think of any reason why the entire RADONLINE table
would 
be cleared.

regards

Hugh


On Wed, 27 Feb 2002 08:45, Anton Krall wrote:
 Guys.. Im having problems with my radonline table on mysql.. Seems that
 every 2 hours.. The ocntents flush and start from 0... Anybody has any
 problems like this?

 I noticed this because Im graphing the radonline total user count every
 5 minute from MRTG, and I noticed that every 2 hours.. The database
 flushes and the graph on MRTG looks funny... Like restarted from 0 every
 2 hours..

 Anybody has any ideas?

 Saludos

 Anton Krall
 Director de Tecnología
 Inter.net México / Panamá

 Tel; 5241-7609 Directo
 Tel: 5241-7600 Conmutador
 Celular: 0445-105-5160 Mobile
 ICQ: 4979450
 email:  [EMAIL PROTECTED]
 web: http://www.mx.inter.net

 Outside Mexico:
 Office: +52(555)241-7609
 PBX: +52(555)241-7600
 Mobile: +52(555)105-5160

 ===
 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: 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.
===
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) RE: Reject access from specific Calling-Station-Id

2002-03-01 Thread Frank Danielson

If you want to block access for all users when that combination of
Calling-Station-Id and Called-Station-Id is used, why not do it in a
handler?

Handler Calling-Station-Id = /^555/, Called-Station-Id = /111/
AuthBy INTERNAL
AuthResult  REJECT
AcctStartResult ACCEPT
AcctStopResult  ACCEPT
DefaultResult   REJECT
/AuthBy
AcctLogFileName /var/log/radacct/detail
/Handler

Just put this before your other handlers so it will match first, see Section
6.16 in the manual for more info. 

Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com


-Original Message-
From: William Hernandez [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 01, 2002 8:28 AM
To: Radiator (Radiator)
Subject: (RADIATOR) RE: Reject access from specific Calling-Station-Id


Hello everyone,

I haven't gotten any closer on this. Does anyone have any suggestions?

Thanks in advance,
William

-Original Message-
From: William Hernandez [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, February 20, 2002 11:34 AM
To: Radiator (Radiator)
Subject: RE: Reject access from specific Calling-Station-Id


Hello everyone,

I think I'm getting closer. I changed blockcli.prw to:
username Calling-Station-Id = /^555/, Called-Station-Id = /111/,
Auth-Type = Reject: Calling station not valid for 111

DEFAULT Auth-Type=Accept

And in radius.cfg I changed ContinueWhileAccept to ContinueUntilReject.

# radpwtst -trace -s www -user username -password password -auth_port
1812 -acct_port 1813 -secret secret -dictionary
/etc/raddb/dictionary.prw Calling-Station-Id=555
Called-Station-Id=111 sending Access-Request... Rejected
Reply-Message = Request Denied
sending Accounting-Request Start...
OK
sending Accounting-Request Stop...
OK
#

/var/log/radius.log:
Wed Feb 20 10:56:57 2002: INFO: Access rejected for username:  Calling
station not valid for 111

# radpwtst -trace -s www -user username -password password -auth_port
1812 -acct_port 1813 -secret secret -dictionary
/etc/raddb/dictionary.prw Calling-Station-Id=333
Called-Station-Id=111 sending Access-Request... OK
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.255
Framed-Compression = Van-Jacobson-TCP-IP
Ascend-Idle-Limit = 1200
Idle-Timeout = 1200
Session-Timeout = 41580
Class = xstop: A, R ANAR CHAT CRIMI DRUGS GAMB HATE OBSC PORN
RRATED I, 1
Ascend-IP-Direct = 10.10.10.10
VPN-Neighbor = 10.10.10.10
sending Accounting-Request Start...
OK
sending Accounting-Request Stop...
OK

It seems to work, but it means that I have to define all my users in the
users file. Is there an easier way?

Thanks in advance,
William

-Original Message-
From: William Hernandez 
Sent: Monday, February 18, 2002 9:38 AM
To: Radiator (Radiator)
Subject: Reject access from specific Calling-Station-Id


Hello everyone,

We're trying to configure Radiator 2.18.2 to reject access to a specific
Called-Station-Id when the Calling-Station-Id is in a specific range
using various ideas picked up from the archives, but the following is
not working for us.

# radpwtst -trace -s www -user username -password password -auth_port
1812 -acct_port 1813 -secret secret -dictionary
/etc/raddb/dictionary.prw Calling-Station-Id=555
Called-Station-Id=111 sending Access-Request... OK
Service-Type = Framed-User
Framed-Protocol = PPP
Framed-IP-Netmask = 255.255.255.255
Framed-Compression = Van-Jacobson-TCP-IP
Ascend-Idle-Limit = 1200
Idle-Timeout = 1200
Session-Timeout = 49920
Class = xstop: A, R ANAR CHAT CRIMI DRUGS GAMB HATE OBSC PORN
RRATED I, 1
Ascend-IP-Direct = 10.10.10.10
VPN-Neighbor = 10.10.10.10
sending Accounting-Request Start...
OK
sending Accounting-Request Stop...
OK

Regards,
William
-- radius.cfg

...
AuthBy FILE
Identifier Check-CLI
AcceptIfMissing
Filename /etc/raddb/blockcli.prw
/AuthBy
...
Handler
SessionDatabase prw-sessiondb

AuthByPolicy ContinueWhileAccept
AuthBy Check-CLI
AuthBy Check-FILE
AuthBy System

PostAuthHook file:/etc/raddb/postauthhook.prw file:

AcctLogFileName /var/log/radacct/detail
PasswordLogFileName /var/log/radius.log
ExcludeFromPasswordLog  root
/Handler
...
-- End of radius.cfg
-

-- blockcli.prw

DEFAULT Calling-Station-Id = /^555/, \
Called-Station-Id = /111/, \
Auth-Type = Reject: Calling station not valid for 111

-- End of blockcli.prw

RE: (RADIATOR) Exactly the Opposite

2002-03-07 Thread Frank Danielson

If I understand section 13.1.6 of the manual correctly you could add a check 
item of Auth-Type = Reject for the users in the DBFILE or if all of the users 
in that database are to be rejected, just put the check item for the DEFAULT 
user.

= Original Message From Jon Snyder [EMAIL PROTECTED] =
Anyone know of a simple way I might have overlooked to invert the sense of
an AuthBy?

AcceptIfMissing is part of this, but what I'm after is more of
RejectIfFound--I want to reject users if they are in a DBFILE.  I have
hacked this by putting a bogus User-Password into the dbm and using
AcceptIfMissing, but it would be nice if there were a way to have an AuthBy
do everything it was going to do, then have a keyword to swap ACCEPT and
REJECT when it was finished.

___
Jon Snyder
Computing  Networking Services
Portland State University

===
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) Ascend-Access-Event-Request.

2002-04-12 Thread Frank Danielson
]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Frank Danielson
[Infrastructure Architect]

wireless:407.467.7832
fax:407.515.9001

Data On Air
301 E. Pine St. Suite 450
Orlando, FL 32801
USA

===
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) AuthBy SQLRADIUS accounting to a database

2002-04-29 Thread Frank Danielson

AuthBy SQLRADIUS proxies requests to other RADIUS servers and doesn't do any 
accounting explicitly. When the docs say it understands the parameters of 
AuthBy SQL they are referring to the parameters that define the connectivity 
to the database. If yout want to do accounting you can add an AuthBy SQL 
clause to your handler to do the accounting.

= Original Message From [EMAIL PROTECTED] =
Though the documention says that AuthBy SQLRADIUS understands all the
parameters that AuthBy SQL and AuthBy RADIUS understand, it seems i cant
have accounting records to an SQL database at that levelis that the
case?


Rgds
TDN


===
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) AuthBy SQL and / or AuthLog SQL

2002-05-13 Thread Frank Danielson

AuthLog SQL records access-requests to a database.
AuthBy SQL w /an empty AuthSelect records accounting-requests to a database.

-Frank

-Original Message-
From: radiator [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 14, 2002 12:06 AM
To: '[EMAIL PROTECTED]'
Subject: (RADIATOR) AuthBy SQL and / or AuthLog SQL



What's the difference between AuthBy SQL w/ and empty AuthSelect and AuthLog
SQL??


Regards,

Virgil

-- 
WebCentral Pty Ltd   Australia's #1 Internet Web Hosting Company
Level 5, 100 Wickham St.   Network Operations - Systems Engineer
PO Box 930, Fortitude Valley.email: [EMAIL PROTECTED]
Queensland, Australia 4006.   phone: +61 7 3230 7176 
 
===
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) AcctColumnDef for MySQL datetime type

2002-06-03 Thread Frank Danielson

You could use the built in MySQL function FROM_UNIXTIME() in your INSERT
statement to convert from a unix timestamp to the datetime format.

-Original Message-
From: Viraj Alankar [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 03, 2002 1:57 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) AcctColumnDef for MySQL datetime type


Hello,

What would be the proper way to insert the Timestamp from accounting into a
MySQL datetime field? Basically it requires format of '-00-00 00:00:00'
but I cannot seem to figure out how to do this with the date formatting.
There
is no format specifier for month with preceeding 0.

Viraj.
===
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) User auths if in the users file only?

2002-07-10 Thread Frank Danielson

You could use identifiers in your client clauses like so-

Client 1.2.3.4
Identifier noip
/Client

Client 1.2.3.5
Identifier send254
/Client

Client 1.2.4.6
Identifier noip
/Client

Client 1.2.3.7
Identifier send254
/Client

Handler Client-Identifier=noip
Do auth and send no Framed-IP-Address
/Handler

Handler Client-Identifier=send254
Do auth and send 255.255.255.254
/Handler

-Original Message-
From: chris [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 10, 2002 12:32 PM
To: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) User auths if in the users file only?



 This was where the problem was.thier setup did not follow this
standard
 and was trying to
 assign 255.255.255.254 as the IP *sigh*

This leads me to a questions. I have a mix of nas servers that I need to use
on the same radius
server. One needs the Framed-IP-Address = 255.255.255.254  attribute and one
needs *nothing*
sent.

I have each nas setup seperate in client clauses. How can I choose to send
the attribute out to only the nas servers that need it?

 -Chris

===
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) Cisco, non-unique NAS-Ports, clobbering Online DB

2002-07-10 Thread Frank Danielson
Title: Cisco, non-unique NAS-Ports, clobbering Online DB



How about handling it with a preclient 
hook in the client clauseto strip the number you want out of the 
Cisco-NAS-Port attribute and stuff it into the NAS-Port 
attribute.

  -Original Message-From: Dave Kitabjian 
  [mailto:[EMAIL PROTECTED]]Sent: Wednesday, July 10, 2002 5:25 
  PMTo: [EMAIL PROTECTED]Subject: (RADIATOR) Cisco, 
  non-unique NAS-Ports, clobbering Online DB
  I finally tracked down the reason 
  why our Online DB has been reporting a much lower count of onliners than are 
  actually online.
  Look at the attached sequence of 
  two accounting records. tmeyers logs on to NAS 216.118.66.25 and 
  Port 105. 
  Then, 3 minutes later, while he's still online, cheezwhiz logs off of the same 
  NAS and Port, clobbering tmeyers' entry in the online DB. 
  But how can two people have been 
  on the same port at the same time, you ask? The answer is that when Cisco is 
  (again) lazy, it's easy to happen. If you look at the Cisco-NAS-Port 
  attribute, you'll see that they are really on two distinct ports. Cisco is 
  just taking a portion of the info and plopping it in NAS-Port, even though 
  that means that many people can be on the same NAS-Port at once. Most 
  manufacturers come up with a procedure for encoding all that 
  "Async4/105*Serial7/0:25:3" stuff 
  into some unique, numeric port number and then put that in NAS-Port. 
  
  Now, if we were enforcing 
  concurrency limits we'd be even more screwed. 
  Has anyone else experienced this? 
  How are you dealing with it? Does Radiator have any solutions? I wonder if 
  using the Acct-Session-Id for deletions would be more reliable than matching 
  NAS/Port combos. Comments welcome!
  Dave _ 
  
  Wed Jul 10 15:23:21 2002: DEBUG: 
  Packet dump: *** 
  Received from 216.118.66.25 port 1646  Code: 
  Accounting-Request Identifier: 188 Authentic: 
  218232t199j16323413827251221133HsX142 
  Attributes: 
   Acct-Session-Id = 
  "87C2"  Framed-Protocol = 
  PPP  Connect-Info = "46667/24000 
  V90/V42bis/LAPM"  cisco-avpair = 
  "connect-progress=Call Up"  Acct-Authentic = 
  RADIUS  Acct-Status-Type = 
  Start  User-Name = 
  "tmeyers"  
  Acct-Multi-Session-Id = "511D"  Acct-Link-Count = 
  "0002"  
  Framed-Address = 216.118.88.4  Cisco-NAS-Port = 
  "Async4/105*Serial7/0:25:3"  NAS-Port = 105  NAS-Port-Type = 
  Async  Class = 
  "netcarrier.com"  Service-Type = 
  Framed-User  NAS-IP-Address = 216.118.66.25  
  Event-Timestamp = 1026329001  Acct-Delay-Time = 
  0 
  Wed Jul 10 15:26:16 2002: DEBUG: 
  Packet dump: *** 
  Received from 216.118.66.25 port 1646  Code: 
  Accounting-Request Identifier: 239 Authentic: 
  30u2264138177143248254:165d182200? 
  Attributes: 
   Acct-Session-Id = 
  "84AB"  Framed-Protocol = 
  PPP  cisco-avpair = 
  "connect-progress=Call Up"  Acct-Session-Time = 
  2897  Connect-Info = "49333/24000 
  V90/V42bis/LAPM"  Acct-Input-Octets = 
  349671  Acct-Output-Octets = 
  2362531  Acct-Input-Packets = 
  3246  Acct-Output-Packets = 
  2835  Acct-Terminate-Cause = 
  User-Request  cisco-avpair = 
  "disc-cause-ext=PPP Receive Term"  Acct-Authentic = 
  RADIUS  Acct-Status-Type = 
  Stop  User-Name = 
  "cheezwhiz"  Acct-Multi-Session-Id = 
  "4F51"  Acct-Link-Count = 
  "0001"  
  Framed-Address = 216.118.90.220  Cisco-NAS-Port = 
  "Async3/105*Serial7/0:18:21"  NAS-Port = 
  105  NAS-Port-Type = 
  Async  Class = 
  "netcarrier.com"  Service-Type = 
  Framed-User  NAS-IP-Address = 216.118.66.25  
  Event-Timestamp = 1026329176  Acct-Delay-Time = 
  0 


RE: (RADIATOR) 'Drop' Intermin-Accounting

2002-07-18 Thread Frank Danielson



A 
simple way around it would be to use a handler that accepts the 
Interim-Accounting requests and then another Handler to proxy the rest. We are 
using this on a production system for similar purposes.

Handler 
Acct-Status-Type=AliveAuthBy 
INTERNALDefaultResult 
ACCEPT/AuthBy/Handler

Handler
AuthBy RADIUS
 
AuthBy Stuff
/AuthBy
/Handler

  -Original Message-From: Steve Rogers 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 18, 2002 10:30 
  AMTo: [EMAIL PROTECTED]Subject: (RADIATOR) 'Drop' 
  Intermin-Accounting
  Hi,
  
  One of our dial 
  providers is sending Interim-Accounting to Radiator, which in turn is proxied 
  to another Radiusserver to perform authentication. We need to 'drop' 
  these Interim-Accounting updates from Radiator so they are not seen by the 
  authenticating radius server.
  
  Has anyone done 
  this already? Do we need to write a handler to achieve 
  this?
  
  Thanks
  Steve


RE: (RADIATOR) vendor 2937, attributes 22/23 ?

2002-08-01 Thread Frank Danielson

According to the IANA website
http://www.iana.org/assignments/enterprise-numbers, 2937 is the enterprise
number for Deutsche Telekom AG. Maybe you could ask whoever is proxying
those requests to you to send you a copy of thier dictionary?

Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com


-Original Message-
From: Kurt Jaeger [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 01, 2002 12:11 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) vendor 2937, attributes 22/23 ?


Hi!

Anyone has a dictionary for vendor 2937 ? I don't even know what
vendor that is, I receive them over some proxy link 8-(

Thu Aug  1 17:54:49 2002: ERR: Attribute number 22 (vendor 2937) is not
defined in your dictionary
Thu Aug  1 17:54:49 2002: ERR: Attribute number 23 (vendor 2937) is not
defined in your dictionary

-- 
MfG/Best regards, Kurt Jaeger  18 years to
go !
LF.net GmbH   [EMAIL PROTECTED]Oberon.net GmbH[EMAIL PROTECTED]
Ruppmannstr. 27   fon +49 711 90074-23 Georg-Glock-Str. 8 mob +49 171
3101372
D-70565 Stuttgart fax +49 711 90074-33 40474 Duesseldorf  fon +49 211
179253-11
===
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) Radiator AS a Proxy?

2002-08-14 Thread Frank Danielson

You could set up an AuthBy RADIUS clause to point to your customer's RADIUS
server and then add and Auth-Type check item to those users in you users
file to database to force them to authenticate using the AuthBy RADIUS. In
the 2.19 manual section 13.1.6 explains the use of the Auth-Type check item.
AuthBy RADIUS is also well documented in the manual and has been discussed
in length on the mailing list.

Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 14, 2002 9:06 AM
To: Skeeve Stevens
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Radiator AS a Proxy?


On Wed, 14 Aug 2002, Skeeve Stevens wrote:

 Is it possible to use Radiator as a Proxy Radius?
 
 We have a customer who wants to be able to authenticate their own dialup
 users... so they can keep control of the passwords.  
 
 I am not completely against this, but would like to let them only
 authenticate users that we have approved 

Radiator can do this, but in a typical proxy radius setup, you would have 
this customer's users dial in as [EMAIL PROTECTED] (whatever their 
domain is) and you would pass these requests on to their radius server(s).  
You can (and should) strip and add certain attributes to their radius 
replies...but I'm not sure how you would handle proxy radius and approving 
or denying access for certain users.  If you want to do that, what's the 
point in proxying the authentication?
 
--
 Jon Lewis *[EMAIL PROTECTED]*|  I route
 System Administrator|  therefore you are
 Atlantic Net|  
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

===
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) Determine IP address request came to

2002-08-26 Thread Frank Danielson

I don't think there is a way to tell inside of Radiator. You can run
multiple instances of Radiator with each one bound to a different address
using the BindAddress config parameter. This will also give you the
advantage of being able to handle more traffic since you will have multiple
threads running.

-Original Message-
From: Timothy G. Wells [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 25, 2002 8:29 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Determine IP address request came to


Greetings,

Has there been anything added to radiator to allow me to determine which IP 
a request came into radiator with? This is needed for a server with 
multiple IP's and one radiator process binding to all addresses.

I brought this up maybe a year ago but no such attribute existed. I think 
it would be very helpful in general.

Thanks,

-- Tim


-- 
This message has been scanned for viruses and
dangerous content by IntelliBlock MailScanner (www.intelliblock.net), and is
believed to be clean.

===
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) Client Statements

2002-08-30 Thread Frank Danielson

Yes, it's quite handy.

-Original Message-
From: Listuser [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 30, 2002 8:54 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Client Statements


Hey Folks,

Just wondering if it is possible to have multiple Client statments with the 
same Identifier as below:

Client X.X.X.X
 Secret XX
 Identifier client-hello
/Client

Client X.X.X.Y
 Secret YYY
 Identifier client-hello
/Client

Thanks in advance,
Art

===
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) users database format

2002-09-20 Thread Frank Danielson

Why not use an AddToReply in your Client clause for this NAS? See section
6.5.18 in the manual.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 20, 2002 10:26 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) users database format


Hello,

I have a flat file users database, which has the format below:

user1  Password = {crypt}*
Framed-Protocol=PPP

The configuration of  one of our new Nases requres that the users database
be of this format:

user1  Password = {crypt}*
Service-Type = Framed-User,
Framed-Protocol=PPP

How can achieve this without having to change each and every entry i.e, set
Service-Type = Framed-User as a default entry.


Rgds
TDN

===
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) Radius Client Java API

2002-09-22 Thread Frank Danielson

http://www.theorem.com/java/

= Original Message From MURUGAN V V [EMAIL PROTECTED] =
hi,

anybody knows about any Java API for implementing a Radius Client.

any body is using Radiator in Japan.

Regards,
Murugan
===
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.

Frank Danielson
[Infrastructure Architect]

wireless:407.467.7832
fax:407.515.9001

Data On Air
301 E. Pine St. Suite 450
Orlando, FL 32801
USA

===
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) Radius Client Java API

2002-09-22 Thread Frank Danielson

http://jradius-client.sourceforge.net/

= Original Message From MURUGAN V V [EMAIL PROTECTED] =
hi,

anybody knows about any Java API for implementing a Radius Client.

any body is using Radiator in Japan.

Regards,
Murugan
===
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) Add IP from SQL table to AuthBy Radius Reply packet

2002-10-23 Thread Frank Danielson
You can call your AuthBy SQL from a ReplyHook making the whole thing easier
than you might think. Examples are in goodies/hooks.txt.

-Original Message-
From: [EMAIL PROTECTED] [mailto:alexander.deboer;kpn.com]
Sent: Wednesday, October 23, 2002 11:59 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Add IP from SQL table to AuthBy Radius Reply packet


Hi all, 

I'm trying to solve the following problem. Our radiator proxies
authentication requests. Upon receiving the response from the remote radius
server, we want to add an user-specific IP-address from our own SQL table.
I'm considering the following approach:

AuthBy Group
Identifier proxy
AuthByPolicy ContinueWhileAccept
AuthBy Radius
Host ...

/AuthBy
AuthBy SQL
DBSource dbi:mysql:radius
DBUsername ...
DBAuth ...
AuthSelect select ipaddress from tblAccess where
username='%u'   
AuthColumnDef 0, GENERIC, reply
/AuthBy
/AuthBy

However, due to the asynchronous behavior of AuthBy Radius this won't work.
See also: 
http://www.open.com.au/archives/radiator/2001-04/msg00192.html
http://www.open.com.au/archives/radiator/2002-08/msg00107.html
I'm a bit reluctant to use the Synchronous parameter, since we cannot really
trust the remote radius server.

Another solution could be using a ReplyHook. However, this seems a bit
cumbersome to me; writing a failure-back-off-fall-back procedure to multiple
SQL-servers myself, while it is so nicely implemented in Radiators AuthBy
SQL.

Does anybody has a suggestion to overcome this problem?

Cheers,
Alexander
 
 dr.  Alexander P. de Boer
 KPN Royal Dutch Telecom
 Room L C7, P.O.Box 421, 2260 AK Leidschendam
 The Netherlands
 
===
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) Attribute not found

2002-12-03 Thread Frank Danielson
According to the Cisco docs at
http://www.cisco.com/univercd/cc/td/doc/product/access/acs_soft/csacs4nt/csn
t2/ap_rads.htm atrribute 151 is Ascend-Session-Svr-Key, it should also be in
the dictionary.ascend file that came with the Radiator distribution. So your
dictionary should have a line in it that looks like this-

ATTRIBUTE   Ascend-Session-svr-Key  151 string

Just stick it in with the other attributes and restart radiator to make it
take effect.

Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com

-Original Message-
From: Tom Swenson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 03, 2002 11:04 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Attribute not found


I'm faily new to Radiator but have it running locally. I am going to
wholesale dialup and during testing I'm getting:

ERR: Attribute number 151 is not defined in your dictionary

This is coming from a Cisco RAS.

I have a number 151's in my dictionary file, but apparently they aren't
the correct one. I looked in the dictionary.cisco, but there are no 151's
in there. 

I'm not sure what to do next. I haven't messed with the dictionary files
before with Radiator or with Cistron which I was using for years before
this. Can someone help me? I don't want a million error messages in my log
file.


Tom Swenson
NetConX - Internet Access - Client Managed Web Database Applications
Wireless - Virus Blocking - Spam Blocking
[EMAIL PROTECTED]
http://www.netconx.net
(641) 421-4170 - Voice  (641) 423-3351 - FAX




===
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) EAPOL authentication for LANs

2002-12-11 Thread Frank Danielson
The Cisco PIX firewall has the option to do RADIUS authentication before
allowing a TCP session to set up for a certain protocol. For example, if you
wanted to control who was able to Telnet into your network through the
firewall you could configure the PIX to check with your RADIUS server to see
if the source IP is allowed. With all of the flexibility of a RADIUS server
like Radiator you it doesn't take much to see why this is so much cooler
than maintaing access lists or manually defining conduits on the firewall.
The docs are on the Cisco site, I think if you search for PIX and RADIUS
you'll come up with it.

-Original Message-
From: Mike McCauley [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 12, 2002 12:10 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) EAPOL authentication for LANs


Hello,

I was speaking recently to someone who told me that Radaitor works fine with

some type of router that requires EAPOL (EAP over LAN) authentication via 
Radius before it will let a client connected to the LAN route traffic.

Does anyone have information or details about what devices support this 
behaviour. Anyone used it in anger. Can it be used to monitor and control 
access to a LAN segment?

Responses direct to me please.

Cheers.


-- 
Mike McCauley   [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia   http://www.open.com.au
Phone +61 3 9598-0985   Fax   +61 3 9598-0955

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS etc.

===
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) AuthPort Cisco Questions

2002-12-17 Thread Frank Danielson
Just to beat Hugh to the punch- please send a trace 4 debug showing the
failure and your config file (no secrets) so the people on the list can see
what's going on. It would really help if you could snoop the traffic between
the NAS and the working RADIUS server with Ethereal(http://www.ethereal.com)
or something similar that would decode the RADIUS packets for you.

Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com


-Original Message-
From: Marcel Brown [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 17, 2002 1:32 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) AuthPort  Cisco Questions


I'm working with a client that I've set up Radiator for and am 
migrating them away from another RADIUS software. For reasons 
unknown, their previous administrator decided to set the auth and 
acct ports for their previous RADIUS server to 245 and 246. I've got 
all of the NAS boxes migrated to Radiator (and ports 1645 and 1646) 
except one. This particular server, a Cisco AS 5xxx, will not let 
them log in or do a password recovery (the config appears to be 
corrupted). Due to certain issues, they do not yet want to do a 
factory reset on this NAS. So this server (the bad Cisco) is stuck 
doing RADIUS on ports 245 and 246 for the time being and I can't yet 
take down their old RADIUS server.

With Radiator 3.4's release, which now do multiple Auth and Acct 
ports, I thought I could simply configure Radiator to the IP of the 
old RADIUS server and set it to listen on ports 245 and 246. So I 
installed and configured Radiator 3.4 in that manner. Radiator would 
receive the auth request from the Cisco box, process it correctly, 
then reply to the Cisco box. However, the Cisco box would apparently 
never hear the reply, as it would send more auth requests, no acct 
requests, and users could never log on. Another identically 
configured Cisco box (the good Cisco) does work with Radiator, 
although it is using ports 1645 and 1646.

Looking over some trace logs and doing further testing, I discovered 
the following behavior:

Radiator says it receives auth and acct requests from both the good 
and bad Cisco boxes on ports 1645 and 1646. As a comparison, it 
receives both auth and acct requests from some other Patton NAS's 
only on port 513. Radiator appears to reply to all NAS's on the same 
port it receives the requests.

Even if I changed the auth and acct ports on the good Cisco box to 
245 and 246, Radiator would always say that it received the requests 
from ports 1645 and 1646. So it appears that Cisco NAS's always send 
RADIUS requests from ports 1645 and 1646 and Patton NAS's send from 
port 513. Is this accurate?

Can anyone figure out a reason why the bad Cisco box would not hear 
the auth reply from Radiator?

Thanks!
Marcel
===
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) Problems with Colubris CN3000

2003-01-16 Thread Frank Danielson
Hi-

As Hugh has said in the past, please send a trace 4 debug showing what's
happening during an acess-request so we can see what the problem is.

-Original Message-
From: Denis Beauchemin [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 16, 2003 12:02 PM
To: Radiator
Subject: (RADIATOR) Problems with Colubris CN3000


Hello,

We are testing a Colubris CN3000 802.1x wireless access point and are
having some problems with it. (see
http://www.colubris.com/en/products/public_access/CN3000/ for more
info).

The biggest one is the HTTP URLs that don't seem to be sent to (or
accepted by) the unit.

Here is what I have in radius.cfg (I am using Radiator 3.5):
Client 132.210.X.Y
Secret oursecret
Identifier  colubris
/Client
Handler Client-Identifier=colubris
MaxSessions 1
WtmpFileName %L/wtmp
AcctLogFileName %L/accounting
#   PasswordLogFileName %L/password.log
AuthBy DBFILE
AutoMPPEKeysYes
AddToReply  Service-Type = Framed-User,\
MS-MPPE-Encryption-Policy = Encryption-Allowed,\
MS-MPPE-Encryption-Types = Encryption-Any,\
Framed-Protocol = PPP,\
Framed-IP-Netmask = 255.255.255.255,\
Framed-Routing = None,\
Framed-MTU = 1500,\
Colubris-AVPair =
login-url=https://somewhere.USherbrooke.ca:8443/java/colubris/login.jsp?log
inurl=%l,\
Colubris-AVPair =
session-page=https://somewhere.USherbrooke.ca:8443/java/colubris/session.ht
ml,\
Colubris-AVPair =
transport-page=https://somewhere.USherbrooke.ca:8443/java/colubris/transpor
t.html,\
Colubris-AVPair =
fail-page=https://somewhere.USherbrooke.ca:8443/java/colubris/fail.html,\
Colubris-AVPair =
logo=https://somewhere.USherbrooke.ca:8443/java/colubris/logo.gif,\
Colubris-AVPair =
access-list=carrefour,ACCEPT,tcp,132.210.X.Y,8443,\
Colubris-AVPair = access-list=carrefour,ACCEPT,tcp,132.210.X.Y,80
Filename %D/usersdb
RcryptKey our key
/AuthBy
AuthLog Defaut
/Handler

This is what I added to dictionary:
VENDOR Colubris8744
VENDORATTR8744   Colubris-AVPair   0   string
ATTRIBUTEColubris-AVPair   0   string

The Colubris-AVPair don't seem to get to the CN3000 when it logs on.

Any ideas?  I'm pretty sure I made a mistake in one of Radiator's conf
files.

Thanks!
-- 
Denis Beauchemin, analyste
Université de Sherbrooke, S.T.I.
T: 819.821.8000x2252 F: 819.821.8045

===
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) How to detect used AuthBy while processing Accounting

2003-01-30 Thread Frank Danielson



You 
could return a value in the Class attribute during the AuthBy and then have a 
Handler use that value to do the Accounting. Something like 
this:

# Authentications 
AuthBy 
SQL
 
Identifier auth1
 AddToReply 
Class="auth1"
/AuthBy 
AuthBy SQL
 
Identifier auth2

 AddToReply 
Class="auth2"
/AuthBy 
AuthBy SQL
 
Identifier auth3

 AddToReply 
Class="auth2"
/AuthBy

# Accounting
AuthBy 
SQL

 Identifier acct1
/AuthBy 
AuthBy SQL

 Identifier 
acct2/AuthBy 

AuthBy SQL

 Identifier 
acct3/AuthBy

# Handlers
Handler Request-Type = 
Accounting-Request, Class = 
auth1
AuthBy acct1/Handler


Handler Request-Type = 
Accounting-Request, Class = 
auth1
AuthBy acct1/Handler

HandlerAuthByPolicy 
ContinueUntilAcceptAuthBy 
auth1AuthBy auth2AuthBy 
auth3/Handler




Frank Danielson
[Infrastructure 
Architect]

wireless: 
407.467.7832
wireline: 407.515.8633

Data On Air
301 E. Pine St. 
Suite 450
Orlando, Fl 
32801
http://www.dataonair.com

  -Original Message-From: Oscar L. Garzón 
  [mailto:[EMAIL PROTECTED]]Sent: Thursday, January 30, 2003 12:08 
  PMTo: [EMAIL PROTECTED]Subject: (RADIATOR) How to 
  detect used AuthBy while processing Accounting
  Hello, 
  
  
  I need to 
  authenticate users from different databases without using a realm, or anything 
  else that could differenciate when a user exists in two databases... So I use 
  threeAuthBy sentencesfor authentication expecting thata user 
  will authenticate ifhis pair username/password matches one of the 
  databases (the first one taht matches).
  
  This works Ok for 
  authentication, and users with the same username can login no matter what 
  database are coming from, however, I need a similar behavior for accounting 
  processing,I mean, if user was authenticated using identifier auth2, its 
  accounting records must go to acct2, but it doesn't workthat fine, It seems 
  like accounting handler can`t differenciate what authentication mehtod was 
  used to authenticate, son depending on the authpolicy used in the accounting 
  handlers, it will store record in the first database or in they all, and 
  that's pretty far from what I want...
  
  Any 
  idea?
  
  This is the 
  escenario
  
  
  
  
  
  
  
  # Authentications 
  AuthBy 
  SQL
   Identifier auth1
  /AuthBy 
  AuthBy 
  SQL
   Identifier auth2
  /AuthBy 
  AuthBy 
  SQL
   Identifier auth3
  /AuthBy
  
  # 
  Accounting
  AuthBy SQL
  
   Identifier acct1
  /AuthBy 
  AuthBy 
  SQL
  
   Identifier 
  acct2/AuthBy 
  
  AuthBy 
  SQL
  
   Identifier 
  acct3/AuthBy
  
  # 
  Handlers
  Handler 
  Request-Type = Accounting-RequestAuthByPolicy 
  ContinueAlways
  AuthBy 
  acct1AuthBy 
  acct2AuthBy acct3/Handler
  
  HandlerAuthByPolicy 
  ContinueUntilAcceptAuthBy 
  auth1AuthBy 
  auth2AuthBy 
  auth3/Handler
  
  -
  
  OSCAR LEONARDO 
  GARZON. [ [EMAIL PROTECTED]]
  Andinet on Line - División de Proyectos 
  Especiales
  Tel. +57(1)6004330. Fax. 
  +57(1)6004370
  http://www.andinet.com. 

  Bogotá, Colombia 
  


RE: (RADIATOR) How to detect used AuthBy while processing Accounting

2003-01-30 Thread Frank Danielson
I hit the send button on the first message too soon, try something like
this-

# Authentications 
AuthBy SQL
Identifier auth1
AddToReply Class=auth1
/AuthBy 
AuthBy SQL
Identifier auth2
AddToReply Class=auth2
/AuthBy 
AuthBy SQL
Identifier auth3
AddToReply Class=auth2
/AuthBy

# Accounting
AuthBy SQL
Identifier acct1
/AuthBy 
AuthBy SQL
Identifier acct2
/AuthBy 
AuthBy SQL
Identifier acct3
/AuthBy

# Handlers
Handler Request-Type = Accounting-Request, Class = auth1

AuthBy acct1
/Handler

Handler Request-Type = Accounting-Request, Class = auth2

AuthBy acct2
/Handler

Handler Request-Type = Accounting-Request, Class = auth3

AuthBy acct3
/Handler

Handler
AuthByPolicy ContinueUntilAccept
AuthBy auth1
AuthBy auth2
AuthBy auth3
/Handler


Frank Danielson
[Infrastructure Architect]
 
wireless: 407.467.7832
wireline: 407.515.8633
 
Data On Air
301 E. Pine St. Suite 450
Orlando, Fl 32801
http://www.dataonair.com

-Original Message-
From: Oscar L. Garzón [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 30, 2003 12:08 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) How to detect used AuthBy while processing Accounting


Hello, 

I need to authenticate users from different databases without using a realm,
or anything else that could differenciate when a user exists in two
databases... So I use three AuthBy sentences for authentication expecting
that a user will authenticate if his pair username/password matches one of
the databases (the first one taht matches).

This works Ok for authentication, and users with the same username can login
no matter what database are coming from, however, I need a similar behavior
for accounting processing, I mean, if user was authenticated using
identifier auth2, its accounting records must go to acct2, but it doesn't
work that fine, It seems like accounting handler can`t differenciate what
authentication mehtod was used to authenticate, son depending on the
authpolicy used in the accounting handlers, it will store record in the
first database or in they all, and that's pretty far from what I want...

Any idea?

This is the escenario


 # Authentications 
AuthBy SQL
Identifier auth1
/AuthBy 
AuthBy SQL
Identifier auth2
/AuthBy 
AuthBy SQL
Identifier auth3
/AuthBy

# Accounting
AuthBy SQL
Identifier acct1
/AuthBy 
AuthBy SQL
Identifier acct2
/AuthBy 
AuthBy SQL
Identifier acct3
/AuthBy

# Handlers
Handler Request-Type = Accounting-Request
AuthByPolicy ContinueAlways
AuthBy acct1
AuthBy acct2
AuthBy acct3
/Handler

Handler
AuthByPolicy ContinueUntilAccept
AuthBy auth1
AuthBy auth2
AuthBy auth3
/Handler


-

OSCAR LEONARDO GARZON. [ [EMAIL PROTECTED] ]
Andinet on Line - División de Proyectos Especiales
Tel. +57(1)6004330. Fax. +57(1)6004370 
http://www.andinet.com. 
Bogotá, Colombia 
===
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) Auth only on same realm

2003-02-04 Thread Frank Danielson
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 correctly. Does the handlers work like a cisco access
list in that it will start at the top of the file and the first handler
that matches, it is completed? 

Tom Swenson - CTO
NetConX - Internet Access - Client Managed Web Database Applications
Wireless - Virus Blocking - Spam Blocking
[EMAIL PROTECTED]
http://www.netconx.net
(641) 421-4170 - Voice  (641) 423-3351 - FAX

There's a better way to do it. Find it!  -  Thomas Edison


*** REPLY SEPARATOR  ***

On 1/31/2003 at 10:35 AM Hugh Irvine wrote:

Hello Tom -

I don't quite understand your question sorry.

Could you give me a bit more detail please?

If you want usernames without realms to be treated the same way as 
those with realms, you can add a DefaultRealm parameter to your Client 
clauses:

# define Client clauses

Client 
   .
   DefaultRealm foo.bar
/Client

.

regards

Hugh


On Friday, Jan 31, 2003, at 10:04 Australia/Melbourne, Tom Swenson 
wrote:

 I tried this and I think it will work, but I have to figure out a way 
 to
 get the default domain in there. Is there an easier way than to put in 
 an
 identifier for every client and then a handler at the end of my 
 domains to
 catch all the ones without domains?

 Thanks again.

 Tom Swenson - CTO
 NetConX - Internet Access - Client Managed Web Database Applications
 Wireless - Virus Blocking - Spam Blocking
 [EMAIL PROTECTED]
http://www.netconx.net
 (641) 421-4170 - Voice   (641) 423-3351 - FAX

 Your imagination is your preview of life's coming attractions - Albert
 Einstein


 *** REPLY SEPARATOR  ***

 On 1/31/2003 at 9:24 AM Hugh Irvine wrote:

 Hello Tom -

 You should not mix Realms and Handlers in the same configuration file
 for exactly this reason - Realms are always evaluated first.

 Change your Realms to Handlers like this:

 Realm foo.bar
 .
 /Realm

 becomes

 Handler Realm = foo.bar
 .
 /Handler

 Note that Handlers are evaluated in the order they appear in the
 configuration file, so the more specific must appear before the more
 general, keeping in mind that you want the most hit Handlers as close
 to the top of the list as possible.

 regards

 Hugh


 On Friday, Jan 31, 2003, at 04:55 Australia/Melbourne, Tom Swenson
 wrote:

 I have a newsgroup server that I have told to authenticate with the
 same
 realm as my dial in customers. I created special client for this 
 server
 and then put in an identifier. I thought it would then go to the
 handler I
 created to just authenticate only. No accounting or sessions. I'm
 finding
 that it is instead of going to the handler, it is going to the realm.
 The
 manual says it this is how it will do this.

 I don't know what to do now. Here is what I have, but I don't think 
 it
 ever goes to the handler. Is there anything I can specify in the 
 client
 section to make it go to a specific realm or handler?

 Client xx.xx.xx.xx
   DupInterval 0
   IgnoreAcctSignature
   Secret xxx
   Identifier newsauth
 /Client

 # news group authentication
 Handler Client-Identifier=newsauth
   AuthBy ID_0
   AuthByPolicy ContinueWhileIgnore
   RewriteUsername s/^([^@]+).*/$1/
 /Handler


 Tom Swenson - CTO
 NetConX - Internet Access - Client Managed Web Database Applications
 Wireless - Virus Blocking - Spam Blocking
 [EMAIL PROTECTED]
http://www.netconx.net
 (641) 421-4170 - Voice (641) 423-3351 - FAX

 Your imagination is your preview of life's coming attractions - 
 Albert
 Einstein


 ===
 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: 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.

 ===
 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: 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.

===
Archive at 

RE: (RADIATOR) Incredibly high Acct-Session-Times

2003-05-30 Thread Frank Danielson
We had a similar situation with accounting data from a 3Com Total Control
chassis. What we noticed was that these abnormally large numbers occurred
when the disconnect cause was 0 or 1 and calls that ended normally had a
disconnect cause of 2. In this case it was due to a call setup failure and
the call disconnected before it had a chance to authenticate. I ended up
writing a hook that set the time to zero if the call had an abnormal
disconnect cause and an impossibly large session time. 
Here is an example of what I did -

Handler
PreProcessingHook sub {\
my $time=${$_[0]}-get_attr('Acct-Session-Time');\
my
$disc_cause=${$_[0]}-get_attr('Disconnect-Cause-Indicator');\
if (($disc_cause  2)  ($time  99)) {\
${$_[0]}-change_attr('Acct-Session-Time',0);\
}\
}
AuthBy 
/AuthBy
/Handler

If you examine your data you will probably find a similar pattern that you
can detect.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
301 E. Pine St. Suite 400
Orlando, FL 32801
USA
 



-Original Message-
From: Richard Grantham [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 29, 2003 10:52 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Incredibly high Acct-Session-Times


Hi all,

I think this only happens when a call does not connect but I've
noticed something strange with regards to call duration.  I think this
is illustrated well in this output listing from our accounting database:

ACCT_SESSION_TIME
-
4
   1054176189
   1054176307
   1054176350
   1054176384
   1054176426
   1054176522
   1054177499
   1054177560
   1054177767
7
   1054179354
   1054179448
   1054196686
   1054197106
   1054198442
   1054199147
   1054200785
   1054200912
   1054201263
   1054201288

The sensible numbers are 'real' Acct-Session-Time values.  I'm
wondering, where does Radiator get these HUGE values from?  They
seem to increase would I be right in thinking they are based on the
system time?  Why are they not 0?  Can I force them to be 0?

Richard
===
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) Injecting passwords in PreAuthHook.

2003-05-30 Thread Frank Danielson
The catch is that a PreAuthHook is not the place to do authentication.
Instead of using a PreAuthHook you could use a PostAuthHook to call the
AuthBy LDAP based on the results of whatever your authentication system
returns. There is an example of calling an AuthBy from a PostAuthHook in
goodies/hooks.txt.

Alternately you could implement your authentication scheme in a custom
AuthBy module and then use an AuthBy policy in a Handler to control the
flow. You could use a config like this-

Handler
AuthByPolicy ContinueUntilReject
AuthBy CustomAuthByModule
config parameters
/AuthBy
AuthBy LDAP2
LDAP config
/AuthBy
/Handler

Or you could put your hook into a PreHandlerHook and add a fake attribute
that you could use to decide which Handler gets the request-

Client x.x.x.x
PreHandlerHook sub { if (my authenticion scheme) {\
${$_[0]}-add_attr('Auth','Yes');\
} else {\
${$_[0]}-add_attr('Auth','No');\
}}
/Client

Handler Auth=Yes
AuthBy LDAP2
LDAP config
/AuthBy
/Handler

Handler Auth=No
AuthBy INTERNAL
DefaultResult REJECT
/AuthBy
/Handler



Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
301 E. Pine St. Suite 400
Orlando, FL 32801
USA
 

-Original Message-
From: Joao Pedro Goncalves [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 29, 2003 1:12 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Injecting passwords in PreAuthHook.


Hi,

We are using AuthBy LDAP2 to retrieve NAS attributes and it's working
great, but we want our users to be authenticated against a different
system in PreAuthHook. We've managed to get it working as a proof of
concept.


My question is,
How can i inject the password in the check item lists, so that later
it will check it as it should, or how do i issue a REJECT directly from
PreAuthHook, which would be optimal, since there would be one less
access to the ldap server.

Thank your for your time.


-- 
João Pedro Gonçalves
http://www.sapo.pt/ - Portugal Online

===
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) rewrite NAS-Port-type?

2003-06-17 Thread Frank Danielson
Try a PreHandlerHook, it's in section 6.5.11 of my radiator manual. Also
look in goodies/hooks.txt for more information on writing hooks.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA
 
-Original Message-
From: Craig Gittens [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 12:29 PM
To: Radiator
Subject: (RADIATOR) rewrite NAS-Port-type?


I am trying to implement a VPN solution using linux pppd and it is sending
the port type as Async. The problem is I don't want dialup customers able to
use this service as well. I was wondering if you could rewqrite NAS port
type before authentication in the CLIENT?

Thanks,

Craig.


===
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) Multiple Accounting DBs, Single Auth DB.

2003-07-08 Thread Frank Danielson
The problem is that you have the two RADIUS servers in seperate AuthBy
RADIUS clauses. The AuthBy RADIUS module will accept more than one host and
try them in the order specified until it gets a response, see section 6.29
in the documentation for more details. Try this-

AuthBy RADIUS
#  Customer's Primary RADIUS server
Host XXX.XXX.XXX.101
#  Customer's Secondary RADIUS server
Host XXX.XXX.XXX.102
Secret sharedsecret
AuthPort 1645 
AcctPort 1646 
StripFromRequest NAS-Port-Id,NAS-Port-Type
ReplyHook sub { ${$_[1]}-delete_attr('Framed-IP-Address'); }
LocalAddress XX.XX.XX.XXX
/AuthBy

Then you should be able to use ContinueWhileAccept without a problem.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA

-Original Message-
From: Kevin McKee [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 08, 2003 5:18 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Multiple Accounting DBs, Single Auth DB.


Hi,

I'm trying to create a handler that will authenticate a user by the first
RADIUS proxy that responds, but then sends Accounting packets to that RADIUS
proxy and an additional SQL server.

I have included the handler I am currently working with.  My problem is that
Accounting packets are being caught by the AuthBy SQL clause and are not
passing to the AuthBy RADIUS clauses.  If I change the AuthByPolicy to
ContinueWhileAccept, then it will authenticate and send accounting to both
of the AuthBy RADIUS clauses, and I want it to only go out to the first
responding one.

Any ideas how to do this?

Thanks,

-_   _
Kevin McKee, Network Mgr   _ __ | |_(_)
Northwest Telephone, Inc. | '_ \| __| |
Tel: +1 509 661 2000 x112 | | | | |_| |
Fax: +1 509 661 2020  |_| |_|\__|_|




Handler Called-Station-Id=/XX0095|XX0096/
#
# Sample Handler
#
MaxSessions 1
AcctLogFileName %L/%Y%m%d-XX-detail
SessionDatabase 
RejectHasReason
AuthBy SQL
#  Accounting only Database
#  Needs a copy of the Accounting packets
DateFormat %Y-%m-%d %H:%M:%S
DBSource dbi:mysql:XX:XX.XX.XX.XXX
DBUsername 
DBAuth 
IgnoreAuthentication
AccountingStopsOnly
AccountingTable  ACCOUNTING%Y%m
AcctColumnDefUSERNAME,User-Name
AcctColumnDefTIME_STAMP,Timestamp,integer-date
AcctColumnDefACCTSTATUSTYPE,Acct-Status-Type
AcctColumnDefACCTDELAYTIME,Acct-Delay-Time,integer
AcctColumnDefACCTINPUTOCTETS,Acct-Input-Octets,integer
AcctColumnDefACCTOUTPUTOCTETS,Acct-Output-Octets,integer
AcctColumnDefACCTSESSIONID,Acct-Session-Id
AcctColumnDefACCTSESSIONTIME,Acct-Session-Time,integer
AcctColumnDefNASPORT,NAS-Port,integer
AcctColumnDefFRAMEDIPADDRESS,Framed-IP-Address
AcctColumnDefNASIPADDRESS,NAS-IP-Address
AcctColumnDef
ASCENDDISCONNECTCAUSE,Ascend-Disconnect-Cause
AcctColumnDef
ASCENDCONNECTPROGRESS,Ascend-Connect-Progress
AcctColumnDefASCENDXMITRATE,Ascend-Xmit-Rate,Integer
AcctColumnDefASCENDDATARATE,Ascend-Data-Rate,Integer
AcctColumnDefCALLINGSTATIONID,Calling-Station-Id
AcctColumnDefCALLEDSTATIONID,Called-Station-Id
AcctColumnDefISP,X,literal
AcctFailedLogFileName %L/detail.newdb
/AuthBy
AuthBy RADIUS
#  Customer's Primary RADIUS server
Host XXX.XXX.XXX.101
Secret sharedsecret
AuthPort 1645 
AcctPort 1646 
StripFromRequest NAS-Port-Id,NAS-Port-Type
ReplyHook sub { ${$_[1]}-delete_attr('Framed-IP-Address');
}
LocalAddress XX.XX.XX.XXX
/AuthBy
   AuthBy RADIUS
#  Customer's Backup RADIUS server
Host XXX.XXX.XXX.102
Secret sharedsecret
AuthPort 1645
AcctPort 1646
StripFromRequest NAS-Port-Id,NAS-Port-Type
ReplyHook sub { ${$_[1]}-delete_attr('Framed-IP-Address');
}
LocalAddress XX.XX.XX.XXX
/AuthBy
/Handler

-
This email and the files transmitted with it are confidential
and intended solely for the use of the individual or entity to 
which they are addressed. If you have received this email in
error, please notify the sender

RE: (RADIATOR) Use of Oracle in PostAuthHook?

2003-07-09 Thread Frank Danielson
I'm not sure what you are trying to do with the database but you should
really look into using an AuthBy SQL cascaded after your AuthBy LDAP. The
folks at Open Systems have done a great job in the module addressing the
issues you have raised and it doesn't seem to make sense trying to rewrite
it all.

You can reuse an existing database connection from an AuthBy SQL and the
associated database access methods in your own hook if you want to and that
will also deal with most of the issues you have listed. Search the mailing
list archives on this topic and you will find some examples. I found this
one from Hugh particularly enlightening:
http://www.open.com.au/archives/radiator/2000-06/msg00023.html

As far as performance the limiting factor is usually the response time of
your database queries and not Radiator itself. You can always run multiple
instances of Radiator to spread the load and improve response time.

Why not post your config file with a more detailed explanation of what you
are trying to accomplish? A number of folks on the list are authenticating
with LDAP/SQL combinations. You can also search the mailing list archives
for examples of what others have done.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA

-Original Message-
From: John McFadden [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 11:47 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Use of Oracle in PostAuthHook?


We use LDAP to do the basic userid/password authentication but intend to 
use one or more Oracle databases
to apply business rules as LDAP is not dynamic enough.

The PostAuthHook gives us a place to do that but I'm not sure if I 
should try to do it within Radiator or
via an external program call.

I'm a bit nervious about the Radiator/Perl SQL overhead.  

Does the PostAuthHook require a new connection for each request or for 
each session or each user?
Or can I open the connection in a StartupHook (global var) then just 
share it in the PostAuthHook to do the required SQL query.
Since we're just doing queries I'm hoping to share one connection to 
minimize overhead.   Any issues with concurrency if we do?

How do I detect the database is down and attempt to allocate a new 
connection?

Comments, suggestions?

Regards JLM








===
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) Queries on proxy radius and config file auto refresh on Radiator Radius

2003-07-18 Thread Frank Danielson
You could use a PreHandlerHook in your Client clause like this-

Client XXX.XXX.XXX.XXX
Secret somesecret
PreHandlerHook sub
{${$_[0]}-change_attr('NAS-IP-Address','YYY.YYY.YYY.YYY');}
/Client

This may cause unintended consequences with your downstream RADIUS servers
since all requests will now appear to be coming from the same NAS. I
personally would not reccomend it.



-Original Message-
From: Brian CHNG Sing Yong [mailto:[EMAIL PROTECTED]
Sent: Friday, July 18, 2003 11:23 AM
To: '[EMAIL PROTECTED]'
Cc: CHEW Yong Sin
Subject: (RADIATOR) Queries on proxy radius and config file auto refresh on
Radiator Radius


Hi 
I've just deployed Radiator Radius in my workplace but am facing some
problems with having to make changes so often and creating many downtimes on
my servers. Would appreciate if you can help me with the following
questions. Thanks
First Question
I'm doing proxy radius to multiple host and I want to minimize having to
configure the Radius Host each time a new RAS is deployed, by default the
Radiator will forward all Radius Attributes to the Radius host and on the
Radius host I would need to configure the NAS-IP so that it will accept the
authentication/accounting packet from the RAS Client. I'm looking at how to
minimize changes made on the Radius Host as I would need to restart the
Radius Host whenever a change is made. Can I configure the Radiator in such
a way that it will strip off the NAS-IP and replace it with its own IP as
the NAS-IP so that the Radius host will only see one NAS-IP or RAS Client
IP? In this way I'll never need to add RAS Client on the Radius host. Or is
there any other better way to tackle this? Thanks
===
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) ip addr allocation

2003-07-31 Thread Frank Danielson
Hi ronnie-

How about a copy of your config file and a trace 4 debug of an authentiction
happening? This would help the people on the list see what is happening and
offer some advice.

-Original Message-
From: ronnie nyaruwabvu [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 31, 2003 11:16 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) ip addr allocation


Hi,

i have configured radiator on a linux platform. it is athenticating, but it 
is failing to allocate an ip address to the client. i have followed the 
recommendations in the goodies ciscoconfig.txt. as done in this document, i 
chose to have the router allocate the ip addresses. any clues of where i am 
getting it wrong.


regards,

ronnie nyaruwabvu
computer centre
university of zimbabwe


--

My grandfather once told me that there are two kinds of people. Those who 
do the work and those who take the credit. He told me to try to be in the 
first group; there was less competition there. Indira Ghandi

- Indira Ganghi - 

===
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) Urgent - Radiator does not reply NAS with accounting accept respo nse

2003-08-11 Thread Frank Danielson
Hi Brian-

We run a similar setup for CDMA IS-95 and 1XRTT networks and found the
IgnoreAccountingResponse parameter does what you are describing. Here is the
excerpt from the manual-

6.29.25 IgnoreAccountingResponse
This optional flag causes AuthBy RADIUS to ignore replies to accounting
requests, instead of forwarding them back to the originating host. This can
be used in conjunction with the AccountingHandled flag in a Handler or Realm
(see Section 6.16.10 ) to ensure that every proxied accounting request is
replied to immediately, and the eventual reply from the remote Radius server
is dropped.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA
 

-Original Message-
From: Brian CHNG Sing Yong [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2003 9:07 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Urgent - Radiator does not reply NAS with accounting
accept respo nse
Importance: High


Hi 
How can I configure the Radiator Radius to work in such a way that when NAS
send an accounting packet to Radiator, it will reply immediately with
accounting response and then proxy the accounting request to multiple Radius
Host without waiting for accounting response from the Radius Host?
Reason for this configuration:- 
I'm using the Radiator in a GPRS network and it has capability of accessing
to the Internet  WAP via GPRS, but I have one issue here is that the GGSN
or NAS requires the Radius to response with a accounting response before it
will establish a PDP context which will allow the mobile phone to access to
the Internet, but due to the behavior of the Radiator Radius Server, it does
not reply with the accounting response to the NAS until the Radius Host
replies to the Radiator with the response. So when my Radius Host is down,
it affects my GPRS network towards the Internet link.
Regards 
Brian 


This email is confidential and privileged.  If you are not the intended
recipient, you must not view, disseminate, use or copy this email. Kindly
notify the sender immediately, and delete this email from your system. Thank
you.
Please visit our website at www.starhub.com 
===
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) How to handle Accounting request in AuthURL

2003-08-26 Thread Frank Danielson
Hugh-

I can't speak for Angus but it makes sense that if you are passing
authentication reqests to an external system using AuthBy URL that you may
want to pass accounting requests to that same system.

It's something that we have looked at since we have a lot of internal talent
in developing java webapps and it would be relatively easy to develop http
interfaces to some of our systems.

Just a thought.

-Frank

-Original Message-
From: Hugh Irvine [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 26, 2003 4:14 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: (RADIATOR) How to handle Accounting request in AuthURL



Hello Angus -

How do you want to store the accounting information?

You should use the AcctLogFileName parameter in the Realm or Handler if 
you want to use a file, or you should use an additional AuthBy SQL 
clause if you want to store the accounting to an SQL database.

See sections 6.16.4 and 6.28 in the Radiator 3.6 reference manual 
(doc/ref.html).

regards

Hugh


On Tuesday, Aug 26, 2003, at 16:52 Australia/Melbourne, 
[EMAIL PROTECTED] wrote:


 Dear Support,

 We are using AuthURL to do the authentication. In AuthURL.pm
 module, i cannot see any function to handle accounting information
 (e.g. listen accounting request, write accounting information).
 Can you
 teach me how to handle the accounting issue in AuthURL?

   Thank you very much for your support.

 Regards,
 Angus


 ===
 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.


RE: (RADIATOR) Problems with SqlDB.pm module.

2003-09-08 Thread Frank Danielson
Hi Julio-

It has been my experience that an ORA-01002 error happens when the results
of the query are no longer available, usually due to memory or TEMP space
limitations on the database server. Have a look in yor Oracle server's error
log when this happens and you should see one or more additional errors that
point to the root of the problem.

-Frank

-Original Message-
From: Julio Cesar Pinto [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 06, 2003 8:52 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Problems with SqlDB.pm module.


Hi Guys.

We are working with version 2.8 without problem. We are trying to
upgrade to version 3.6, but the daemon (radiusd) dies with the following
error:

DBD::Oracle::db prepare failed: ORA-01002: fetch out of sequence (DBD
ERROR: OCIStmtExecute/Describe) [for Statement select PASSWORD,
TO_CHAR(EXPIRATION,'-MM-DD'), CHECKATTR, REPLYATTR  from SUBSCRIBERS
where USERNAME='tadomenech' and ACTIVE=1] at
/usr/lib/perl5/site_perl/5.6.1/Radius/SqlDb.pm line 180.


We're working with the following:
Linux RedHat Version 7.3.
Perl Version 5.6.1
Radiator Version 3.6 with the patches-3.6 applied.

I thank for any information on the matter.


Regards,
-- 
Julio Cesar Pinto [EMAIL PROTECTED]
IFX NETWORKS

===
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) High availability radius

2003-09-26 Thread Frank Danielson
Igor-

It sounds like you are using the Oracle database for storing accounting data
only. If that is the case how about runnning an instance of Radiator on each
box for authentication and another instance of Radiator for accounting? That
way authentication should not be affected by database problems.

-Frank

-Original Message-
From: Igor Briski [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 4:06 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) High availability radius



Hello!

We had some problems in the past regarding our main database server
(Oracle). The problem is, when the database slows down (it is still
accepting connections but runs very slow) Radiator starts slowing down
too and my NAS boxes eventually timeout. So all my users start getting
rejected. 

Both of our Radiator servers connect to the same database, so we
generally have a single point of failure. 

Is there any way to configure Radiator so that when it detects a very
slow database it stops using it (similar behaviour when the database
goes down, it backs off). 

Authorization part is using .db files, so when the database is not
available authorization can continue. But when the database is slow, the
whole thins slows down to a point where the system is not usable. 

Any comments, suggestions? 

-- 
Igor Briski [EMAIL PROTECTED]

===
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) PostAuthHook and DB connection

2003-09-26 Thread Frank Danielson
You can use an existing database handle from an AuthBy SQL or SessSQL in
your hook. This not only reduces the overhead of disconnecting and
reconnecting to the db each time but also lets you leverage the work that
Radiator does behing the scenes to manage the db connection.   Here is an
excerpt from a post by Hugh to the mailing list that explains the details.
The original message can be found here -
http://www.open.com.au/archives/radiator/2000-06/msg00023.html

I use this technique in several hooks and it works just dandy.


.
# configuration to allow a PostAuthHook to access a database
# either define a new AuthBy SQL if different to an existing AuthBy SQL
# or add an Identifier tag to your existing AuthBy SQL

AuthBy SQL
Identifier yourSQL
DBSource 
DBUsername 
DBAuth 
/AuthBy


Then in your hook use the find function in AuthGeneric to retrieve the
reference
to that AuthBy SQL. Once you have the reference, you can use all the
standard
routines in AuthSQL.pm and SqlDb.pm, including prepareAndExecute, etc.

# hook to use an SQL database

sub
{
my $p = ${$_[0]};
my $rp = ${$_[1]};
my $result = ${$_[2]};

my $authby_handle = Radius::AuthGeneric::find('yourSQL');
my $query = select ..;
my $sth = $authby_handle-prepareAndExecute($query);
.
}

This way you avoid most of the housekeeping, as it is already taken care of
by
the routines in SqlDb.pm. As a relatively simple example of some SQL code
that
uses these routines, have a look at Radius/SessSQL.pm.



Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA
 
-Original Message-
From: S H A N [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 6:45 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) PostAuthHook and DB connection


hi,
i am trying to think of a method where i can avoid 

connect to db
do something...
disconnect from db

each time one of my hook gets processing in a radius operation for
each
postauth request. (so if it handles 100k packets it means that i
does
100k times connect to db and 100k times of disconnect!)

ideally i want..

to connect to db... (at the point of startup of radius)

keep on doing something without disconnecting/connecting
again
till the life of the radius session/process.

any suggestions?

S H A N
===
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) Authentication to one DB, Accounting to another

2003-09-26 Thread Frank Danielson
The only catch is that AuthBy SQL will open a connection to the database
when it starts up and keep that connection up unless there is a problem with
it so your round robin DNS will not do much. AuthBY SQL supports declaring a
database to use as a backup which may be a better scheme for reliability. If
you are looking to load balance among your databases I would run a Radiator
instance for each database instance and then proxy requests to them using a
main instance with AuthBy ROUNDROBIN or AuthBy LOADBALANCE.

-Frank

-Original Message-
From: Derek Buttineau [mailto:[EMAIL PROTECTED]
Sent: Friday, September 26, 2003 6:20 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Authentication to one DB, Accounting to another


Just want to make sure I'm not totally out in left field on how to 
accomplish this, I thought I'd ask.  We just recently setup MySQL 
Replication.. and I'd like to make our Radiator software use the master 
and slaves for authentication (just using DNS round robin atm).. but 
since only the master can receive updates, I'd like to make sure the 
accounting packets only go to the master.

I'm thinking I need to make the configuration look like this, but please 
let me know if I'm totally off base:

AuthByPolicy ContinueAlways

AuthBy SQL
DBSourcedbi:mysql:radius:Slave Hostname
DBUsernameusername
DBAuthpassword

# Setup Authentication
AuthSelectselect ENCRYPTEDPASSWORD, REPLYATTR from 
AUTHENTICATIONTABLE where USERNAME='%U'
AuthColumnDef0, Encrypted-Password, check
AuthColumnDef1, GENERIC, reply

# Disable Accounting
AccountingTable
/AuthBy

AuthBy SQL
DBSourcedbi:mysql:radius:Master Database
DBUsernameradius
DBAuthcsrox

# Disable Authentication
AuthSelect

# Setup Accounting
AccountingTable ACCOUNTINGTABLE
AcctColumnDef   USERNAME,User-Name
AcctColumnDef   TIME_STAMP,Timestamp,formatted-date,'%Y%m%d 
%H:%M:%S'
AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause
AcctColumnDef   NASIDENTIFIER,NAS-IP-Address
AcctColumnDef   NASPORT,NAS-Port,integer
AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address
AcctColumnDef   CONNECTSPEED,Connect-Speed
/AuthBy

Thanks a bunch in advance.  Sorry if this has already been covered on 
the list, took a look but perhaps my search techniques are in need of 
improvement :)

-- 
Regards,

Derek Buttineau
Internet Systems Administrator
Compu-SOLVE Internet Services


===
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) Rewrite username or Quintum configuration?

2003-09-30 Thread Frank Danielson
How about using the DefaultRealm directive inside of the client clause for
the Quintum boxes? Something like this-

Client 111.222.333.444
Identifier Quintum
Secret somesecret
DefaultRealm 111.222.333.444
Other client config
/Client

Client 111.222.333.555
Identifier OtherQuintum
Secret somesecret
DefaultRealm 111.222.333.555
Other client config
/Client

DefaultRealm is documented in Section 6.5.2 of my Radiator 2.19 manual and
is used to add a realm to incoming requests that do not have a realm
specified.


Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA
 
-Original Message-
From: Richard Grantham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 30, 2003 1:10 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Rewrite username or Quintum configuration?


Hi List,

I've been looking at the hooks with regards to rewriting usernames but
I'm not getting much mileage in what I'm trying to achieve.

What I want to do is the opposite of stripping realms out of requests. 
If the username does not have a realm in it it will add the NAS IP
address as a realm instead.  This is for a calling card platform where
requests are made with the username given as [EMAIL PROTECTED]. 
Hopefully the following Perl function will illustrate what I want to do:

sub
{
my $p = ${$_[0]};

my $username = $p-getUserName;
if ($username !~ /\@/)
{
$username = [EMAIL PROTECTED]get_attr('NAS-IP-Address');
}
return $username;
}

I want to do this because a customer wishes to use our calling card
platform with a Quintum which does not allow you to edit its IVR scripts
(and add the realm) and I don't want to write another load of handlers
when I can make the current ones more versatile.

If anyone else has a better idea or has experience getting Quintums to
authenticate as [EMAIL PROTECTED] it would be most welcome.  Being a
Cisco shop no-one here has had much use with them!

TIA

Richard
===
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) CachePasswords not available in AuthBy ROUNDROBIN

2003-10-02 Thread Frank Danielson
Just a guess from the last time I looked into AuthBy ROUNDROBIN but I
believe the CachePasswords directive is specific to a host if it works at
all. Try this and see if it works:

Handler
UsernameCharset [EMAIL PROTECTED]
RewriteUsername tr/A-Z/a-z/
RewriteUsername s/\s+//g
RewriteUsername s/[EMAIL PROTECTED]/\?/g
AuthBy ROUNDROBIN
FailureBackoffTime  300
Secret  
Retries 3
RetryTimeout10
AuthPort1812
AcctPort1813
Host 1.1.1.1
CachePasswords
/Host
Host 2.2.2.2
CachePasswords
/Host
RejectEmptyPassword
NoDefault
/AuthBy
SessionDatabase NoneDB
/Handler


-Original Message-
From: Robert Blayzor [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 1:01 PM
To: Radiator
Subject: (RADIATOR) CachePasswords not available in AuthBy ROUNDROBIN


I have a Radiator farm setup which I'm trying to AuthBy ROUNDROBIN to... It
doesn't appear that CachePasswords works for this AuthBy.  Looking at my
trace, auths are always sent to the clients and never lookedup in the cache
even though I've authed several times..

Here is the handler I have:

Handler
UsernameCharset [EMAIL PROTECTED]
RewriteUsername tr/A-Z/a-z/
RewriteUsername s/\s+//g
RewriteUsername s/[EMAIL PROTECTED]/\?/g
AuthBy ROUNDROBIN
FailureBackoffTime  300
Secret  
Retries 3
RetryTimeout10
AuthPort1812
AcctPort1813
Host 1.1.1.1
/Host
Host 2.2.2.2
/Host
CachePasswords
RejectEmptyPassword
NoDefault
/AuthBy
SessionDatabase NoneDB
/Handler

Shouldn't CachePasswords be supported in this AuthBy?  It is in AuthBy
RADIUS...


--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
PGP: http://www.inoc.net/~dev/
Key fingerprint = A445 7D1E 3D4F A4EF 6875  21BB 1BAA 10FE 5748 CFE9

If at first you don't succeed, call it version 1.0


===
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) Handler SIP Proxy

2003-10-17 Thread Frank Danielson
I would use a PreHandler hook in your Client clause to look for the request
type and set an appropriate attribute to use in a Handler later. Since you
have multiple Digest-Attribute attributes the only way I know of to handle
it would be to spool through the incoming request's attrbutes looking for
the one you want. You could try something like this-

Client 111.222.333.444
Secret somesecret
PreHandlerHook sub {my ($r,$value);\
foreach $r (@{${$_[0]}-{Attributes}})\
{\
if ($r-[0] eq Digest-Attributes)\
{\
$value = Radius::AttrVal::pclean($r-[1]);\
${$_[0]}-add_attr('SIP-Request',$value) if ($value
=~ /REGISTER|INVITE/);\
}\
}}
/Client

Handler SIP-Request=REGISTER
/Handler

Handler SIP-Request=INVITE
/Handler


Obviously I have not tested this so proceed at your own risk.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA

-Original Message-
From: Jesus Rodriguez [mailto:[EMAIL PROTECTED]
Sent: Friday, October 17, 2003 2:30 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Handler SIP Proxy


Hello,

My SIP proxy authenticates REGISTER and INVITE requests against Radiator. I
would like to be able to diferentiate between both requests.

This is a REGISTER request:

Code:   Access-Request
Identifier: 104
Authentic:  21713430y250D214j212`N\F254{222
Attributes:
User-Name = [EMAIL PROTECTED]
Digest-Attributes = 1012340002
Digest-Attributes = 113voztele.com
Digest-Attributes = 2*3f9032160a04f9a07db6b7431a03c66e63917d8e
Digest-Attributes = 417sip:voztele.com
Digest-Attributes = 310REGISTER
Digest-Response = 5d484ab3e8c3ee3aa8aeb4f7238d9456
Service-Type = SIP
SIP-URI-User = 340002
NAS-IP-Address = 192.168.1.34
NAS-Port = 5060


And this is an INVITE request:

Code:   Access-Request
Identifier: 100
Authentic:  230141168k203:}239134139O227]6147'
Attributes:
User-Name = [EMAIL PROTECTED]
Digest-Attributes = 101234
Digest-Attributes = 113voztele.com
Digest-Attributes = 2*3f90309d03749b41dfcc0d202bc35f89ebfc9d1c
Digest-Attributes = 427sip:[EMAIL PROTECTED]
Digest-Attributes = 38INVITE
Digest-Response = f398469d53d8eeb47bbde0d45f78583d
Service-Type = SIP
SIP-URI-User = 34
NAS-IP-Address = 192.168.1.34
NAS-Port = 5060


The only difference between them are these Digest-Attributes:

Digest-Attributes = 310REGISTER
Digest-Attributes = 38INVITE

I've been playing with Handler Digest-Attributes = x where x are
different regular expressions but no luck.

Is there some way to diferentiate both requests? I have to treat them in a
different way because i need to send a reply attribute only for the INVITEs.

Thanks in advance.

Saludos
JesusR.

---
Jesus Rodriguez
Endercom Comunicaciones, S.L.
[EMAIL PROTECTED]
http://www.endercom.com
Tel. +34 934424293
---
===
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) Feature request: Multifunctional radpwtst

2003-10-21 Thread Frank Danielson
You can do this right now using the correct command line options. Here is
what I use to send Accounting-Alives with radpwtst -

radpwtst -secret mysecret -noauth -noacct -trace -code Accounting-Request
Acct-Status-Type=Alive Calling-Station-Id=5551212 Called-Station-Id=5551234
Acct-Session-Id=1234556 Class=someclass Acct-Session-Time=X

Where X is the amount of time elapsed for the session so far. You will most
likely need to use a different set of attributes depending on what you are
trying to test.

Frank Danielson
[Infrastructure Architect]

voice:407.515.8633
fax:407.515.9001

ClearSky Mobile Media, Inc.
56 E. Pine St. Suite 200
Orlando, FL 32801
USA
 
-Original Message-
From: Karel van der Velden [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 10:26 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Feature request: Multifunctional radpwtst


Hello,

The present radpwtst is focussed to sending radius requests for a dial
environment (eg. it default sends called-station-id and
calling-station-id). We would like to see the utility extended so it
will be able to send radius accounting alive packets. Presently we are
rebuilding it ourselves, but it would be convenient to have this within
the product itself.

With kind regards,
 
Karel van der Velden
Postbus 28129
3828 ZJ Amersfoort / Groningen
Tel: 050-5881003
Bgg Tel:  030-6588500
Fax: 033-4513101
E-mail: [EMAIL PROTECTED]
===
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) Input queue size

2003-11-12 Thread Frank Danielson
It's really not that hard. You run a number of Radiator instances, with each
one having it's own connection to the LDAP, SQL, or whatever backend. Then
you front end those with an instance or two of Radiator running AuthBy
ROUNDROBIN or AuthBy LOADBALANCE to distribute the requests among them.

You can process quite a lot of requests simultaneously this way. If your
current server is not responding fast enough but the CPU utilization is not
maxed out you are probably just hitting the ceiling on how many requests a
single instance can process at a time. Start up some more processes on the
box and use all those processor cycles that you paid for.

-Frank

-Original Message-
From: Claudio Lapidus [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 12, 2003 9:19 PM
To: Guðbjörn S. Hreinsson; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Input queue size

..

From my own corner, I wish it were possible to have more than one
established connection with the SQL backend, so as to paralellize requests
to a certain degree. But yes, I suppose that means multithreading, and AFAIK
that's not possible under perl 5.6 nor 5.8 I think. Perhaps Perl 6 would do
it?

===
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) Username/Password hacking while using AuthBy SQL

2003-12-10 Thread Frank Danielson
Rodrigo-

If I understand you correctly, you are concerned that someone may insert
some characters or even SQL statements into the password in order to launch
some sort of attack against your database. I think the root of your issue is
the fact that you want to include the password in the queries, that opens up
any number of potential security issues including the one you have described
here.

Lots of people use Radiator and allow users to have more than one session.
Maybe if you described in more detail exactly what you are trying to
accomplish by including the password in the query someone on the list might
have in interesting solution. If you have an end user that is using CHAP
authentication they are never going to send the password to you so it would
be impossible to use it in a query. If you are plugging potential security
loopholes I'm sure you are not letting people authenticate using PAP are
you?

Of course you could always do your own password character set checking in a
hook before sending the query out if you are so inclined.

-Frank

-Original Message-
From: Rodrigo Nuno Bragança da Cunha
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2003 7:25 AM
To: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Username/Password hacking while using AuthBy SQL


Hugh Irvine wrote:


 Hello Rodrigo -

 You can use the UsernameCharset parameter to restrict the characters 
 in the username.

 See section 6.4.30 in the Radiator 3.7.1 reference manual.

 As far as the password is concerned, this field is only read from the 
 database and the comparison is done inside Radiator.

Well... it works, but is not enought. Won't work for SQL logging, for 
instance.

Also I need the password in the SQL query itself because there can be 
various active and valid sessions for the same username, and a query 
without password might return many valid sessions. So the password is 
exploitable also. Perhaps a PasswordCharset clause would work :-)

The Charset should apply to auth logging also, right?

I'm sending the configuration file. It works fine as is, except with 
malicious username/passwords ...

 NB: have you included a copy of your configuration file (no secrets),
 together with a trace 4 debug showing what is happening?

Here goes the trace, including the SQL syntax errors, witch could be 
exploited.

Thanks for the help!

Tue Dec  9 12:08:22 2003: DEBUG: Finished reading configuration file 
'/home/radius/Radiator-3.7.1/goodies/vpn3000-test00.cfg'
Tue Dec  9 12:08:22 2003: DEBUG: Reading dictionary file 
'/home/radius/Radiator-3.7.1/dictionary'
Tue Dec  9 12:08:22 2003: DEBUG: Creating authentication port 0.0.0.0:1645
Tue Dec  9 12:08:22 2003: DEBUG: Creating accounting port 0.0.0.0:1646
Tue Dec  9 12:08:22 2003: NOTICE: Server started: Radiator 3.7.1 on 
radius-vpn.vf-pt.internal.vodafone.com
Tue Dec  9 12:08:25 2003: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32784 
Code:   Access-Request
Identifier: 10
Authentic:  1234567890123456
Attributes:
User-Name = norte'gregwe
Service-Type = Framed-User
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password = 
158238-202216;424618889160216}x153

Tue Dec  9 12:08:25 2003: DEBUG: Handling request with Handler 
'Realm=DEFAULT'
Tue Dec  9 12:08:25 2003: INFO: Access rejected for norte'gregwe: 
Invalid character in User-Name
Tue Dec  9 12:08:25 2003: DEBUG: do query is: 'INSERT   INTO accountlog 
( id, idsession, timestamp, authaccountQ, authsuccessQ, duration, 
comments ) VALUES ( 0, 0, unix_timestamp(), 0, 0, 0, 'Auth Failure for 
username norte'gregwe' )':

DBD::mysql::db do failed: You have an error in your SQL syntax near 
'gregwe' )' at line 1 at Radius/SqlDb.pm line 219.
Tue Dec  9 12:08:25 2003: ERR: do failed for 'INSERTINTO accountlog 
( id, idsession, timestamp, authaccountQ, authsuccessQ, duration, 
comments ) VALUES ( 0, 0, unix_timestamp(), 0, 0, 0, 'Auth Failure for 
username norte'gregwe' )': You have an error in your SQL syntax near 
'gregwe' )' at line 1
DBD::mysql::db do failed: You have an error in your SQL syntax near 
'gregwe' )' at line 1 at Radius/SqlDb.pm line 219.
Tue Dec  9 12:08:25 2003: ERR: do failed for 'INSERTINTO accountlog 
( id, idsession, timestamp, authaccountQ, authsuccessQ, duration, 
comments ) VALUES ( 0, 0, unix_timestamp(), 0, 0, 0, 'Auth Failure for 
username norte'gregwe' )': You have an error in your SQL syntax near 
'gregwe' )' at line 1
Tue Dec  9 12:08:25 2003: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 32784 
Code:   Access-Reject
Identifier: 10
Authentic:  1234567890123456
Attributes:
Reply-Message = Request Denied

Tue Dec  9 12:08:25 2003: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 32784 
Code:   Accounting-Request
Identifier: 11
Authentic:  201T'190194144135CW(239150=~*m
Attributes:
User-Name = 

RE: (RADIATOR) Radiator ignoring some clients

2003-12-17 Thread Frank Danielson
It's hard to say from the info you have provided. How about providing the
config file, a level 4 trace, and doing a snoop -o to capture some of this
unanswered traffic to a file and send that as well? 

-Original Message-
From: Jason Signalness [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 2:11 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Radiator ignoring some clients


Hello,

We are having serious issues with Radiator.  I tried e-mailing this to 
radius-support and to the list, but have not received a response from 
either.  It doesn't appear the message posted to the list, so I will try 
again using my other address.

Our environment:
  Radiator 3.7.1
  Perl 5.8.1
  Solaris 9

Basically, we tried to upgrade from Radiator 3.3.1 running on Solaris 8 
with Perl 5.6 to the new setup.  On the new server (Solaris 9) I 
installed Radiator, copied over the config files, updated the 
environment variables (ORACLE_HOME, etc) and started it up.  No 
problems.  I used radpwtst to test users in our various databases (LDAP, 
Oracle, and a flat file) and it all seemed fine.

Then we put this upgraded system (actually 2 identical systems) into 
production.  Requests from certain access servers are handled and 
answered by Radiator.  Requests from other access servers seem to be 
completely ignored.  By completely ignored, I mean that nothing shows 
up at all in a DEBUG level log.  If I run a snoop on the radius server, 
I see a ton of traffic from a given NAS to the radius server on port 
1812, but not a single response going the other way.

We have cleared the ARP entries in our switches and rebooted one of the 
NASes.  Same behavior.  It is as if Radiator simply doesn't pay 
attention to some access servers or some requests from some access servers.

Eventually, we gave up and powered on our old servers (Radiator 3.3.1, 
Perl 5.6, Solaris 8).  The really weird thing is that we see this 
behavior on these servers as well... and they worked perfectly earlier. 

When I launch Radar, I see the clients listed.  And like I said before, 
I'm not getting any bad authenticator errors in the logs.  Nothing 
shows up at all for most of our access servers.

I'm desparate for assistance.

Thanks,

-- 
Jason Signalness, Systems Administrator
Basin Telecommunications, Inc.
-- 

===
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) Radiator ignoring some clients

2003-12-17 Thread Frank Danielson
Hi Jason-

OK. If you have some time in the future and can do a snoop -o and a trace 4
at the same time it may help someone on the list identify your problem. The
only suggestion I can make is that there may be a local network problem of
some sort. By default snoop runs in promiscuous mode so it catches
everything going down the wire, try turning off promiscuous mode with the -P
option and see what happens. Or try looking at the MAC address those packets
are sent to and make sure it matches the interface on your server.

-Frank

-Original Message-
From: Jason Signalness [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 4:05 PM
To: Frank Danielson
Subject: Re: (RADIATOR) Radiator ignoring some clients



I have attached my radius.cfg file.  Currently, I don't have the ability 
to capture a snoop showing the problem.  Basically, here's what I saw 
during the snoop:

# snoop port 1812 ns1
NAS A - ns1
NAS A - ns1
NAS A - ns1
NAS B - ns1
NAS B - ns1
NAS B - ns1
. . .

As far as a level 4 trace, it showed nothing from the NASes it decided 
to ignore (like A and B in the example snoop).  According to the logs, 
all the other NASes were behaving normally.

Thanks,
jason

Frank Danielson wrote:

It's hard to say from the info you have provided. How about providing the
config file, a level 4 trace, and doing a snoop -o to capture some of this
unanswered traffic to a file and send that as well? 

-Original Message-
From: Jason Signalness [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 17, 2003 2:11 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Radiator ignoring some clients


Hello,

We are having serious issues with Radiator.  I tried e-mailing this to 
radius-support and to the list, but have not received a response from 
either.  It doesn't appear the message posted to the list, so I will try 
again using my other address.

Our environment:
  Radiator 3.7.1
  Perl 5.8.1
  Solaris 9

Basically, we tried to upgrade from Radiator 3.3.1 running on Solaris 8 
with Perl 5.6 to the new setup.  On the new server (Solaris 9) I 
installed Radiator, copied over the config files, updated the 
environment variables (ORACLE_HOME, etc) and started it up.  No 
problems.  I used radpwtst to test users in our various databases (LDAP, 
Oracle, and a flat file) and it all seemed fine.

Then we put this upgraded system (actually 2 identical systems) into 
production.  Requests from certain access servers are handled and 
answered by Radiator.  Requests from other access servers seem to be 
completely ignored.  By completely ignored, I mean that nothing shows 
up at all in a DEBUG level log.  If I run a snoop on the radius server, 
I see a ton of traffic from a given NAS to the radius server on port 
1812, but not a single response going the other way.

We have cleared the ARP entries in our switches and rebooted one of the 
NASes.  Same behavior.  It is as if Radiator simply doesn't pay 
attention to some access servers or some requests from some access servers.

Eventually, we gave up and powered on our old servers (Radiator 3.3.1, 
Perl 5.6, Solaris 8).  The really weird thing is that we see this 
behavior on these servers as well... and they worked perfectly earlier. 

When I launch Radar, I see the clients listed.  And like I said before, 
I'm not getting any bad authenticator errors in the logs.  Nothing 
shows up at all for most of our access servers.

I'm desparate for assistance.

Thanks,
  

===
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) Shutdown in a Hook

2004-01-05 Thread Frank Danielson
How about using-

kill '1',$$

or if you are in a hurry-

kill '9',$$

Using kill 1 should allow Radiator to execute any shutdown hooks you have
and otherwise exit normally.

-Frank

-Original Message-
From: Jerome Fleury [mailto:[EMAIL PROTECTED]
Sent: Monday, January 05, 2004 12:16 PM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) Shutdown in a Hook


Hello there,

under certain conditions, I would like Radiator to shutdown itself inside a
hook. I tried:

  if ($@) {
main::log($main::LOG_ERROR,  (jeje) cannot recreate data
structures from \$config_file\:
[EMAIL PROTECTED] Exiting.) if $@;
close CONF;
main::shutdown();
  }

the log prints:

Mon Jan  5 18:16:59 2004: NOTICE: SIGTERM received: stopping

But the server doesn't really stop. It's still alive.

Any idea someone ?

Thanks!
--
Jerome Fleury
===
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] Question on FarmSize, SocketQueueLength, and net.core.rmem_max on Linux

2011-08-23 Thread Frank Danielson
We are currently running Radiator 4.7 under Redhat 5.5 and I am trying to make 
sure I understand the effect that the FarmSize setting has on the amount of 
memory allocated for the SocketQueue. If Radiator is configured with some 
FarmSize does each worker have its own SocketQueue with the effect of making 
the total amount of memory allocated = FarmSize * SocketQueueLength? For 
example if my SocketQueueLength is 100 and the FarmSize is 4, is there a 
total of 400 bytes allocated or is it just 100? In either instance I am 
assuming that the net.core.rmem_max size needs to be at least as large as that 
number, is that correct?

Frank Danielson
ClearSky Mobile Media, Inc. | fdaniel...@csky.commailto:fdaniel...@csky.com

A human being should be able to change a diaper, plan an invasion, butcher a 
hog, conn a ship, design a building, write a sonnet, balance accounts, build a 
wall, set a bone, comfort the dying, take orders, give orders, cooperate, act 
alone, solve equations, analyze a new problem, pitch manure, program a 
computer, cook a tasty meal, fight efficiently, die gallantly. Specialization 
is for insects.

-Robert A. Heinlein

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] Unknown reply received in AuthRADIUS

2013-05-03 Thread Frank Danielson
Hi Jim-

Have you tried FarmSize instead of Fork? 

-Frank

On May 3, 2013, at 7:34 AM, Jim Tyrrell wrote:

 OK, I increased the timeout of the AuthBy RADIUS to 20 seconds and had 
 to add 'UseExtendedIds', which just delays the issue occuring.
 
 It looks like the issue is with the MySQL server in the new AuthBy 
 RadiusSessionUpdate which is slow in responding.  I suspect a backlog is 
 building up here which is delaying processing of the RADIUS proxy 
 replies.  If I truncate the new MySQL tables then the RADIUS proxy is 
 happy, until the table builds up again and performance of the MySQL 
 AuthBy is degraded.
 
 I need to fix the MySQL server performance, but it has identified I need 
 to allow for a slow MySQL server so it does not impact the RADIUS proxy 
 AuthBy.  I thought a Fork in the MySQL authby should do the trick?
 
 AuthBy SQL
 Identifier RadiusSessionUpdate
 Fork
 DBSource dbi:mysql:Radius:10.10.4.12
 DBUsername user
 DBAuth pass
 Timeout 2
 AcctSQLStatement CALL RadiusUpdate(statement)
 /AuthBy
 
 However I'm still getting the RADIUS proxy taking longer and longer to 
 process and eventually 'Unknown reply received in AuthRADIUS'. Should 
 the Fork not cause Radiator to fork a new process for this AuthBy so 
 that it does not delay any other processing?
 
 This is running on a CentOS 6.4 box and also has 'MaxChildren = 100' 
 defined.  Can I tell if it is forking?  I dont see any more radiusd 
 processes..
 
 I just need to ensure that any slowness to a MySQL update does not 
 impact any other authby's.  I'm not seeing any timeouts to MySQL so I'm 
 guessing that the updates are taking less than 2 seconds, but long 
 enough for a backlog to build up on a busy box.
 
 Appreciate any ideas.
 
 Jim.
 
 
 On 02/05/2013 08:18, Hugh Irvine wrote:
 Hello Jim -
 
 You need it in *both* AuthBy RADIUS clauses.
 
 regards
 
 Hugh
 
 
 On 2 May 2013, at 15:56, Jim Tyrrell j...@scusting.com wrote:
 
 I already have IgnoreAccountingResponse in my AuthBy RADIUS below, is that 
 the correct place for it?
 
 Jim.
 
 On 02/05/2013 00:38, Hugh Irvine wrote:
 Hello Jim -
 
 Just add IgnoreAccountingResponse to your AuthBy RADIUS clauses.
 
 See section 5.32.30 in the Radiator 4.11 reference manual (doc/ref.pdf).
 
 regards
 
 Hugh
 
 
 On 2 May 2013, at 04:49, Jim Tyrrell j...@scusting.com wrote:
 
 Hi,
 
 I have a default accounting handler which currently formats a few
 attributes via a hook, updates a MySQL database with session info, and
 then relays the RADIUS packet onto a couple of Cisco management servers
 (so they can maintain a mapping of user to IP).
 
 We have always had a few Unknown reply received in AuthRADIUS, but
 quite rarely and then only a handful at a time so ignored them.  I had
 assumed it was down to the remote RADIUS replying after Radiator had
 timed out the request (RetryTimeout 5) and so it was no longer valid -
 is that a correct assumption?
 
 However, I then added another AuthBy between the MySQL update and the
 RADIUS proxy to update a 2nd MySQL server (that will eventually replace
 the current MySQL), and now I get floods of Unknown reply received in
 AuthRADIUS approx 10 seconds after starting the RADUS process.  I have
 'Retries 2' so 10 seconds would be the time taken before giving up the
 AuthBy RADIUS.
 
 I dont understand why adding in an AuthBy before the AuthBy RADIUS could
 have an impact?  Even if the new AuthBy is slow, and I dont believe it
 is as I have seen no timeouts for it, then wouldnt that just delay the
 RADIUS proxy sending rather than effect its performance?  My accounting
 handler is as follows:
 
 Handler
 AuthByPolicy ContinueAlways
 AccountingHandled
 PreProcessingHook file:%D/scripts/format_attributes.pl
 
 ## Log User session status to MySQL servers via insert/update/delete
 statements
 AuthBy RadiusOnline-Start
 AuthBy RadiusOnline-Alive
 AuthBy RadiusOnline-Stop
 
 ##  NEW AuthBy to log to new MySQL server via stored procedure
 AuthBy RadiusSessionUpdate
 
 ## Proxy accounting packet to Cisco management server 10.153.253.1
 AuthBy Proxy-to-CiscoSM
 
 ## Proxy accounting packet to Cisco management server 10.153.253.12
 AuthBy Proxy-to-CiscoSM_lab
 
 /Handler
 
 The remote RADIUS servers are defined as such:
 AuthBy RADIUS
 Identifier Proxy-to-CiscoSM
 Host 10.153.253.1
 Secret mypassword
 RetryTimeout 5
 Retries 2
 /Host
 IgnoreAccountingResponse
 NoDefault
 /AuthBy
 
 The messages I get are:
 Wed May  1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
 for request 26 from 10.153.253.1:1646
 Wed May  1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
 for request 26 from 10.153.253.12:1646
 Wed May  1 19:18:53 2013: WARNING: Unknown reply received in AuthRADIUS
 for request 27 from 10.153.253.1:1646
 Wed May  1 19:18:53 2013: WARNING: 

Re: [RADIATOR] Multiple AuthBy inside an Handler

2016-07-06 Thread Frank Danielson
Hi Marco-

Take a look at AuthByPolicy in section 5.27.1 of the manual. The default 
behavior is-

• ContinueWhileIgnore
This is the default. Continue trying to authenticate until either Accept, 
Challenge or Reject

Because the first AuthBy is handling Start messages it satisfies the handler 
and the second AuthBy is not called.

You could set  AuthByPolicy ContinueAlways in the Handler to always execute all 
of the AuthBy clauses.

[cid:A5561F0C-29ED-4FB5-B132-7DDD0D907642]

Frank Danielson | Chief Technology Officer
• 
fdaniel...@csky.com

On Jul 6, 2016, at 6:45 AM, Marco Marino 
<marino@gmail.com<mailto:marino@gmail.com>> wrote:

Hi, I'm trying to adjust a configuration problem on an old server that uses 
radiator.
Actually I have:


AuthBy auth1
AuthBy auth2
SessionDatabase SDBpppoe_start




Identifier  auth1

AccountingStartsOnly

DBSourcedbi:mysql:radius:X.Y.Z.W
DBUsername  radius
DBAuth  

DBSourcedbi:mysql:radius:X.Y.Z.K
DBUsername  radius
DBAuth  yyy

AuthSelect

AcctSQLStatement update SUBSCRIBERS_PPPOE set AUTHCOUNTER=AUTHCOUNTER+1 
 where USERNAME='%n'






Identifier  auth2

DBSourcedbi:mysql:radius:a.b.c.d <- Different db respect to 
auth1!!
DBUsername  radius
DBAuth  x

AccountingTable ACCOUNTING
DateFormat %Y-%m-%d %T
AcctColumnDef   USERNAME,User-Name
AcctColumnDef   TIME_STAMP,Timestamp,integer-date
AcctColumnDef   ACCTSTATUSTYPE,Acct-Status-Type
AcctColumnDef   ACCTDELAYTIME,Acct-Delay-Time,integer
AcctColumnDef   ACCTINPUTOCTETS,Acct-Input-Octets,integer
AcctColumnDef   ACCTOUTPUTOCTETS,Acct-Output-Octets,integer
AcctColumnDef   ACCTSESSIONID,Acct-Session-Id
AcctColumnDef   ACCTSESSIONTIME,Acct-Session-Time,integer
AcctColumnDef   ACCTTERMINATECAUSE,Acct-Terminate-Cause,
AcctColumnDef   NASIDENTIFIER,NAS-Identifier
AcctColumnDef   NASPORT,NAS-Port,integer
AcctColumnDef   FRAMEDIPADDRESS,Framed-IP-Address, char
HandleAcctStatusTypes Start,Stop,Alive




Actually auth2 Doesn't write Start request in the Db. It works only for Stop 
and Alive. Please, someone can help me?
Thank you


___
radiator mailing list
radiator@open.com.au<mailto:radiator@open.com.au>
http://www.open.com.au/mailman/listinfo/radiator

___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator