Nicolas Baradakis <nbk@sitadelle.com> wrote:
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)
Sure, but we don't want to *force* that, either.
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.
pre-proxy may require User-Name re-writing, which really belongs in the same "function" module for authentication && accounting. Post-proxy is pretty useless for accounting, though.
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.
Sure. We should take a sweep through the modules to double-check their return codes. Alan DeKok.