[RADIATOR] Radiator Version 4.23 released - security fixes, new features, enhancements and bug fixes

[l.m.c.haverkotte at utwente.nl]

Hello Heiki,


> On 11 Apr 2019, at 12:39, Heikki Vatiainen <hvn at open.com.au> wrote:
> 
> On 11/04/2019 11.06, l.m.c.haverkotte at utwente.nl wrote:
> 
>> Some nice improvements and fixes. I’ve just installed this version on our test environment and i’m seeing some strange behaviour/errors on a configuration that runs fine with 4.22-2.
> 
>> Thu Apr 11 09:56:37 2019 137963: ERR: Could not handle an EAP request: Can't locate object method "getOriginaluserNameString" via package "Radius::Radius" at /opt/radiator/radiator/Radius/Util.pmline 88.
> 
> This is now fixed. The downloads have 4.23-2 packages with a fix for %W formatter that was causing the problem. It was caused by updates which allow Radiator to run with maximal warnings in which case care needs to be taken to, for example, not to split undefined User-Name to realm part.
> 
> While the function it tried to call had a test, actual %W formatter did not have, but it now has.

I can confirm that this has indeed fixed the problem.

>> Similarly, TTLS-PAP authentication logs the following:
>> Thu Apr 11 10:00:48 2019 916527: DEBUG: Handling with EAP: code 2, 8, 87, 21
>> Thu Apr 11 10:00:48 2019 916961: DEBUG: Response type 21
>> Thu Apr 11 10:00:48 2019 917282: INFO: EAP Response type 21 in unexpected state. NAS did RADIUS server failover for an ongoing EAP authentication?
> 
> This can happen, for example, when a RADIUS client switches to a secondary RADIUS server because of, for example, timeout from the primary. In this case the secondary gets an EAP message that is part of ongoing EAP authentication but it has no means to continue. In other words, it has no state that is needed for the authentication.
> 
> Changes in 4.23 should not have changed EAP handling. Could you try with with 4.23-2 package to see that it's not releated to problems caused by the %W problem.

This issue is also gone in the new release; I reviewed what was actually happening here, and I missed something in the earlier test on 4.23-1: radiator actually crashed related to the %W problem, so the continueing messages of the test client arrived at a newly started radiator instance causing the mismatch.

Thanks for the awesomely fast response and fix!

Kind regards,

Leon Haverkotte | Network engineer | University of Twente | Library, ICT Services & Archive (LISA) / ITO | Campus building Spiegel, room 226 | T: +31 (0)53 - 489 3016 | l.m.c.haverkotte at utwente.nl | www.utwente.nl/lisa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20190411/7d7fcd7e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3518 bytes
Desc: not available
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20190411/7d7fcd7e/attachment.p7s>