Proxy when module_accounting rejects the request

[Nicolas Baradakis]

Alan DeKok wrote:

>   If "preacct" says that the request should be proxied, we probably
> shouldn't even run "accounting" at all.

I think there are some cases when there is a need to do both logging
and proxying. (for example if the server and the proxy belong to
different ISP)

In those cases logging could be done in pre-proxy section instead of
accounting, but currently not all the modules have a method for both
accounting and pre-proxy. (for example rlm_sql can do accounting only)

I've never understood why we have pre-proxy and post-proxy for
accounting requests. As it is now, everything done in pre-proxy can
be done in accounting, too. And post-proxy is meaningless since
Accounting-Response packets are empty.

>   That will let people log local accounting data only for
> requests that are handled locally.

For now that can be achieved using Acct-Type stanzas.

>   That sounds reasonable, except for FAIL.  If we fail to log
> accounting data, it's even more useful to proxy it.

I understand your reasons. The logs of the proxy may be incoherent,
but that's probably better than to have nothing at all.

>   And most of those return codes don't make sense for accounting
> requests.  Since accounting just does logging, the return codes should
> be:
>
>   FAIL, OK, HANDLED, INVALID, NOOP.

I agree. It should be the same for preacct modules, too.

>   REJECT doesn't make sense.  USERLOCK doesn't make sense, and I'm not
> sure what UPDATED means.

Comments in modules.h says UPDATED is "OK (pairs modified)".

However if a module returns REJECT or USERLOCK, it just means the
module is seriously broken. It's unclear whether the packet should be
proxied in this case. If something that shouldn't happen actually
happens, I would vote to drop the packet.

-- 
Nicolas Baradakis