Hello, I am upgrading from FR 1.1 to 3.0.4. I am struggling to understand the the syntax for upgrading my $GENERIC$ statement. I have only found 3 threads discussing, which I did non fully understand, and am not sure they covered my problem. In my old ldap.attrmap I have the following lines:

replyItem Framed-IP-Address dslIPAddress replyItem Idle-Timeout dslIdleTimeout replyItem $GENERIC$ dslACLin replyItem $GENERIC$ dslACLout replyItem $GENERIC$ dslINSPECTin replyItem $GENERIC$ dslINSPECTout replyItem $GENERIC$ dslStatus

The example ldap contents of dslACLin and dslACLout are:

dslACLin: cisco-avpair += "ip:inacl=OUTBOUND" dslACLout: cisco-avpair += "ip:outacl=FIREWALL"

So, in my mods-enabled/ldap, when I added:

valuepair_attribute = "dslACLin"

In my radtest reply, I do get a:

Cisco-AVPair = "ip:inacl=OUTBOUND"

But based on one of the other threads and the way that it is configured, I will assume that "valuepair_attribute =" is only good once? Good news for me however, down at the bottom of update{} I see the following.

# These are provided for backwards compatibility. # Where only a list is specified as the RADIUS attribute, # the value of the LDAP attribute is parsed as a valuepair # in the same format as the 'valuepair_attribute' (above). # control: += 'radiusCheckAttributes' # reply: += 'radiusReplyAttributes'

so I add:

reply: += 'dslACLout'

Then radiusd -X gets:

...

/usr/local/etc/raddb/mods-enabled/ldap[85]: Invalid source for list '+='

so I try :=, and = with the same. To be honest, I dont know what the source list is. After reading man unlang I see that there is "update <list>" but then again, it says right above the block that this is not a unlang update format so, I am still lost. So I try this:

reply:Cisco-AVPair += 'dslACLout'

And the server will start, but it does not parse out the avpair, this is the radius reply:

Cisco-AVPair = "cisco-avpair += \"ip:outacl=FIREWALL\""

So I dont know what I am doing wrong there, but I also bear in mind that this is just a "compatibility" feature, so when that gets dropped I will still be in the same spot. That makes me wonder about how I should have done that in the first place. I suppose I used GENERIC because it was in the same file as the other attributes, I tried it and it worked. Is there a "more correct" way of doing that for long term support? Like creating dictionary entries for those attributes then map them? Also, as an interim solution until I can update my schema and management applications, if I add dslACLout to the dictionary, and map it, then is it possible to use unlang and regex in post-auth/"update reply" to parse "cisco-avpair +=" out of dslACLout and then add it back in as cisco-avpair? Thanks in advance any help, Cody