(RADIATOR) Using Radiator for Wholesale DialupandSessionDatabase
Hugh Irvine
hugh at open.com.au
Wed Jul 11 01:56:27 CDT 2001
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.
More information about the radiator
mailing list