<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
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.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
While this might be true:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
"..<span>then the trusted AP would force the </span><span>end user to start authentication from the scratch"</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span><br>
</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<span>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.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id="Signature">
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<div style="font-family:Tahoma; font-size:13px">---
<div><span id="ms-rterangepaste-start"></span><span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Roberto Ullfig - rullfig@uic.edu</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Systems Administrator</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">Enterprise Architecture and Development | ACCC</span><br style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">
<span style="font-family:arial,helvetica,sans-serif; font-size:13px; line-height:16.003px">University of Illinois - Chicago</span>
<div><span id="ms-rterangepaste-end"></span></div>
</div>
</div>
</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> radiator <radiator-bounces@lists.open.com.au> on behalf of Heikki Vatiainen <hvn@open.com.au><br>
<b>Sent:</b> Wednesday, September 4, 2019 4:52 AM<br>
<b>To:</b> radiator@lists.open.com.au <radiator@lists.open.com.au><br>
<b>Subject:</b> Re: [RADIATOR] EAP Response type 25, but no expected type known - Rogue Access Point?</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 03/09/2019 23.03, Ullfig, Roberto Alfredo wrote:<br>
> If a rogue access point existed and a user walks within range of both a <br>
> legitimate and rogue AP while authenticating - could the EAP packets be <br>
> distributed between the two systems possibly resulting in:<br>
> <br>
> EAP Response type 25, but no expected type known<br>
> <br>
> on the legitimate server?<br>
<br>
Before going into possible reasons, I'll quickly summarise what this <br>
message means. This message is logged when a PEAP (type 25) message from <br>
a RADIUS client is received, but Radiator couldn't find a currently <br>
ongoing EAP authentication this response (message from client) belongs <br>
to. In short: unexpected PEAP message from client was received.<br>
<br>
One reason this could happen is when a RADIUS client has multiple RADIUS <br>
servers configured and it decides for some reason to switch to another <br>
server. It might be that the client's retransmission and failover <br>
settings triggered a switch to another server when there was a problem <br>
in the network and messages were dropped. These problems then led the <br>
client to think its currently active RADIUS server was having problems.<br>
<br>
I'd think that if the end user was communicating with a rogue AP first <br>
and then switching to a trusted AP, then the trusted AP would force the <br>
end user to start authentication from the scratch. This would mean <br>
sending EAP-Response/Identity, not continuing with EAP-Response/PEAP.<br>
<br>
I would first check if there's a possibility that a non-rogue AP or <br>
controller was doing a switch to a different RADIUS server. If not, I'd <br>
then take a look at the possible other causes.<br>
<br>
Thanks,<br>
Heikki<br>
<br>
-- <br>
Heikki Vatiainen <hvn@open.com.au><br>
<br>
Radiator: the most portable, flexible and configurable RADIUS server<br>
anywhere. SQL, proxy, DBM, files, LDAP, TACACS+, PAM, Active Directory,<br>
EAP, TLS, TTLS, PEAP, WiMAX, RSA, Vasco, Yubikey, HOTP, TOTP,<br>
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, etc.<br>
_______________________________________________<br>
radiator mailing list<br>
radiator@lists.open.com.au<br>
<a href="https://lists.open.com.au/mailman/listinfo/radiator">https://lists.open.com.au/mailman/listinfo/radiator</a><br>
</div>
</span></font></div>
</body>
</html>