On Jan 14, 2021, at 3:58 PM, Dan M <dan.red.beard@gmail.com> wrote:
[DTM] Well, clear to YOU. You're intimate with the product.
So... where do we have to put the documentation where people will read it? The default config says: # # Access-Reject packets are sent through the REJECT sub-section of the # post-auth section. # Which seems clear If you read the debug output, you'll see that Access-Accepts are run through the "post-auth" section. And Access-Rejects are sent through the above section. That's it. 5 minutes of testing, and you'll see exactly what it does. The general frustration here is that there's a *ton* of documentation, comments, and examples. Instead of making things clearer for people, it seems to make things worse somehow.
We don't have to carry this on further but I respectfully point out for consideration in other/future comments Since there is no section: Post-Auth-Type ACCEPT I expected (and I don't think I would be alone) that the surrounding post-auth section was *always* performed and that the type section was additional. Especially since the distribution has reply_log in the bigger section but not in the Post-Auth-Type section. Maybe there's a reason not to log rejects that isn't obvious to someone just getting into this.
I think this is happens with the comments: sometimes they're clear but sometimes they only provide a hint at a possibility. e.g. the comment # Access-Reject packets are sent through the REJECT sub-section of the # post-auth section. is missing the keyword ONLY which would be clear.
If ONLY there was some kind of debug output you could read, to see what the server was doing. This isn't difficult. If the document says "if does X", then it does X. It doesn't mean that it randomly does Y, or Z, or maybe Q. Maybe the Access-Reject packets are *also* sent through the "accounting" section. After all, the documentation doesn't say that _doesn't_ happen. Should we fix that, too?
Granted it doesn't say "also sent" so perhaps you see the ambiguity.
No. There's an infinite number of things which *might* be possible. It is unreasonable to document them all. Instead, we document what the server does, and then leave the reader to make the logical conclusion Alan DeKok.