[RADIATOR] EAP Response type 25, but no expected type known - Rogue Access Point?

Ullfig, Roberto Alfredo rullfig at uic.edu
Tue Sep 10 17:58:05 UTC 2019


Have some new information now. These errors seems to have gone away on their own on our load-balanced service; however, the five eduroam (non-load balanced service) errors over the past few weeks are all for umn.edu logins so it's highly likely that this is a problem with the umn.edu eduroam server. We have users from many organizations using eduroam and only that org's logins are failing occasionally.

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Architecture and Development | ACCC
University of Illinois - Chicago
________________________________
From: Heikki Vatiainen <hvn at open.com.au>
Sent: Tuesday, September 10, 2019 11:41 AM
To: Ullfig, Roberto Alfredo <rullfig at uic.edu>; radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: [RADIATOR] EAP Response type 25, but no expected type known - Rogue Access Point?

On 04/09/2019 16.06, Ullfig, Roberto Alfredo wrote:

> "Outside Interference From Nearby WiFi Networks Negatively Impacts Yours
> The signal from nearby wireless networks and access points can impact
> performance on your network. Access points on the same channel can
> affect your network performance and cause dropped connections or lost
> packets while using the internet."

There's one idea you could try based on the quote of the above article:
Add on top level Radiator configuration this flag:

EAP_UseState

In case the client gets handled by another AP/controller during the
authentication and this causes the RADIUS message attributes to change,
this could cause problems keeping track of current authentications.

The above flag changes the tracking to use State attribute which could
help. If you use AuthBy EAPBALANCE, see the reference manual, because
it's likely to cause compatibility problems:

https://open.com.au/radiator/ref/EAP_UseState_Global.html

This option has been available for a while now and it seems to be
working fine. It's likely something that could be a default in the
future releases.

Thanks,
Heikki

--
Heikki Vatiainen <hvn at open.com.au>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20190910/2e102a7a/attachment.html>


More information about the radiator mailing list