Issue with EAP authentication on packet loss

[jm+freeradiususer at roth.lu]

On 4/25/2018 12:39 PM, Arran Cudbard-Bell wrote:
>
>> On Apr 25, 2018, at 8:45 PM, Stefan Winter <stefan.winter at RESTENA.LU> wrote:
>>
>> Hi,
>>
>>> We have a problem when packet loss occurs at step #4 of the EAP dialogue:
>>> 1) Access-Request
>>> 2) Access-Challenge
>>> 3) Access-Request
>>> 4) Accept or Reject (in this case: Access-Accept)
>>> 5) Access-Request (duplicate)
>>> 6) Reject
>>>
>>> In this case, #4 is sent by the server but gets lost on its way to the
>>> NAS. I've managed to reproduce using iptables dropping the packet. So
>>> after some time the NAS sends packet #3 again. At that point I am
>>> getting "No EAP session matching state" from the eap module in the
>>> "authenticate" section and the request is rejected.
>> To be fair, this is not limited to packet loss.
>>
>> We've seen this in normal operations - the story goes like:
>> - server sends Access-Accept with an attribute X via a chain of proxies
>> - some proxy takes offence by the presence of attribute X, discards
>> - client times out and re-sends
>> - server has forgotten all about the session state, rejects
>>
>> I believe the underlying issue is that FreeRADIUS thinks "fire and
>> forget" when the final packet is out.
> It should cache the response for the duration of cleanup_delay.  If it's not, then that's a bug.
>
> -Arran

Unfortunately, that doesn't seem to be the case.

Final packet sent to the NAS (which is lost):
(5) eap: Expiring EAP session with state 0x88491844885a1c9c
(5) eap: Finished EAP session with state 0x88491844885a1c9c
(5) eap: Previous EAP request found for state 0x88491844885a1c9c, 
released from the list

NAS retries after 15 < cleanup_delay = 20 seconds: No success: (even 
Wireshark detects it as a duplicate, so I guess it is actually a 
repetition of the initial packet)
(6) eap: ERROR: rlm_eap (EAP): No EAP session matching state 
0x88491844885a1c9c
(6) eap: Either EAP-request timed out OR EAP-response to an unknown 
EAP-request
(6) eap: Failed in handler

 From the mails that Alan posted this seems to be slightly more complicated.