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. 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. A better solution, seeing as we now pre-parse all conditions and xlat expansions, might be to add unknown attributes at parse time. The server didn't do this when we first started using DICT_ATTR pointers in VALUE_PAIRs. Arran Cudbard-Bell <a.cudba...@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
