Version 3.0.10 has been released

[Herwin Weststrate]

On 07-10-15 13:14, Sebastian Hagedorn wrote:
> Hi,
> 
> thanks for the update. I'm currently changing our configuration to adapt
> to the changes in the update - mostly some small syntactic issues where
> we apparently were still using deprecated forms. But there is one part
> I'm not sure about. mods-config/attr_filter/access_reject has these two
> new lines:
> 
>       FreeRADIUS-Response-Delay =* ANY,
>       FreeRADIUS-Response-Delay-USec =* ANY
> 
> When I start radiusd, the following gets logged:
> 
> Oct  7 13:01:44 xxx.rrz.uni-koeln.de radiusd[10038]:
> [/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item
> "FreeRADIUS-Response-Delay"     found in filter list for realm "DEFAULT".
> Oct  7 13:01:44 xxx.rrz.uni-koeln.de radiusd[10038]:
> [/etc/raddb/mods-config/attr_filter/access_reject]:11 Check item
> "FreeRADIUS-Response-Delay-USec"     found in filter list for realm
> "DEFAULT".
> 
> I'm not sure if that is just cosmetic or something I should worry about?

Short version: that warning is harmless. If you want to get rid of it,
just remove the two lines from attr_filter/access_reject, there will be
no behaviour changes.

Longer version: The check you're seeing tries to warn us that we allow
an attribute in the reply-list that we cannot send in an Access-Reject.
The functionality has been added in PR #1216 to allow packet specific
overrides of the reject_delay, so in this case we're not adding the
attribute to send it to the client, but we're adding it to change
something inside FreeRADIUS.

I guess there are two simple options to remove this warning:
- Set those attributes in another list than reply
- Remove the warning from rlm_attr_filter

From
https://github.com/FreeRADIUS/freeradius-server/pull/1216#issuecomment-138924345
it looks like option 2 would be the better idea, as a preparation to
making things more consistent.

-- 
Herwin Weststrate