Hello Mark -
I understand what you are trying to do, but I need to explain a couple of
things so you understand what is happening here.
Firstly, when you configure any AuthBy RADIUS clause, it will cause Radiator to
fork a sub-process just to execute the AuthBy RADIUS clause. This is why you
are seeing the behaviour that you are. Radiator forks, executes the AuthBy
RADIUS, then that sub-process exits and you never get to the following AuthBy
clause. You could use the Synchronous parameter as you say, but the performance
implications are significant and this is not recommended.
So, how to deal with the problem?
Well, I think the first thing to do is check the IPASS replies to see if there
actually is an IP address present. If there is no IP address present in the
replies, you could reverse the order of the AuthBy's and do the allocation
first, then do the AuthBy RADIUS. This does however have the inconvenience of
allocating IP addresses even if the authentication fails, which is not good.
The second option is to do what you are doing currently with a ReplyHook, and
calling the Allocator from there. You can do this by looking up the AuthBy
DYNADDRESS clause using Radius::AuthGeneric::find('OurAllocator'), then calling
its handle_request function.
Thirdly, your AuthBy DYNADDRESS clause below is incorrect, as the PoolHint
declaration is saying to use an attribute in the original request called
"premium" which will contain the value of the pool to use. I don't think this
is what you want. It would probably be easiest to use the default PoolHint
(%{Reply:PoolHint}) and add a reply attribute by that name with the value of
"premium" before calling the allocator. You will of course have to strip the
PoolHint attribute from the reply as the last thing in your hook before exiting.
Here is an idea of the code you will need (there are example hooks in the file
"goodies/hooks.txt" in the distribution:
.....
my $allocator = Radius::AuthGeneric::find('OurAllocator');
my $rc = $allocator->handle_request($p, $rp);
.....
hth
Hugh
On Tue, 25 Jul 2000, Orcon Network Coordinator, Mark Mackay wrote:
> Hugh/Anyone -
>
> Here's our config (the relevant section):
> ----------------------
>
> <Handler>
> SessionDatabase SDBrealm
>
> <AuthBy GROUP>
> AuthByPolicy ContinueWhileAccept
>
> <AuthBy RADIUS>
> Host xxxx
> Secret xxxx
>
> # listen port for Netserver
> AuthPort 11812
> AcctPort 11813
>
> Retries 2
> RetryTimeout 15
>
> # Strip the ip addresses supplied by remote radius server
> ReplyHook file:"%D/neworcon/hook-ipass-reply.pl"
>
> </AuthBy>
>
>
> # now that we're authenticated, assign an IP address
> <AuthBy DYNADDRESS>
>
> Allocator OurAllocator
> PoolHint premium
>
> StripFromReply PoolHint, Framed-IP-Netmask
>
> </AuthBy>
>
> </AuthBy>
>
> </Handler>
>
> ----------------------
>
> Basically what we're after is to authenticate to iPass, then add an address
> from our AddressAllocator to the config. But whenever I try doing this, the
> AuthGROUP gets called - which then calls the AuthRadius, and the hook cleans
> up any bogus static addresses which (may) be supplied. But the second
> AuthGroup parameter - AuthDYNADDRESS doesn't seem to be called at all. Thus
> all that gets returned to the NAS is
>
> Service-Type=Framed-User, Framed-Protocol=PPP.
>
> No ip address.
>
> If I take the AuthGroup out -- it processes the iPass hook, then immediately
> replies with an Access-Accept and an IP address, then when the iPass reply
> comes back it returns Service-Type.., Framed-Protocol... (again with no
> Framed-IP).
>
> Any ideas (without resorting to Synchronous and Fork)?
>
> - Is there a way to execute and AuthBy section from a perl hook (ie. in the
> ReplyHook) - thereby calling Authby DYNADDRESS directly?
>
> .........................................................................
>
> Mark Mackay,
> Network Coordinator,
> Orcon Internet.
>
>
>
> ===
> Archive at http://www.starport.net/~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. 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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.