Ah ok. So it appears the network guys are doing something non-compliant with
the RFCs around here. I hate that, but I'm not going to be able to change it
either, so I'll just maintain a small patch for our environment. Thanks for
clearing that up.
Alan DeKok wrote:
Geoff Silver <[EMAIL PROTECTED]> wrote:
As a side note, I had to change the Class attribute in dictionary.rfc2865 to
be a string, *not* octets. I changed:
....
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:
The dictionaries are solely for internal server purposes. The
reason Class is "octets" in the FreeRADIUS dictionaries is that it can
contain binary data.
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 original RFC's had "string" type for both printable & binary
data. FreeRADIUS moved to "string" and "octets", and the RFC's moved
to "text" and "string".
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
