Hi, list. I figured out the solution to this issue by simply altering the order of supported EAP types in the AuthBy clause: just putting PEAP in first place in the handler that takes care of our users in radiator configuration file is enough to MacBook use that outer method (instead of TTLS), which behaves correctly when re-authentication occurs - I wasn't aware that High Sierra supplicant negotiates the available protected EAP methods, choosing the first one provided by the radius server - I may say that I discovered it by accident.
The issue here is that for some reason, perhaps too many Challenges exchanged during TTLS(MSCHAPv2) process, caused the re-authentication not to succeed. About security: the first time users connect to eduroam they are prompted to validate the server certificate and it's issuers. At this first step, users are free to accept or reject it - info about Certification Authority chain and server certificate is available in our eduroam support page. Support documentation is being updated to overcome the problem related to server certification validation. Best regards, Amândio _______________________________________________ radiator mailing list radiator@lists.open.com.au http://lists.open.com.au/mailman/listinfo/radiator
