(RADIATOR) Add IP from SQL table to AuthBy Radius Reply packet

2002-10-23 Thread alexander . deboer 
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.

(RADIATOR) Error in the manual: AddAddressQuery

2002-08-26 Thread alexander . deboer 

Dear all,

For your reference, the Radiator 3-2 manual contains a small error regarding
the AddAddressQuery in section 6.53.8. 

Below you find the correct text  and the correct default SQL-query:

snip
AddAddressQuery
This optional parameter allows you to define a custom SQL query to add an
address to the pool if it is not found by CheckPoolQuery. Defaults to
 
insert into RADPOOL (STATE, TIME_STAMP,
POOL, YIADDR, SUBNETMASK, DNSSERVER) values (0, %t, '%0', '%1',
'%2', '%3')
%t is replaced by the current time in Unix epoch seconds, %0 by the pool
name, %1 by the address, %2 by the subnet mask, and %3 by the DNS server
address.

/snip

Cheers,
Alexander


dr. ir. Alexander P. de Boer
KPN Research - Broadband  Voice Solutions
Room L C7, P.O.Box 421, 2260 AK Leidschendam
The Netherlands

tel.: +31 70 4461788 (mobiel)  / fax.: +31 70 4463166
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.

RE: (RADIATOR) AddtoReply

2002-08-26 Thread alexander . deboer 

If you don't like this behavior, you can specify your handlers like this:

Handler Realm=bogus-service, Request-Type=Access-Request
...
...
AddToRequest Attribute-Name = Attribut-Value
/Handler 

Handler Realm=bogus-service, Request-Type=Accounting-Request
...
...
/Handler

Cheers,
Alexander

-Original Message-
From: Wim Biemolt [mailto:[EMAIL PROTECTED]]
Sent: zaterdag 24 augustus 2002 14:12
To: Hugh Irvine
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) AddtoReply 



So many e-mail. So little time. But ...

== From: Hugh Irvine

 This is the expected behaviour - why is it a problem?

Why is it expected behaviour that AddToReply also works for Accounting
replies when the manual states (6.17.8 AddToReply) Adds attributes to
Access-Accepts before replying to the originating client.? If I read
this I expect AddToReply wouldn't add attributes to accounting replies.

And since I don't need attributes added to the accounting replies I
would be in favour of the behaviour described in the manual. But since
on the other hand the added attributes to the accounting replies don't
cause any real problem updating the manual would also be fine with me.
Leaving everything just the way it is now probably isn't a good idea.

-Wim -/- SURFnet

===
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) SQL server fallback behaviour

2002-07-30 Thread alexander . deboer 

Hi Mike and Hugh,

I have checked the requested information:

- Our platform: DELL PC with 1Ghz CPU and 1 GB RAM (seems contradictory with
high-availability ;0). However, we use primary and secondary AAA-servers and
our SQL servers run on SUN Solaris 8.
- Our perl version: ActivePerl 5.6.1 build 631
- Our DBI module: 1.201
- Our DBD-Mysql module: 1.2200

PPM reports this modules as being up to date. However, do you expect some
improvement by upgrading to the latest Perl CPAN modules (DBI-1.30,
DBD-Mysql-2.017 of should I use Mysql-Mysql-modules-1.2219?)? I assume that
our hardware is fast enough.

The experienced behaviour appears insensitive to the Timeout parameter: We
have tried values of 0, 1, 10 and default (60)

Cheers,
Alexander

-Original Message-
From: Mike McCauley [mailto:[EMAIL PROTECTED]]
Sent: dinsdag 30 juli 2002 2:51
To: Hugh Irvine; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: (RADIATOR) SQL server fallback behaviour



Hello Alexander,

On Tue, 30 Jul 2002 10:31, Hugh Irvine wrote:
 Hello Alexander -

 Thanks for sending the configuration and log files.

 The Timeout parameter should specify the length of time to wait for a
 response.

 I have copied this mail to Mike for his comments.

Your Timeout parameter should indeed cause Radiator to wait at most 10 secs 
before giving up.

What platform and OS are you running Radiator on? What version of perl? What

version of DBI-Mysql?

Cheers.


 regards

 Hugh

 On Tuesday, July 30, 2002, at 01:02 AM, [EMAIL PROTECTED] wrote:
  Dear all,
 
  Using Radiator in a high-availability environment, I encounter a
  somewhat
  random delay time before Radiator proceeds after a SQL-server failure.
 
  I'm using Radiator-3.1 with two SQL databases: if the Master DB fails,
  Radiator falls back to the Slave DB.
 
  The trace 4 logging below is produced using radpwtst after disabling the
  connection between Radiator and the primairy database server.
 
  After failing the select query, Radiator waits most of time 46 seconds
  (sometimes it takes even longer) before checking the SQL connection and
  falling back to the secondary database server.
 
  What is the origin of this delay time (46 seconds)? Can I shorten it? Is
  anybody familiar with this behaviour?
 
  Thanks in advance,
 
  Alexander de Boer
 
 
  AuthBy SQL
  Identifier sqlAuth
 
  #master database
  DBSource dbi:mysql:radiusaccess:x.x.x.x:3306
  DBUsername ***
  DBAuth ***
  Timeout 10
 
  #slave database
  DBSource dbi:mysql:radiusaccess:y.y.y.y:3306
  DBUsername ***
  DBAuth ***
  Timeout 10
 
  AuthSelect select Tele_password, concat(Framed-IP-Address = ,
  Tele_ipaddress) as Tele_ipaddress from tblTeleAccess where
  ((Tele_username='%u') AND (Tele_active='1'))
 
  AuthColumnDef 0, User-Password, check
  AuthColumnDef 1, GENERIC, reply
 
  #Radiator will never look for a DEFAULT user
  NoDefault
 
  #The AuthBy SQL clause sends default an Accounting Response, no
  logging
 
  /AuthBy
 
 
  Handler Realm=service1
 
  AuthBy sqlAuth
 
  #   AuthLog myAuthlogger
  #   PasswordLogFileName %L/Password-AAA01.log
 
  AcctLogFileName %L/Acct-AAA01-%Y-%m-%d.log
  AcctLogFileFormat %o, %{User-Name}, %{Framed-IP-Address}, \
  %{NAS-Identifier}, %{Acct-Status-Type}, %{Acct-Session-Time}
 
  /Handler
 
 
 
  Trace 4 logging:
 
  *** Received from 127.0.0.1 port 1153 
  Code:   Access-Request
  Identifier: 208
  Authentic:  1234567890123456
  Attributes:
  User-Name = h6-1@service1
  Service-Type = Framed
  NAS-IP-Address = 203.63.154.1
  NAS-Port = 1234
  Called-Station-Id = 123456789
  Calling-Station-Id = 987654321
  NAS-Port-Type = Async
  User-Password =
  152234=207203e24618889160216}x153
 
  Fri Jul 26 15:47:43 2002: DEBUG: Handling request with Handler
  'Realm=service1'
  Fri Jul 26 15:47:43 2002: DEBUG:  Deleting session for h6-1@service1,
  203.63.154.1, 1234
  Fri Jul 26 15:47:43 2002: DEBUG: Handling with Radius::AuthSQL
  Fri Jul 26 15:47:43 2002: DEBUG: Handling with Radius::AuthSQL: sqlAuth
  Fri Jul 26 15:47:43 2002: DEBUG: Query is: select Tele_password,
  concat(Framed-IP-Address = , Tele_ipaddress) as Tele_ipaddress from
  tblTeleAccess where ((Tele_username='h6-1@service1') AND
  (Tele_active='1'))
 
  Fri Jul 26 15:48:29 2002: ERR: Execute failed for 'select Tele_password,
  concat(Framed-IP-Address = , Tele_ipaddress) as Tele_ipaddress from
  tblTeleAccess where ((Tele_username='h6-1@service1') AND
  (Tele_active='1'))': MySQL server has gone away
  Fri Jul 26 15:48:52 2002: ERR: Could not connect to SQL database with
  DBI-connect dbi:mysql:radiusaccess:x.x.x.x:3306, ***, ***:  Can't
  connect
  to MySQL server on 192.168.87.11 (10065)
  Fri Jul 26 15:48:52 2002: DEBUG: Radius::AuthSQL looks for match with
  h6-1@service1
  Fri Jul 26 15:48:52 2002: DEBUG: Radius::AuthSQL ACCEPT:
  Fri Jul 26 15:48:52 2002: DEBUG: Access

(RADIATOR) SQL server fallback behaviour

2002-07-29 Thread alexander . deboer 

Dear all,

Using Radiator in a high-availability environment, I encounter a somewhat
random delay time before Radiator proceeds after a SQL-server failure.

I'm using Radiator-3.1 with two SQL databases: if the Master DB fails,
Radiator falls back to the Slave DB.

The trace 4 logging below is produced using radpwtst after disabling the
connection between Radiator and the primairy database server.

After failing the select query, Radiator waits most of time 46 seconds
(sometimes it takes even longer) before checking the SQL connection and
falling back to the secondary database server.

What is the origin of this delay time (46 seconds)? Can I shorten it? Is
anybody familiar with this behaviour?

Thanks in advance,

Alexander de Boer


AuthBy SQL
Identifier sqlAuth

#master database
DBSource dbi:mysql:radiusaccess:x.x.x.x:3306
DBUsername ***
DBAuth ***
Timeout 10

#slave database
DBSource dbi:mysql:radiusaccess:y.y.y.y:3306
DBUsername ***
DBAuth ***
Timeout 10

AuthSelect select Tele_password, concat(Framed-IP-Address = ,
Tele_ipaddress) as Tele_ipaddress from tblTeleAccess where
((Tele_username='%u') AND (Tele_active='1'))

AuthColumnDef 0, User-Password, check
AuthColumnDef 1, GENERIC, reply

#Radiator will never look for a DEFAULT user
NoDefault 

#The AuthBy SQL clause sends default an Accounting Response, no
logging

/AuthBy


Handler Realm=service1

AuthBy sqlAuth

#   AuthLog myAuthlogger
#   PasswordLogFileName %L/Password-AAA01.log 

AcctLogFileName %L/Acct-AAA01-%Y-%m-%d.log 
AcctLogFileFormat %o, %{User-Name}, %{Framed-IP-Address}, \
%{NAS-Identifier}, %{Acct-Status-Type}, %{Acct-Session-Time}

/Handler



Trace 4 logging:

*** Received from 127.0.0.1 port 1153 
Code:   Access-Request
Identifier: 208
Authentic:  1234567890123456
Attributes:
User-Name = h6-1@service1
Service-Type = Framed
NAS-IP-Address = 203.63.154.1
NAS-Port = 1234
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
NAS-Port-Type = Async
User-Password =
152234=207203e24618889160216}x153

Fri Jul 26 15:47:43 2002: DEBUG: Handling request with Handler
'Realm=service1'
Fri Jul 26 15:47:43 2002: DEBUG:  Deleting session for h6-1@service1,
203.63.154.1, 1234
Fri Jul 26 15:47:43 2002: DEBUG: Handling with Radius::AuthSQL
Fri Jul 26 15:47:43 2002: DEBUG: Handling with Radius::AuthSQL: sqlAuth
Fri Jul 26 15:47:43 2002: DEBUG: Query is: select Tele_password,
concat(Framed-IP-Address = , Tele_ipaddress) as Tele_ipaddress from
tblTeleAccess where ((Tele_username='h6-1@service1') AND (Tele_active='1'))

Fri Jul 26 15:48:29 2002: ERR: Execute failed for 'select Tele_password,
concat(Framed-IP-Address = , Tele_ipaddress) as Tele_ipaddress from
tblTeleAccess where ((Tele_username='h6-1@service1') AND
(Tele_active='1'))': MySQL server has gone away
Fri Jul 26 15:48:52 2002: ERR: Could not connect to SQL database with
DBI-connect dbi:mysql:radiusaccess:x.x.x.x:3306, ***, ***:  Can't connect
to MySQL server on 192.168.87.11 (10065)
Fri Jul 26 15:48:52 2002: DEBUG: Radius::AuthSQL looks for match with
h6-1@service1
Fri Jul 26 15:48:52 2002: DEBUG: Radius::AuthSQL ACCEPT: 
Fri Jul 26 15:48:52 2002: DEBUG: Access accepted for h6-1@service1
Fri Jul 26 15:48:52 2002: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 1153 
Code:   Access-Accept
Identifier: 208
Authentic:  1234567890123456
Attributes:
Framed-IP-Address = 10.125.91.63


dr. ir. Alexander P. de Boer
KPN Royal Dutch Telecom
Room L C7, P.O.Box 421, 2260 AK Leidschendam
The Netherlands

tel.: +31 70 4461788 (mobiel)  / fax.: +31 70 4463166
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.