Re: Cisco-AVpair accounting client-mac-address with unlang
Alan DeKok wrote:
Joe Maimon wrote:
It does make the code a bit more hairy - I have been making a stab at
this and it seems to be quite ugly.
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
With some sanity checks to ensure that:
(Foo != bar)
is the same as
!(Foo == bar)
Alan DeKok.
-
Ok, I have a preliminary patch, targeted at a pre-2.1.8 code base (git
stable 20090923)
480-evaluate-unlang-allvps.dpatch
(attached and pushed to my out of date github fork/branch)
It is indeed fairly ugly. I have not as of yet determined whether to
hang operational hat on it yet.
This patch aims to have the following as true:
(Foo != bar) == !(Foo == bar) (Foo !~ bar) == !(Foo =~ bar)
Which is inline with the patch I currently use operationally.
200-cmp-operators-fix.dpatch
(attached)
I do not believe that this behavior is present unpatched.
I am undecided as to proper behavior for many of the other tests.
Thank you for all your help and feedback.
Joe
#! /bin/sh /usr/share/dpatch/dpatch-run
## 200-cmp-operators-fix.dpatch by j...@sv04
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad radiusd~/src/main/valuepair.c radiusd/src/main/valuepair.c
--- radiusd~/src/main/valuepair.c 2008-07-20 15:35:53.0 -0400
+++ radiusd/src/main/valuepair.c2008-07-20 15:36:07.0 -0400
@@ -155,10 +155,9 @@
compare = regexec(reg, value, REQUEST_MAX_REGEX + 1,
rxmatch, 0);
regfree(reg);
-
- if (compare != 0) return 0;
- return -1;
-
+ /* !~ only succeeds if NO matches are found in reply pair */
+ if (compare == 0) return -1;
+ ret = -1; /*check the rest for no match */
}
#endif
@@ -432,7 +431,12 @@
* Didn't find it. If we were *trying*
* to not find it, then we succeeded.
*/
- if (check_item-operator == T_OP_CMP_FALSE)
+ if (check_item-operator == T_OP_CMP_FALSE ||
+#ifdef HAVE_REGEX_H
+ check_item-operator == T_OP_REG_NE ||
+#endif
+ check_item-operator == T_OP_NE
+ )
continue;
else
return -1;
#! /bin/sh /usr/share/dpatch/dpatch-run
## 470-evaluate-unlang-allvps.dpatch by j...@jmdeb01
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad freeradius-server~/src/main/evaluate.c
freeradius-server/src/main/evaluate.c
--- freeradius-server~/src/main/evaluate.c 2010-01-10 18:16:59.0
-0500
+++ freeradius-server/src/main/evaluate.c 2010-01-10 18:44:25.0
-0500
@@ -302,7 +302,8 @@
FR_TOKEN rt, const char *pright,
int cflags, int modreturn)
{
- int result;
+ int attempts = 0;
+ int result = 0;
int lint, rint;
VALUE_PAIR *vp = NULL;
#ifdef HAVE_REGEX_H
@@ -336,6 +337,32 @@
if (radius_get_vp(request, pleft, vp)) {
VALUE_PAIR myvp;
+restart_cmp:
+ if (attempts) {
+ DICT_ATTR *da;
+
+ switch (token) {
+#ifdef HAVE_REGEX_H
+ case T_OP_REG_NE:
+#endif
+ case T_OP_NE:
+ /* Testing stops at the first negative
match */
+ if (!result)
+ return TRUE;
+ break;
+ default:
+ /* For all other tests, testing stops
at the first positive match */
+ if (result)
+ return TRUE;
+ }
+
+ /* pleft is trampled below, reinitialize it */
+ pleft = vp-name;
+ da = dict_attrbyname(pleft);
+ if (da)
+ vp = pairfind(vp-next, da-attr);
+ }
+
/*
* VP exists, and that's all we're looking for.
*/
@@ -344,6 +371,15 @@
return TRUE;
}
+ /*
+* VP exists and we were looking for non-existence
+*/
+
+
Re: Cisco-AVpair accounting client-mac-address with unlang
Alan DeKok al...@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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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/msg00367.html
bbc -
Alan DeKok wrote:
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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/msg00367.html
bbc -
Alan DeKok wrote:
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
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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
Re: Cisco-AVpair accounting client-mac-address with unlang
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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. 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. Well... yes. 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 doesn't do anything with it. It does make the code a bit more hairy - I have been making a stab at this and it seems to be quite ugly. 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 With some sanity checks to ensure that: (Foo != bar) is the same as !(Foo == bar) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Cisco-AVpair accounting client-mac-address with unlang
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
Re: Cisco-AVpair accounting client-mac-address with unlang
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
Joe Maimon wrote:
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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
Joe Maimon wrote:
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
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Cisco-AVpair accounting client-mac-address with unlang
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
