On 2 Jul 2013, at 11:57, Phil Mayers <p.may...@imperial.ac.uk> wrote:
> 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) It appears Alan has already done what I just suggested below. update reply { Vendor-1-Attr-2 := 0x01 } if (&reply:Vendor-1-Attr-2) { ok } (0) update reply { (0) Vendor-1-Attr-2 := 0x01 (0) } # update reply = notfound (0) ? if (&reply:Vendor-1-Attr-2) (0) ? if (&reply:Vendor-1-Attr-2) -> TRUE (0) if (&reply:Vendor-1-Attr-2) { (0) - entering if (&reply:Vendor-1-Attr-2) {...} (0) [ok] = ok (0) - if (&reply:Vendor-1-Attr-2) returns ok Sending Access-Reject of id 208 from 0.0.0.0 port 1812 to 127.0.0.1 port 54941 Attr-26.1.2 = 0x01 Waking up in 4.9 seconds. Radclient gets confused though... rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=208, length=29 Attr-26 = 0x00000001020301 So you may in fact now be able to use them in conditions, and be able to ignore everything I previously said. Arran Cudbard-Bell <a.cudba...@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html