(RADIATOR) Using Radiator for WholesaleDialupandSessionDatabase

Hugh Irvine hugh at open.com.au
Wed Jul 11 20:33:24 CDT 2001


Hello Tom -

If you are using different CalledStationId's, then you can use a 
RewriteUsername to add the realm and use the special characters %n 
and %u to store both forms of the username in the session database 
(you will have to add a field for the rewritten one). Then you can 
use custom queries in the session database to use the correct one for 
checking simultaneous use, as well as writing both forms.

hth

Hugh


At 13:53 -0400 01/7/11, Tom Daly wrote:
>The DNIS defines who the call belongs to. Each wholesaler is given each a
>unique DNIS.
>
>--Tom
>
>----- Original Message -----
>From: "Hugh Irvine" <hugh at open.com.au>
>To: "Tom Daly" <tomdaly at metro2000.net>; <radiator at open.com.au>
>Sent: Wednesday, July 11, 2001 2:56 AM
>Subject: Re: (RADIATOR) Using Radiator for WholesaleDialupandSessionDatabase
>
>
>>
>>  Hello Tom -
>>
>>  My point is, how are you going to decide how to apply a
>>  RewriteUsername if you don't know who the customer belongs to?
>>
>>  regards
>>
>>  Hugh
>>
>>
>>  At 12:31 -0400 01/7/9, Tom Daly wrote:
>>  >I would say that's the problem. Since I enforce a default simultaneous
>use
>>  >of 1 caller, if identical usernames are trying to login from two
>different
>>  >wholesalers, one will be rejected, therefore, I would like to be able to
>add
>>  >a realm name before the username goes into the Session DB.
>>  >
>>  >--Tom
>>  >
>>  >----- Original Message -----
>>  >From: "Hugh Irvine" <hugh at open.com.au>
>>  >To: "Tom Daly" <tomdaly at metro2000.net>; <radiator at open.com.au>
>>  >Sent: Saturday, July 07, 2001 12:50 AM
>>  >Subject: Re: (RADIATOR) Using Radiator for Wholesale
>>  >DialupandSessionDatabase
>>  >
>>  >
>>  >>
>>  >>  Hello Tom -
>>  >>
>>  >>  How are you going to know which customer is which?
>>  >>
>>  >>  regards
>>  >>
>>  >>  Hugh
>>  >>
>>  >>
>>  >>  At 12:51 -0400 01/7/6, Tom Daly wrote:
>>  >>  >Hugh,
>>  >>  >
>>  >>  >I would say my problem then is this. I am using CalledStation.pm to
>send
>>  >>  >users to radius proxy which does not use a realm, so users will
>dialup
>>  >with
>>  >>  >'username'. Now, our ISP does not require users to have a realm name
>>  >either,
>>  >>  >so they also dialup with 'username'. In the case of two identical
>>  >usernames
>>  >>  >between ISPs, one user will not be authenticated. Is there a way I
>can
>>  >add a
>>  >>  >realm name to the CalledStation.pm users for the sake of the session
>>  >>  >database, however, still send the proxy server just 'username'. I am
>>  >>  >guessing this will need to be done with some sort of hook.
>>  >>  >
>>  >>  >--Tom
>>  >>  >
>>  >>  >----- Original Message -----
>>  >>  >From: "Hugh Irvine" <hugh at open.com.au>
>>  >>  >To: "Tom Daly" <tomdaly at metro2000.net>; <radiator at open.com.au>
>>  >>  >Sent: Friday, July 06, 2001 12:21 PM
>>  >>  >Subject: Re: (RADIATOR) Using Radiator for Wholesale Dialup
>>  >>  >andSessionDatabase
>>  >>  >
>>  >>  >
>>  >>  >>
>>  >>  >>  Hi Tom -
>>  >>  >>
>>  >>  >>  By default Radiator uses the username string as received from the
>>  >>  >>  NAS, as that is what it needs if it is to query the NAS directly
>to
>>  >>  >>  verify connections.
>>  >>  >>
>>  >>  >>  regards
>>  >>  >>
>>  >>  >>  Hugh
>>  >>  >>
>>  >>  >>
>>  >>  >>  At 12:29 -0400 01/7/6, Tom Daly wrote:
>>  >>  >>  >Hi,
>>  >>  >>  >
>>  >>  >>  >By default, what entry does Radiator to put into the Session
>>  >Database?
>>  >>  >From
>>  >>  >>  >what I can see, it seems that it copies the <Username> as entered
>by
>>  >the
>>  >>  >>  >user, before any rewrite username, or other functions are used.
>>  >>  >>  >
>>  >>  >>  >Tom
>>  >>  >>  >
>>  >>  >>  >----- Original Message -----
>>  >>  >>  >From: "Hugh Irvine" <hugh at open.com.au>
>>  >>  >>  >To: "Tom Daly" <tomdaly at metro2000.net>; <radiator at open.com.au>
>>  >>  >>  >Sent: Friday, July 06, 2001 5:44 AM
>>  >>  >>  >Subject: Re: (RADIATOR) Using Radiator for Wholesale Dialup and
>>  >>  >>  >SessionDatabase
>>  >>  >>  >
>>  >>  >>  >
>>  >>  >>  >>
>>  >>  >>  >>  Hello Tom -
>>  >>  >>  >>
>>  >>  >>  >>  At 12:17 -0400 01/7/5, Tom Daly wrote:
>>  >>  >>  >>  >Hello,
>  > >>  >>  >>  >We are currently using Radiator and MySQL for a SessionDB. As
>a
>>  >>  >wholesale
>>  >>  >>  >>  >provider, we have two ways for our wholesalers to access
>>  >accounts.
>>  >>  >>  >>  >
>>  >>  >>  >>  >1. Per Port - An ISP is assigned a unique DNIS to which all
>>  >radius
>>  >>  >>  >requested
>>  >>  >>  >>  >are directed at thier radius server by proxy. We do this by
>the
>>  >>  >following
>>  >>  >>  >>  >method.
>>  >>  >>  >>  >
>>  >>  >>  >>  ><CalledStationId /......3400/>
>>  >>  >>  >>  >         <AuthBy RADIUS>
>>  >>  >>  >>  >                 Host xxx.xxx.xxx.xxx
>>  >>  >>  >>  >                 Secret VeryVerySecret
>>  >>  >>  >>  >                 AuthPort 1645
>>  >>  >>  >>  >                 AcctPort 1646
>>  >>  >>  >>  >                 Retries 5
>>  >>  >>  >>  >                 RetryTimeout 15
>>  >>  >>  >>  >         </AuthBy>
>>  >>  >>  >>  >
>>  >>  >>  >>  >This method seems to be slow, as we have to search through a
>few
>>  >>  >hundred
>>  >>  >>  >>  >DNISs for the same provider, if they have multiple DNISs. So
>I am
>>  >>  >looking
>>  >>  >>  >>  >for a way to use one statement that will search each
>providers
>>  >list
>>  >>  >of
>>  >>  >>  >>  >DNISs. Also, when a customer dials in, thier username is just
>>  >>  >username.
>>  >>  >>  >It
>>  >>  >>  >>  >there a way to make the session database show
>>  >username at isp_name.com,
>>  >>  >but
>>  >>  >>  >>  >still pass username to the proxy radius server?
>>  >>  >>  >>
>>  >>  >>  >>
>>  >>  >>  >>  If you are using the "CalledStationId.pm" file from the
>goodies
>>  >>  >>  >>  section of the distribution, there is almost no overhead, as
>the
>>  >>  >>  >>  number that is specified in the definition is used as a key to
>>  >>  >>  >>  directly access that clause. This is by far the fastest way to
>>  >>  >>  >>  process large numbers of phone numbers.
>>  >>  >>  >>
>>  >>  >>  >>  For your second question, you can use RewriteUsername(s) and
>>  >custom
>>  >>  >>  >>  queries for the SessionDatabase to do what you require.
>>  >>  >>  >>
>>  >>  >>  >>
>>  >>  >>  >>  >2. Per User - An ISP is assigned a Unique REALM via a <Realm>
>or
>>  >>  ><Handler
>>  >>  >>  >>  >Realm=> Clause. This gets very very complicated, so it there
>a
>>  >way to
>>  >>  >>  >>  >simplify this?
>>  >>  >>  >>
>>  >>  >>  >>
>>  >>  >>  >>  I don't understand the problem, sorry. Can you elaborate?
>>  >>  >>  >>
>>  >>  >>  >>
>>  >>  >>  >>  >Also, 1 ISP does not use a realm, so is there a way to make
>>  >>  >>  >>  >the session database show username at isp_name.com and the
>radius
>>  >server
>>  >>  >>  >check
>>  >>  >>  >>  >for just username?
>>  >>  >  > >>
>>  >>  >>  >>  See above - RewriteUsername(s) and custom queries.
>>  >>  >>  >>
>>  >>  >>  >>  regards
>>  >>  >>  >>
>>  >>  >>  >>  Hugh
>>  >>  >>  >>
>>  >>  >>  >>  --
>>  >>  >>  >>
>>  >>  >>  >>  NB: I am travelling this week, so there may be delays in our
>>  >>  >>  >correspondence.
>>  >>  >>  >>
>>  >>  >>  >>  Radiator: the most portable, flexible and configurable RADIUS
>>  >server
>>  >>  >>  >>  anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT,
>>  >Emerald,
>>  >>  >>  >>  Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc,
>etc.
>>  >>  >>  >>  Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT,
>MacOS
>>  >X.
>>  >>  >>  >>
>>  >>  >>
>>  >>  >>  --
>>  >>  >>
>>  >>  >>  NB: I am travelling this week, so there may be delays in our
>>  >>  >correspondence.
>>  >>  >>
>>  >>  >>  Radiator: the most portable, flexible and configurable RADIUS
>server
>>  >>  >>  anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT,
>Emerald,
>>  >>  >>  Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
>>  >>  >>  Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS
>X.
>>  >>  >>
>>  >>  >
>>  >>  >===
>>  >>  >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.
>>  >>
>>  >>  --
>>  >>
>>  >>  NB: I am travelling this week, so there may be delays in our
>>  >correspondence.
>>  >>
>>  >>  Radiator: the most portable, flexible and configurable RADIUS server
>  > >>  anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>>  >>  Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
>>  >>  Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
>>  >>
>>
>>  --
>>
>>  NB: I am travelling this week, so there may be delays in our
>correspondence.
>>
>>  Radiator: the most portable, flexible and configurable RADIUS server
>>  anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
>>  Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
>>  Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
>>
>
>===
>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.

-- 

NB: I am travelling this week, so there may be delays in our correspondence.

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
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