Hello Steve -
There are some extensions to the AuthBy SQLRADIUS clause in Radiator 3.0 which should support your requirements. However, as mentioned in my previous mail, I would prefer to see the results of your testing using a simple default setup before going any further down this path. I think you will agree that if the results of a simple test are slower than what you are doing currently there is no point in pursuing this avenue. regards Hugh On Tue, 16 Apr 2002 00:35, Steve Katen wrote: > Hugh, > > I apologize. I did not type my request correctly. I wanted to speed up > the evaluation of a long list of Handlers. So yes, you are correct. > > So what about the below two questions? If I can't dynamically load IP > Adresses or AllowInReply and AddToReply then this is not a feasible > option. So if I am going to test I would like to get those working > correctly before testing. So how would I get those two as part of an > AUTHBY SQLRADIUS. > > 2) Dynamically load the IP address that is allocated based on the > replyHook? Currently the IP address is allocated via the Handler. I need > a way to pick the IP address out of different pools in the AUTHBY > SQLRADIUS. The table that I am reading everything from the HostSelect has > a field called POOL which has the POOL name and reference to a > PoolHint. How do I link those together? > > 3) Dynamically load the AllowInReply and AddToReply attributes? As you see > in the first AUTHBY RADIUS the attributes are there. However, in the > AUTHBY SQLRADIUS they are not. They would need tobe assigned by the > DNIS. The table that I am reading everything from the HostSelect has a > field called FILTER which has the AllowInReply and AddToReply > attributes. How do I link those together? > > > katen > > At 12:30 PM 4/13/2002 +1000, Hugh Irvine wrote: > >Hello Steve - > > > >I think you have misunderstood my suggestion. Using an AuthBy SQLRADIUS > >clause will not speed up proxy operation - this is determined by the > > length of time a given proxy target takes to respond. You question was > > whether there was some way to speed up the evaluation of a long list of > > Handlers based on Called-Station-Id, and my suggestions were to > > investigate either the AuthBy SQLRADIUS clause, or the CalledStationId.pm > > module (contained in the goodies directory). You will have to do some > > testing to ascertain whether or not either of these will speed up the > > overall operation. I suggest you try a simple example using the default > > configuration to see how long it takes compared to your current setup. > > > >In answer to your questions below, > > > >1. you can specify a default host in the AuthBy SQLRADIUS clause - this is > >just a warning, not an error > > > >yes you need to specify the database with the usual DBSource, DBUsername > > and DBSource lines > > > >For the other questions, I think you need to do the testing described > > above first to see whether or not the idea is worth pursuing. > > > >regards > > > >Hugh > > > >On Sat, 13 Apr 2002 02:11, Steve Katen wrote: > > > maybe this isn't that creative, but i cannot seem to get the logic to > > > work. I have an AUTHBY RADIUS that works perfectly. However, it is > > > too slow. To make it faster Hugh told me to try the AUTHBY SQLRADIUS > > > idea, and so here I am. > > > > > > I need an AUTHBY SQLRADIUDS / HostSelect that will be able to handle > > > the AUTHBY RADIUS below: > > > > > > <AuthBy RADIUS> > > > Identifier CheckRemoteRadius > > > IgnoreAccounting > > > IgnoreReplySignature > > > ServerHasBrokenAddresses > > > RejectEmptyPassword > > > NoForwardAccounting > > > NoDefault > > > > > > #USERNAME = username > > > #PASSWORD = password > > > <Host xxx.xxx.xxx.xxx> > > > Secret xxxx > > > AuthPort 1812 > > > Retries 3 > > > RetryTimeout 20 > > > </Host> > > > # FAILOVER SERVER > > > <Host xxx.xxx.xxx.xxx> > > > Secret xxxx > > > AuthPort 1812 > > > Retries 3 > > > RetryTimeout 20 > > > </Host> > > > ReplyHook > > > file:"/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy" # > > > FILTER NAME: STATIC-ALLOW > > > AllowInReply > > > Framed-IP-Address,Session-Timeout,Ascend-Data-Filter,Idle-Timeout > > > AddToReply > > > Service-Type=Framed-User,Framed-Protocol=PPP,Framed-Netmask=255.255.255 > > >.255 </AuthBy> > > > > > > I have been able to get some information from the radiator > > > documentation and I have gotten this far: > > > > > > <AuthBy SQLRADIUS> > > > Identifier CheckRemoteRadius > > > IgnoreAccounting > > > IgnoreReplySignature > > > ServerHasBrokenAddresses > > > RejectEmptyPassword > > > NoForwardAccounting > > > NoDefault > > > NumHosts 4 > > > HostSelect select TARGET_%0_AUTH, SHARED_SECRET, PORT, > > > RETRIES, TIMEOUT from PROXY2 where TARGET_%0_AUTH<>"" and DNIS= > > > substring('%{Called-Station-Id',7,4) and REALM='' and STATUS=1; > > > replyHook > > > file:"/usr/local/radiator/hooks/AllocateIPAddressOnReplyFromProxy" > > > </AuthBy> > > > > > > However, I run across a couple problems: > > > 1) When I restart radius I get this error: WARNING: No Hosts defined > > > for Radius::AuthSQLRADIUS at /etc/radius.cfg line 120. Did I forget > > > something? I am assuming I Need to tell the AUTHBY SQLRADIUS what > > > database to use... > > > 2) Can I dynamically load the IP address that is allocated based on the > > > replyHook? Currently the IP address is allocated via the Handler. I > > > need a way to pick the IP address out of different pools in the AUTHBY > > > SQLRADIUS. 3) Can I dynamically load the AllowInReply and AddToReply > > > attributes? As you see in the first AUTHBY RADIUS the attributes are > > > there. However, in the AUTHBY SQLRADIUS they are not. They would need > > > to be assigned by the DNIS. > > > > > > Any help would be greatly appreciated. > > > > > > katen > > > > > > > > > === > > > Archive at http://www.open.com.au/archives/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. -- 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 [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.