(RADIATOR) "WARNING: No such attribute" for internal use

[Hugh Irvine]

Hello Toomas -

Yes I agree with you for most cases, but in this case the request is  
going to be forwarded by an AuthBy RADIUS (ROUNDROBIN/VOLUMEBALANCE/ 
LOADBALANCE), so adding the data to the request gets too messy.

Mark is using a ReplyHook to access the data anyway, so an additional  
line to remove it is trivial.

regards

Hugh


On 17 Feb 2006, at 17:37, Toomas Kärner wrote:

> Hello Hugh,
>
> Just a note....
> I actually prefer to store temp data in request packet because then  
> I don't
> have to bother to remove it in PostAuthHook and I can use it as
> searches/check attribute also.
> Rgds.
> Toomas
>
> Friday, February 17, 2006, 5:39:49 AM, you wrote:
>
>> Hello Mark -
>
>> Rather than storing the temporary data in the request packet, I
>> suggest you store it in the reply packet instead. Then your ReplyHook
>> can remove the temporary data before the reply is sent to the NAS.
>
>> hope that helps
>
>> regards
>
>> Hugh
>
>
>> On 17 Feb 2006, at 12:55, Mark Mackay - Orcon wrote:
>
>>> Hi all
>>>
>>> We're setting up proxy-radius to a customer, and want to store some
>>> information that we lookup in a PreHandlerHook for later re-use in
>>> a ReplyHook (to avoid a double unneeded SQL lookup, etc).
>>>
>>> The current solution I've done is to do a lookup in the PreHandler
>>> and add an attribute to the request packet:
>>>
>>>     Custom-Data = XYZ
>>>
>>> This doesn't get sent to the client, because Radiator comes back
>>> with log warnings after every proxied packet:
>>>
>>>     WARNING: No such attribute Custom-Data
>>>
>>> However in the ReplyHook - I can still access this information via:
>>>
>>>     $originalrequest->get_attr("Custom-Data")
>>>
>>> so everything works, except for the repeated warnings in the log.
>>>
>>>
>>>
>>> Maybe the solution is simply to accept and ignore these warnings -
>>> but I can't help but think there's a better way:
>>>
>>> - Is there a way to pass Variables between hooks (I've browsed the
>>> list but they only refer to global variables, but this would be per-
>>> request variables I guess).
>>>
>>> - Is there a way to silence these warnings elegantly -- e.g. a way
>>> to strip this attribute out from attempted transmission but keep it
>>> available from the hooks.
>>>
>>> - Maybe a dummy dictionary entry could be used to suppress the
>>> warning but not affect the proxy-target?
>>>
>>> Regards,
>>> Mark.
>
>
>> NB:
>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive (www.open.com.au/archives/
>> radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>
>
>


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
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, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


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