warning? about attr_filter for default Debian configs

[Users mailing list]

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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok-2]

On Dec 10, 2020, at 1:58 PM, Matt Zagrabelny via Freeradius-Users <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Users mailing list]

Hey Alan,

Thanks for the prompt reply (as always!)

On Thu, Dec 10, 2020 at 1:01 PM Alan DeKok <[hidden email]>
wrote:

> On Dec 10, 2020, at 1:58 PM, Matt Zagrabelny via Freeradius-Users <
> [hidden email]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Alan DeKok-2]

On Dec 10, 2020, at 2:51 PM, Matt Zagrabelny via Freeradius-Users <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Users mailing list]

On Thu, Dec 10, 2020 at 1:59 PM Alan DeKok <[hidden email]>
wrote:

> On Dec 10, 2020, at 2:51 PM, Matt Zagrabelny via Freeradius-Users <
> [hidden email]> 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Brian Julin]

Matt Zagrabelny via Freeradius-Users <[hidden email]> 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.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

[Users mailing list]

On Thu, 10 Dec 2020 at 20:42, Brian Julin <[hidden email]> wrote:

> Matt Zagrabelny via Freeradius-Users <[hidden email]> 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 <[hidden email]>
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.
...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html