I have searched. I am unsatisfied with the results. The cisco_vsa_hack may have unintended consequences. unlang should properly loop over the vp list, like other paircompares do. I have patched this kind of oversight before elsewhere, not sure if thats the right approach here. Bryan Campbell wrote:

Been there, done that . . . search the mailing list archives from last month for this topic.

The hack turns the av-pair strings into attributes (if you add them to the dictionary).

Then you just have to adjust your SQL to address them for writing to the database.

Again . . . search the mailing list archives. This has been done before by at least a dozen people.

bbc

...

I have this in preacct, and it works.

if ("%{Cisco-AVpair[3]}" =~ /^client-mac-address=(.+)$/) { if (!Calling-Station-Id) { update request { Calling-Station-Id := "%{1}" } } }

However this is ugly. I dont want to have to know which Cisco-AVpair it is, it should work whichever the order or number there is. It does not seem to work any other way.

I know other directions to head include cisco_vsa_hack or the rlm_policy and others.

I would appreciate any tips.

Thanks,

Joe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Joe Maimon wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Alan DeKok <aland@deployingradius.com> writes:

Maybe something like:

if (*Cisco-AVpair =~ /^client-mac-address=(.+)$/) {

i.e. "*" means "any one matches"

Is it ever useful to match on a single one? You'll always have a hard time knowing the order and number of attributes. I believe you could just as well overload the meaning of if (Cisco-AVpair =~ /^client-mac-address=(.+)$/) { to mean "any one matches" regardless of the number of Cisco-AVpair attributes. Bjørn

According to what I see turning on cisco vsa hack can overwrite any existing attributes that happen to match the value in the avpair and also seems to possibly delete information from the avpair -- its not clear to me exactly what it does. In any event, I just need to solve this "little" problem and all will be well. Thanks, Joe Bryan Campbell wrote:

See the following link and the associated reference posts.

What you need is already built-in. It takes two steps (5 minutes) to get access to the attributes. The only question then is how you will format your SQL statements to write the attributes out to the database (another 5 minutes).

http://lists.freeradius.org/mailman/htdig/freeradius-users/2009-December/msg...

bbc -

...

Joe Maimon wrote:

...

I have searched. I am unsatisfied with the results.

The cisco_vsa_hack may have unintended consequences.

Like... ?

...

unlang should properly loop over the vp list, like other paircompares do.

I would prefer that behavior to be *explicit* rather than *implicit*.

...

I have patched this kind of oversight before elsewhere, not sure if thats the right approach here.

Maybe something like:

if (*Cisco-AVpair =~ /^client-mac-address=(.+)$/) {

i.e. "*" means "any one matches"

Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Alan DeKok wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

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

Alan DeKok wrote:

Joe Maimon wrote:

...

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.

That's a pretty specific need. I suggest Perl for complex programming.

I wanna use unlang! (I could also be convinced to use rlm_policy)

Hmm... much of this work could be relegated to the radius_do_cmp() function. It needs to do:

a) return if condition matches b) continue if it doesn't match

Thats where I have been poking at it.

With some sanity checks to ensure that:

(Foo != bar)

is the same as

!(Foo == bar)

Alan DeKok.

Didnt think of that yet. I am certain there are other complications. I know you can do this better than I can, but I will probably keep trying. Joe