rlm_perl - Asymmetric attribute encoding

Scott Ireland sireland+freeradius at ualberta.net
Tue Apr 1 18:35:18 CEST 2014


On Mon, Mar 31, 2014 at 6:29 PM, Alan DeKok <aland at deployingradius.com>wrote:

>   Yes.  The parser is forgiving.  If you give a hex string to an
> attribute of "octets" type, it parses the hex into binary data.  If you
> give a printable string to an "octets" attribute, it assumes you're
> being lazy.  The printable string is used as the value for the attribute.
>
>
OK.  So it's the "forgivingness" that gives the appearance of inconsistency
here because of that extra conversion.


>   No.  The binary attributes are printed and parsed as hex strings:
> 0xabcdef.  That is the normal (and expected) method of operation.
>

Knowing that now makes a big difference, so yes, treating them as
"0x"-prepended hex strings at both ends does give me consistent behaviour.
 Things seem to work in the general case with something like:

$RAD_REPLY{'State'} = "0x".unpack("H*",$data);

and

my $data = pack("H*",substr($RAD_REPLY{'State'},2)); # remove leading '0x'
before pack


to move data in and out of the attribute.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140401/850a7f4d/attachment.html>


More information about the Freeradius-Users mailing list