(RADIATOR) AddToReply and Hosts

Tue Apr 8 17:03:49 CDT 2003

Hello Miko -

No there is no limit for attributes in memory.

Note that this is different to the limits on attributes that are 
encoded in radius requests, the values of which are limited to less 
than 255 octets as the length is defined by an eight bit field.

regards

Hugh

On Wednesday, Apr 9, 2003, at 02:17 Australia/Melbourne, 
<miko at yournetplus.com> wrote:

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

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.