How to use reference instead of printing attribute
Hi, We currently use 3.0.x version of freeRADIUS. I try to follow recommendations found in unlang man concerning use of attribute references. Extract from man: "We recommend using attribute references instead of printing attributes to a string, e.g. (User-Name == "%{Filter-Id}"). Attribute references will be faster and more efficient." It seems not to work correctly with my configuration. An example of debug which works with printing of attribute: (2) } # if ("%{proxy-reply:Packet-Type}" == "Access-Accept") = ok (2) if ("%{proxy-reply:Packet-Type}" == "Access-Challenge") { (2) EXPAND %{proxy-reply:Packet-Type} (2) --> Access-Accept (2) if ("%{proxy-reply:Packet-Type}" == "Access-Challenge") -> FALSE (2) } # post-proxy = ok Corresponding configuration: if ("%{proxy-reply:Packet-Type}" == "Access-Challenge") { The same example using reference which do not work: (2) } # if ("%{proxy-reply:Packet-Type}" == "Access-Accept") = ok (2) if (&proxy-reply:Packet-Type == "Access-Challenge") { (2) ERROR: Failed retrieving values required to evaluate condition (2) } # post-proxy = ok Corresponding configuration: if (&proxy-reply:Packet-Type == "Access-Challenge") { Another test using directly integer value (2) } # if ("%{proxy-reply:Packet-Type}" == "Access-Accept") = ok (2) if (&proxy-reply:Packet-Type == 11) { (2) ERROR: Failed retrieving values required to evaluate condition (2) } # post-proxy = ok Corresponding configuration: if (&proxy-reply:Packet-Type == 11) { Same thing using following configuration: (2) if (&proxy-reply:Packet-Type == Access-Challenge) { (2) ERROR: Failed retrieving values required to evaluate condition Is there some limitations using references ? Weird thing is that reference works with Auth-Type attribute used in another place in my configuration: (6) if (&control:Auth-Type == WIFI-GW-Auth) { (6) if (&control:Auth-Type == WIFI-GW-Auth) -> TRUE Corresponding configuration: if (&control:Auth-Type == WIFI-GW-Auth) { Thanks for help. Nicolas Castel This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
I think the problem is that Packet-Type, as Client-Shortname and other request specific information are defined as virtual attributes in dictionary. They are not really present in vp list. Reference works fine with all others attributes. Sorry for inconvenience. Nicolas Castel This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
On 26 Mar 2015, at 06:34, Castel, Nicolas <nicolas.a.castel@capgemini.com> wrote:
I think the problem is that Packet-Type, as Client-Shortname and other request specific information are defined as virtual attributes in dictionary. They are not really present in vp list.
Reference works fine with all others attributes.
Correct. Hopefully one day the distinction will go away... It's a really stupid one. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Castel, Nicolas