(RADIATOR) Re: Multiple Statements in AcctSQLStatement
Hi Andrew,
On Feb 6, 7:11pm, Andrew McManus wrote:
Subject: Multiple Statements in AcctSQLStatement
Hi Group,
We are also having problems with multiple entries for the one session being
inserted.
I have researched the Archive, but i need to know what the following effect
would be if I tried to include a second SQL Statement in the
AcctSQLStatement and how the accounting process would handle it.
I'm really new to Radiator, but am a long time SQL user.
You can run multiple queriesd by defining several AcctSQLStatements:
AcctSQLStatement delete from ACCOUNTINGTABLE where .
AcctSQLStatement INSERT INTO ACCOUNTINGTABLE .
ie:
delete from ACCOUNTINGTABLE where \
USERNAME='%{User-Name}' and \
ACCTSESSIONID='%{Acct-Session-Id}' and \
NASIDENTIFIER='%{NAS-IP-Address}' \
INSERT INTO ACCOUNTINGTABLE \
USERNAME, ACCTSESSIONID ... VALUES ('%{User-Name}', '%{Acct-Session-Id}'
Any help would be appreciated.
Regards
Andrew McManus
Senior NT Systems Engineer
Davnet Telecommunications Pty Ltd
Level 7, 209 Castlereagh Street
SYDNEY NSW 2000
Tel:61 2 9272 9600
Fax:61 2 9272 9624
mailto:[EMAIL PROTECTED]
www.davnet.com.au
-
Australian General Telecommunications Carrier License No 23
-
Disclaimer:
Please note that this correspondence is for the named
person's use only and may contain information that is
confidential and privileged.
If you received this correspondence in error, please
immediately delete it from your system and notify
the sender. Please ensure that you do not disclose,
copy or rely on any part of this correspondence if
you are not the intended recipient. We apologise for
any inconvenience and thank you for your assistance.
Please note that nothing in this correspondence shall
be construed or otherwise relied upon by the recipient
as an offer, acceptance of an offer, representation,
agreement or resolution of any kind.
-
-- End of excerpt from Andrew McManus
--
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 etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Fw: (RADIATOR-ANNOUNCE) web Interface
Is there any web interface with Radiator? Thanks Wiz
(RADIATOR) Setting time blocks and account expirations
Hi all, I've been working on a particular project for a couple of days now, but I haven't found the missing key that lets everything fit together... I am trying to accomplish a setup where users will buy a block of time (for instance 2 days (48 hours))... What I want to happen is that the user will be able to authenticate as many times as they want to the NAS/RADIUS system within that 48 hour period, but as soon as the specified 48 hours is over, the server will disconnect the user AND stop the user from authenticating again with the expired account. Any ideas? -- Wyness Casama === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Setting time blocks and account expirations
--- Forwarded mail from [EMAIL PROTECTED] Date: Wed, 7 Feb 2001 06:10:12 +1100 (EST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: BOUNCE [EMAIL PROTECTED]:Non-member submission from ["Wyness Casama" [EMAIL PROTECTED]] From mikem Wed Feb 7 06:10:08 2001 Received: by oscar.open.com.au (8.9.0/8.9.0) id GAA13229 for [EMAIL PROTECTED]; Wed, 7 Feb 2001 06:10:08 +1100 (EST) Received: from mail.roomlinx.com (roomlinx.com [209.153.237.60]) by perki.connect.com.au with ESMTP id FAA00747 (8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Wed, 7 Feb 2001 05:50:57 +1100 (EST) Received: from mail.roomlinx.com (roomlinx.com [209.153.237.60]) by perki.connect.com.au with ESMTP id FAA00747 (8.8.8/IDA-1.7 for [EMAIL PROTECTED]); Wed, 7 Feb 2001 05:50:57 +1100 (EST) Received: from rltech1 [209.153.237.43] by mail.roomlinx.com (SMTPD32-6.00) id A9C88F1011E; Tue, 06 Feb 2001 11:02:32 + From: "Wyness Casama" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Setting time blocks and account expirations Date: Tue, 6 Feb 2001 10:50:55 -0800 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Content-Type: text/plain; charset="iso-8859-1" Hi all, I've been working on a particular project for a couple of days now, but I haven't found the missing key that lets everything fit together... I am trying to accomplish a setup where users will buy a block of time (for instance 2 days (48 hours))... What I want to happen is that the user will be able to authenticate as many times as they want to the NAS/RADIUS system within that 48 hour period, but as soon as the specified 48 hours is over, the server will disconnect the user AND stop the user from authenticating again with the expired account. Any ideas? -- Wyness Casama ---End of forwarded mail from [EMAIL PROTECTED] -- 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 etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Setting time blocks and account expirations
Yes, if your using SQL set the SessionTimeout to the amount of time they bought, and restrict the login limit to one. After that is done you can use a stored procedure to hook to decrement the SessionTimeout each time the user disconnects and you get the Account-Session-Stop packet. This would be easy to accomplish using MS SQL Server or Sybase ASE -Original Message- From: Wyness Casama [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 1:12 PM To: [EMAIL PROTECTED] Subject: (RADIATOR) Setting time blocks and account expirations Hi all, I've been working on a particular project for a couple of days now, but I haven't found the missing key that lets everything fit together... I am trying to accomplish a setup where users will buy a block of time (for instance 2 days (48 hours))... What I want to happen is that the user will be able to authenticate as many times as they want to the NAS/RADIUS system within that 48 hour period, but as soon as the specified 48 hours is over, the server will disconnect the user AND stop the user from authenticating again with the expired account. Any ideas? -- Wyness Casama === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Setting time blocks and account expirations
Hello Wyness - You should use the "Expiration " check item. Have a look at section 13.1.4 in the Radiator 2.17.1 reference manual. regards Hugh On Wednesday 07 February 2001 07:12, Wyness Casama wrote: Hi all, I've been working on a particular project for a couple of days now, but I haven't found the missing key that lets everything fit together... I am trying to accomplish a setup where users will buy a block of time (for instance 2 days (48 hours))... What I want to happen is that the user will be able to authenticate as many times as they want to the NAS/RADIUS system within that 48 hour period, but as soon as the specified 48 hours is over, the server will disconnect the user AND stop the user from authenticating again with the expired account. Any ideas? -- Wyness Casama === Archive at http://www.starport.net/~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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Ascend Compatibility mode on 5300/5400
Hello Tim - On Tuesday 06 February 2001 18:32, Tim Johnson wrote: Does anyone know the syntax to enable Ascend Compatability mode on a 5400? I'm assuming it's the same as a 5300 or a 5200. Have a look at the file "goodies/ciscoConfig.txt" in the distribution. regards Hugh -- 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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
RE: (RADIATOR) Setting time blocks and account expirations
---
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 2:28 PM
To: Wyness Casama; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Setting time blocks and account expirations
Hello Wyness -
You should use the "Expiration " check item.
Have a look at section 13.1.4 in the Radiator 2.17.1 reference manual.
regards
Hugh
---
Thanks for your suggestion Hugh.
I had originally looked at that option but I wanted the epiration to happen
at an exact time. For instance, if a user bought a day's worth of internet
at 1:00p, I want that account to expire next day at 1:00p. The Expiration
field seems to expect the data to come in a 'FEB 06 2001' format. I guess it
might be possible to pass another timestamp into the DB...
--
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Chris Given
Sent: Tuesday, February 06, 2001 1:37 PM
To: 'Wyness Casama'; [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Setting time blocks and account expirations
Yes, if your using SQL set the SessionTimeout to the amount of time they
bought, and restrict the login limit to one. After that is done you can use
a stored procedure to hook to decrement the SessionTimeout each time the
user disconnects and you get the Account-Session-Stop packet.
This would be easy to accomplish using MS SQL Server or Sybase ASE
--
Hm This sounds feasable as well... What I can do is send the
SessionTimeout to the NAS like you have already suggested then I'll couple
that with the Expiration field suggestion that Hugh mentioned along with an
ExpirationTime. Here's what I'm trying to do with all of those fields: The
SessionTimeout field will hold the time bought (this will prevent the user
from staying logged on past the cut-off time as it's decremented from the
time bought. the timestamps in the start/stop accounting entries will be
used to determine remaining time,) then the Expiration date and
ExpirationTime will be used to keep the user from logging on after a certain
time. So, the whole process will be determined by a hook... So, let's try
some pseudo-code:
---
# Hello, Access-Request packet!
make username's sessionTimeout to be the difference left between ((current
date/time) and (expiration date/time));
if (username = valid) and (password = valid) {
if (username's SessionTimeout 0) and ((currentTime expirationTime) and
(currentDate Expiration) and (user is not on more than one instance){
allow login;
send remaining sessionTimeout to NAS;
}
else {
later, gator! you've been denied!;
}
---
Anyhow, it has been some time since I've even tried any programming. I
think this little exercise is a throwback that I learned from my TurboPascal
days back in high school.
Any thoughts about the problem at hand? (I already know my code stinks.
lol)
-- Wyness G. Casama
=== (here's my original post)
===
On Wednesday 07 February 2001 07:12, Wyness Casama wrote:
Hi all,
I've been working on a particular project for a couple of days now, but I
haven't found the missing key that lets everything fit together...
I am trying to accomplish a setup where users will buy a block of time
(for
instance 2 days (48 hours))... What I want to happen is that the user
will
be able to authenticate as many times as they want to the NAS/RADIUS
system
within that 48 hour period, but as soon as the specified 48 hours is over,
the server will disconnect the user AND stop the user from authenticating
again with the expired account.
Any ideas?
-- Wyness Casama
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Mysql
I have converted to using Mysql from a flat file everything seems to be working except some of my accounting packets get bumped to a backup server. They client seem to think the server is down when this happens. The server is up and running just doesn't seem to get the all of the accounting packets in time. This never seemed to happen when I used authby and stored the accounting packets in a flat file so I think its MySQL related. I have modified my online database to use the INSERT DELAYED but think I mainly need this in the Authby SQL section is there some equal to insert delayed that can be placed in with AuthSelect? Here is my AuthbySQL Any body have any ideas what I am doing wrong or is there a better way of correcting this problem. AuthBy SQL # Adjust DBSource, DBUsername, DBAuth to suit your DB DBSource dbi:mysql:radius DBUsernameX DBAuthX # Timeout 60 FailureBackoffTime 600 AuthSelect select PASSWORD, CHECKATTR, REPLYATTR from USERS where USERNAME='%n' # You may want to tailor these for your ACCOUNTING table AccountingTable %Y_%m_ACCOUNTING AccountingStopsOnly AuthColumnDef 0, User-Password, check AuthColumnDef 1, GENERIC, check AuthColumnDef 2, GENERIC, reply AcctColumnDef USERNAME,User-Name AcctColumnDef TIME_STAMP,Timestamp,integer AcctColumnDef TRUE_TIME,Timestamp,formatted-date,'%Y-%m-%d %H:%M:%S' AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer AcctColumnDef ACCTSESSIONID,Acct-Session-Id AcctColumnDef CONNECTSPEED,Connect-Speed AcctColumnDef CALLEDSTID,Called-Station-Id AcctColumnDef CALLINGSTID,Calling-Station-Id AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer AcctColumnDef ACCTTERMINATECAUSE,Ascend-Disconnect-Cause AcctColumnDef NASIDENTIFIER,NAS-IP-Address AcctColumnDef FRAMEDIPADDRESS,Framed-IP-Address /AuthBy
Re: (RADIATOR) Setting time blocks and account expirations
Hello Wyness -
You can also use the "Session-Timeout = until Time" reply item in conjunction
with the Time check item.
Section 13.2.7 in the manual.
regards
Hugh
On Wednesday 07 February 2001 11:55, Wyness Casama wrote:
---
From: Hugh Irvine [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 06, 2001 2:28 PM
To: Wyness Casama; [EMAIL PROTECTED]
Subject: Re: (RADIATOR) Setting time blocks and account expirations
Hello Wyness -
You should use the "Expiration " check item.
Have a look at section 13.1.4 in the Radiator 2.17.1 reference manual.
regards
Hugh
---
Thanks for your suggestion Hugh.
I had originally looked at that option but I wanted the epiration to happen
at an exact time. For instance, if a user bought a day's worth of internet
at 1:00p, I want that account to expire next day at 1:00p. The Expiration
field seems to expect the data to come in a 'FEB 06 2001' format. I guess
it might be possible to pass another timestamp into the DB...
--
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Chris Given
Sent: Tuesday, February 06, 2001 1:37 PM
To: 'Wyness Casama'; [EMAIL PROTECTED]
Subject: RE: (RADIATOR) Setting time blocks and account expirations
Yes, if your using SQL set the SessionTimeout to the amount of time they
bought, and restrict the login limit to one. After that is done you can
use a stored procedure to hook to decrement the SessionTimeout each time
the user disconnects and you get the Account-Session-Stop packet.
This would be easy to accomplish using MS SQL Server or Sybase ASE
--
Hm This sounds feasable as well... What I can do is send the
SessionTimeout to the NAS like you have already suggested then I'll couple
that with the Expiration field suggestion that Hugh mentioned along with an
ExpirationTime. Here's what I'm trying to do with all of those fields: The
SessionTimeout field will hold the time bought (this will prevent the user
from staying logged on past the cut-off time as it's decremented from the
time bought. the timestamps in the start/stop accounting entries will be
used to determine remaining time,) then the Expiration date and
ExpirationTime will be used to keep the user from logging on after a
certain time. So, the whole process will be determined by a hook... So,
let's try some pseudo-code:
---
# Hello, Access-Request packet!
make username's sessionTimeout to be the difference left between ((current
date/time) and (expiration date/time));
if (username = valid) and (password = valid) {
if (username's SessionTimeout 0) and ((currentTime expirationTime) and
(currentDate Expiration) and (user is not on more than one instance){
allow login;
send remaining sessionTimeout to NAS;
}
else {
later, gator! you've been denied!;
}
---
Anyhow, it has been some time since I've even tried any programming. I
think this little exercise is a throwback that I learned from my
TurboPascal days back in high school.
Any thoughts about the problem at hand? (I already know my code stinks.
lol)
-- Wyness G. Casama
=== (here's my original post)
===
On Wednesday 07 February 2001 07:12, Wyness Casama wrote:
Hi all,
I've been working on a particular project for a couple of days now, but I
haven't found the missing key that lets everything fit together...
I am trying to accomplish a setup where users will buy a block of time
(for
instance 2 days (48 hours))... What I want to happen is that the user
will
be able to authenticate as many times as they want to the NAS/RADIUS
system
within that 48 hour period, but as soon as the specified 48 hours is
over, the server will disconnect the user AND stop the user from
authenticating again with the expired account.
Any ideas?
-- Wyness Casama
===
Archive at http://www.starport.net/~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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Differentiated services on the same NAS
Hi Can anyone suggest where or how I can find any information on how to use radiator to preauthenticate users based on different service offerings. ie: Premium customers are authenticated every time (modems are always available) and All you can eat customers are authenticated based on the availablility of modems (set size modem pool) and are subsequently given a different ip subnet IP address. It may be that I need my radius to pre authenticate based on called_station_id .What would be the best way to do this? Is it possible for radiator to check the called_station_id number and then determine whether there are modems available in a modem pool prior to answering the call.? Can anyone suggest what I should be searching for in the archives. I am using a Cisco 3640 / 5300 access dial solution. Is this possible? or should I be looking at separating the NAS ports to separate NAS's. Thanks Tim === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Differentiated services on the same NAS
Hello Tim - On Wednesday 07 February 2001 17:06, Tim McCullagh wrote: Hi Can anyone suggest where or how I can find any information on how to use radiator to preauthenticate users based on different service offerings. ie: Premium customers are authenticated every time (modems are always available) and All you can eat customers are authenticated based on the availablility of modems (set size modem pool) and are subsequently given a different ip subnet IP address. It may be that I need my radius to pre authenticate based on called_station_id .What would be the best way to do this? Is it possible for radiator to check the called_station_id number and then determine whether there are modems available in a modem pool prior to answering the call.? Can anyone suggest what I should be searching for in the archives. I am using a Cisco 3640 / 5300 access dial solution. Is this possible? or should I be looking at separating the NAS ports to separate NAS's. Pre-authentication (checking radius prior to answering the phone) is a NAS-specific feature that you will need to check with your vendor. ONce you have the NAS configured, you would use an AuthBy PORTLIMITCHECK to do whatever checks you require. hth Hugh -- 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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
