RE: hex:attribute-name behavior is changed
Hello, I've just opened an issue that looks very similar, this is probably the same: https://github.com/FreeRADIUS/freeradius-server/issues/2672 Regards, Nicolas.
Hi,
Previously the expansion %{hex:DHCP-Client-Hardware-Address} worked correctly by expanding to the mac address value inside the attribute. Now the latest master(#a88b05513956b21ec037383780f9b568eeb49124) is expanding the raw string "DHCP-Client-Hardware-Address" to hex.
However, %{hex:%{DHCP-Client-Hardware-Address} is working as expected(expands the value inside the attribute).
Is this behavior is an intended change or a mistake?
debug out: (1) if ("0x%{hex:DHCP-Client-Hardware-Address}" == "%{DHCP-Relay-Remote-Id}") { (1) EXPAND 0x%{hex:DHCP-Client-Hardware-Address} (1) EXPAND %{hex:DHCP-Client-Hardware-Address} (1) --> 444843502d436c69656e742d48617264776172652d41646472657373 (1) --> 0x444843502d436c69656e742d48617264776172652d41646472657373 (1) EXPAND %{DHCP-Relay-Remote-Id} (1) --> 0x00a0bc00000a
(0) if ("0x%{hex:%{DHCP-Client-Hardware-Address}}" == "%{DHCP-Relay-Remote-Id}") { (0) EXPAND 0x%{hex:%{DHCP-Client-Hardware-Address}} (0) EXPAND %{DHCP-Client-Hardware-Address} (0) --> 00:a0:bc:00:00:0a (0) EXPAND %{hex:%{DHCP-Client-Hardware-Address}} (0) (%{hex:00:a0:bc:00:00:0a}) (0) --> 00a0bc00000a (0) --> 0x00a0bc00000a
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 9 May 2019, at 04:57, Chaigneau, Nicolas via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hello,
I've just opened an issue that looks very similar, this is probably the same:
No, nothing to do with that. It's an intended change. Virtually every xlat expansion that previously took references now uses nested expansions instead, the notable exceptions are debug_attr and tag, but tag will probably go away soon, as we'll no longer support for <attr>:<tag> syntax and replace it with something more sane. xlats now work with boxed values and not strings, so there's no benefit to them using attribute references anymore when we can just return the boxed value from the pair instead. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Chaigneau, Nicolas