(RADIATOR) Using Radiator for WholesaleDialupandSessionDatabase
Tom Daly
tomdaly at metro2000.net
Wed Jul 11 12:53:54 CDT 2001
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.
More information about the radiator
mailing list