Freeradius Google Secure LDAP EAP-GTC issues

[Henning Kessler]

Hello,

Another detail in this issue: The problem only starts to take place if you have more then one Radius server configured in the Unifi-Controller.

> Am 06.02.2023 um 14:02 schrieb Henning Kessler <maillist at henningkessler.de>:
> 
> Hi Alan,
> 
> I just want to confirm you advice. I have now tested my setup with a TP-LINK AP (EAP650) and it works flawlessly. 
> 
> Regards
> 
> Henning
> 
>> Am 23.01.2023 um 16:34 schrieb Alan DeKok <aland at deployingradius.com>:
>> 
>> On Jan 23, 2023, at 9:38 AM, Henning Kessler <maillist at henningkessler.de> wrote:
>>> I followed this tutorial  (https://www.nasirhafeez.com/wp-comments-post.php) for testing purposes several times and it worked flawlessly. several month later I wanted to put it in production and it stop working.
>> 
>> There's nothing at that site.
>> 
>> But if it suddenly stops working and you haven't changed the server, the problem is an external system,
>> 
>>> This is my setup: 2 Raspberry PIs with freeradius 3.0.12 (allready tried the Backport version 3.2.1 as well) Unifi AC HD AccessPoints and as clients macOS and iOS devices (tried macOS versions 11.7 to 13.1) for testing I tried an Ubuntu client as well.
>> 
>> You shouldn't be running 3.0.12.  It's very old.
>> 
>>> Binding to Google LDAP works without any issues (radtest results in Access-Accept) I even see  that the Radius server sends an “Access-Accept” to the clients but shortly after the client starts another Access-Request an that fails with:
>>> 
>>> (9) eap: ERROR: rlm_eap (EAP): No EAP session matching state 0x864de94f8144fc95
>>> (9) eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request
>>> (9) eap: Failed in handler
>>> 
>>> Any idea what is happening here?
>> 
>> The error message above is technical, but it describes the problem accurately.
>> 
>> EAP involves many packet exchanges between the end user system and FreeRADIUS.  Those packets are tracked, and both systems have to finish the packet exchange.  If something goes wrong, the packets are dropped, or come too late.  Then the above message is printed.
>> 
>>> Here the full output of a test with freeradius -X
>> 
>> This shows request 7 getting a reply with a particular State attribute.  Then that state is sent in request 8, as is supposed to happen.  That request gets an Access-Accept reply.
>> 
>> Instead of using the Access-Accept, something retransmits request 7 twice, which shows up as request 9 and request 10.  That shouldn't happen.
>> 
>>> Any Idea what I am doing wrong here?
>> 
>> Nothing.
>> 
>> Something other than FreeRADIUS is broken.  The AP should believe the Access-Accept in request 8, and let the user on the network.  It shouldn't retransmit packet 7 over and over again.
>> 
>> I don't think there's anything you can do to FreeRADIUS which will help.  Maybe try a different AP.
>> 
>> Alan DeKok.
>> 
>> -
>> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>