On Thu, Dec 12, 2019 at 02:35:18PM -0800, James Prestwood wrote: > I have 2 tests which each use a FILS APs (one is SHA256, the other > SHA384). The two tests both use the same hostapd instance, and the only > difference between the hostapd config files (besides SHA size) is that > one is configured to use a radius server. The radius server is shared > between the two APs. Could you please clarify what you mean by sharing a RADIUS server between the two APs? If only one of the APs is configured to use a RADIUS server, it does not sound like this could be sharing the server.. Where is the RADIUS server? Does that happen to be running in one of those APs? If so, please note that there are two instances of authentication server running in that AP: one for the RADIUS server and the other one for the local authentication needs. The ERP key cache is not shared between those two instances. > Whichever config file I put the radius config in, that test fails. E.g. > > radius_server_clients=/tmp/certs/radius-clients.text > radius_server_auth_port=1812 This will start two instances of authentication server in the hostapd interface where this is running. > But the other test passes fine. They both use the same user for each > test. The initial EAP connection succeeds (EAP-PWD in this case), but > the FILS connection fails (only for the one test) because it cannot > find the Re-auth identity (e.g. c785ec7b0b8808e9@xxxxxxxxxxx) in the > radius server: > > hostapd_radius_get_eap_user: Failed to find user > RADIUS SRV: User-Name not found from user database > RADIUS SRV: Could not create a new session > RADIUS SRV: Reject invalid request from 127.0.0.1:35888 This would seem to imply that the ERP key cache was created in another instance of the authentication server. For example, if you go through the initial EAP-pwd authentication through the AP that does not use an external RADIUS server, the ERP key gets added in the authentication server instance of that AP, not the RADIUS server that might be also running in the context of that AP. > I know these tests used to work, and confirmed with a git bisect that > this is the offending commit: > > fa1f0751cc259dd76325556b8460864aa408cad9 > > This is a refactor and replaces a lot of code. I am digging through > this but its a bit out of my knowledge of hostapd. I am happy to > explain in greater detail the exact test scenario if required. My initial guess would be that the configuration used here is incorrect and might have worked by accident in the past. You would need to use three hostapd interface instance (all can be within the same process) was this type of test configuration: RADIUS server, AP1 (FILS-SHA256), and AP2 (FILS-SHA384). Both AP1 and AP2 would then need to point to that same RADIUS server instance (auth_server_addr/auth_server_port) for ERP to work properly. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
