Garbled class attribute?
Geoff Silver
geoff+freeradius at uslinux.net
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
to
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
Description
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
25 for Class.
Length
>= 3
String
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