On 2 Jul 2013, at 11:57, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 02/07/13 11:37, Arran Cudbard-Bell wrote:
On 2 Jul 2013, at 08:53, Phil Mayers <p.mayers@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.cudbardb@freeradius.org> FreeRADIUS Development Team