Garbled class attribute?

Geoff Silver geoff+freeradius at
Thu Aug 17 22:10:48 CEST 2006

Stefan Winter wrote:
>>>   It works for me, so my guess is that something else in your
>>> configuration is setting Class to that value.
>> Okay, I'll bite - so what on earth might be causing that?  I'm not doing
>> any rewriting, and both the Filter-Id and the Split-Tunnel-List attributes
>> come back as strings.  I thought maybe it was getting confused on the Class
>> since it contains an =, but changing that to an _ doesn't help.  Is this
>> perhaps coming back from the proxy server, and if so, is there a way to use
>> my local Class attribute instead?
> Well, you can use := instead of = , this overwrites any Class attribute that a 
> proxy may have sent. See if that helps.
> Stefan

Setting Proxy-to-Realm=UAS doesn't seem to work... not sure why. 
Nevertheless, configuring attr_filter to only use attributes I care about from 
the proxy seems to work just fine.

As a side note, I had to change the Class attribute in dictionary.rfc2865 to 
be a string, *not* octets.  I changed:

ATTRIBUTE       Class                                   25      octets


ATTRIBUTE       Class                                   25      string

to make it work (and be readable), though I can't tell if that's just an 
oddity of the Cisco VPN 3000 and the way it was previously implemented here or 
what.  According to the RFC:

5.25. Class


       This Attribute is available to be sent by the server to the client
       in an Access-Accept and SHOULD be sent unmodified by the client to
       the accounting server as part of the Accounting-Request packet if
       accounting is supported.  The client MUST NOT interpret the
       attribute locally.

    A summary of the Class Attribute format is shown below.  The fields
    are transmitted from left to right.

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |     Type      |    Length     |  String ...


       25 for Class.


       >= 3


       The String field is one or more octets.  The actual format of the
       information is site or application specific, and a robust
       implementation SHOULD support the field as undistinguished octets.

       The codification of the range of allowed usage of this field is
       outside the scope of this specification

More information about the Freeradius-Users mailing list