warning? about attr_filter for default Debian configs
Greetings FR-users, On a default debian install of freeradius there is some yellow text when running the server in debug (-X) mode: [...] reading pairlist file /etc/freeradius/3.0/mods-config/attr_filter/post-proxy # Instantiating module "attr_filter.pre-proxy" from file /etc/freeradius/3.0/mods-enabled/attr_filter reading pairlist file /etc/freeradius/3.0/mods-config/attr_filter/pre-proxy # Instantiating module "attr_filter.access_reject" from file /etc/freeradius/3.0/mods-enabled/attr_filter reading pairlist file /etc/freeradius/3.0/mods-config/attr_filter/access_reject [/etc/freeradius/3.0/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay" found in filter list for realm "DEFAULT". [/etc/freeradius/3.0/mods-config/attr_filter/access_reject]:11 Check item "FreeRADIUS-Response-Delay-USec" found in filter list for realm "DEFAULT". [...] The last two lines which reference line 11 are yellow. Here is the contents of access_reject: $ sudo cat -n /etc/freeradius/3.0/mods-config/attr_filter/access_reject 1 # 2 # Configuration file for the rlm_attr_filter module. 3 # Please see rlm_attr_filter(5) manpage for more information. 4 # 5 # $Id: afd89473dc50e4ff62389e35e5cb73b512e9d352 $ 6 # 7 # This configuration file is used to remove almost all of the attributes 8 # From an Access-Reject message. The RFCs say that an Access-Reject 9 # packet can contain only a few attributes. We enforce that here. 10 # 11 DEFAULT 12 EAP-Message =* ANY, 13 State =* ANY, 14 Message-Authenticator =* ANY, 15 Error-Cause =* ANY, 16 Reply-Message =* ANY, 17 MS-CHAP-Error =* ANY, 18 Proxy-State =* ANY, 19 FreeRADIUS-Response-Delay =* ANY, 20 FreeRADIUS-Response-Delay-USec =* ANY I'm afraid I don't know what to modify to eliminate the warning. Any suggestions? Thank you! -m
On Dec 10, 2020, at 1:58 PM, Matt Zagrabelny via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
On a default debian install of freeradius there is some yellow text when running the server in debug (-X) mode:
It's a warning, not an error.
Here is the contents of access_reject:
Really? I have _never_ understood the idea behind posting default configuration files to the list. It's not like we're unaware of the contents.
I'm afraid I don't know what to modify to eliminate the warning.
Any suggestions?
Warnings are not errors. Ignore them. Alan DeKok.
Hey Alan, Thanks for the prompt reply (as always!) On Thu, Dec 10, 2020 at 1:01 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 10, 2020, at 1:58 PM, Matt Zagrabelny via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
On a default debian install of freeradius there is some yellow text when running the server in debug (-X) mode:
It's a warning, not an error.
Agreed. I am just trying to eliminate warnings as that seems like a sensible policy for one's life.
Here is the contents of access_reject:
Really?
I have _never_ understood the idea behind posting default configuration files to the list. It's not like we're unaware of the contents.
Wasn't sure if the deb package had different contents from what gets shipped in the source tarball. Sorry about the noise. I'll check next time.
I'm afraid I don't know what to modify to eliminate the warning.
Any suggestions?
Warnings are not errors. Ignore them.
I'm okay with ignoring warnings. But warnings in default config files seems a little curious. Cheers, -m
On Dec 10, 2020, at 2:51 PM, Matt Zagrabelny via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I'm okay with ignoring warnings. But warnings in default config files seems a little curious.
We're happy to take patches to fix it. :) The short answer is that there's only so much time in a day. Serious issues get fixed. Smaller ones get put off. Alan DeKok.
On Thu, Dec 10, 2020 at 1:59 PM Alan DeKok <aland@deployingradius.com> wrote:
On Dec 10, 2020, at 2:51 PM, Matt Zagrabelny via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
I'm okay with ignoring warnings. But warnings in default config files seems a little curious.
We're happy to take patches to fix it. :)
Maybe I'll buy us both a beer to help us forget and ignore it.
The short answer is that there's only so much time in a day.
Stop taking time to help noobs - like me! Thanks again for the dialog - it really does help me (us) understand the software better. Best, -m
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.
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. ...
participants (4)
-
Alan DeKok -
Brian Julin -
Matt Zagrabelny -
Terry Burton