Update Reply returns noop

Alan DeKok aland at deployingradius.com
Mon Jul 25 21:58:51 CEST 2016

On Jul 25, 2016, at 3:34 PM, Anastasios Gryponisiotis <plant7 at gmail.com> wrote:
> I will probably create my own dictionary with custom made attributes for
> these, thank you. There are multiple ifs to give me more control, and each
> of the contains a "else" to reject all that does not match.

  I suspect you mean:

	if (A) {
	else {

	if (B) {
	else {

  Which is NOT what Matthew and I suggested, and will NOT work.

> With all these responses however, we still have not adressed the fact that
> the update reply in my first "if" returns noop and therefore does not stop
> processing right then and there.

  What led you to believe that an "update" section will cause the server to stop processing a section?

  Please point to documentation which says that's what happens.

  The problem here is that you *think* you know how the server works.  But the server doesn't work that way.  As a result, you're confused as to why the server isn't doing what you expect.

  Well... it behaves the way it's documented to behave.  Read the documentation, and fix your mental model of how the server works.

> Am I wrong to assume that since the reply
> is acted upon it should not return noop?

  That assumption is wrong.  I've been trying to convince you of that for a while now.

  Why is to so hard to trust the experts? 

> This is what all my other if/else
> conditionals are already doing.

  No, they're not.

  Read the debug output again.  The "update" section are transparent to module return codes.  i.e. if the module before the "update" section returned "foo", the update section will also return "foo".

  The only caveat is that a module returning "reject" will always cause the server to immediately stop processing the section.  Which means that any subsequent "update" section won't get run.

> Instead I get a reject from a "else"
> further down the conditionals.

  Because as I've said before... you can't use the module return codes for control flow.  Use the "if" sections for that.

  Go read the FreeRADIUS technical guide located at http://networkradius.com/freeradius-documentation/

  It describes in great detail how the server processes "authorize", etc.

  And believe Matthew and me when we tell you that your control flow of "if" statements is wrong.  You can keep arguing and not fixing the problem, or you can implement our suggestion (which was largely identical), and fix the problem.

  Alan DeKok.

More information about the Freeradius-Users mailing list