(RADIATOR) MySQL & Simultaneous-Use
Hugh Irvine
hugh at open.com.au
Tue Dec 18 19:25:11 CST 2001
Hello Andy -
I usually suggest to people that they add a column to the session database
table to store the rewritten username too and then specify the corresponding
queries to do "the right thing" (tm).
The reason the session database uses the original username is because that is
what must be queried on the NAS if you are doing strict limit checking.
regards
Hugh
On Wed, 19 Dec 2001 03:55, Andy Dills wrote:
> Sorry about the blank email. I had tried to cancel the email, as I had
> thought I had figured out the problem, but had accidently sent it instead
> of cancelling (cntrl-x being right next to cntrl-c).
>
> Anyways, the problem is this: I use the standard realm stripping
> RewriteUsername s/^([^@]+).*/$1/ in my <Realm...> clauses. However, the
> full user at realm.com is being injected into the session db. This isn't
> good, because I have some NASes that send plain usernames with no realms,
> which get routed with a DefaultRealm statement. These logins do not have
> the realm attached when injected into the session db.
>
> As a result, simultaneous use doesn't work properly, as
> andy at xecu.net != andy
>
> Any ideas on how to fix this? My initial thought was a RewriteUsername
> clause inside of the <SessionDatabase SQL> statement. That, of course,
> isn't kosher.
>
> Thanks!
> Andy
>
>
>
> Here's some trace 4:
>
> First, when the realm is specified:
>
> Tue Dec 18 05:24:21 2001: DEBUG: Handling request with Handler
> 'Realm=xecu.net'
> Tue Dec 18 05:24:21 2001: DEBUG: Rewrote user name to xandy
> Tue Dec 18 05:24:21 2001: DEBUG: xecu.net Deleting session for
> xandy at xecu.net, 203.63.154.1, 1234
> Tue Dec 18 05:24:21 2001: DEBUG: do query is: delete from RADONLINE where
> NASIDENTIFIER='203.63.154.1' and NASPORT=01234
>
> Tue Dec 18 05:24:21 2001: DEBUG: Handling with Radius::AuthGROUP
> Tue Dec 18 05:24:21 2001: DEBUG: Handling with Radius::AuthSQL
> Tue Dec 18 05:24:21 2001: DEBUG: Handling with Radius::AuthSQL:
> Tue Dec 18 05:24:21 2001: DEBUG: Query is: select ENCRYPTEDPASSWORD,
> CHECKATTR, REPLYATTR from SUBSCRIBERS where USERNAME='xandy'
>
> Tue Dec 18 05:24:21 2001: DEBUG: Radius::AuthSQL looks for match with
> xandy
> Tue Dec 18 05:24:21 2001: DEBUG: Query is: select NASIDENTIFIER, NASPORT,
> ACCTSESSIONID, FRAMEDIPADDRESS from RADONLINE where
> USERNAME='xandy at xecu.net'
>
> Tue Dec 18 05:24:21 2001: DEBUG: Radius::AuthSQL ACCEPT:
> Tue Dec 18 05:24:21 2001: DEBUG: Access accepted for xandy
> Tue Dec 18 05:24:21 2001: DEBUG: Handling request with Handler
> 'Realm=xecu.net'
> Tue Dec 18 05:24:21 2001: DEBUG: Rewrote user name to xandy
> Tue Dec 18 05:24:21 2001: DEBUG: xecu.net Adding session for
> xandy at xecu.net, 203.63.154.1, 1234
> Tue Dec 18 05:24:21 2001: DEBUG: dFrom owner-radiator at open.com.au Tue Dec 18 18:29:44 2001
Received: (from majordomo at localhost)
by server1.open.com.au (8.11.0/8.11.0) id fBJ0TiT05096
for radiatorzz-list; Tue, 18 Dec 2001 18:29:44 -0600
X-Authentication-Warning: server1.open.com.au: majordomo set sender to owner-radiator at open.com.au using -f
Received: from MAIL.netspeed.com.au ([203.22.239.1])
by server1.open.com.au (8.11.0/8.11.0) with ESMTP id fBJ0Th305093
for <radiator at open.com.au>; Tue, 18 Dec 2001 18:29:43 -0600
Received: from [203.22.237.2] by MAIL.netspeed.com.au (NTMail 5.06.0016/NU0474.00.d45cc3bb) with ESMTP id srftabaa for radiator at open.com.au; Wed, 19 Dec 2001 13:08:43 +1100
Message-ID: <009201c18832$10e3ee40$6f00a8c0 at netspeed.com.au>
From: "Brian Morris" <brian at netspeed.com.au>
To: <radiator at open.com.au>
References: <Pine.GSO.4.32.0112181139180.17624-100000 at shell.xecu.net>
Subject: (RADIATOR) Possible Gotcha in Radiator RADONLINE
Date: Wed, 19 Dec 2001 13:08:35 +1100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-radiator at open.com.au
Precedence: bulk
List-Id: <radiator.list-id.open.com.au>
Hi All,
I thought I would share something that had me very confused for a couple of
hours this morning. It is not really a bug, rather my poor implementation
of reporting the contents of Radonlne. But it may help some others on the
list.
This relates to NAS's that send interim 'Alive' packets in addition to start
and stop packets. (For people in Australia - Comindico do this)
It appears that whichever module manages the Radonline table takes this
packet and adds or replaces the current radonline details with these updated
details including specifically the timestamp field.
I have an inhouse web page we use to report active users using the radonline
database. This page calculates the time a user has been online as the time
difference between 'now' and the value in the radonline record 'timestamp'.
This works fine for NAS's that don't send alive packets, but it reports
incorrect information for those that do - it reports the time since the last
alive packet instead of the time since login.
After reading the doco the solution I found is to change the default
RADONLINE table and create a custom AddQuery to also insert acctsessiontime
values into radonline. I then had to adjust my web page to calculate and
report based on both the timestamp and the interim acctsessiontime.
I hope this helps others. It had me convinced that a NAS 'upgrade' was
causing users to drop off after 15 minutes (ie the time between 'alive'
packets)
Regards, Brian Morris
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
o query is: delete from RADONLINE where
> NASIDENTIFIER='203.63.154.1' and NASPORT=01234
>
> Tue Dec 18 05:24:21 2001: DEBUG: do query is: insert into RADONLINE
> (USERNAME, NASIDENTIFIER, NASPORT, ACCTSESS
> IONID, TIME_STAMP, FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) values
> ('xandy at xecu.net', '203.63.154.1', 01234, '00001234', 1008653061, '',
> 'Async', 'Framed-User')
>
> Tue Dec 18 05:24:21 2001: DEBUG: Handling with Radius::AuthGROUP
> Tue Dec 18 05:24:21 2001: DEBUG: Handling with Radius::AuthSQL
> Tue Dec 18 05:24:21 2001: DEBUG: Handling accounting with Radius::AuthSQL
> Tue Dec 18 05:24:21 2001: DEBUG: Accounting accepted
>
>
>
> And now when the realm is not specified:
>
>
>
> Tue Dec 18 16:29:20 2001: DEBUG: Handling request with Handler
> 'Realm=xecu.net'
> Tue Dec 18 16:29:20 2001: DEBUG: Rewrote user name to xandy
> Tue Dec 18 16:29:20 2001: DEBUG: xecu.net Deleting session for xandy,
> 203.63.154.1, 1234
> Tue Dec 18 16:29:20 2001: DEBUG: do query is: delete from RADONLINE where
> NASIDENTIFIER='203.63.154.1' and NASPORT=01234
>
> Tue Dec 18 16:29:20 2001: DEBUG: Handling with Radius::AuthGROUP
> Tue Dec 18 16:29:20 2001: DEBUG: Handling with Radius::AuthSQL
> Tue Dec 18 16:29:20 2001: DEBUG: Handling with Radius::AuthSQL:
> Tue Dec 18 16:29:20 2001: DEBUG: Query is: select ENCRYPTEDPASSWORD,
> CHECKATTR, REPLYATTR from SUBSCRIBERS where USERNAME='xandy'
>
> Tue Dec 18 16:29:20 2001: DEBUG: Radius::AuthSQL looks for match with
> xandy
> Tue Dec 18 16:29:20 2001: DEBUG: Query is: select NASIDENTIFIER, NASPORT,
> ACCTSESSIONID, FRAMEDIPADDRESS from RADONLINE where USERNAME='xandy'
>
> Tue Dec 18 16:29:20 2001: DEBUG: Radius::AuthSQL ACCEPT:
> Tue Dec 18 16:29:20 2001: DEBUG: Access accepted for xandy
> Tue Dec 18 16:29:20 2001: DEBUG: Handling request with Handler
> 'Realm=xecu.net'
> Tue Dec 18 16:29:20 2001: DEBUG: Rewrote user name to xandy
> Tue Dec 18 16:29:20 2001: DEBUG: xecu.net Adding session for xandy,
> 203.63.154.1, 1234
> Tue Dec 18 16:29:20 2001: DEBUG: do query is: delete from RADONLINE where
> NASIDENTIFIER='203.63.154.1' and NASPORT=01234
>
> Tue Dec 18 16:29:20 2001: DEBUG: do query is: insert into RADONLINE
> (USERNAME, NASIDENTIFIER, NASPORT, ACCTSESS
> IONID, TIME_STAMP, FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) values
> ('xandy', '203.63.154.1', 01234, '00001234', 1008692960, '', 'Async',
> 'Framed-User')
>
> Tue Dec 18 16:29:20 2001: DEBUG: Handling with Radius::AuthGROUP
> Tue Dec 18 16:29:20 2001: DEBUG: Handling with Radius::AuthSQL
> Tue Dec 18 16:29:20 2001: DEBUG: Handling accounting with Radius::AuthSQL
> Tue Dec 18 16:29:20 2001: DEBUG: Accounting accepted
>
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Andy Dills 301-682-9972
> Xecunet, LLC www.xecu.net
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Dialup * Webhosting * E-Commerce * High-Speed Access
>
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' 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 radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.
More information about the radiator
mailing list