Version 3.0.10 has been released
It was delayed (again) for one last issue. The result is a nice clean release, with a whole lot of new tests and features. The full change log is available at: http://freeradius.org/press/index.html#3.0.10 We'd like to thank Matthew Newton, Herwin Weststrate, Christopher Hoskin, Alan Buxey, and and Jorge Pereira for a ton of cleanups and fixes, especially for Debian builds. Input from the community helps "round out" the functionality of FreeRADIUS. Alan DeKok.
On 5 Oct 2015, at 14:52, Alan DeKok <aland@deployingradius.com> wrote:
It was delayed (again) for one last issue. The result is a nice clean release, with a whole lot of new tests and features.
The full change log is available at: http://freeradius.org/press/index.html#3.0.10
We'd like to thank Matthew Newton, Herwin Weststrate, Christopher Hoskin, Alan Buxey, and and Jorge Pereira for a ton of cleanups and fixes, especially for Debian builds. Input from the community helps "round out" the functionality of FreeRADIUS.
Please report any positive or negative changes in supplicant behaviour when running PEAP/MSCHAPv2. Technically FreeRADIUS hasn't been compliant with the MSCHAPv2 RFC 2759 for the past 12 years, as it's been omitting the challenge and message part of some MSCHAP-Error messages. It was also including messages in MSCHAPv1 messages which were not supported. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Oct 5, 2015, at 4:02 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Please report any positive or negative changes in supplicant behaviour when running PEAP/MSCHAPv2. Technically FreeRADIUS hasn't been compliant with the MSCHAPv2 RFC 2759 for the past 12 years, as it's been omitting the challenge and message part of some MSCHAP-Error messages.
Yes. The changes work in our tests, but we don't have access to the hundreds of versions of supplicants that are "out there" in the wild. This change was considered relevant enough that it should go into 3.0.10, and it *shouldn't* affect compliant software. Alan DeKok.
Alan DeKok wrote:
It was delayed (again) for one last issue. The result is a nice clean release, with a whole lot of new tests and features.
The full change log is available at: http://freeradius.org/press/index.html#3.0.10
FWIW: People looking for an urgent FreeRADIUS update for openSUSE can use the Factory packages built for various platforms (or branch in OBS for your own customization and platform choice). https://build.opensuse.org/package/show/network/freeradius-server I've successfully tested EAP-TTLS/PAP with LDAP backend. Ciao, Michael.
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? --On 5. Oktober 2015 14:52:34 -0400 Alan DeKok <aland@deployingradius.com> wrote:
It was delayed (again) for one last issue. The result is a nice clean release, with a whole lot of new tests and features.
The full change log is available at: http://freeradius.org/press/index.html#3.0.10
-- .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
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-13892... it looks like option 2 would be the better idea, as a preparation to making things more consistent. -- Herwin Weststrate
--On 7. Oktober 2015 13:34:29 +0200 Herwin Weststrate <herwin@quarantainenet.nl> wrote:
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-13 8924345 it looks like option 2 would be the better idea, as a preparation to making things more consistent.
Thanks for the fast reply. Now that I know the messages are harmless, I will just ignore them. -- .:.Sebastian Hagedorn - Weyertal 121 (Gebäude 133), Zimmer 2.02.:. .:.Regionales Rechenzentrum (RRZK).:. .:.Universität zu Köln / Cologne University - ✆ +49-221-470-89578.:.
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Herwin Weststrate -
Michael Ströder -
Sebastian Hagedorn