On Mon, Dec 30, 2019 at 09:42:56AM -0800, James Prestwood wrote: > Thanks, creating a standalone radius server fixed it. I will leave my > test in this configuration, but I am still curious if the broken test > was just a configuration issue after hostapd refactored the radius > server code, or if its an actual bug. You should be able to have a > radius server in one of the AP instances and have the other AP use that > server right? Either way thanks for the help. It is not really a bug, i.e., this was really working just by accident before. The way the authentication server functionality is implemented in hostapd does not currently allow the RADIUS server and AP/EAPOL authenticator functions to share the same state. In other words, if you configure one hostapd interface to act as a server (eap_server=1) you'll get a separate authentication server instance from the one that the RADIUS server on that same hostapd interface uses. There is no way of directing the AP side of that interface to use an "external" RADIUS authentication server since that eap_server=1 makes it handle EAP authentication internally. In theory, this could be modified to make those two different authentication server users share a single instance, but I'm not convinced the extra complexity needed for that is really justified when the same outcome can be achieved by running a separate hostapd interface instance (even if that were to be running within the same hostapd process). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
