No, this is our eduroam server - it's a single server. Our other servers started doing this as well at about the same time (it's only a .0035% failure rate with this error) with over 2,000,000 successful attempts a day (so only a few 10s of these) - so yes we thought it was a load-balancing problem at first but that's ruled out with eduroam running on only one server. It does not make use of any load-balancing device.
While this might be true: "..then the trusted AP would force the end user to start authentication from the scratch" That user's device is still going to send that UDP packet to the new AP and end up on our server no? Also, it doesn't have to be a rogue AP does it, it could be someone else's legitimate AP that just happens to be near one of our APs. --- Roberto Ullfig - [email protected] Systems Administrator Enterprise Architecture and Development | ACCC University of Illinois - Chicago ________________________________ From: radiator <[email protected]> on behalf of Heikki Vatiainen <[email protected]> Sent: Wednesday, September 4, 2019 4:52 AM To: [email protected] <[email protected]> Subject: Re: [RADIATOR] EAP Response type 25, but no expected type known - Rogue Access Point? On 03/09/2019 23.03, Ullfig, Roberto Alfredo wrote: > If a rogue access point existed and a user walks within range of both a > legitimate and rogue AP while authenticating - could the EAP packets be > distributed between the two systems possibly resulting in: > > EAP Response type 25, but no expected type known > > on the legitimate server? Before going into possible reasons, I'll quickly summarise what this message means. This message is logged when a PEAP (type 25) message from a RADIUS client is received, but Radiator couldn't find a currently ongoing EAP authentication this response (message from client) belongs to. In short: unexpected PEAP message from client was received. One reason this could happen is when a RADIUS client has multiple RADIUS servers configured and it decides for some reason to switch to another server. It might be that the client's retransmission and failover settings triggered a switch to another server when there was a problem in the network and messages were dropped. These problems then led the client to think its currently active RADIUS server was having problems. I'd think that if the end user was communicating with a rogue AP first and then switching to a trusted AP, then the trusted AP would force the end user to start authentication from the scratch. This would mean sending EAP-Response/Identity, not continuing with EAP-Response/PEAP. I would first check if there's a possibility that a non-rogue AP or controller was doing a switch to a different RADIUS server. If not, I'd then take a look at the possible other causes. Thanks, Heikki -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory, EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc. _______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
_______________________________________________ radiator mailing list [email protected] https://lists.open.com.au/mailman/listinfo/radiator
