(RADIATOR) AddToReply and Hosts

miko at yournetplus.com miko at yournetplus.com
Tue Apr 8 11:17:55 CDT 2003


Thanks Hugh, that's a good possibility for it,,, do you know if there is
a maximum on the characters that can be used when setting an Attr
value???

-Miko

-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au] 
Sent: Friday, April 04, 2003 8:50 PM
To: miko at yournetplus.com
Cc: radiator at open.com.au
Subject: Re: (RADIATOR) AddToReply and Hosts



Hello Miko -

Yes. The easiest way to do this is add whatever you need as additional 
attributes in the original request, which you can use as a temporary 
scratchpad area. Radiator automatically handles the housekeeping by 
deleting the in-memory request packets after processing.

regards

Hugh


On Saturday, Apr 5, 2003, at 10:46 Australia/Melbourne, 
<miko at yournetplus.com> wrote:

> Thanks Hugh,,, unfortunately that makes things a bit more difficult 
> for me... Is there anyway that I could use a variable created in a 
> preclienthook from within a replyhook???
>
> -Miko
>
> -----Original Message-----
> From: Hugh Irvine [mailto:hugh at open.com.au]
> Sent: Friday, April 04, 2003 5:13 PM
> To: miko at yournetplus.com
> Cc: radiator at open.com.au
> Subject: Re: (RADIATOR) AddToReply and Hosts
>
>
>
> Hello Miko -
>
> No this won't work. As you have discovered, AddToReply and 
> StripFromReply will not work in a <Host ..> clause.
>
> I think you will need to use a ReplyHook to manipulate the proxy 
> reply.
>
> You will find some example hooks in the file "goodies/hooks.txt".
>
> regards
>
> Hugh
>
>
> On Saturday, Apr 5, 2003, at 05:30 Australia/Melbourne, 
> <miko at yournetplus.com> wrote:
>
>> I am attempting to use the AddToReply and StripFromReply on a per 
>> host
>
>> basis with SQLRADIUS and am not having much luck... Upon looking at 
>> the source code and the archives it looks like it should work...
>>
>> Here are the relevant pieces of my config, I am almost certain I am 
>> doing it correctly.
>>
>>         HostSelect SELECT host%0, authport%0, acctport%0, secret%0, 
>> retries, retrytimeout, failurepolicy, \
>>                       serverhasbrokenaddresses, 
>> serverhasbrokenportnumbers, ignorereplysignature, 
>> noforwardaccounting,
>
>> rewriteusername, stripfromreply, addtoreply \
>>                     FROM RAD_RADIUSINFO \
>>                     WHERE realm = '%W'
>>
>>         HostColumnDef 0, Host
>>         HostColumnDef 1, AuthPort
>>         HostColumnDef 2, AcctPort
>>         HostColumnDef 3, Secret
>>         HostColumnDef 4, Retries
>>         HostColumnDef 5, RetryTimeout
>>         HostColumnDef 6, failurePolicy
>>         HostColumnDef 7, ServerHasBrokenAddresses
>>         HostColumnDef 8, ServerHasBrokenPortNumbers
>>         HostColumnDef 9, IgnoreReplySignature
>>         HostColumnDef 10, NoForwardAccounting
>>         HostColumnDef 11, RewriteUsername
>>         HostColumnDef 12, StripFromReply
>>         HostColumnDef 13, AddToReply
>>
>>
>> The record gets pulled and processed correctly, host response is as 
>> it
>
>> should be, but my StripFromReply and AddToReply are ignored...
>>
>> I also did a test with AUTH RADIUS entering in a <Host xx.xx.xx.xx> 
>> with an AddToReply statement in there and it was ignored as well...
>>
>> If anyone has any suggestions about ways to correct this, or to 
>> handle
>
>> this with a hook I would greatly appreciate any feedback. Just as an 
>> informational, I am wanting to do this in order to be able to specify

>> different reply attributes for the reply packet based on the realm, 
>> but I do not want to create a separate handler for each realm.
>>
>> TIA
>> -Miko
>>
>> ===
>> 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: have you included a copy of your configuration file (no secrets), 
> together with a trace 4 debug showing what is happening?
>
> --
> 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.
>
>
>

NB: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
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 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