[RADIATOR] tagged-string and tag0

Tim Jones tim.jones at fon.com
Fri Feb 27 08:07:08 CST 2015


Hello all,

We have recently run in to  a problem with one of our clients using
tagged-string attributes.
For instance when we receive an Accounting-Request with the attribute
Tunnel-Client-Endpoint untagged (that is, the first octet greater than
0x1f) unpacking works fine.
However when repacked being forwarded back to the client, Radiator adds a
tag of 0x00 by default to untagged tagged-string attributes. This causes
problems as 0 tag is undefined by RFC 2826 (only values 0x01 through to
0x1f are valid tags), and also that the attribute now no longer matches
what the client expects.

The issue is in Radius/Radius.pm, lines 315-326:

'tagged-string' => sub {
        if ($_[0] =~ /^(\d+):(.*)/)
        {
            # Tagged
            return pack 'ca*', $1, $2;
        }
        else
        {
            # Not tagged, implicit 0 tag
            return pack 'ca*', 0, $_[0];
        }
},

The else{} block adding an implicit 0 tag is the issue. I don't know how
other systems handle the undefined 0 tag, but the RFC does allow for
"untagged" tagged-string attributes.

Something like this should work and still be backwards-compatible I think:

'tagged-string' => sub {
        if ($_[0] =~ /^(\d+):(.*)/)
        {
            # Tagged
            return pack 'ca*', $1, $2;
        }
        else
        {
            # Not tagged
            # Leave untagged if 1st byte > 0x1f else implicit 0 tag
            my $tag_check = unpack 'c', $_[0];
            return ord $tag_check > 0x1f ? pack 'a*', $_[0] : pack 'ca*',
0, $_[0];
        }
},

This is untested in production, but seemed OK in my isolated test
environment.

Also, it still has an issue where if someone were to add a tagged-string
attribute (in code or config) with a tag greater than 31 e.g. AddToReply
Tunnel-client-Endpoint = "32:Whatever" will encode to 0x205768... which
will unpack as " Whatever" (note the leading space) and cause errors again.
But that's another issue :)

Many thanks, and kind regards,

[image: Fon] <http://www.fon.com/>Tim JonesSoftware Development+34 612345678
C/ Quintanavides 15, Edificio 2, Planta 1ª
Parque Empresarial Vía Norte de Metrovacesa
Las Tablas
28050 MadridSkype: tim.jones.fonAll information in this email is
confidential <http://corp.fon.com/legal/email-disclaimer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20150227/6c03eaba/attachment.html 


More information about the radiator mailing list