On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.may...@imperial.ac.uk>
wrote:
On 07/02/2013 07:52 AM, Arran Cudbard-Bell wrote:
This may work for 2.x.x but definitely wont't work for 3.0 which
uses direct DICT_ATTR pointer comparisons in some places (instead
of comparing vendor/attribute number).
So... what *can* you do with Vendor-X-Attr-Y?
Use it to figure out which dictionary entries you're missing.
I was hoping for something more specific than that ;o)
So you can't compare them; can you set them:
update reply {
Vendor-X-Attr-Y = 0xff
}
?
Can you xlat them?
update request {
Tmp-String-0 = "%{Vendor-X-Attr-Y}"
}
?
Or are they basically display-only i.e. debug output and detail file?
We can't modify the dictionaries dynamically after startup without
locking the tree (on every read/write), else we could of added
unknown attributes as octet type attributes.
The compromise is to dynamically allocate fake DICT_ATTR entries for
attributes which couldn't be resolved in the dictionaries, or that
have values which don't match their data type (64bit value in integer
type for example).
As these DICT_ATTRs are dynamically allocated and unique to each
request, comparing the pointers doesn't result in a match.
Ah.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
