I understand that, so let me write it more clearly:
1. the 'reject' state is being set at the beginning
No. It definitely doesn't do that.
Here's the code: int modcall(int component, modcallable *c, REQUEST *request) { int myresult; ... myresult = stack.result[0] = default_component_results[component]; But to be 100% precise: the way I configured it, I'm calling pap {..} before testing_module, and so pap is also setting reject. But if I comment this out: authenticate { # # PAP authentication, when a back-end database listed # in the 'authorize' section supplies a password. The # password can be clear-text, or encrypted. Auth-Type PAP { #pap { # ok = return # reject = 1 #} testing_module } then what I said was correct (reject is being set up-front when modcall is first entered)
2. the 'update' module returns 'updated' but this is discarded, hence the return code remains at 'reject'
"updated" is a lower priority than "reject". See doc/configurable_failover. It's obscure, but useful.
That's correct but irrelevant. Here is the code again: if (child->type == MOD_UPDATE) { int rcode; modgroup *g = mod_callabletogroup(child); rcode = radius_update_attrlist(request, g->cs, g->vps, child->name); if (rcode != RLM_MODULE_UPDATED) { myresult = rcode; That is: after a MOD_UPDATE, a return value of RLM_MODULE_UPDATED is *explicitly* discarded. It's nothing to do with the relative priorities of updated and reject.
As always, patches are welcome for suggested behavior.
I am happy to do so, I was just trying to understand if there was any reasoning behind the current behaviour. In particular: (1) why is a return of RLM_MODULE_UPDATED from MOD_UPDATE being discarded? (src/main/modcall.c line 468) (2) why does RLM_COMPONENT_AUTH use the RLM_COMPONENT_AUTZ actions table? (modcall.c line 1950 and 2131) (3) why does an update {} section not set any actions? (modcall.c, do_compile_update, doesn't copy actions) (3) may be an oversight, but (1) and (2) are explicitly coded that way, so there may be some reason for them which I can't see. I guess I can patch it to change it, and see what breaks :-) Regards, Brian.