regexp matches are sensitive to position in check items
Basically, this works in "hints": DEFAULT NAS-Port-Id =~ "(.+):(.+)", NAS-Port !* ANY NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes ...but this does not: DEFAULT NAS-Port !* ANY, NAS-Port-Id =~ "(.+):(.+)" NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes ...as %{1} and %{2} are undefined in the latter case. I would have expected this to be the opposite case if anything. Is this expected? In 2.0 I would use an "if" unlang, but this is on our (soon to be upgraded) production servers.
Quoting Phil Mayers:
Basically, this works in "hints":
DEFAULT NAS-Port-Id =~ "(.+):(.+)", NAS-Port !* ANY NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes
...but this does not:
DEFAULT NAS-Port !* ANY, NAS-Port-Id =~ "(.+):(.+)" NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes
...as %{1} and %{2} are undefined in the latter case. I would have expected this to be the opposite case if anything. Is this expected?
I just stumbled over the same, but with huntgroups. Both use paircmp(), so they have the same problem: a positive "!*" (T_OP_CMP_FALSE) condition short-cuts the whole line, so the remaining comparisons are not done. In your case, the regex is not done then, so %{*} are not defined. This is caused by an apparent bug in src/main/valuepair.c. Line 287 should say "continue;" instead of "return 0;". Oh, and to save some processor time, the same logic there (only inverted ) could be used for the "=*" (T_OP_CMP_TRUE) operator. I'll be happy to provide a patch, I just don't know if Alan will release any further 1.1.x version.
In 2.0 I would use an "if" unlang, but this is on our (soon to be upgraded) production servers.
Hope we can do this here soon, too.
Jakob Hirsch wrote:
Quoting Phil Mayers:
Basically, this works in "hints":
DEFAULT NAS-Port-Id =~ "(.+):(.+)", NAS-Port !* ANY NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes
...but this does not:
DEFAULT NAS-Port !* ANY, NAS-Port-Id =~ "(.+):(.+)" NAS-Port = `%{expr:1000*%{1} + %{2}}`, Fall-Through = Yes
...as %{1} and %{2} are undefined in the latter case. I would have expected this to be the opposite case if anything. Is this expected?
I just stumbled over the same, but with huntgroups. Both use paircmp(), so they have the same problem: a positive "!*" (T_OP_CMP_FALSE) condition short-cuts the whole line, so the remaining comparisons are not done. In your case, the regex is not done then, so %{*} are not defined.
Ah, yes of course.
This is caused by an apparent bug in src/main/valuepair.c. Line 287 should say "continue;" instead of "return 0;".
Oh, and to save some processor time, the same logic there (only inverted ) could be used for the "=*" (T_OP_CMP_TRUE) operator.
I'll be happy to provide a patch, I just don't know if Alan will release any further 1.1.x version.
Does the same bug not exist in 2.0?
In 2.0 I would use an "if" unlang, but this is on our (soon to be upgraded) production servers.
Hope we can do this here soon, too.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Phil Mayers wrote:
This is caused by an apparent bug in src/main/valuepair.c. Line 287 should say "continue;" instead of "return 0;". ... I'll be happy to provide a patch, I just don't know if Alan will release any further 1.1.x version. Does the same bug not exist in 2.0?
I think not. I took a quick look, and the line I mentioned has just the fix I proposed.
participants (2)
-
Jakob Hirsch -
Phil Mayers