Issue with VSA Attributes with Tags and 3.0x

[Peter Lambrechtsen]

On Sun, Aug 16, 2015 at 11:01 AM, Arran Cudbard-Bell <
a.cudbardb at freeradius.org> wrote:

>
> > On 15 Aug 2015, at 18:17, Peter Lambrechtsen <peter at crypt.co.nz> wrote:
> >
> > Hi
> >
> > I'm trying to pass a number of Tunnel-Type VSAs from RFC2868 back that
> have
> > multiple tags to a NAS using LDAP generic mapping attributes.
> >
> > This used to work in 2.x, but no longer works in 3.0.x
> >
> > In LDAP I have a multi-valued attribute that contains all the VSAs I want
> > to return:
> >
> > Tunnel-Type:1 = L2TP
> > Tunnel-Type:2 = L2TP
> > Tunnel-Medium-Type:1 = IP
> > Tunnel-Medium-Type:2 = IP
> > Tunnel-Server-Endpoint:1 = 1.2.3.4
> > Tunnel-Server-Endpoint:2 = 2.3.4.5
> >
> > Previously in 2.x I had the ldap.attrmap to set the $GENERIC$ point to
> the
> > ldap attribute I have defined
>
> *sigh* that was a a hack for backwards compatibility.  You should really
> use the generic attribute, and qualify your attributes in LDAP with list
> prefixes.
> I guess it should still be fixed though.
>

Yep... The $GENERIC$ was used in 2.x in the ldap.attrmap and $GENERIC$ was
a beautiful thing. Now in 3.0.x I am now using:

ldap {
        update {
...
                control:                        += 'proxyControl'
                request:                        += 'proxyRequest'
                reply:                          += 'proxyReply'
        }

And that works a treat for me now that I have fixed the tag issue :)

It's feeling a lot like map_to_request and callbacks should be altered in
> v3.1.x so that they produce a list of maps with the rhs resolved to
> TMPL_TYPE_DATA, instead of producing VPs. We then get rid of the 'op' field
> from VALUE_PAIRs and remove all the pairmove functions and switch
> everything to operate on map lists.
>

That too would make more sense, since there would be less steps in the
translation and places things like tag and other esoteric VSAs types that
get missed in code from when the data is sucked out of the database
whatever flavour that database maybe until it's on the wire.


> That's a lot cleaner where the destination is a list, or looking forward,
> a grouping attribute.
>
> I've merged your changes for v3.0.x, and done a similar thing for
> map_exec_to_vp which should fix the same issues when passing back pairs
> using backtick expansion and a list on the LHS.
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS development team
>
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/devel.html
>