Hello Heiki,
> On 11 Apr 2019, at 12:39, Heikki Vatiainen <[email protected]> wrote: > > On 11/04/2019 11.06, [email protected] 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 | [email protected] | www.utwente.nl/lisa
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
