On Thu, 10 Dec 2020 at 20:42, Brian Julin <BJulin@clarku.edu> wrote:
Matt Zagrabelny via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Thanks again for the dialog - it really does help me (us) understand the software better.
In way of explanation, I'm going to go out on a limb and make an educated guess that there's a generic mechanism warning about the use of internally used attributes in the filter module, as those attributes have no representation on the wire, and that there turned out to be a use case for internally handling Access-Reject packets (it would seem these are timing parameters, so something to do with DoS/flood protection or a keepalive mechanism.) This ended up passing these attributes through the attribute filter module, so they were exempted as a quick fix rather than specially handling the internally handled packets.
This hasn't affected the official packages for some time: $ git log raddb/mods-config/attr_filter/access_reject commit 76e8c12fb728a3634cebeb56d36cf26f5ebf4951 Author: Matthew Newton <matthew-git@newtoncomputing.co.uk> Date: Mon Nov 12 18:11:30 2018 +0000 attr_filter: Don't permit FreeRADIUS-Response-Delay in reject No-op, but they're internal attributes so can't go in a reply anyway, and cause a warning at every server start. ...