Cisco-AVpair accounting client-mac-address with unlang

[Joe Maimon]

Hi Alan,

I could use vsa hack. But it is a hack and its impact is a bit larger 
than the actual functionality I want. I just want to leave everything 
else unchanged but to have the mac address represented as 
calling-station-id, which for anything ethernet and not POTS related, it is.

unlang or other directed processing is the proper solution in my view, 
and it is working. It is just that I must predict which avpair to 
operate on which is troubling. In a start message, its the second one. 
In interim-update, its the fourth. For my purposes, only the Start one 
is of value, but having to know the order of attributes seems to be a 
bit flimsy.

Its problematic enough that a NAS can behave badly when sending them 
attributes in the wrong order. (cisco-avpair = lcp:interface-config="")

(And how does the vsa_hack deal with this form of the avpair?)

It is quite normal to have multiple attributes of the same name in a vp 
list. Matching against them all seems to be the normal behavior.

pairmove() and pairxlatmove() do this.
rlm_policy does this.
unlang does not seem to do this.

It does make the code a bit more hairy - I have been making a stab at 
this and it seems to be quite ugly.

Your idea to make it explicit is interesting, but does not seem to be 
inline with previous behavior, plus as it is pointed out, it is probably 
what is wanted more often than not.

Perhaps it could be made explicit to just check the Nth match, but thats 
exactly what the array operators do already.

Perhaps an array symbol of [*] for all. Or an [#] for the number of 
attributes and/or a way to loop through them.

Thanks,

Joe




Alan DeKok wrote:
> Joe Maimon wrote:
>> According to what I see turning on cisco vsa hack can overwrite any
>> existing attributes that happen to match the value in the avpair
>
>    The Cisco boxes don't send:
>
> 	Cisco-AVPair = "foo = bar"
> 	foo = bar
>
>    *both* in the same packet.
>
>> and
>> also seems to possibly delete information from the avpair -- its not
>> clear to me exactly what it does.
>
>    It's pretty simple.  See my previous message.
>
>    Yes... it deletes data from the avpair.  That's what it's *supposed*
> to do.  Do you really want tons of attributes like:
>
> 	foo-bar-baz = "foo-bar-baz = value"
>
>    or would it be saner to have:
>
> 	foo-bar-baz = "value"
>
>   ?
>
>    The NAS sends the first form, (Or Cisco-AV-Pair = "foo-bar-baz =
> value), and we re-write it into a form that isn't retarded.
>
>    Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>