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@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@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@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html