Update Reply returns noop

[Anastasios Gryponisiotis]

Matthew thank you very much for this response. This clarifies some
misconceptions I had in regards to the noop return.

I will use my own attributes to achieve this, along with some if/else
statements and should get the result needed.

On Tue, Jul 26, 2016 at 12:22 PM Matthew Newton <mcn4 at leicester.ac.uk>
wrote:

> On Mon, Jul 25, 2016 at 08:47:21PM +0000, Anastasios Gryponisiotis wrote:
> > Please appreciate that I need to understand what needs to be done, not
> > mindlessly read documentation and change logic without knowing why/what
> I'm
>
> But reading documentation helps you understand how things work :(
>
> > For the record, Mathew did not suggest doing a if/elseif/else tree. He
> > actually said that it would be too complicated to troubleshoot.
>
> I didn't say *don't* do an if/elsif/else tree. Just that trying to
> get the whole logic of that in one tree with rejects in the right
> places can be too hard to do sometimes. Hence breaking it up into
> smaller ifs, and setting other attributes to control whether you
> reject or not at the end.
>
> > My question all along is why an update reply statement returns noop
> > although it is performing a change. I get this:
> >
> > ++++[reply] returns noop
>
> if() statements are not modules, so do not set module return
> codes by themselves. Which is why you see "noop". You might see a
> different result if the contents of the if returned something
> different, as the if() will pass the contained module return
> code back up.
>
> In this case, "update" pretty much *always* returns code "noop",
> which is why the if() also returns noop.
>
> If you want to explicitly reject, you need to call a module that
> sets the return code to "reject". Conveniently, the "reject"
> module does this for you.
>
> > I have read the documentation, which says that noop means "the module did
> > nothing". Isn't updating the reply something?
>
> There was no module. if() isn't a module, it's an unlang
> statement. update{} updates the attribute lists (request, control,
> or reply), and is also an unlang statement.
>
> Modules set the return code, most unlang statements do not. At the
> end of each section (authorize, post-auth, etc) the module return
> code with the highest priority is used to determine which type of
> RADIUS packet (Accept, Reject) to send back - not the attributes
> that have been set (with update{} or otherwise). The attributes
> from the reply list are put *in* the packet, but don't set the
> *type* of the packet.
>
> If you want to reject at some point, then call "reject".
>
> As I said before, it looks like you've got some pretty complex
> logic, so breaking that down to simpler stages, and using
> meaningful attribute names, can make things much easier to follow
> in your config.
>
> Then put a short section at the end which explicitly does a
> "reject" if required.
>
> Matthew
>
>
> --
> Matthew Newton, Ph.D. <mcn4 at leicester.ac.uk>
>
> Systems Specialist, Infrastructure Services,
> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>
> For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html